Xv video output has purple tint instead of beeing black

[flami]

I have an mobility X700, fglrx 8.8
I use XIne ( through kafeine ) with the xv driver.
use "videooverlay" in the xorg.conf wich is Adaptor #0: "ATI Radeon Video Overlay" with xvinfo . ( textured video crashes , this is the AVIVO adpator when you run xvinfo ).

I dont experience any color corruption on my screen , I ran the test image and it looks exactly as your screenshot of x11 .

[Nighthog]

I have an mobility X700, fglrx 8.8
I use XIne ( through kafeine ) with the xv driver.
use "videooverlay" in the xorg.conf wich is Adaptor #0: "ATI Radeon Video Overlay" with xvinfo . ( textured video crashes , this is the AVIVO adpator when you run xvinfo ).

I dont experience any color corruption on my screen , I ran the test image and it looks exactly as your screenshot of x11 .

If you read the thread more closely, you would have seen that the problem is whit TexturedVideo + Xv, and no other combo! Sure I can ignore the problem like you and use VideoOverlay... and leave this bug to hang around for how long more?

Besides the newer HD3xxx HD4xxx etc cards should use TexturedVideo instead of the VideoOverlay... the particular hardware that did VideoOverlay doesn't exist in these cards any more... so using VideoOverlay isn't gonna work like you expect.

And I need to use TexturedVideo otherwise video will blink like crazy and whatnot + give you a disco party effect maker instead of actual film.. >_>;

Whit VideoOverlay video will blink no matter what if you use compiz-fusion whit it. TexturedVideo at least stops blinking in full-screen. Sadly you get the distorted colour levels. Which seems to be a bug and should be addressed maybe?

[Fran]

Which seems to be a bug and should be addressed maybe?

Yeah, probably. Other drivers work as they should. The only one with this color deviation is fglrx.

I've managed to get better colors with brightness=-7 and contrast=17 in mplayer, but still not as accurate as I'd like. I should modify saturation too, but playing with three variables is quite difficult. Well, at least it looks better than with default settings.

[bridgman]

I took a look through the Bugzilla db and couldn't find a bug ticket for the "washed out colours" issue. I suspect it may have something to do with colour profiles and if so would probably be more noticeable on some displays than others, ie we may need to get a specific display in order to reproduce this in house.

Can someone pls file a big at http://ati.cchtml.com and include specifics of their display as well as the usual card, driver, OS info ?

[Nighthog]

I took a look through the Bugzilla db and couldn't find a bug ticket for the "washed out colours" issue. I suspect it may have something to do with colour profiles and if so would probably be more noticeable on some displays than others, ie we may need to get a specific display in order to reproduce this in house.

Can someone pls file a big at http://ati.cchtml.com and include specifics of their display as well as the usual card, driver, OS info ?

Maybe a specific display isn't needed, but at least a screen that produces colours all right or good at least. I think the difference in colours on the video will show on any screen that does produce colour good or OK at least. It isn't a screen issue per-see.

If you take a look at the screen captures, if you see a diffrence whit your current screens. well I don't see why then you would need to get any specific screen at all as you should be able to reproduce it whit just the graphics card (one using TexturedVideo) and use a mediaplayer that can output whit Xv on your current/any screen/monitor.

I'll take a look tomorrow and see what info I can collect together for the bug-report (if no one does it before me, in which case I can complement their bug-report instead)



EDIT:
Ok I took some time and did some reading over at AVSforums and read about those pc levels and video levels a bit more.
I've come to conclusion that the video level colours are in fact correct for several videos, but it's not for all videos. XV does give the accurate colours for most video whit black starting at 16 and white stopping at 235. DVD's and SD(standard definition video) like most PAL and NTSC source stuff use the 16-235 colour space, so if watching on a computer screen set to/calibrated for pc-level colours between 0-255 it's correct whit Xv video that black is gray and white isn't fully white eihter, so if video black starts at 16, it shows as 16 on your 0-255 range screen, which is correct.
X11 etc are actually in this case giving the wrong colours and expanding the 16-235 colour palette off the SD video's to the full range off pc-level colours between 0 to 255. But this isn't wrong either really. As on a PC-monitor whit pc-level colours 0-255. Many would like black to be black and white to be white in video so it expands as per settings standard for X11 etc I think.

