Is there any good reason why FFmpeg doesn't do "-vcodec copy" automatically.
Is there any good reason why FFmpeg which sees that the video file input and output match every single characteristic doesn't copy the stream to avoid useless reencoding? Basically doing "-vcodec copy" automatically. -- Best Regards, Stephane Archer
Am 30.09.23 um 20:46 schrieb Stéphane Archer:
Is there any good reason why FFmpeg which sees that the video file input and output match every single characteristic doesn't copy the stream to avoid useless reencoding? Basically doing "-vcodec copy" automatically.
is there a good reason to throw a video file through ffmpeg when you don't want to touch it? yeah, there may be a few reasons, and for the really *few* reasons you are supposed to state that
On 9/30/2023 12:07 PM, Reindl Harald wrote:
is there a good reason to throw a video file through ffmpeg when you don't want to touch it?
Changing the container or working only with the audio or subtitle tracks. So yes, there is a good reason. z!
Am 30.09.23 um 21:29 schrieb Carl Zwanzig:
On 9/30/2023 12:07 PM, Reindl Harald wrote:
is there a good reason to throw a video file through ffmpeg when you don't want to touch it?
Changing the container or working only with the audio or subtitle tracks.
So yes, there is a good reason
whatever the default is you will always have workloads where it don't match - hence you have options to specify your needs if you have a godd reason for "-vcodec copy" the specify it, case closed
Dear Reindl Harald, Seeing the sarcastic tone of your emails and finishing your emails with "case closed" when someone is asking a question and is opening a discussion doesn't make you appear smart, on the contrary actually. Yes, you can always specify "-vcodec copy" when you need to, that is not what the discussion is about. It's about whether we can make it automatic so we don't have to specify it. "case closed" lol Stéphane Archer On Sat, Sep 30, 2023 at 4:39 PM Reindl Harald <h.reindl@thelounge.net> wrote:
Am 30.09.23 um 21:29 schrieb Carl Zwanzig:
On 9/30/2023 12:07 PM, Reindl Harald wrote:
is there a good reason to throw a video file through ffmpeg when you don't want to touch it?
Changing the container or working only with the audio or subtitle tracks.
So yes, there is a good reason
whatever the default is you will always have workloads where it don't match - hence you have options to specify your needs
if you have a godd reason for "-vcodec copy" the specify it, case closed
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
-- Best Regards, Stephane Archer
On Sep 30, 2023, at 12:07 PM, Reindl Harald <h.reindl@thelounge.net> wrote:
Am 30.09.23 um 20:46 schrieb Stéphane Archer:
Is there any good reason why FFmpeg which sees that the video file input and output match every single characteristic doesn't copy the stream to avoid useless reencoding? Basically doing "-vcodec copy" automatically.
is there a good reason to throw a video file through ffmpeg when you don't want to touch it?
yeah, there may be a few reasons, and for the really *few* reasons you are supposed to state that
Perhaps the user has an automated workflow that accepts X, Y, Z, and W, but always outputs W. If any particular incoming file happens to be W, it would be more efficient to not re-encode that particular file.
is there a good reason to throw a video file through ffmpeg when you> don't want to touch it? I guess you might want to touch the audio but not the video, maybe? In general, I suspect the reason it's not easy to implement the requested feature is that it isn't often trivial, or even possible, to know even quite roughly what settings were used to encode a video. As far as I know it'd be perfectly valid to have a video in certain codecs that might contain an enormous string of millions of I-frames, followed after hours, days or weeks with a single B-frame, and there wouldn't be any way to anticipate that other than just examining the whole file. You can't, as far as I know, know what the requested bitrate was when encoding the file. You can only know what the bitrate is. Different encoders use different techniques in different ways; there is no standard H.264 encoder, only a reference decoder, so there's not even a standard collection of settings to use as a basis. As far as I know it's not actually possible to do what the OP seems to want to do, regardless. P
participants (5)
-
Carl Zwanzig -
Phil Rhodes -
Reindl Harald -
Steven Kan -
Stéphane Archer