On Tue, Dec 1, 2020 at 12:42 AM Carl Eugen Hoyos <[email protected]> wrote: > > Am Mo., 30. Nov. 2020 um 08:57 Uhr schrieb Mathieu Malaterre > <[email protected]>: > > > > > $ ffmpeg -y -i input.avi -c:v libx264 -b:v 1321894 -pass 1 -an -f null > > > > /dev/null && \ > > > > ffmpeg -y -i input.avi -c:v libx264 -b:v 1321894 -pass 2 -c:a aac -b:a > > > > 128k fixed.mp4 > > > > > > This cannot work (and this is not related to the fact that you are not > > > using a version of FFmpeg that we support here). > > > > > > In some cases - if you are lucky - there is a crash and no output file > > > is written, in other cases, a "broken" output file is written, broken in > > > the sense that two-pass encoding did not work the way it is supposed > > > to (more bitrate was given to frames that do not need it). > > > > > > Do not use -an on the first pass and add "-vsync cfr" to the first pass. > > > (Other workarounds are possible.) > > > > Confirmed. The above suggestion does fix the symptoms. > > I would say it fixes the cause.
Point taken :) I have to admit I fail to understand the root cause, I'll do my homework and eventually figure that out. Thanks. > > Did you base your suggestion on: > > > > "Error while decoding stream #0:1: Invalid data found when processing > > input" ? > > No, I know that there are many guides suggesting to use -f null for two-pass > encoding with FFmpeg where the second pass outputs to mov, these guides > are typically broken. I see. I assumed that pages from domain ffmpeg.org, could be considered universal solutions, until I realized anyone could edit it. I've copy/pasted your comment above for the future readers: * https://trac.ffmpeg.org/wiki/Encode/H.264?action=diff&version=77&old_version=76 > > > For future questions: Do not cut FFmpeg's console output, only > > > post ffprobe output if you see an issue with it. > > > > > > Not really related: > > > > Does it make sense to simply copy/paste the existing bit_rate to > > > > re-encode it ? > > > > > > No, to the best of my knowledge, it makes no sense whatsoever. > > > > > > Very generally you either want a specific output quality, in this > > > case specifying a bitrate and two-pass encoding make no > > > sense. > > > Or you have a particular size requirement for the output file, > > > then bitrate and two-pass encoding make sense. > > > > Are you saying that taking the original file size as size requirement > > is the whole issue ? > > Partly. > If you need the original file size (but for example another codec) then > two-pass encoding should provide the best quality (if done correctly). > > But this is an extremely unlikely use case since DVD's are less > popular to store videos. Nowadays, what you (likely) want is to > specify an output quality (how depends on the encoder) and let > the encoder decide how to produce the quality you requested. Understood. I was disappointed with something as simple as: $ ffmpeg -i input.avi -c:v libx264 -preset slow -crf 18 -c:a copy output.mkv Sometimes the output.mkv file was very close in size to the original input.avi, sometimes it would double in size (again I am missing the background to have a proper diagnosis). So I tried the two pass solution to have a finer control. > Carl Eugen > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". -- Mathieu _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
