I'm creating a fragmented mp4 for html5 streaming, using the following command:
-i rtsp://172.20.28.52:554/h264 -vcodec copy -an -f mp4 -reset_timestamps 1 -movflags empty_moov+default_base_moof+frag_keyframe -loglevel quiet -
- "-i rtsp://172.20.28.52:554/h264" because the source is h264 in rtp packets stream from an ip camera. For the sake of testing, the camera is set with GOP of 1 (i.e. all frames are key frames)
- "-vcodec copy" because I don't need transcoding, only remuxing to mp4.
- "-movflags empty_moov+default_base_moof+frag_keyframe" to create a fragmented mp4 according to the media source extensions spec.
- "-" at the end in order to output the mp4 to stdout. I'm grabbing the ouput and sending it to the webclient through web sockets.
Everything is working well, expect for a latency issue which I'm trying to solve. If I'm logging every time a data is coming in from stdout, with the timestamp of arrival, I get this output:
16/06/2015 15:40:45.239 got data size = 24
16/06/2015 15:40:45.240 got data size = 7197
16/06/2015 15:40:45.241 got data size = 32768
16/06/2015 15:40:45.241 got data size = 4941
16/06/2015 15:40:45.241 got data size = 12606
16/06/2015 15:40:45.241 got data size = 6345
16/06/2015 15:40:45.241 got data size = 6339
16/06/2015 15:40:45.242 got data size = 6336
16/06/2015 15:40:45.242 got data size = 6361
16/06/2015 15:40:45.242 got data size = 6337
16/06/2015 15:40:45.242 got data size = 6331
16/06/2015 15:40:45.242 got data size = 6359
16/06/2015 15:40:45.243 got data size = 6346
16/06/2015 15:40:45.243 got data size = 6336
16/06/2015 15:40:45.243 got data size = 6338
16/06/2015 15:40:45.243 got data size = 6357
16/06/2015 15:40:45.243 got data size = 6357
16/06/2015 15:40:45.243 got data size = 6322
16/06/2015 15:40:45.243 got data size = 6359
16/06/2015 15:40:45.244 got data size = 6349
16/06/2015 15:40:45.244 got data size = 6353
16/06/2015 15:40:45.244 got data size = 6382
16/06/2015 15:40:45.244 got data size = 6403
16/06/2015 15:40:45.304 got data size = 6393
16/06/2015 15:40:45.371 got data size = 6372
16/06/2015 15:40:45.437 got data size = 6345
16/06/2015 15:40:45.504 got data size = 6352
16/06/2015 15:40:45.571 got data size = 6340
16/06/2015 15:40:45.637 got data size = 6331
16/06/2015 15:40:45.704 got data size = 6326
16/06/2015 15:40:45.771 got data size = 6360
16/06/2015 15:40:45.838 got data size = 6294
16/06/2015 15:40:45.904 got data size = 6328
16/06/2015 15:40:45.971 got data size = 6326
16/06/2015 15:40:46.038 got data size = 6326
16/06/2015 15:40:46.105 got data size = 6340
16/06/2015 15:40:46.171 got data size = 6341
16/06/2015 15:40:46.238 got data size = 6332
As you can see, the first 23 lines (which contain data of about 1.5 secs of video) are arriving almost instantly, and then the delay between each 2 consecutive lines is ~70ms which makes sense because the video is 15 frames per sec. This behavior introduces a latency of about 1.5 sec.
It looks like a flushing issue because I don't see any reason why would ffmpeg need to hold the first 23 frames in memory, especially since each frame is a fragment of it's own inside the mp4. I couldn't however, find any method that would cause ffmpeg to flush this data faster.
Has anyone got a suggestion?
I'd like to note that this is a follow up question to this one: Live streaming dash content using mp4box
The key to removing the delay is to use the -probesize argument:
By default the value is 5,000,000 bytes which was equivalent to ~1.5 sec of video. I was able to almost completely eliminate the delay by reducing the value to 200,000.