It can be even faster if we can do multiple cuts with one command, so we traverse the frames once. This will make us able to have exact cuts with slightly slower operation but still super faster than re-encoding the full video. Note that the first two parts are expected to be small (and one of them or both can be zero length), so, the re-encoding process will be fast. I suggested suggest this algorithm, to divide the segment (t1, t2) that we want to copy to 3 parts:ġ.a part (t1-x, t1+y), which is a complete encoded block that should be re-encoded to be able to copy the part (t1, y) precisely.Ģ.a part (t2-z, t3+w), which is a complete encoded block that should be re-encoded to be able to copy the part (z, t2) precisely.ģ.a middle part (y, z) which contains complete encoded blocks, where it can be copied as is.Ĥ.Join the 3 parts resulted from the above steps. I want to know how ffmpeg decides the cutpoints). We recommend that you use a stream bitrate of 4500 Kbps.I have a solution, but I don't know how to do it using current ffmpeg commands (my trials to copy at keyframes didn't come accurate too. The stream's current bitrate (6653.00 Kbps) is higher than the recommended bitrate. We recommend that you use an audio stream bitrate of 128 Kbps. The audio stream's current bitrate (2.00 Kbps) is lower than the recommended bitrate. Note that ingestion errors can cause incorrect GOP (group of pictures) sizes. The current keyframe frequency is 6.0 seconds. Currently, keyframes are not being sent often enough, which will cause buffering. "Please use a keyframe frequency of four seconds or less. I have quite good performance for 2-3 minutes, and then I get a warning message on Youtube that my Key Frame interval is currently at 6 seconds, and needs to be at 4 seconds: Code: Select all sudo raspivid -o -t 0 -vf -hf -fps 10 -b 6000000 | sudo ffmpeg/./ffmpeg -f lavfi -re -i anullsrc -f h264 -thread_queue_size 1024 -framerate 10 -probesize 100 -i -vcodec copy -acodec aac -g 20 -f flv rtmp://
0 kommentar(er)
