unsupported track type: *mpegts.Track

[ingalls]

Which version are you using?

v1.11.0

Which operating system are you using?

Linux amd64 standard

Describe how to replicate the issue

1. start the server with the following path:

paths:
  test:
    source: "https://publicstreamer2.cotrip.org:443/rtplive/070E11870CAM1RP1/playlist.m3u8"


2. Ensure the upstream source is workign

ffplay 'https://publicstreamer2.cotrip.org:443/rtplive/070E11870CAM1RP1/playlist.m3u8

3. Attempt to stream via MediaMTX Proxy

ffplay 'http://localhost:8888/test/index.m3u8'

Server logs

2025/01/08 16:35:59 INF MediaMTX v1.11.0
2025/01/08 16:35:59 INF configuration loaded from /home/state/Downloads/mediamtx.yml.bk
2025/01/08 16:35:59 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2025/01/08 16:35:59 INF [path test] [HLS source] started
2025/01/08 16:35:59 INF [RTMP] listener opened on :1935
2025/01/08 16:35:59 INF [HLS] listener opened on :8888
2025/01/08 16:35:59 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2025/01/08 16:35:59 INF [SRT] listener opened on :8890 (UDP)
2025/01/08 16:35:59 ERR [path test] [HLS source] unsupported track type: *mpegts.Track
2025/01/08 16:36:04 ERR [path test] [HLS source] unsupported track type: *mpegts.Track

Network dump

No response

[ingalls]

It appears as though this section of the GO HLS Library is the root cause:

https://github.com/bluenviron/gohlslib/blob/e9dce86b68717db4435855adaa2332569632e3ab/client_stream_processor_mpegts.go#L153-L15

Not being super familiar with the architecture of the library, is it possible to pass through valid tracks and ignore invalid ones? Based on my read of the above code a single track that ideally would be ignored will cause the HLS reader to fail.

[ingalls]

This will be closed if/when bluenviron/gohlslib#211 is accepted and merged

[aler9]

Hello, as you already saw, in one of my previous commits i improved the log message in order to print out the discarded codec. Can you post the log again? in this way we can understand whether these additional tracks are metadata or unsupported video codecs, and choose to support them or ignore them. Thanks.

[ingalls]

Absolutely, I rebuilt with your changes and get the following error:

2025/01/20 17:24:27 ERR [path test] [HLS source] unsupported codec: *mpegts.CodecUnsupported
2025/01/20 17:24:32 ERR [path test] [HLS source] unsupported codec: *mpegts.CodecUnsupported

I'm still very novice on your codebase but I would assume this indicates the codec determination is further down the stack than the error message?

[aler9]

fixed by bluenviron/gohlslib#214