> Clay via ffmpeg-user (12022-11-02): >> Doesn't this serial ordering of the same command (-c:v xxxx) twice just >> drive cpu workload up for no actual benefit? >> >> To clarify: executing -c:v xxxx and then executing -c:v yyyy just >> causes one output: yyyy. Thus you are forcing the CPU to >> decode:encode:decode:encode rather than just decode:encode.... can >> someone confirm or correct me here? > No, except for the ridiculously negligible CPU workload necessary to > process the option itself. Doesn't -c enable encoding or decoding (as well as the certainly trivial 'copy') of a stream, depending upon the choice and the existing stream's codec? Encoding is not a trivial workload :-) Can you clarify that a bit more? *I learn more from ffmpeg-user mail than my best efforts using TheGoogle :-D > ffmpeg does not have the infrastructure to make multiple decode-encode > cycles, what you describe is not possible on top of being useless. What > happens is just that the second -c:v option will override the first one. > This is great to know!
What you are saying is: ffmpeg reads in the entire serial string of commands/actions and, when duplicate commands/actions are identified, programmatically uses the last entry. Is this the case with all commands? _______________________________________________ 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".