HLS Video takes too much time to load

[Javierd]

Question

Hi everyone,
I'm working in a project in which I receive h264 video from IP cameras and stream it to browsers using LL-HLS via mediamtx 1.9.2.
The project is working, but I'm finding problems with some cameras where the video takes a lot of time to be displayed (over 15 seconds) and I don't really know what to do or where to look at. The current workflow is the following one:

• A unique identificator is created for a camera
• The camera SDK is started,a nd the h264 received data is sent through FFMPEG to mediamtx and pusblish with the previously created identificator
• The LL-HLS stream is opened in the browser through http://localhost:8888//

The problem is that since the stream is published to mediamtx, until the first frame is displayed in the browser, sometimes the waiting time is even greater than 10 seconds, which makes no sense.

Maybe some I-Frames that are present at the start of the stream are not received in the browser? Because using ffprobe with -show_frames -show_entries frame=pkt_pts_time,pict_type I can see how the first frame of the file is an I-Frame
Is there any way I could improve this without re-encoding the stream? Does anyone have something that could guide me to find a solution?

I've also tried saving the video received from the camera as an mp4 file and stream it on demand using the following yaml configuration

  ondemand:
    runOnDemand: ffmpeg -re -stream_loop -1 -i ./test.mp4 -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH
    runOnDemandRestart: yes

However, the result is pretty much the same, it takes a lot of time to load.
In this case, I can see some FFMPEG warnings when reading the video file like

[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 270000, current: 270000; changing to 270001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 450000, current: 450000; changing to 450001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 1170000, current: 1170000; changing to 1170001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 1440000, current: 1440000; changing to 1440001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 1890000, current: 1890000; changing to 1890001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 2340000, current: 2340000; changing to 2340001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 2610000, current: 2610000; changing to 2610001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 3690000, current: 3690000; changing to 3690001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 3870000, current: 3870000; changing to 3870001. This may result in incorrect timestamps in the output file.
[rtsp @ 0x5afc098503c0] Non-monotonous DTS in output stream 0:0; previous: 4844430, current: 4844430; changing to 4844431. This may result in incorrect timestamps in the output file.

When opening the stream using webrtc, it seems to work a lot better, but webrtc is not always available in these scenarios, so I need to be able to use HLS.

Thanks a lot.

[Javierd]

Ok, I think I figured out the problem might be related to the first I-Frame of the stream being lost.
I use a custom backend to publish the stream to mediamtx, and from the frontend I know beforehand when and in which path the stream is goin to be published. The problem is that when trying to access the stream before it has been published the HLS page gets a 404 error and retries some millideconds after that.
From what think, once the stream is loaded, those first milliseconds with the first I-Frame have already been lost, and therefore the web player has to wait before being able to play the video.

Does this make sense? Is there any way I could wait for some seconds when trying to read the stream before getting that 404 error to solve this problem? Does somebody else have a solution?

Thanks a lot

[aler9]

Hello, if you believe that the error is caused by the fact that the first I-frame is getting lost between the moment in which the stream is published and the moment in which the HLS stream is first requested, you can use hlsAlwaysRemux to start generating the HLS stream as soon as possible, even before it is requested, avoiding the frame loss:

hlsAlwaysRemux: true

Keep also in mind that HLS requires at least two I-frames, therefore, if the I-frames interval is 10 seconds, you'll have to wait at least 10 seconds.