But don't be writing this all away now yet. There still exists a bug, or lack off feature if one would put it in a another way, or someone just was lazy and implemented this thing in this way for now, or didn't have time to implement it fully correctly.

Let me say what I found out when playing several videos on the Windows XP side and tell you how the colours etc looked like there and how it seems to work. Then I'll compare to the Linux side.

As said dvd's and SD content most use the 16-235 colour range or "video colours", this shows as such in Windows. SD content and video's on the windows side all start whit black at 16 and white ending at 235. The video's are as they should and are exactly like they are here in linux now whit TexturedVideo combined whit Xv video output. i.e. if you have a 0-255 ranging screen 16 will show as 16 which is correct etc.
Their black starts at 16 and it shows as 16 there in windows as in Linux. But there is a diffrence in when this is applied or not. I said SD and dvd's used the 16-235 range, but HD and full-HD many use the full range off 0-255. This diffrence is applied in windows side.
Let me explain. HD content or rather all video off a resolution off 1280x720 (720p) and larger are treated and displayed whit their correct full-range 0-255 colour range when played and it's nice and colours are accurate in them if you watch them now on a 0-255 colour level screen, which is kinda any computer screen or HDTV, and all lower are set to use the 16-235 range. This is kinda nice and works quite nicely over in Windows XP.
(or some way like that, something decides that this one video uses the 16-235 range while this other should use the 0-255, it works quite nicely in XP as far as I can tell, above description is a bit faulty as I have some SD sized video that use the 0-255 levels and gets them as well correctly. So I don't know how it fully works but you get the idea right? (a algorithm?))

Now here in Linux/Ubuntu and the ati-drivers here. Standard seemed to have been that all video was expanded no matter what to use the 0-255 full range pc-levels no matter the output or source(dvd/SD,HD etc) you choose. Though there came an exception into the game which is TexturedVideo + Xv that gives you the 16-235 colour levels ALL THE TIME. Doesn't matter if it's a video that uses 0-255 colour range it is cramped together to use the 16-235 range also which is incorrect. All video I have end upp only getting the 16-235 colour range whit Xv. 1080p movies as well that should have 0-255 range.
A: This is either a bug, it's not working as it should.
B: It's not a bug. it's working the way it was coded. i.e. someone was lazy
C: as B. but all the features for this wasn't implemented. i.e. it's unfinished. Correct implementation to be added later?
the feature to automatically choose 0-255 range or 16-235 range or other isn't there so it default to use 16-235 as that's the most used one for videos?

Well the problem in short is TexturedVideo + Xv all the time uses the 16-235 or such colours range? Well at least I get this result.

so... what am I gonna make out of all this mess I might have figured out and wrote? is it a bug? a incomplete function? or something else?

What can I do?

What I want to do is able to choose the 0-255 range or 16-235 range for my videos manually when I play them or that it works automatically as in windows XP seemingly.

>_>;

and about getting best quality and correct colours for those 16-235 colour range videos. Well you should calibrate you screen whit brightness and contrast etc so black is black on 16 and white is white on 235 for best image and correct image. This isn't maybe the most easy way but will give best image for the video. The other way is like how all the other outputs work that they expand the 16-235 video into the 0-255 colour range that your screen is able and normally produces. You can read this kinda advanced stuff like buttloads over at AVSforums.
=_=;

[Fran]

The other way is like how all the other outputs work that they expand the 16-235 video into the 0-255 colour range that your screen is able and normally produces. You can read this kinda advanced stuff like buttloads over at AVSforums.
=_=;

Well, if the problem is what you exposed (good work BTW ), that's the logical solution, and the driver not doing it is a bug. These are PC cards, not TV adapters. Monitors are calibrated for 0-255, so the drivers should convert the 16-235 range to 0-255, as ALL the drivers do in linux (except fglrx). Movies look much better with -vo x11 than with -vo xv, at least in my monitor (Samsung 226BW).

Anyway, do you know if is there a methodical way to expand the color range "by hand", using contrast/brightess/saturation? Just until this bug is fixed.

(edit) Or at least they should allow us to change it in the control panel, as nvidia does (shit, everytime I see their beautiful gtk2 control panel I get jealous :P)

[Nighthog]

Well, if the problem is what you exposed (good work BTW ), that's the logical solution, and the driver not doing it is a bug. These are PC cards, not TV adapters. Monitors are calibrated for 0-255, so the drivers should convert the 16-235 range to 0-255, as ALL the drivers do in linux (except fglrx). Movies look much better with -vo x11 than with -vo xv, at least in my monitor (Samsung 226BW).

Anyway, do you know if is there a methodical way to expand the color range "by hand", using contrast/brightess/saturation? Just until this bug is fixed.

(edit) Or at least they should allow us to change it in the control panel, as nvidia does (shit, everytime I see their beautiful gtk2 control panel I get jealous :P)

Gotta tell though using the 16-235 colour range and calibrating the screen for that gives the best quality in image and the most correct one, it's the general consensus that it's better, but it's no where as easy to just expand the damn video which in turn mostly gives a all good image anyway for most to accept.
Though calibrating a computer monitor for 16-235 levels will be a huge problem if you do other stuff than watch movies on it. Basically everything but 16-235 content video will show incorrect colours >_>;
So if you have a seperate monitor/TV/HDTV calibrating that might be the better solution for best image as you will have it dedicated for the video only and you will probably like the image/colours on video there alot better than on your main screen when set up correctly for it.

[archman]

I have the same problem, and dig for a while, no solution is found.
>_<
And moreover, my video card's chipset is M52, so I have to enable TexturedVideo in order to use xv drive when using mplayer. -__-
But, I want the best pic while playing video.
So, I tried other drivers when using mplayer.
Now, I find that both gl2 and gl will give the right black color,
but here is another issue, since there are several other subparameters with gl2 or gl, I donot know which is better.
Maybe you can have a try:
-vo gl2:yuv=x
or
-vo gl:yuv=x
above both x can be 2,3,or 4
but when I use gl, I press f to go fullscreen, but when press f again to go back, the whole screen is messed up, I donot know why?

My environment: Archlinux 2.6.26 i686, openbox, using catalyst 8.8-1 driver

[leef]

Without actually looking anything up, here are some thoughts:

1. Xv's job was utilize special video hardware to do colorspace and scaling for video (back when the CPU was slow). ATI doesn't even put this hardware on their cards anymore (but you can write a driver to allocate some of the texture units to simulate hardware).

2. Each display device has its own (adjustible) color profile.

3. Most video formats don't have color profiles.

4. There's more than one way to specify colors.

5. The OS (linux) might have a way of inserting filters (like mplayer's -vf). Maybe somewhere in X?

6. The drivers should have a way of inserting filters, since they should be able to adjust displays based on the display's color profile, or a color profile supplied by a calibration tool.

7. 8 bit color channel depth is a current hardware constraint. There were and will be displays with different bit depths.

8. The cinematographers should be able to shoot the movie using the colors they want. That used to mean selecting film emulsions and adjusting camera exposures and lighting.

Where should adjustments be done?

1. The user program (mplayer) does the conversion (or calls upon the driver to do so (see gl:yuv) based on user input or headers in the video file.

2. The driver does the conversion based on input from the user or from the driven display.

So, IMO, Xv shouldn't be doing any "brightness" compression unless specifically asked.

Thanks for listening.

[legume]

-vo gl:yuv=x

Use whatever x works for you. With gl you can also choose the type of scaling with the lscale=x parameter.

but when I use gl, I press f to go fullscreen, but when press f again to go back, the whole screen is messed up, I donot know why?

This happens if your screen res x and y aren't divisible by 64 AFAICT.

The work around is to add a virtual line to your xorg.conf with 1 added (it will mean your screen will scroll by a pixel).

eg

Section "Screen"
        Identifier "aticonfig-Screen[0]"
        Device     "aticonfig-Device[0]"
        Monitor    "aticonfig-Monitor[0]"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes   "1920x1440_50.00"
                virtual 1920 1441
        EndSubSection
EndSection

fixes the problem for a test I just tried.