[FFmpeg-user] Basic Video Manipulation Qustions

Clay clay at 42streams.com
Thu Oct 27 19:49:45 EEST 2022


Carl's comments are great.  I try to carve out duplicate content, but
this Q&A format may allow for leaving Carl's initial reply inline.
>> 1. Why does it make sense to convert from a lossy format to raw?
>> You're not
>> gaining any more detail.
>
> It doesn't, unless you need raw for some further processing (that's
> what happens in the ffmpeg pipeline- demux, decode, filter/transform,
> encode, mux, see https://ffmpeg.org/ffmpeg.html#Detailed-description).
>
>> 2. Does re-rendering video over and over at the same resolution, frame
>> rate, and bit rate cause degradation? For example, if I want to make
>> several changes to the video, like colour correction, splicing out
>> sections, transitions, titling, etc. should I be trying to do that
>> all in
>> one command?
>
> It can, and yes or store the intermediate files in a lossless format
> (which could be raw frames in a container); I prefer intermediate
> files as the command lines can get complex and if I mess something up
> or don't like it, part of the work has already been done (as an
> ancient IT person, keeping backups of each step is assumed).
>
> Or use some ffmpeg library based software that allows for you to
> effectively script/render the output.
The stacked command-line ability of ffmpeg is a blessing and a curse;
python-ffmpeg (and other) wrappers really help to harness the
complexity. There are several python wrapper efforts, here are two of
the most popular: https://github.com/PyAV-Org/PyAV and
https://github.com/kkroening/ffmpeg-python (doing a search on github
illuminates 850 repos)
>> 3. I understand that -c copy is a great way to eliminate time and
>> preserve
>> detail but what's the best way to do this when converting from one
>> codec to
>> another, or when performing editing or other changes?
>
> Copy does just that, it copies; changing the
> encoding/size/pixel-format/etc requires going through an
> uncompressed/raw state (the pipeline).
We use Copy to preserve quality between various ffmpeg actions when
possible.
>
>> 4. How important is it to keep standard resolutions, frame rates, and
>> bit
>> rates? Do hardware decoders do better with those? Do software decoders
>> handle weird resolutions better?  Will strange decoding artifacts appear
>> more often with non-standard parameters?
>
> Importance is relative. If the final output must be played on a wide
> varieties of player, then stick to the standards and it's more likely
> to work. Bit rates- AFAIK there are no "standards" for compressed
> video & audio, only conventions or guidelines to use a certain max
> rate to get a given quality (and some media, like dvd/bluray, can only
> go so fast). I can't answer for how s/w decoders play with
> non-standard resolutions. And as I understand, some decoders get wonky
> the resolution isn't divisible by 8.
HLS (http packaged mp4) has some Apple recommended bitrates and sizes. 
For example, they recommend 2mbps avg-bitrate for wifi streaming and
730kbps for cellular streaming along with a slew of pixel
recommendations
(https://developer.apple.com/documentation/http_live_streaming/http_live_streaming_hls_authoring_specification_for_apple_devices).



More information about the ffmpeg-user mailing list