[MPlayer-dev-eng] [PATCH] -vf fixpts=use_timer
Reimar.Doeffinger at gmx.de
Tue Jul 20 19:28:08 CEST 2010
On Mon, Jul 19, 2010 at 09:49:49AM +0200, Rudolf Polzer wrote:
> It is mostly useless in mplayer as mplayer usually generates good pts anyway,
> but works there too for completeness.
Sounds to me like for most cases MPlayer could then just set the pts/dts before
it enqueues the frames to that value.
> In case of mencoder, sh_video->timer was not available, and sh_video->pts was
> not monotonous (and thus bad for e.g. subtitle rendering), so I got no better
> idea than using the audio timer instead.
Well, enabling the timestamp reordering code for the nocorrect-pts case would
probably take care of that, it's just the problem that I suspect it will
not be quite as easy to enable it without breaking things.
Regardless of that, the subtitle code should probably be improved to handle
non-monotonous time stamps more reasonably, it's not like it's very hard to
detect this and do something at least somewhat reasonable as long as we don't
care if the subtitles are off 100 ms or so sometimes.
> As I noticed the audio timer is broken
> (positive infinity) for some input video files (e.g. those which use vorbis as
> audio codec)
Not to mention it is unfixably broken when there's no audio...
I doubt it's much better when the file isn't properly interleaved.
> I had to port over mplayer's audio PTS generation (which is, if
> possible, no longer based on constant bitrate input data sizes, but on output
> data sizes of the audio codec, which also works for VBR audio like vorbis).
> This also solves almost all failcases of mencoder that I have that previously
> needed -mc 0 to encode properly, as apparently this very issue also caused AV
> sync to fail in mencoder.
That is interesting, but
a) would warrant making this a separate patch to review and apply first
b) what happens with -oac copy?
Oh, and if it's the same code, actually reusing it would be far better
than copying it.
More information about the MPlayer-dev-eng