yes excuse me I was not clear. I do ffmpeg -h muxer=mp4 and have a long list of ffmpeg capabilities, but unfortunately "frag_every_frame" is missing in the list. Because of my old version of ffmpeg.
Obviously, I cannot do a "simple" update because it indicates that I am already on the last version ffmpeg is already the newest version (7: 3.2.15-0 + deb9u1) while you are at the 4.1.6-1
Which version of Debian are you on ? Ffmpeg 4 should be part of buster
for my part, I am on my RPI3B:
pi@pi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
my RPI3B is too old to update 
No it isn’t. Buster runs fine on all pi
I digress a bit from the subject: I did not find the command to update from Stretch to Buster. Do i have to completely re-flash the SD card?
[EDIT] ifound https://www.raspberrypi.org/blog/buster-the-new-version-of-raspbian/
My advice, SD cards are pretty cheap these days, start fresh with a new card, then you can return to your original system if necessary.
I'm usually grateful to have had the old system available, as I seem to always forget something, being able to go back at look at what I changed in /etc or retrieve something from /home/pi has always more than justified the cost of a fresh SD card.
I have indeed upgraded several RPi3's from Stretch to Buster succesfully following the steps listed in the article linked to by @dceejay. It has worked all the time (I even upgraded a few from Jessie -> Stretch -> Buster following the same principles).
However, I really recommend to make a backup of the SD card before moving on. In all my RPi's I do have a permanent connected microSDcard reader with an additional SD card inserted. When I make a "major" change of something, I always run the easy to use "SD Card Copier" tool. This will save my hard work the day an active SD card eventually would die (I have also tested this, it creates a perfect clone, swapping the SD cards works fine, the RPi boots up and runs exactly as expected with the clone inserted)
EDIT: Also checked one of my upgraded RPi's, for sure ffmpeg ver 4 was there, it's not the latest but "good enough":
ffmpeg version 4.1.4-1+rpt7~deb10u1 Copyright (c) 2000-2019 the FFmpeg developers
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Muxer mp4 [MP4 (MPEG-4 Part 14)]:
Common extensions: mp4.
Mime type: video/mp4.
Default video codec: h264.
Default audio codec: aac.
mp4 muxer AVOptions:
-movflags <flags> E........ MOV muxer flags (default 0)
rtphint E........ Add RTP hint tracks
empty_moov E........ Make the initial moov atom empty
frag_keyframe E........ Fragment at video keyframes
frag_every_frame E........ Fragment at every frame
separate_moof E........ Write separate moof/mdat atoms for e
In one of my RPi's I decided to build from source so here I have a newer version (but I guess both would work)
ffmpeg version N-99578-gaf701196ec Copyright (c) 2000-2020 the FFmpeg developers
built with gcc 8 (Raspbian 8.3.0-6+rpi1)
configuration: --extra-ldflags=-latomic --arch=armel --target-os=linux --enable-gpl --enable-omx --enable-omx-rpi --enable-libx264 --enable-nonfree
libavutil 56. 60.100 / 56. 60.100
libavcodec 58.111.101 / 58.111.101
libavformat 58. 62.100 / 58. 62.100
libavdevice 58. 11.102 / 58. 11.102
libavfilter 7. 87.100 / 7. 87.100
libswscale 5. 8.100 / 5. 8.100
libswresample 3. 8.100 / 3. 8.100
libpostproc 55. 8.100 / 55. 8.100
Muxer mp4 [MP4 (MPEG-4 Part 14)]:
Common extensions: mp4.
Mime type: video/mp4.
Default video codec: h264.
Default audio codec: aac.
mp4 muxer AVOptions:
-movflags <flags> E......... MOV muxer flags (default 0)
rtphint E......... Add RTP hint tracks
empty_moov E......... Make the initial moov atom empty
frag_keyframe E......... Fragment at video keyframes
frag_every_frame E......... Fragment at every frame
separate_moof E......... Write separate moof/mdat atoms for
ok i got it : frag_every_frame is here after Buster update 
After a lot of fright I updated my RPI3B with Buster (thanks to @dceejay ), ffmpeg is on version 4, and I can use your new command of "frag_every_frame" and the result is perfect:
UNLESS I lose the signal, I lose 7 seconds which will not be caught automatically.
I indicate that the camera is in wifi, where it is I cannot pull an ethernet cable.
Losing the connection for a few seconds is not dramatic, the ideal would be to speed up the video to find real time. Too bad for the fluidity if it happens a few times a day it goes unnoticed.
I do not understand this fully, just for my understanding:
Are you sure also video is behind and not only showed time is "wrong" ??
I mean, if the camera connection is lost, there is not possible that frames are transferred and shown later as "behind" or delayed?? Maybe is the node that is "stopping" time counting and when frames are coming again, continuos showing time from when frames stopped arriving?? Therefore a 7 second lost connection will show as 7 second behind? But this is just a guess
My reference stream is the one played by VLC because it is the one that plays the video without any delay compared to the original streamming of the IP camera (Android app, CMS, IP camera client on browser).
So, if I put VLC side by side and the UI_MP4FRAG (of our friend Kevin 
) , when I lose the signal (weak wifi):
In this example I am in the worst case, in FHD so the wifi signal is in difficulty and yes, the accumulated delay went up to 7s "behind" compared to VLC.
Aha, understood, so the acceleation is the point (or simply skipping frames to start just to catch up with "live video"??)
Since the goal is to be the least late compared to the original flow.
Was this using the new ffmpeg movflag frag_every_frame? I have noticed an issue with atleast 1 of my cams that generally performs poorly and can only generate 10s duration segments based on the iframe interval. It can take up to 10s for the video to start being rendered after receiving segments, since I suspect that some of the newly received (shortened) segments don't have enough data to complete the visual frame.
Another thing I am currently working on is a different way to push the segments from server to client when using socket io. Currently, each new segment is requested after receiving the previous segment. I am going to add the option to request "all" segments, so there only needs to be the single request and all new segments will be sent as soon as they are available from the server. Not sure if this will make a difference or not, but it might take a small burden off of the socket io server.
I could implement another setting on the ui that can detect and fast forward the currentTime property of the video element. The tricky part is knowing what is a good value. I can constantly check it and see the current time vs available time and move the play head forward. The downside to that is if you move too far forward and dont receive a new video segment in time, then you will see lots of the spinning loading icon since the player will be stalled waiting on new video content.
Yes i applied this new change command , with the ffmpeg v4 :
yes I see it is difficult to find the happy medium.
Would you not be able to calculate a kind of "moving average segment rate" that can be used as a "move forward" stepper
Did you create that nice UI with node-red dashboard ?
[off topic] Yes everything is done with the Node-red Dashboard, with some Dashboard ui-template keys (except the wifi chart which is a Win10 window in the background).
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
