[MPlayer-dev-eng] Re: N-buffering...

[Nikolaj]

On Wed, 1 Jun 2005 19:42:18 +0300, Ivan Kalvachev <ikalvachev at gmail.com> 
wrote:

> On 6/1/05, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>> On Wed, Jun 01, 2005 at 11:36:03AM -0400, Rich Felker wrote:
>> > > Would it help to implement a video fifo of N frames? (Where N is 
>> perhaps
>> > > 5 or 10). This would be like double-buffering but with N frames. If
>> > > there are occasionally "difficult" frames to decode, the N-buffer 
>> would
>> > > even it out. I realize that the N-buffer would affect A-V sync but 
>> that
>> > > should be possible to solve...
>> >
>> > Not possible to solve in MPlayer's architecture, and in fact this is
>> > very difficult to solve in any single-task player.
>>
>> Wouldn't it be possible to move the output buffer into shared memory
>> and use either a second process or a second thread (depending on the
>> architecture which is cheaper) to display them at the right time?
>> It would get most of the threading benefits without having to lock down
>> mplayer (and the costs associated with that).
>
> Cut it, MplayerXP does it. Go for it.
> MPlayer is the player that doesn't do it.
...

I don't want to flame (please forgive me :) ), just want to say what this 
can be done in one thread,
by using a polling technique. For example, decoder part "dumps" ready 
frames into videomemory area, and at each slice-end (or so) callback is 
called and checks if it is time to output next frame. If so, it blits 
frame location into visible part (or flips). This check can be quite light 
and don't cause a sensible overhead.

Is this compatible with MPlayer?

-- 
Best regards,
    Nikolaj                          mailto:nialpof at pisem.net