[FFmpeg-user] 2nd pass has more frames than 1st pass (99021)2kbits/s dup=27 drop=0 speed=4.76x

[Mathieu Malaterre]

On Tue, Dec 1, 2020 at 12:42 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> Am Mo., 30. Nov. 2020 um 08:57 Uhr schrieb Mathieu Malaterre
> <mathieu.malaterre at gmail.com>:
>
> > > > $ 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
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".



-- 
Mathieu