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).
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".