[MPlayer-dev-eng] [PATCH] DXR3

[David Holm]

In this case it does since the DXR3 is not a video device but an mpeg
decoder. Flushing it's buffer requires a fraction of time, that fraction
is enough to cause a glitch in a/v sync if audio data is written before
video data after a seek. I've tried to work around this in vo_dxr3.c but
it isn't possible.
It's either this way or we can forget about smooth playback on old
computers. The device works great on fast computers as it is, but it
needs the prebuffering to work on older ones. Xine uses this, I do not
since seeking breaks it...

//David

> 
> I don't agree with this change. It looks like as an ugly workaround than a
> fix or so. Order or audio and video decoding MUST NOT affect a-v sync of a
> given libvo driver...
> 
> 
> A'rpi / Astral & ESP-team
> 
> --
> "I don't RTFM? Wow. What's the meaning of this? It's new for me."
> 	-- Martin Baum, a tipical MPlayer user...
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng