Page 1 of 1

H264/MP4 live stream from ffmpeg gets delayed

Posted: Sun Sep 30, 2018 9:51 pm
by pio82
I’m transcoding a MJPEG stream to H264/MP4 using ffmpeg. As client I’m using VLC.

I use this command line:

ffmpeg -use_wallclock_as_timestamps 1 -f mjpeg -i "" -f mp4 -vcodec libx264 -movflags frag_keyframe+empty_moov+faststart -tune zerolatency -crf 30 -preset ultrafast -g 1 -reset_timestamps 1 -vsync 1 -flags global_header -r 15 -listen 1 -fflags flush_packets -avioflags direct -flush_packets 1 *output_URL*

If I set the *output_URL* to this:


it works just fine. I start ffmpeg, then after some time I start VLC with this URL udp://@, and it plays (almost) real time. The delay is 1-2 seconds, which is acceptable. And this delay is constant, it does not depend on when I start VLC. I can stop and reopen VLC and it keeps going realtime.

But I need this stream to also be viewed in browser (in a HTML5 video), so I normally use this for *output_URL*:

In VLC I use this URL and it also works fine, but only if I start VLC immediately after I start ffmpeg. If there is a significant delay between the start of ffmpeg and the start of VLC, then that delay will be noticeable in the playback. Let’s say that I start ffmpeg at time T then after 10 seconds (at T+10) I start VLC. I have this behavior in VLC:

- It starts, and it displays the frame at time T and then the stream freezes
- After 10 seconds, the streaming resumes in VLC and it starts playing, but the image is 10 second behind ‘realtime’
- This delays is constant, it does not recover from it

Is there a way to solve this?

- Instruct ffmpeg to start transcoding only when the client connects?
- Instruct ffmpeg to not buffer transcoded stream until the client connects? (with current command line, it clearly buffers because when VLC starts at T+10, the first frame displayed is from time T)?

Thank you!