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

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



-- 
Mathieu
___
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".

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

2020-11-30 Thread Carl Eugen Hoyos
Am Mo., 30. Nov. 2020 um 08:57 Uhr schrieb Mathieu Malaterre
:

> > > $ 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.

> 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.

> > 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.

Carl Eugen
___
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".

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

2020-11-29 Thread Mathieu Malaterre
Carl Eugen,

Thanks for taking the time to answer my questions.

On Sun, Nov 29, 2020 at 7:40 PM Carl Eugen Hoyos  wrote:
>
> Am So., 29. Nov. 2020 um 16:32 Uhr schrieb Mathieu Malaterre
> :
>
> > $ 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.

Did you base your suggestion on:

"Error while decoding stream #0:1: Invalid data found when processing input" ?

> 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 ?
If I follow the guide again and do the computation as described, the
bitrate value is just very slightly different:

>>> 690*8192./(3600+6*60+2) - 128
1298.673397274104

Assuming my mp3 audio did not have any particular problem, would there
be an actual difference in between using -b:v 1298k vs -b:v 1321894 ?


Thanks again,

> Carl Eugen
> ___
> 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".



--
Mathieu
___
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".

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

2020-11-29 Thread Carl Eugen Hoyos
Am So., 29. Nov. 2020 um 16:32 Uhr schrieb Mathieu Malaterre
:

> $ 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.)

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.

Carl Eugen
___
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".

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

2020-11-29 Thread Mathieu Malaterre
Hi there,

I am staring at the following guide to re-encode an existing avi
(mpeg4+mp3) into MP4 (h264+aac):

https://trac.ffmpeg.org/wiki/Encode/H.264#twopass

My video is such that:

$ ffprobe -show_streams -show_format -print_format json -i input.avi
[...]
Input #0, avi, from 'input.avi':
  Duration: 01:06:01.97, start: 0.00, bitrate: 1459 kb/s
Stream #0:0: Video: mpeg4 (DIVX / 0x58564944), yuv420p, 640x480,
1321 kb/s, 24.99 fps, 25 tbr, 24.99 tbn, 30k tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo,
fltp, 127 kb/s
"streams": [
{
"index": 0,
"codec_name": "mpeg4",
"bit_rate": "1321894",
...
"index": 1,
"codec_name": "mp3",
"bit_rate": "127704",
...
"format": {
"format_name": "avi",
"bit_rate": "1459407",

Does it make sense to simply copy/paste the existing bit_rate to
re-encode it ? Or did I miss something from the guide (I find it hard
to make sense of the error message given) ?

In my case, the following command:

$ 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

gives:

ffmpeg version 4.1.6-1~deb10u1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --prefix=/usr --extra-version='1~deb10u1'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl
--disable-stripping --enable-avresample --disable-filter=resample
--enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libcodec2 --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame
--enable-libmysofa --enable-libopenjpeg --enable-libopenmpt
--enable-libopus --enable-libpulse --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvidstab --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265
--enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi
--enable-lv2 --enable-omx --enable-openal --enable-opengl
--enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883
--enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil  56. 22.100 / 56. 22.100
  libavcodec 58. 35.100 / 58. 35.100
  libavformat58. 20.100 / 58. 20.100
  libavdevice58.  5.100 / 58.  5.100
  libavfilter 7. 40.101 /  7. 40.101
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale  5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc55.  3.100 / 55.  3.100
[mpeg4 @ 0x563b663d7580] looks like this file was encoded with
(divx4/(old)xvid/opendivx) -> forcing low_delay flag
Input #0, avi, from 'input.avi':
  Duration: 01:06:01.97, start: 0.00, bitrate: 1459 kb/s
Stream #0:0: Video: mpeg4 (DIVX / 0x58564944), yuv420p, 640x480,
1321 kb/s, 24.99 fps, 25 tbr, 24.99 tbn, 30k tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, stereo,
fltp, 127 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg4 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[mpeg4 @ 0x563b667c5040] looks like this file was encoded with
(divx4/(old)xvid/opendivx) -> forcing low_delay flag
[libx264 @ 0x563b667c8380] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX
[libx264 @ 0x563b667c8380] profile Main, level 3.0
Output #0, null, to '/dev/null':
  Metadata:
encoder : Lavf58.20.100
Stream #0:0: Video: h264 (libx264), yuv420p, 640x480, q=-1--1,
1321 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
  encoder : Lavc58.35.100 libx264
Side data:
  cpb: bitrate max/min/avg: 0/0/1321000 buffer size: 0 vbv_delay: -1
[mpeg4 @ 0x563b667c5040] Error at MB: 11510:57:03.56 bitrate=N/A speed=12.5x
[mpeg4 @ 0x563b667c5040] I cbpc damaged at 8 27
[mpeg4 @ 0x563b667c5040] Error at MB: 1115
[mpeg4 @ 0x563b667c5040] marker does not match f_code
Last message repeated 23 times
[mpeg4 @ 0x563b667c5040] concealing 1200 DC, 1200 AC, 1200 MV errors in I frame
[mpeg4 @ 0x563b667c5a40] P cbpy damaged at 8 0:45.68 bitrate=N/A speed=12.5x
[mpeg4 @ 0x563b667c5a40] Error at MB: 8
[mpeg4 @ 0x563b667c5a40] marker does not match f_code
Last message repeated 4 times
[mpeg4 @ 0x563b667c5a40] P cbpy damaged at 22 8
[mpeg4 @ 0x563b667c5a40] Error at MB: 350
[mpeg4 @ 0x563b667c5a40] marker does not match f_code
Last message repeated 7 times
[mpeg4 @ 0x563b667c5a40] P cbpy damaged at 17 8
[mpeg4 @ 0x563b667c5a40] Error at MB: 345
[mpeg4 @ 0x563b667c5a40] marker does not match f_code
Last message repeated 5 times
[mpeg4 @ 0x563b667c5a40] concealing 1200 DC, 1200 AC, 1200 MV errors