[FFmpeg-user] VFR video re-encoding

[Moritz Barsnick]

On Tue, Feb 09, 2016 at 14:56:47 +0300, ValdikSS wrote:
> > How did you create this file?
> > I wonder if it is valid to have more frames than the 
> > framerate suggests...
> As I said, I've encoded episode and opening separately and joined it into one file with mkvmerge.

That's what I have been wondering all along in this thread. Who is
doing it wrong?

What I could observe (I think) from using the file:
Its DTS/PTS seem to be correct. They are about 41..42 ms apart in the
first section (corresponds to 23.98 fps), about 33..34 ms apart in the
second section (corresponds to 29.97 fps). The pkt_duration, as
mentioned by Valdik originally, also seems to be correct for each
section.

Matroska supports VFR, so this shouldn't be a general problem (should
it?). Does it support a CFR header, and did mkvmerge insert this? Just
wondering.

$ ffmpeg -i rkszxnz.mkv -threads 3 -speed 5 rkszxnz.webm

Now, what ffmpeg seems to be doing is to be converting to CFR 23.98
(when converting to webm with libvpx-vp9). Obvious from the warnings
and the dropped frames starting from the "cut" point around 55 s, and
from the pkt_duration in the resulting file.

Is this intended? What's the point of *not* retaining the DTS/PTS and
the frame rate when converting without explicit "-r" or the likes?

Anyway, I do not see this effect mentioned by Valdik:
> All I get is stuttering opening.
Not even after 55 seconds. (Using my conversion.) OTOH, I can't seek in
the resulting video, which is wildly annoying.

Valdik, I must apologize at this point, none of us has yet pointed out
that you should supply the complete, uncut console log of your ffmpeg
calls (along with the proper command line of course). Because:
> encoder         : Lavf56.40.101
You seem to be using a version from around July 20 2015. Have you tried
latest git master yet?

Moritz