Hi all,
I'm trying to sort out an issue I've run into with ffmpeg on the cli and
was wondering if anyone might be able to help. I am trying to leverage 2
pass encoding as well as inputting additional audio tracks to generate
multiple output versions (MPEG-DASH/HLS/MP4/MP3).
During the 2nd pass
Am Sa., 14. März 2020 um 06:04 Uhr schrieb Jeff Langston :
> I'm trying to sort out an issue I've run into with ffmpeg on the cli and
> was wondering if anyone might be able to help. I am trying to leverage 2
> pass encoding as well as inputting additional audio tracks to generate
> multiple outp
Hi,
Here's the input commands boiled down to the simplest reproducible
versions.
Here's links to the input files https://s3.amazonaws.com/Jlangston/bunny.mp4
https://s3.amazonaws.com/Jlangston/track1.m4a
Trying either without the 2nd audio input or without rendering multiple
video versions with m
Am Sa., 14. März 2020 um 20:09 Uhr schrieb Jeff Langston :
>
> Hi,
>
> Here's the input commands boiled down to the simplest reproducible
> versions.
>
> Here's links to the input files https://s3.amazonaws.com/Jlangston/bunny.mp4
> https://s3.amazonaws.com/Jlangston/track1.m4a
> Trying either with
Am 14.03.20 um 21:06 schrieb Carl Eugen Hoyos:
> name to x264) but in general you cannot do this, you have to use the same
> output
> format and especially the same audio for pass one and two. The reason is that
> ffmpeg (the application) may duplicate (or drop) frames to keep a/v sync and
> if
Right -an in the first pass is referenced in the docs "On pass 1, you may
just deactivate audio and set output to null"
Which looking closer at the docs and some further experimentation I was
able to sort out my issue. I didn't realize the -pass argument also took a
stream specifier which was what
Am Sa., 14. März 2020 um 22:53 Uhr schrieb Jeff Langston :
> Right -an in the first pass is referenced in the docs "On pass 1, you may
> just deactivate audio and set output to null"
Let me repeat:
The problem is not only that you get a completely broken encode (wrong
frames get higher bitrates)
Am Sa., 14. März 2020 um 21:06 Uhr schrieb Carl Eugen Hoyos
:
> The problem gets worse by the fact that in general, neither ffmpeg nor x264
> can
> detect that you are using different settings for the two passes (x264
> sometimes
> crashes if the passes do not fit, I always wondered if this isn'
