Hello, I used to use the xvidix VO until it broke quite some time ago, I don't remember when exactly, but it was months ago (I seem to remember it was spring then, but I don't know if it was this year or the last). I assumed it would get fixed eventually, and just used cvidix instead. Now I upgraded my graphics card, from a Radeon 9600XT to a X800 GTO, and cvidix doesn't work (I haven't yet gotten the console to support my 1600x1200 resolution, I guess that's the problem). Unfortunately xvidix still doesn't work (with current mplayer svn). With the 9600, xvidix usually showed a green window, but some switches between fullscreen and windowed usually made the movie show (sometimes it worked on first start, and sometimes the movie wasn't quite where the window was). I tested some older mplayer revisions then, but the problem was always there, so I assumed a problem with some X update (though I'm not sure if that really was the cause, I didn't really investigate further). Now with the X800, I don't even get an image of the movie, either green as before, or some random noise (sometimes not in the window, as the movie before; as I haven't tested xvidix before exchanging the graphics card, I cannot say if this is specific to the X800). The noise is just on the screen, a Gimp screenshot just gets the green colour key, and -vf screenshot an image from the movie. If an image of that is useful, I can make one once the batteries for my digicam are recharged. I am using Debian unstable (32 bit) on an AMD X2 3800+, updated at least every few weeks. The current kernel is 2.6.26.3, before that I used mostly 2.6.22.12-ck1. Currently installed are xserver-xorg-core 2:1.4.2-6 and xserver-xorg-video-ati 1:6.9.0-1+lenny4, though as I said, the problem appeared months ago, with some older version. lspci information for the X800: Display controller [0380]: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary) [1002:5d6f] I don't think the following is relevant, but just in case: libc6 2.7-13 gcc 4:4.3.2-1 binutils 2.18.1~cvs20080103-7 depth of root window: 24 planes The attached log was done without the ~/.mplayer directory, with some switches between windowed and fullscreen. One line caught my eye: "[radeon] DVI port has no monitor connected", since I have a display attached to the DVI port. Best regards, Christian Ohm
Hello, On Monday, 29 September 2008 at 16:26, Christian Ohm wrote:
I used to use the xvidix VO until it broke quite some time ago, I don't remember when exactly, but it was months ago (I seem to remember it was spring then, but I don't know if it was this year or the last). I assumed it would get fixed eventually, and just used cvidix instead. Now I upgraded my graphics card, from a Radeon 9600XT to a X800 GTO, and cvidix doesn't work (I haven't yet gotten the console to support my 1600x1200 resolution, I guess that's the problem). Unfortunately xvidix still doesn't work (with current mplayer svn).
With the 9600, xvidix usually showed a green window, but some switches between fullscreen and windowed usually made the movie show (sometimes it worked on first start, and sometimes the movie wasn't quite where the window was). I tested some older mplayer revisions then, but the problem was always there, so I assumed a problem with some X update (though I'm not sure if that really was the cause, I didn't really investigate further).
Now with the X800, I don't even get an image of the movie, either green as before, or some random noise (sometimes not in the window, as the movie before; as I haven't tested xvidix before exchanging the graphics card, I cannot say if this is specific to the X800). The noise is just on the screen, a Gimp screenshot just gets the green colour key, and -vf screenshot an image from the movie. If an image of that is useful, I can make one once the batteries for my digicam are recharged.
I am using Debian unstable (32 bit) on an AMD X2 3800+, updated at least every few weeks. The current kernel is 2.6.26.3, before that I used mostly 2.6.22.12-ck1. Currently installed are xserver-xorg-core 2:1.4.2-6 and xserver-xorg-video-ati 1:6.9.0-1+lenny4, though as I said, the problem appeared months ago, with some older version. lspci information for the X800:
Display controller [0380]: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary) [1002:5d6f]
I don't think the following is relevant, but just in case: libc6 2.7-13 gcc 4:4.3.2-1 binutils 2.18.1~cvs20080103-7 depth of root window: 24 planes
The attached log was done without the ~/.mplayer directory, with some switches between windowed and fullscreen. One line caught my eye: "[radeon] DVI port has no monitor connected", since I have a display attached to the DVI port.
No answers in two weeks... Does xvidix work for everyone else? Is there some information missing? I can also test patches, and to a limited extend hack on the code, but I have absolutely no idea where to start here. Best regards, Christian Ohm
On Wed, 2008-10-15 at 19:08 +0200, Christian Ohm wrote:
No answers in two weeks... Does xvidix work for everyone else? Is there some
It fails to work for a lot of people. Is using another VO a problem?
On Wednesday, 15 October 2008 at 20:12, Uoti Urpala wrote:
On Wed, 2008-10-15 at 19:08 +0200, Christian Ohm wrote:
No answers in two weeks... Does xvidix work for everyone else? Is there some It fails to work for a lot of people. Is using another VO a problem?
Well, xvidix is one of the two (X11) VOs which show movies without tearing for me. The other one is -vo sdl, which has its own share of problems: - Doesn't recognize shift as modifier - Doesn't keep aspect ratio when resizing the window - Doesn't allow changing desktops in fullscreen mode. Xv tears sometimes, not that often, but it's noticeable. Gl does as well, even though I've activated the vsync option in driconf. Perhaps I can get cvidix working again, when I find a kernel patch that makes radeonfb recognize the X800GTO. Best regards, Christian Ohm
On Wed, Oct 15, 2008 at 07:51:28PM +0200, Christian Ohm wrote:
Perhaps I can get cvidix working again, when I find a kernel patch that makes radeonfb recognize the X800GTO.
Huh, cvidix always worked for me on an ordinary text console (I only used NVidia though), at least with -nocolorkey or -colorkey 0. But I am not sure if your newer card still supports hardware overlay, at least the newest graphics card models do not.
On Wed, 2008-10-15 at 19:51 +0200, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 20:12, Uoti Urpala wrote:
On Wed, 2008-10-15 at 19:08 +0200, Christian Ohm wrote:
No answers in two weeks... Does xvidix work for everyone else? Is there some
It fails to work for a lot of people. Is using another VO a problem?
Well, xvidix is one of the two (X11) VOs which show movies without tearing for me. The other one is -vo sdl, which has its own share of problems:
SDL does not have its own interface to the X server. On my machine libsdl uses xv by default. So if -vo sdl works then it should be possible to get xv working too (or whatever mechanism SDL uses - I doubt it's vidix though).
Xv tears sometimes, not that often, but it's noticeable. Gl does as well, even though I've activated the vsync option in driconf. Perhaps I can get cvidix
Do you have compositing enabled?
On Wednesday, 15 October 2008 at 21:46, Uoti Urpala wrote:
SDL does not have its own interface to the X server. On my machine libsdl uses xv by default. So if -vo sdl works then it should be possible to get xv working too (or whatever mechanism SDL uses - I doubt it's vidix though).
That's strange, because I definitely notice tearing with -vo xv but not with -vo sdl. Besides, sdl also seems to show frames more evenly. I made a vsync test file with alternating a) black frame, b) black frame with white bar down the middle. sdl shows the white bar flickering regularly, while with xv the display is quite irregularly (and sometimes teared). gl is regular but teared. Perhaps SDL uses XV in another way than -vo xv, if it could be made to work the same, that would be perfect.
Xv tears sometimes, not that often, but it's noticeable. Gl does as well, even though I've activated the vsync option in driconf. Perhaps I can get cvidix
Do you have compositing enabled?
It is enabled, but not used, I think. I'll try disabling later. Best regards, Christian Ohm
On Wed, 15 Oct 2008 19:08:04 +0200 Christian Ohm <chr.ohm@gmx.net> wrote:
I can also test patches, and to a limited extend hack on the code, but I have absolutely no idea where to start here.
You haven't included all the important information, and don't seem to have tried any of the many options that affect video output. You may be better served by using the -users list to get help. At worst, you could always do a binary search through the SVN history until you find the exact revision that broke vidix on your card. That tends to motivate the responsible party... -- Don't trust me! I'm wrong!
On Wednesday, 15 October 2008 at 10:19, RC wrote:
You haven't included all the important information, and don't seem to have tried any of the many options that affect video output. You may be better served by using the -users list to get help.
What information is missing? I've included everything that's mentioned in the bugreporting docs, and every other useful information I could think of. The one thing I unfortunately don't remember is when exactly xvidix failed to work.
At worst, you could always do a binary search through the SVN history until you find the exact revision that broke vidix on your card. That tends to motivate the responsible party...
I did that shortly after it broke, but even older revisions failed then. But I did an update of X.org before it broke, and together with cvidix still working it seems there was no change in xdivix that broke it, but in the X driver. Best regards, Christian Ohm
Hi, On Mittwoch, 15. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 10:19, RC wrote:
You haven't included all the important information, and don't seem to have tried any of the many options that affect video output. You may be better served by using the -users list to get help.
What information is missing? I've included everything that's mentioned in the bugreporting docs, and every other useful information I could think of. The one thing I unfortunately don't remember is when exactly xvidix failed to work.
At worst, you could always do a binary search through the SVN history until you find the exact revision that broke vidix on your card. That tends to motivate the responsible party...
I did that shortly after it broke, but even older revisions failed then. But I did an update of X.org before it broke, and together with cvidix still working it seems there was no change in xdivix that broke it, but in the X driver.
You may have a point here. Also nvidia_vid seems to be broken sometimes. Regards Sascha
On Wed, 15 Oct 2008 20:12:36 +0200, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 10:19, RC wrote: What information is missing? I've included everything that's mentioned in
when you make install on mplayer, your vidix .so files get overwritten, right? -compn
On Wednesday, 15 October 2008 at 14:54, compn wrote:
when you make install on mplayer, your vidix .so files get overwritten, right?
I usually make a .deb and install that, so all files should be updated always.
Hi, On Mittwoch, 15. Oktober 2008, Christian Ohm wrote:
Hello,
On Monday, 29 September 2008 at 16:26, Christian Ohm wrote:
I used to use the xvidix VO until it broke quite some time ago, I don't remember when exactly, but it was months ago (I seem to remember it was spring then, but I don't know if it was this year or the last). I assumed it would get fixed eventually, and just used cvidix instead. Now I upgraded my graphics card, from a Radeon 9600XT to a X800 GTO, and cvidix doesn't work (I haven't yet gotten the console to support my 1600x1200 resolution, I guess that's the problem). Unfortunately xvidix still doesn't work (with current mplayer svn).
With the 9600, xvidix usually showed a green window, but some switches between fullscreen and windowed usually made the movie show (sometimes it worked on first start, and sometimes the movie wasn't quite where the window was). I tested some older mplayer revisions then, but the problem was always there, so I assumed a problem with some X update (though I'm not sure if that really was the cause, I didn't really investigate further).
Now with the X800, I don't even get an image of the movie, either green as before, or some random noise (sometimes not in the window, as the movie before; as I haven't tested xvidix before exchanging the graphics card, I cannot say if this is specific to the X800). The noise is just on the screen, a Gimp screenshot just gets the green colour key, and -vf screenshot an image from the movie. If an image of that is useful, I can make one once the batteries for my digicam are recharged.
I am using Debian unstable (32 bit) on an AMD X2 3800+, updated at least every few weeks. The current kernel is 2.6.26.3, before that I used mostly 2.6.22.12-ck1. Currently installed are xserver-xorg-core 2:1.4.2-6 and xserver-xorg-video-ati 1:6.9.0-1+lenny4, though as I said, the problem appeared months ago, with some older version. lspci information for the X800:
Display controller [0380]: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary) [1002:5d6f]
I don't think the following is relevant, but just in case: libc6 2.7-13 gcc 4:4.3.2-1 binutils 2.18.1~cvs20080103-7 depth of root window: 24 planes
The attached log was done without the ~/.mplayer directory, with some switches between windowed and fullscreen. One line caught my eye: "[radeon] DVI port has no monitor connected", since I have a display attached to the DVI port.
No answers in two weeks... Does xvidix work for everyone else? Is there some information missing? I can also test patches, and to a limited extend hack on the code, but I have absolutely no idea where to start here.
Xvidix on radeon seems to be broken indeed. I'll try to find out why and when it broke. Unfortunatelly I do not know if your new card will work with vidix. It is also possible that a) newer cards no longer contain the overlay unit b) newer cards require different programming. Regards Sascha
On Wednesday, 15 October 2008 at 19:29, Sascha Sommer wrote:
Xvidix on radeon seems to be broken indeed. I'll try to find out why and when it broke. Unfortunatelly I do not know if your new card will work with vidix.
As I said, I don't think some change in xvidix itself broke it, but some change in the X driver.
It is also possible that a) newer cards no longer contain the overlay unit b) newer cards require different programming.
The X800 is a R400, which should be quite similar to the R300s and still has the overlay unit. I don't know about the programming, but the PCI ID (1002:5d4f) is in some vidix file, so I guess the card should work. Best regards, Christian Ohm
Hi, On Mittwoch, 15. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 19:29, Sascha Sommer wrote:
Xvidix on radeon seems to be broken indeed. I'll try to find out why and when it broke. Unfortunatelly I do not know if your new card will work with vidix.
As I said, I don't think some change in xvidix itself broke it, but some change in the X driver.
It is also possible that a) newer cards no longer contain the overlay unit b) newer cards require different programming.
The X800 is a R400, which should be quite similar to the R300s and still has the overlay unit. I don't know about the programming, but the PCI ID (1002:5d4f) is in some vidix file, so I guess the card should work.
Most ids were added without testing them afaik. Attached patch fixes the xvidix problem for me. Regards Sascha
On Wednesday, 15 October 2008 at 20:48, Sascha Sommer wrote:
Most ids were added without testing them afaik.
OK, so the X800 might not work. I'll try the 9600 again later.
Attached patch fixes the xvidix problem for me.
For me it fixes the problem that sometimes no image is displayed, or not (completely) inside the window. That happened sometimes before xvidix broke completely, and was "fixed" by switching between windowed and fullscreen. With this patch, I now always get the corrupted image in the window where it belongs. Definitely an improvement for the cards where xvidix works.
On Mittwoch, 15. Oktober 2008, Sascha Sommer wrote:
Hi,
On Mittwoch, 15. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 19:29, Sascha Sommer wrote:
Xvidix on radeon seems to be broken indeed. I'll try to find out why and when it broke. Unfortunatelly I do not know if your new card will work with vidix.
As I said, I don't think some change in xvidix itself broke it, but some change in the X driver.
It is also possible that a) newer cards no longer contain the overlay unit b) newer cards require different programming.
The X800 is a R400, which should be quite similar to the R300s and still has the overlay unit. I don't know about the programming, but the PCI ID (1002:5d4f) is in some vidix file, so I guess the card should work.
Most ids were added without testing them afaik.
Attached patch fixes the xvidix problem for me.
Fixed in svn. Regards Sascha
On Wednesday, 15 October 2008 at 20:48, Sascha Sommer wrote:
Attached patch fixes the xvidix problem for me.
With that patch the 9600 worked again.
Most ids were added without testing them afaik.
The X800 still doesn't work though. Now what? Is someone still working on vidix and interested in adding support for this card? If not, wouldn't it be better to remove the IDs of cards not supported?
Hi, On Donnerstag, 16. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 20:48, Sascha Sommer wrote:
Attached patch fixes the xvidix problem for me.
With that patch the 9600 worked again.
Most ids were added without testing them afaik.
The X800 still doesn't work though. Now what? Is someone still working on vidix and interested in adding support for this card? If not, wouldn't it be better to remove the IDs of cards not supported?
From your mail:
Display controller [0380]: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary) [1002:5d6f]
From pci_ids.h : #define DEVICE_ATI_R480_RADEON_X8002 0x5d6f /*R480 [Radeon X800 GTO (PCIE)] (Secondary)*/ From radeon_vid.c: { DEVICE_ATI_R430_RADEON_X8003, R_430|R_PCIE }, { DEVICE_ATI_R430_RADEON_X8004, R_430|R_PCIE }, { DEVICE_ATI_R480_RADEON_X800, R_480 }, { DEVICE_ATI_R480_RADEON_X8002, R_480 }, { DEVICE_ATI_R480_RADEON_X850XT, R_480 }, Maybe it works if you add |R_PCIE ?? Apart from that I have no idea. Regards Sascha
Hmmm, On Freitag, 17. Oktober 2008, Sascha Sommer wrote:
Hi,
On Donnerstag, 16. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 20:48, Sascha Sommer wrote:
Attached patch fixes the xvidix problem for me.
With that patch the 9600 worked again.
Most ids were added without testing them afaik.
The X800 still doesn't work though. Now what? Is someone still working on vidix and interested in adding support for this card? If not, wouldn't it be better to remove the IDs of cards not supported?
From your mail:
Display controller [0380]: ATI Technologies Inc R480 [Radeon X800 GTO
(PCIE)] (Secondary) [1002:5d6f]
From pci_ids.h :
#define DEVICE_ATI_R480_RADEON_X8002 0x5d6f /*R480 [Radeon X800 GTO (PCIE)] (Secondary)*/
From radeon_vid.c:
{ DEVICE_ATI_R430_RADEON_X8003, R_430|R_PCIE }, { DEVICE_ATI_R430_RADEON_X8004, R_430|R_PCIE }, { DEVICE_ATI_R480_RADEON_X800, R_480 }, { DEVICE_ATI_R480_RADEON_X8002, R_480 }, { DEVICE_ATI_R480_RADEON_X850XT, R_480 },
Maybe it works if you add |R_PCIE ??
Apart from that I have no idea.
Forget it. The R_PCIE seems to be unused... Regards Sascha
Hi, On Donnerstag, 16. Oktober 2008, Christian Ohm wrote:
On Wednesday, 15 October 2008 at 20:48, Sascha Sommer wrote:
Attached patch fixes the xvidix problem for me.
With that patch the 9600 worked again.
Most ids were added without testing them afaik.
The X800 still doesn't work though. Now what? Is someone still working on vidix and interested in adding support for this card? If not, wouldn't it be better to remove the IDs of cards not supported?
Do you know exactly in what chip version the overlay feature was removed? Regards Sascha
On Thursday, 23 October 2008 at 13:19, Sascha Sommer wrote:
Do you know exactly in what chip version the overlay feature was removed?
AFAIK all R400s (i.e. up to the X850) support the overlay, it was removed in the R500s (X1600 etc., don't know the lowest of those cards, and some budget cards in that series might be rebranded r400s). Best regards, Christian Ohm
On Wed, Oct 15, 2008 at 07:08:04PM +0200, Christian Ohm wrote:
No answers in two weeks... Does xvidix work for everyone else? Is there some information missing? I can also test patches, and to a limited extend hack on the code, but I have absolutely no idea where to start here.
vidix is not support on most current PCs/GPUs, and my ancient PC needs "forever" to compile MPlayer. Just as explanation why it takes so long to get an answer. It is very weird that cvidix works for you. I assume you tested the standard stuff like -nocolorkey etc.?
On Wednesday, 15 October 2008 at 19:38, Reimar Döffinger wrote:
It is very weird that cvidix works for you.
Well, it worked with the old 9600, the X800 doesn't so far. I had hacked cvidix to always use 1600x1200 (my display's resolution, and the resolution radeonfb ran at) which produced a strange flickering image with the default text mode (which the display shows as 800x600). Removing this hack or changing to 800x600 shows the same as xvidix now. I guess I have to try the 9600 again, to see if xvidix works there now.
I assume you tested the standard stuff like -nocolorkey etc.?
I've tried everything I can think of. -nocolorkey makes the window black instead of green. -nodouble makes the flickering go away, and the corrupted image is static (photo attached). Anything else I should try? Best regards, Christian Ohm
One thing I've just noticed is that everytime I (try to) use vidix, the kernel gives the following message: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0. Bank 4: a60000010005001b Best regards, Christian Ohm
On 15/10/08 19:08:04, Christian Ohm wrote:
No answers in two weeks... Does xvidix work for everyone else?
For me cvidix and xvidix are working fine. I'm running vesa-tng-fb though and cvidix with svgalib-helper on a "Radeon R250 [Mobility FireGL 9000]". There is a bug in the radeon.drv of Xorg-6.8 but that did not concern xvidix on my system (LFS). I also don't have any problems with Xorg-7 and xvidix so far. Have You tried -vo cvidix -screenw -screenh instead of modifying the code? Something very strange (that I found out accidently) and special for my setup is that I have to boot my fb with 1400x1050 to get a signal out of my radeon card that the external LCD recognises as 1280x1024. Well, don't know if any of this helps You with Your problems. Regards, Lynx
On Thursday, 16 October 2008 at 20:36, lynx.abraxas@freenet.de wrote:
Have You tried -vo cvidix -screenw -screenh instead of modifying the code?
No, because I couldn't find the parameters in the manpage (grepping for "width"/"height" doesn't help, those words aren't mentioned in the screenw/h descriptions). cvidix gives an error message which I grepped for, and hacking the code was easier than searching for where the width/height values come from.
On 16/10/08 23:44:23, Christian Ohm wrote:
On Thursday, 16 October 2008 at 20:36, lynx.abraxas@freenet.de wrote:
Have You tried -vo cvidix -screenw -screenh instead of modifying the code?
No, because I couldn't find the parameters in the manpage (grepping for "width"/"height" doesn't help, those words aren't mentioned in the screenw/h descriptions). cvidix gives an error message which I grepped for, and hacking the code was easier than searching for where the width/height values come from.
I can remember I once hacked the code there as well because I couldn't find parameters in the man page that seemed to do what one needs here. Perhaps the parameters "-screenw -screenh" should be mentioned in the error message where mplayer tells about its fallback resolution. Regards, Lynx
On Saturday, 18 October 2008 at 10:48, lynx.abraxas@freenet.de wrote:
I can remember I once hacked the code there as well because I couldn't find parameters in the man page that seemed to do what one needs here.
Perhaps the parameters "-screenw -screenh" should be mentioned in the error message where mplayer tells about its fallback resolution.
Attached is a patch that modifies the man page to include width/height in the screenw/h descriptions, mentions those options in the cvidix message, and adapts the message to actually say what the code does.
On Sat, Oct 18, 2008 at 04:30:50PM +0200, Christian Ohm wrote:
On Saturday, 18 October 2008 at 10:48, lynx.abraxas@freenet.de wrote:
I can remember I once hacked the code there as well because I couldn't find parameters in the man page that seemed to do what one needs here.
Perhaps the parameters "-screenw -screenh" should be mentioned in the error message where mplayer tells about its fallback resolution.
Attached is a patch that modifies the man page to include width/height in the screenw/h descriptions, mentions those options in the cvidix message, and adapts the message to actually say what the code does.
Applied. Diego
participants (8)
-
Christian Ohm -
compn -
Diego Biurrun -
lynx.abraxas＠freenet.de -
RC -
Reimar Döffinger -
Sascha Sommer -
Uoti Urpala