[Bug 5876] big xvideo issues with ATI Radeon RV100 family (Mobility M6 LY, ...)

bugzilla-daemon at annarchy.freedesktop.org bugzilla-daemon at annarchy.freedesktop.org
Tue Dec 5 02:43:48 PST 2006

Please do not reply to this email: if you want to comment on the bug, go to    
the URL shown below and enter yourcomments there.     

------- Additional Comments From sroland at tungstengraphics.com  2006-12-05 02:43 -------
(In reply to comment #28)
> So mplayer assumes that by the time it wants to fill that buffer again, X has
> finished copying it. That sounds very broken, and not really consistent with
> observed behaviour.
> If mplayer didn't pay attention to what X is doing with the buffer, then it
> wouldn't be able to detect and whine about "your machine is too slow to play
> Right, in libvo/vo_xv.c we can find this:
> static void flip_page(void)
> {
>     put_xvimage( xvimage[current_buf] );
>     /* remember the currently visible buffer */
>     visible_buf = current_buf;
>     if (num_buffers > 1)
>     {
>         current_buf =
>             vo_directrendering ? 0 : ((current_buf + 1) % num_buffers);
>         XFlush(mDisplay);
>     } else
>         XSync(mDisplay, False);
>     return;
> }
So I can't see where it would wait or notice X hasn't finished the last request.
XFlush does nothing, and XSync isn't called. It will never show the "too slow"
message unless mplayer itself does not get enough cpu time to decode a picture
or the event queue would be full (I think - not sure there what happens in that
case). Yes this looks a bit broken, but under the assumption that the decoding
time of mplayer is larger than what the driver needs, and the schedular is at
least somewhat fair, it's only going to be a problem if the box is too slow
anyway, so who cares.

Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the Xorg-driver-ati mailing list