[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mplayer-g2-dev
Subject:    Re: [MPlayer-G2-dev] Re: more on frame timing, framerate-changing
From:       D Richard Felker III <dalias () aerifal ! cx>
Date:       2003-06-11 15:33:10
Message-ID: 20030611153310.GA30224 () brightrain ! aerifal ! cx
[Download RAW message or body]

On Wed, Jun 11, 2003 at 03:45:46PM +0300, Andriy N. Gritsenko wrote:
>     Hi, D Richard Felker III!
> 
> Sometime (on Wednesday, June 11 at  7:05) I've received something...
> 
> >If you're worried about not wanting all framerate-changing filters (or
> >apps) to have to support this stuff, it could be an optional feature,
> >where any filter in the chain can ignore the exact info and just use
> >"float pts" the rest of the way down the chain...
> 
> I'm sorry, I don't understand exactly all you said but I think for any
> filter with time prediction (inverse-telecine, video time-rendering for
> slower/faster play, etc.) we have at least have as input for get_frame():
> 1) wanted pts (presentation time stamp of current pulled frame);
> 2) wanted duration (relative time stamp of frame that will be requested
>     next time).
> So filter could know must it pull frame from previous filter or not and
> may it return duplicate or dropped frame instead. Also that info will let
> us have variable framelength/fps because filter will be not related on
> fps anymore.

Duplicate/dropped? You really misunderstand the whole issue here I
think... Some filters might drop frames, but duplication is
near-useless. The much more common case will be rearrangement of data,
where input and output frames don't necessarily correspond in any
fixed pattern.

And anyway, the above paragraph you quoted was about use of exact
absolute timestamp/timebase versus the current system with floats
where the player/encoder at the end keeps trying to correct/fudge the
numbers to make it work.

Rich

[prev in list] [next in list] [prev in thread] [next in thread]