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

[Ivan Kalvachev]

On 6/1/05, 4664 <4664 at telia.com> wrote:
> Hi. Playing x264 encoded videos on my machine is quite taxing, using
> maybe 80% CPU. But even though I have 20% CPU left I still get jerky
> pan/scan motion. I suspect that this happens because the CPU is
> sometimes too slow to decode a frame within the 1/25th of a second that
> is available (for a 25fps movie). These occasional "difficult" frames
> (or set of frames) probably cause the problems.
> 
> 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...
> 
> Perhaps this is already implemented but I haven't found it? How hard
> would it be to do?
> 
> I'm willing to give this a try but first I'd like to know what you guys
> think about it.

I think this was the exact reason Nick to fork MPlayerXP (now found in sf.net).
You can give it a try.

The problem with buffering comes from the fact that MPlayer is single
threaded application. So even if we have 10 frames in a buffer and the
currently decoded one is taking too much time, we still will miss the
right time to show the long-time-ago decoded 10'th frame. To solve
that we need an separate thread and this is why Nick forked.
I personally have done an small queue for vo_xvmc driver, because
there decoding is done independently from main CPU and xvmc actually
honnors vsync.

I don't think that your problems are caused by not enough CPU to
decode one frame,
you can try -autosync 30 (or nosound), or some video driver that
honnors vsync (been jurky is usually because image is changed while
still visible and it have nothing to do with CPU been slow or fast).

Wish You Best
   Ivan Kalvachev
  iive