Bug 12744

Summary: corrupted colorized lines when outputing to xvideo
Product: xorg Reporter: Wade Berrier <wberrier>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: avillaci
Version: 7.2 (2007.02)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
camera snapshot of corrupted xvideo output
none
Xorg.0.log
none
xvinfo output
none
bring back to life planar-to-packed conversion for rs4xx none

Description Wade Berrier 2007-10-08 16:26:41 UTC
It almost looks like a kalidescope.  I'll attach a picture and my X.org log.

lspci:

01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M] (prog-if 00 [VGA])
        Subsystem: Gateway 2000 Unknown device 0318
        Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 10
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at 9000 [size=256]
        Memory at c0000000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c0020000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Comment 1 Wade Berrier 2007-10-08 16:27:53 UTC
Created attachment 11943 [details]
Xorg.0.log

This is on suse 10.3 (amd64) xorg 7.2.  Gateway ml3109 laptop.
Comment 2 Wade Berrier 2007-10-08 16:35:19 UTC
Created attachment 11944 [details]
camera snapshot of corrupted xvideo output
Comment 3 Wade Berrier 2007-10-08 16:47:04 UTC
I end up using the 'radeonold' driver so that xvideo works.  ('radeonrandr12' also has this same problem reported above).

Although, using radeonold has the problem reported in #12743 .
Comment 4 Alex Deucher 2007-10-09 06:19:34 UTC
The overlay on the XPRESS chips may have additional limitations we don't know about (no documentation).  The fix for bug 1462 may be what's causing this bug.  If you revert that code, it may fix this bug.
Comment 5 Roland Scheidegger 2007-10-09 06:53:34 UTC
(In reply to comment #4)
> The overlay on the XPRESS chips may have additional limitations we don't know
> about (no documentation).  The fix for bug 1462 may be what's causing this bug.
>  If you revert that code, it may fix this bug.
That code can only be an issue if the video in question has more than the maximum supported width (i.e. 1536).
You also could get back the old behaviour by setting "OverlayWidth" option to 1920 in your xorg.conf (you can override it because we don't know the supported width for each chip - we DO know it for those rs480 chips though, apparently).
Maybe the chips have an issue with planar video though, which wasn't supported in 6.6.3 neither natively (was converted to packed). If that's the case, something like mplayer -vf format yuy2 should show a correct picture.
Comment 6 Wade Berrier 2007-10-09 11:27:47 UTC
I get the same effect on frame sizes smaller than hd... so it's probably not the pink bar issue.

I'll try the mplayer suggestion to see if that works.
Comment 7 Wade Berrier 2007-10-09 19:02:43 UTC
mplayer  -vf yuy2 worked wonderfully.

I even tried a 1080 clip and it looked great.  I'm assuming it does the scaling as talked about in #1462 , but it still looked quite good.
Comment 8 Roland Scheidegger 2007-10-10 07:02:15 UTC
(In reply to comment #7)
> mplayer  -vf yuy2 worked wonderfully.
Hmm. Could you try with a newer driver? Not that I'd think there are any fixes which could affect it, but you never know...
Otherwise, it looks like either xpress 200 chips (all of them?) don't support planar yuv, or need a somewhat different setup - both of those seem a bit strange considering the overlay is pretty much the same for r100-r4xx (and even older ati chips, actually). We'd need some input from ati to confirm, or someone could spy on the overlay regs while running fglrx (and using overlay-based xv).
Of course, the old code to convert it to packed yuv in the driver could be readded (removed it as all radeon chips I knew of supported planar yuv just the same) for those chips, but it's certainly not as efficient as using planar yuv directly.

> I even tried a 1080 clip and it looked great.  I'm assuming it does the scaling
> as talked about in #1462 , but it still looked quite good.
If you're using a monitor with a horizontal resolution lower than 1920 you're unlikely to ever notice. I've tried with 1920 and it still looked great - I'd guess you'd need direct comparison side-by-side to really see it with normal video source material.

Comment 9 Wade Berrier 2007-10-10 11:59:59 UTC
Created attachment 11980 [details]
Xorg.0.log

I built the latest from git without any changes or improvements.

(My checkout ended in c9264aa53bf1470ad9104d1e7c4a8ce13c49c270)

Attaching Xorg.0.log...
Comment 10 Thomas Hood 2007-10-23 03:20:32 UTC
Created attachment 12159 [details]
xvinfo output
Comment 11 Alex Villacís Lasso 2008-01-09 13:32:59 UTC
Bug has also been noted at https://bugzilla.redhat.com/show_bug.cgi?id=427450
Comment 12 Michel Dänzer 2008-02-13 04:03:00 UTC
(In reply to comment #8)
> Of course, the old code to convert it to packed yuv in the driver could be
> readded (removed it as all radeon chips I knew of supported planar yuv just the
> same) for those chips, but it's certainly not as efficient as using planar yuv
> directly.

Still, we should probably do that or just disable planar YUV for these chipsets for now?
Comment 13 Roland Scheidegger 2008-02-13 04:52:15 UTC
(In reply to comment #12)
> (In reply to comment #8)
> > Of course, the old code to convert it to packed yuv in the driver could be
> > readded (removed it as all radeon chips I knew of supported planar yuv just the
> > same) for those chips, but it's certainly not as efficient as using planar yuv
> > directly.
> 
> Still, we should probably do that or just disable planar YUV for these chipsets
> for now?

Some video players though AFAIK really need this format, so adding back the planar-to-packed conversion is probably needed. I was hoping maybe we could avoid it if those chips would support planar yuv but needed different setup, but I guess I'll have to fix it now...
Comment 14 Roland Scheidegger 2008-02-15 09:45:33 UTC
Created attachment 14335 [details] [review]
bring back to life planar-to-packed conversion for rs4xx

Here's a patch to bring back the code for converting planar yuv to packed yuv, if a RS400 family chip is used (though I've no idea if they really all fail with planar yuv). I'm currently unable to test this, so YMMV.
Comment 15 Alex Deucher 2008-02-15 12:17:20 UTC
(In reply to comment #14)
> Created an attachment (id=14335) [details]
> bring back to life planar-to-packed conversion for rs4xx
> 
> Here's a patch to bring back the code for converting planar yuv to packed yuv,
> if a RS400 family chip is used (though I've no idea if they really all fail
> with planar yuv). I'm currently unable to test this, so YMMV.
> 

I'd say go ahead an commit it.  I took at look at the RS4xx registers and they should be able to support the planar formats, but in practice they don't seem to.
Comment 16 Alex Deucher 2008-02-17 09:36:04 UTC
(In reply to comment #14)
> Created an attachment (id=14335) [details]
> bring back to life planar-to-packed conversion for rs4xx
> 
> Here's a patch to bring back the code for converting planar yuv to packed yuv,
> if a RS400 family chip is used (though I've no idea if they really all fail
> with planar yuv). I'm currently unable to test this, so YMMV.
> 

I tested this patch and the planar to packed conversion path works fine.  
Comment 17 Alex Deucher 2008-02-18 17:30:16 UTC
I went ahead and committed Roland's patch:
03aa4cc6d6e8c715a1c1d677cc1845223505b358

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.