Tag Info

New answers tagged

0

You have a misunderstanding of how compression works. In all but a few specialized types of lossy compression, when you compress something a second time, even in a much higher quality level than previous encodings, you still lose additional quality. Using a slower encoding from the same original source with constant quality will often produce a smaller ...


2

-preset Use the slowest preset that is fast enough that it does not drop frames. You can see if ffmpeg is dropping frames in the console output (if I recall correctly). Presets are: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow. -crf Use the highest -crf value that still provides an acceptable quality level. Range is 0-51. 0 ...


2

You specify a preset and a quality value at the same time and by that overriding the preset. I would also recommend you don't encode with ffmpeg while capturing as this would be pretty slow on most PCs. The "error" in your ffmpeg commandline is the option -crf 1. CRF is a quality setting of x264 and the lower the value the higher the bitrate of the video ...


1

The first thing I would try is to add -force_key_frames to your original command, drop the preset and lower the -crf value. The following example sets a key frame every second. ffmpg -i input.mov -c:v libx264 -profile main \ -force_key_frames expr:gte(t,n_forced*1) \ -crf 15 -pix_fmt yuv420p -an output.mp4 As a second resort I would use a series ...


2

Although I am not sure if stderr will really help here because of the way that ffmpeg does its reporting, I can recommend the following pattern. Use the -progress [url] flag and parse it with the tool of your choice every 100ms or so. Here is something to get you started that (with a little tweaking) might do what you want: #!/bin/bash touch ...


1

The first thing that I noticed is that your camera is delivering yuv422p - which isn't bad in and of itself, but you could try forcing it to yuv420 by adding -pix_fmt yuv420p to your command. (This is nice if you ever plan on displaying your video on anything that isn't linux.) The second thing that I noticed is that the start times are wildly different - ...


0

Without knowing the exact details of your workflow it is hard to answer this question, so more information would be greatly helpful. One approach would be to use raw video during your "joining" phase of the algo to strip the moov atom. The final step would be to convert your concat'ed raw video back into mp4.


1

From FFmpeg Documentation – Detailed Description: ffmpeg calls the libavformat library (containing demuxers) to read input files and get packets containing encoded data from them. When there are multiple input files, ffmpeg tries to keep them synchronized by tracking lowest timestamp on any active input stream. Encoded packets are then passed ...


0

Yes, compositing, as it is known in the industry, involves decoding two or more assets in to video streams and them combining those streams in some way. The end result is then saved as a new file on render. There is some variation in when rendering is done though. Some software can put off rendering for a while to reduce the number of re-encodes required. ...


2

It is actually quite easy using a videofilter with select. This is quite sensitive to video changes: -vf "select=gt(scene\,0.0098)" whereas this is not so sensitive: -vf "select=gt(scene\,0.3)" EDIT (added your command) so your command would look like: ffmpeg -f video4linux2 -s 800x600 -r 15 -i /dev/video1 -maxrate 800k \ -minrate 1k -bt 800k ...



Top 50 recent answers are included