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

[Rich Felker]

On Fri, Jun 03, 2005 at 12:45:57AM +0600, Nikolaj wrote:
> 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.

Yes, this is how my player will work, or either it will use SIGALARM
(probably even better because a good kernel will give us perfect
timing).

> Is this compatible with MPlayer?

No, the architectural obstacles are much bigger imo..

Rich