Created attachment 26099 [details]
Test video (3 seconds)

This test video contains fast movement to better visualize the issue. The chroma mismatch doesn't appear e.g. with using 'x11' instead of 'xv'.

Created attachment 26100 [details]
NV34M xvinfo

Created attachment 26101 [details]
NV34M xdpyinfo

Created attachment 26102 [details]
NV34M glxinfo

Created attachment 26103 [details]
NV34M xrandr --verbose

Created attachment 26104 [details]
NV34M xorg.conf

What xv port are you using? Also, what happens when using different xv ports (texture, overlay, blitter) ?

Created attachment 26105 [details]
NV34M Xorg.0.log

(In reply to comment #7)
> What xv port are you using? Also, what happens when using different xv ports
> (texture, overlay, blitter) ?
> 

I didn't specify a port manually but I just checked and found out that according to 'xvinfo' the chroma mismatch only appears when mplayer uses the "NV Video Overlay with Composite" at port 57. The other three adaptors "NV30 texture adapter", "NV30 high quality adapter" and "NV Video Blitter" don't produce such an issue. They render all as expected and totally correct.

Can you try editing nv10_xv_ovl.c from the DDX, and change :
        /* Those are important only for planar formats (NV12) */
        if (uvoffset) {

into  

        /* Those are important only for planar formats (NV12) */
        {

around line 120.

That didn't change anything. Sorry.

What should i be looking at exactly? Is it that the buttons are visible transparently through the hand?

In that case, i see it as well (nv34M@ppc). Only with the overlay. Now I do admit that I have for a long time suspected some of the changes darktama made to the overlay code a few months ago reduced the image quality, but I could never really pinpoint it. Perhaps it is this. I will try to see if i can bisect it with this testcase.

Danny

(In reply to comment #12)
> What should i be looking at exactly? Is it that the buttons are visible
> transparently through the hand?
> 
> In that case, i see it as well (nv34M@ppc). Only with the overlay. Now I do
> admit that I have for a long time suspected some of the changes darktama made
> to the overlay code a few months ago reduced the image quality, but I could
> never really pinpoint it. Perhaps it is this. I will try to see if i can bisect
> it with this testcase.
> 
> Danny
> 

Yes, exactly. In addition as soon as I move the video window around the screen it gets updated and this seems to bring the chroma back in line.

I've just reproduced the issue in a picture.

Created attachment 26143 [details]
Chroma not updated to current frame

This is a reproduction of the issue using gimp, the nice RGB to YUV plugin and frames number 58 (the chroma) and frame 59 (luminance) from the test video file.

This is exactly what I see in the video at frame 59.

Also it not determined if the chroma issue appears at odd or even frames.

I confirm this problem with nv28. Xv port "NV Video Overlay" suffers it, "NV Video Blitter" is fine.

I've been watching TV with gxine and some time in the past it started to look like there was something lagging with colors, especially certain red and blue hues. I didn't pinpoint it then, but this bug is the problem.

My Nouveau installation is still quite old, March 27th.

Thanks for the test case! For instance, when the red buttons light up in the beginning, they start white and turn red on the next frame. Without the bug they become red from the beginning. Later, when the red hands move, the chroma and luma are clearly "out of sync" every other frame: pale hands have a red "shadow".

I can confirm this issue on NV36 as well.  It is possible to watch the chroma fail to change while doing single-frame steps with mplayer.

(In reply to comment #12)
> What should i be looking at exactly? Is it that the buttons are visible
> transparently through the hand?
> 
> In that case, i see it as well (nv34M@ppc). Only with the overlay. Now I do
> admit that I have for a long time suspected some of the changes darktama made
> to the overlay code a few months ago reduced the image quality, but I could
> never really pinpoint it. Perhaps it is this. I will try to see if i can bisect
> it with this testcase.
> 
> Danny
> 

How's the progress on this issue?

Since video overlays are not supported with KMS, I doubt there is any point in trying to fix this. Other types of Xv adaptors do not exhibit this bug, do they?

(In reply to comment #19)
> Since video overlays are not supported with KMS, I doubt there is any point in
> trying to fix this. Other types of Xv adaptors do not exhibit this bug, do
> they?
> 

I disagree here, it's feasible to have overlay + KMS, we just need to put together an ioctl to program the overlay through KMS and things will work.

(In reply to comment #19)
> Since video overlays are not supported with KMS, I doubt there is any point in
> trying to fix this. Other types of Xv adaptors do not exhibit this bug, do
> they?
> 

OK, but as long as I understand KMS it just provides textured video which uses the 3D engine whereas XV uses separate resources and therefore wouldn't interfere calculations in the 3D pipeline or OpenCL as much as textured video does.

Am I completely wrong at this point?

Additionally I see a lot of attributes for the overlay adapter:
      "XV_DOUBLE_BUFFER" (range 0 to 1)
      "XV_COLORKEY" (range 0 to 16777215)
      "XV_AUTOPAINT_COLORKEY" (range 0 to 1)
      "XV_SET_DEFAULTS" (range 0 to 0)
      "XV_BRIGHTNESS" (range -512 to 511)
      "XV_CONTRAST" (range 0 to 8191)
      "XV_SATURATION" (range 0 to 8191)
      "XV_HUE" (range 0 to 360)
      "XV_ITURBT_709" (range 0 to 1)
      "XV_ON_CRTC_NB" (range 0 to 1)

In contrast all other adapters just have these:
      "XV_SET_DEFAULTS" (range 0 to 0)
      "XV_SYNC_TO_VBLANK" (range 0 to 1)

That leads me to the conclusion that XV does provide much more utilizing the graphics hardware whereas the others provide less and therefore video players will do other tasks on the CPU regardless of the fact that the hardware might be better for that (although this may not be the case for nVidia cards).

As I see how fast the XV implementation is (except this chroma issue) on my rather limited system (Pentium M 1.4GHz, NV34M 64MB) and I fear that if I upgrade to Ubuntu Karmic later this month I will see much more of my CPU being used for just video playback whereas it is open most open for other tasks until now.

So can I be sure that KMS and its related stuff will use my available hardware at least as good as nouveau does it until now by itself?

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team