[MPlayer-dev-eng] [PATCH] -vf fixpts=use_timer

[Rudolf Polzer]

On Tue, Jul 20, 2010 at 07:28:08PM +0200, Reimar Döffinger wrote:
> 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.

MPlayer does exactly that, it passes the pts down the filter chain already,
which is why fixpts is pretty much useless in mplayer.

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

I have no idea what that is, sorry.

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

Possibly, I was not sure if it is intentional that mencoder processes the
frames out of order, or not (the pts seem out of order, but matching the
subtitles to the pts yielded a weird effect... but the video does not look
randomly reordered, so this makes no sense whatsoever).

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

Indeed.

> I doubt it's much better when the file isn't properly interleaved.

Have not tried such videos yet, though, apart from one that needs -ni. On that
video it doesn't get worse, but it stays a failcase of mencoder (i.e. no set of
commandline options yields working AV sync on output).

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

Can do that. I hope it's okay to just reply in this case.

> b) what happens with -oac copy?

The old code then runs.

> Oh, and if it's the same code, actually reusing it would be far better
> than copying it.

It is not entirely the same, the functions differ because no adjustment to
playback speed, or AO buffer size is done. But yes, the common parts (i.e.:
what I added to mencoder.c) could be merged into one function. Just no idea
where it would belong.

Best regards,

Rudolf Polzer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_audio_pts.diff
Type: text/x-diff
Size: 2881 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100721/5ebdde83/attachment.diff>