Video from some HLS streams not displaying correctly

[brian7704]

Which version are you using?

v1.5.1

Which operating system are you using?

• [X] Linux amd64 standard
• [ ] Linux amd64 Docker
• [ ] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm7 Docker
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

Describe the issue

When viewing some HLS streams in MediaMTX, the video doesn't display correctly. Only the top 1/3 to 1/2 is shown, and the bottom is mostly black. However, when playing the same HLS stream directly in VLC without bouncing it through MediaMTX, the video displays correctly.

Describe how to replicate the issue

1. Add a path with this link as a source https://live.hdontap.com/hls/hosb5/dollywood-eagles-aviary1-overlook_aef.stream/playlist.m3u8
2. Read from that path and see the incorrect video display. It will look like the attached screenshot
3. View that link directly in VLC and see that it looks normal

Did you attach the server logs?

Mar 1 13:47:30 server mediamtx[165059]: 2024/03/01 13:47:30 INF [WebRTC] [session bfcb3af2] created by 127.0.0.1:54876 Mar 1 13:47:31 server mediamtx[165059]: 2024/03/01 13:47:31 INF [path EagleCam] [HLS source] started on demand Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF [path EagleCam] runOnReady command started Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF [path EagleCam] [HLS source] ready: 2 tracks (H264, MPEG-4 Audio) Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF reloading configuration (API request) Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF [WebRTC] [session bfcb3af2] peer connection established, local candidate: host/udp/10.17.0.5/8189, remote candidate: prflx/udp/<PUBLIC_IP_REDACTED>/60319 Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF [WebRTC] [session bfcb3af2] is reading from path 'EagleCam', 1 track (H264) Mar 1 13:47:32 server mediamtx[165059]: 2024/03/01 13:47:32 INF [WebRTC] [session bfcb3af2] runOnRead command started Mar 1 13:47:40 server mediamtx[165059]: 2024/03/01 13:47:40 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:47:42 server mediamtx[165059]: 2024/03/01 13:47:42 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:47:50 server mediamtx[165059]: 2024/03/01 13:47:50 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:47:52 server mediamtx[165059]: 2024/03/01 13:47:52 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:01 server mediamtx[165059]: 2024/03/01 13:48:01 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:02 server mediamtx[165059]: 2024/03/01 13:48:02 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:11 server mediamtx[165059]: 2024/03/01 13:48:11 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:13 server mediamtx[165059]: 2024/03/01 13:48:13 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:22 server mediamtx[165059]: 2024/03/01 13:48:22 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:23 server mediamtx[165059]: 2024/03/01 13:48:23 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:32 server mediamtx[165059]: 2024/03/01 13:48:32 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:40 server mediamtx[165059]: 2024/03/01 13:48:40 WAR [path EagleCam] [HLS source] initial delimiter not found Mar 1 13:48:42 server mediamtx[165059]: 2024/03/01 13:48:42 WAR [path EagleCam] [HLS source] initial delimiter not found

Did you attach a network dump?

no

[aler9]

Hello, after some debugging on the HLS feed you provided, it turned out that it incorrectly splits H264 key frames into multiple MPEG-TS PES units.

FFmpeg and GStreamer are able to support this situation by waiting for start of the next frame, after which they merge together every byte received until that moment, resulting in a complete frame.

Implementing such logic requires the server to wait for the next frame, therefore it would result in a in a 1-frame delay in all MPEG-TS streams (which are used in HLS, SRT and UDP), regardless of the fact that this wrong encoding technique is used or not.

Minimizing latency is a key objective of this project, therefore the additional logic cannot be implemented in the form described above.

[brian7704]

Thanks for your response and the technical explanation. Would you consider adding a config option that enables support for these non-standard streams? I've experienced quite a few streams with the same symptoms and in my case I'd be willing to have a one frame delay if it meant the picture displayed correctly.