Considering this, the little RPi is doing all right I think 
1 Like
This is the old working , end of the ffmpeg command :
-c:a aac -c:v copy -f mp4 -movflags +frag_keyframe+empty_moov+default_base_moof pipe:1
Now , i change like you said :
-c:a aac -c:v copy -f mp4 -movflags +frag_every_frame+empty_moov+default_base_moof -min_frag_duration 500000 pipe:1
BUT I have no flow
. Can you tell me where the fault is in my mpeg command ?
I believe you already did also??
cd .node-red
npm update
It may be possible that new movflag may not be in your version of ffmpeg. It was added sometime during 2018.
Can you run this command and see if it shows frag_every_frame listed?
ffmpeg -h muxer=mp4
I did it again just in case, but it's the same
ffmpeg version 3.2.15-0+deb9u1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1+deb9u1) 20170516
indeed, I can't find a : frag_every_frame 
[EDIT] I tried this: sudo apt-get update && sudo apt-get install ffmpeg and return : ffmpeg is already the newest version (7:3.2.15-0+deb9u1).
The command ffmpeg -h muxer=mp4 should have given much output pertaining to the mp4 container. But looking at what seems like a timestamp, 20170516 from your ffmpeg, perhaps that is the date. Your version seems that maybe it is too old if it is from 2017, since I think the feature may have been added in 2018.
pi@raspberrypi:~ $ ffmpeg -h muxer=mp4
ffmpeg version 4.1.6-1~deb10u1+rpt1 Copyright (c) 2000-2020 the FFmpeg developers
built with gcc 8 (Raspbian 8.3.0-6+rpi1)
...
mp4 muxer AVOptions:
-movflags 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
...
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/
1 Like
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.
2 Likes
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
1 Like
@dceejay @wb666greene @krambriw what happened. RPI down! I was optimistic 
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.
2 Likes
I do not understand this fully, just for my understanding:
- the camera connection is lost, say 7 seconds
- then connection is back and streaming works again
- time showed is 7 seconds "behind"
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):
- VLC stops a few seconds and accelerates the video to resume real time
- UI_MP4FRAG "turns in circles" waiting for the return of the signal, then resume reading but late compared to VLC.
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"??)
