[FFmpeg-user] on frame changes in recode

[Xen]

Carl Eugen Hoyos schreef op 29-04-2016 12:34:
> Hi!
> 
>> ffmpeg version 2.8.6-1ubuntu2
> 
> Generally, on this mailing list, only current FFmpeg git head is 
> supported.

Well there you get it, more nitpicking. Important reason not to give 
this data to people.

Example: if you go to #ubuntu (before release of 16.04) and ask 
something about, say, nvidia driver or issue with game, and you say that 
you use 16.04, you get directed to #ubuntu+1 because "unreleased 
versions are not supported". But #ubuntu+1 doesn't care about issues 
that don't have anything to do with #ubuntu+1 so not really feel like 
helping you with stuff that is equivalent across versions.

In the end it turned out my issue was with nVidia 361.28 driver which 
was also supported in 15.10 so my place indeed was in #ubuntu and not 
#ubuntu+1.

It was a steam issue and in #ubuntu-steam they also did not know but 
there was some prick directing me to #ubuntu+1 instead of to 
#ubuntu-steam. Which was pointless. You see?

And, as it turns out, in this case the issue is also not related to 
ffmpeg! Apparently not in any case. It seems to be related to players 
instead of encoders.

So you would then ask me to install and compile ffmpeg from git head, 
which is ludicrous and costs so much time and energy when the benefits 
are minimal. Sometimes you can just look at whether the issue has 
anything to do with version, first, you know.


> (Among the reasons are that our man-power is limited and that we can 
> only
> fix issues in current FFmpeg git head, non-security patches are 
> normally
> not backported.)

No one is asking you to fix issues in older versions, come on.


> There is also a bug tracker for FFmpeg on Ubuntu but you would likely 
> be
> asked to test current FFmpeg there as well.

And there's be no difference in this issue.

> Another reason for using current FFmpeg git head is that we now have a
> better default aac encoder.

It's not about audio.


>> frame=  666 fps=8.0 q=-1.0 Lsize=    2496kB time=00:00:22.20
>> bitrate=  920.6kbits/s
> 
> This status line indicates that no frame was dropped or duplicated 
> while
> transcoding.

Thank you, I'm sorry for leaving it out.

> (Although I realize you didn't post your command line, it is possible 
> to
> create command lines that drop and / or duplicate frames without 
> showing
> anything suspicious in the status line.)

Apologies, there have been multiple messages and I have posted my 
command line already in one of them and it was very simple:

ffmpeg -i input.mp4 -ss 00:5:50.800 -vcodec libx264 output.mp4

> Feel free to provide an input sample.

Both output and input were already provided, to my dismay.

In any case, the situation is that:

(as I said in the other mail).

* input sees no duplicated frame in VLC and gstreamer
* output sees no duplicated frame in mplayer / ffmpeg
* output sees duplicated frame in VLC and gstreamer.

* Main difference would be new keyframe right before duplicated frame.

I left the status line out because it was garbled from ctrl-z followed 
by other stuff followed by fg.... Apologies.