[MPlayer-users] mplayer crash on 64-bit Fedora Core 6 machine.

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Sat May 12 10:50:17 CEST 2007


Hello,
On Fri, May 11, 2007 at 04:33:59PM -0700, Dean S. Messing wrote:
> Reimar Döffinger wrote:
> : On Fri, May 11, 2007 at 08:48:40AM -0700, Dean S. Messing wrote:
> : [...]
> : > special reqs. of their 4096x2160 display.  But evidently the
> : > card is very limited.  For example it does not seem to 
> : > "XV" capability.
> : 
> : Possibly it really does not have xv hardware, but probably it's just
> : that the fglrx drivers suck. You can't use the opensource drivers?
> : If you have to use fglrx I'd recommend using -vo gl:yuv=2 or something
> 
> I can't turn the sequence in to yuv due to the chrominance resolution
> loss relative to 24-bit RGB. We are studying very subtle artifacts in
> our processing algorithms and can't be introducing additional ones.

The yuv=2... option won't make any difference if your source is RGB.
With -vo x11 you will have no vsync so I somewhat doubt the quality of
that will be good enough.

> : similar, x11 is quite slow and really not a good idea for such high
> : resolutions (though since your video is already in BGR format -vo gl is
> : probably not faster. You could try "-vo gl -dr" though, I do not know if
> : ATI supports the functions needed for that yet though).
> 
> It didn't work.

What exactly do you mean by "didn't work"? -vo gl2 is a possibility too.

> Also if there's any hope of driving the Toshiba display (4096x2160, QHD)
> under Linux (which I can't currently do) I figured I had to use the
> latest fglrx, esp. given the card is proprietary.  The Toshiba display
> is not a standard display: It takes in two dual link DVI signals
> each 1920x2160 and "stitches" them together to form the QHD image.

I doubt the solution for this will be any different regardless which
driver you use.

> : > Is it possible that the card is unable to "flip"
> : > and mplayer crashes when it tells the card to do so?
> : 
> : No, doesn't seem like a problem related to the video card, BGR stuff if
> : just tested very rarely, it could be something missed while porting
> : to AMD64 architecture.
> : 
> 
> The machine uses a 32/64 bit Intel processor.  I don't know if that is
> "AMD64 architecture" or not.

AMD64, EM64T, x86_64 (anything x86 running in 64 bit mode) is all the same
at least for userspace. I personally decided not to care for some intel
developer's ego and just stick with the original AMD64 name.

> So from what you are saying, I ought to try building the 32-bit
> version of mplayer (which I know works on my various 32-bit machines)
> and see if that works.

No, you ought to try to make a proper bug report and help us fix it. But
since I was able to reproduce it you don't need to anymore.

> I'm new to x86_64 multilib machines.  I will have to figure out what
> to pull onto the machine to do this and hope that I don't create a
> rat's nest for the package manager.

brrr. multilib is ugly. If you're lucky and it's something simple it will
be fixed soon.

Greetings,
Reimar Döffinger



More information about the MPlayer-users mailing list