[xv] Source image dimensions are too high" makes mplayer unusable in any media centre

[bugzilla.mplayerhq.hu@…]

After a recent upgrade to 'MPlayer 1.0pre8-3.3.5 (C) 2000-2006 MPlayer Team', I
found the following message:

mplayer -vo xv foo.avi

VO: [xv] 800x336 => 800x336 Planar YV12
[xv] Source image dimensions are too high: 800x336 (maximum is 768x576)
FATAL: Cannot initialize video driver.

However, prior to this, XV worked fine with many oversized videos.. using XV to
rescale them. Matters are worse, however, because one can not do something
along the lines of:

-vo xv,x11

Without this, it means that the media centre user can only use X11 output. A
media centre users (someone using a remote control), can not type -vo xv or -vo
x11 for each video. Further, many such users are incapable of such feats.

As a work around, I attempted to use -xy 768 to software scale all videos before
XV, which does not seem to work. When doing so, I get the following:

mplayer -vo xv -xy 768 foo.avi

VO: [xv] 800x336 => 768x322 Planar YV12
[xv] Source image dimensions are too high: 800x336 (maximum is 768x576)
FATAL: Cannot initialize video driver.

Which doesn't make sense, since it seems that mplayer is about to resize to
768x322.. but then fails with the above message. The above would work in a
media centre, with a cpu cost, because all videos need to be resized to fill the
screen anyhow.

Unfortunately, I do not know any other method besides -xy, that allows one to
specify the horizontal resolution without the vertical and retain aspect.

However, when playing around, I noticed the following:

mplayer -sws 2 -vop scale=768, foo.avi

SwScaler: BICUBIC scaler, from Planar YV12 to Planar YV12 using MMX2
VO: [xv] 768x336 => 800x336 Planar YV12
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!

Which is then passed off to XV, and XV seems to scale the video fine. Something
is odd here, but what I am most worried about is finding a reliable method (that
isn't a hack, such as the above, and likely to break in an upgrade) of playing
videos larger than my screen size.

Allowing software scaling before -vo xv would do the trick, if Mplayer is no
longer prepared to allow XV to perform scaling on video larger than the display.

NOTE:

• enlarging the screen size is not an option, for myself or many other users

that want a good video output to their NTSC tvs

• changing mplayer options on a file by file basis is not an option in all

current media centres that I know of, or at least, not something that is
desirable for end users with remote controls

Thanks for the good work, hopefully there is an easy way around this!

Thanks!

[reimar]

I do not have any problems like this, and you didn't include most of the stuff
asked in bugreports.html.
Esp. what kind of system and which graphics card this is. But this sounds a lot
like a graphics card driver bug if claims that it can only do 768x576 when it is
capable of rescaling higher dimensions.
What does "xvinfo | grep maximum" return?

[bugzilla.mplayerhq.hu@…]

This is a PVR-350 card, a _good_ TV out card. The maximum video output size is
accurate as stated by mplayer.

xvinfo | grep maximum

maximum XvImage size: 768 x 576

I didn't see bugreports.html at ​http://bugzilla.mplayerhq.hu/, which is why I
didn't follow it. I don't see it at ​http://mplayer.hu/bugreports.html either,
or a link on the main page. I might have missed it, but perhaps a link on the
bugzilla page would help, I simply went there after searching mailing lists for
similar problems.

Other users have seen this message, as seen by this thread that ended without
resolution:
​http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2005-November/038726.html)

This is a Linux system, Debian stable, mplayer version above. As stated below,
the problem does not occur with prior mplayer versions.

[reimar]

This is a PVR-350 card, a _good_ TV out card. The maximum video output size is
accurate as stated by mplayer.

xvinfo | grep maximum

maximum XvImage size: 768 x 576

You said that with an older MPlayer version it worked with higher resolutions,
so it is not all accurate but the driver is buggy!

In the xf86-video-ivtvdev source code you will find something like this:

/* client libraries expect an encoding */
static XF86VideoEncodingRec DummyEncoding[1] = {

{ /* overlay limit */

0,
"XV_IMAGE",

768, 576,

{1, 1}
}

};

Find out what the real maximum resolution is for that card and replace 768, 576
by that.
This is not an MPlayer bug.

[bugzilla.mplayerhq.hu@…]

This bug report is not about my specific card. This report has nothing to
do with what *my* max resolution is, but that all cards have max
resolutions, and may be trying to play videos with larger resolutions than
their max available. There are a lot of HD movies starting to spread out
there, and this market penetration will only grow. More and more people
are going to be effected by this.

For example, this machine reports:

xvinfo | grep maximum

maximum XvImage size: 2046 x 2046

Whereas my laptop reports:

xvinfo | grep maximum

maximum XvImage size: 1440x1080

As you can see, my laptop is unable to play a 1920×1080i movie.

Since this is a MPEG TV out card, with NTSC or PAL *only* resolutions for
output, XV out isn't going to be too high. Frankly, I believe the
driver to be correct, but again, that isn't the point is it? After all,
this isn't a bug report about my card, this is a bug report about how
Mplayer handles fallback when XV is not usable. Right now, Mplayer does
not allow for fallback, nor does it allow for rescaling the video before
playing with XV.

Say Again, this bug is *NOT* about my card, but (as the topic
originally stated!) about Mplayer's behaviour when a video is played that
is larger than XV output. There must be a means of fallback, otherwise
mplayer becomes useless in a media player.

As well, the way mplayer is reacting to that larger than XV video size is
not-logical.

[reimar]

Your original report was about a regression - something that worked before but
does not anymore with pre8. It would significantly simplify if you could decide
what exactly this bugreport is supposed to be about and give it a more specific
summary.

xvinfo | grep maximum

maximum XvImage size: 1440x1080

As you can see, my laptop is unable to play a 1920×1080i movie.

And there is hardly any chance this will change. You can use software scaling
(using something like -vf scale=1440:1080, maybe you also need to set -aspect
1920/1080), but it is quite unlikely it will still be fast enough then.
There is simply no way MPlayer can fix crappy hardware.

[bugzilla.mplayerhq.hu@…]

Your original report was about a regression - something that worked
before but does not anymore with pre8. It would significantly simplify
if you could decide what exactly this bugreport is supposed to be about
and give it a more specific summary.

I see.

My summary is quite specific. I mentions a new feature in mplayer ("[xv]
Source image dimensions are too high") and that this feature "makes
mplayer unusable in any media centre". I am quite precise and specific as
to why this makes mplayer unusable in any media center, in my bug report.

However, you have not responded or examined my reasoning as to why this is
the case. Instead, you have focused on my card for some unknown reason,
even when the topic is not about my card, and the bug report is not
focusing on my card, but the bug report is focusing on what mplayer does
when it discovers a video larger than the allowed XV resolution.

xvinfo | grep maximum

maximum XvImage size: 1440x1080

As you can see, my laptop is unable to play a 1920×1080i movie.

And there is hardly any chance this will change.

I did not file a bug report about this changing. I did not request that
it changes. I did not want it to change.

You have not read my bug report.

If you had, you would have seen that I am looking for mplayer to properly
handle fallback to an alternative -vo, or that I want mplayer to support
software scaling before XV.. both of which DO NOT WORK RIGHT NOW.

You can use software scaling (using something like -vf scale=1440:1080,
maybe you also need to set -aspect 1920/1080),

How will this enable mplayer to properly support keyboardless playing in a
media centre, as my bug report discussed at length? I can not enter the
-aspect information each time, as I do not know the video size ahead of
time.

As well, -scale is over-ridden by full screen mode, something one uses on
a media center.

but it is quite unlikely it will still be fast enough then. There is
simply no way MPlayer can fix crappy hardware.

Now you are insulting my hardware, when it is not crappy.

There were stories about the mplayer team's rudeness and inability to even
look at bug reports or user requests in a polite manner. I see that I
have encountered this now.

However, hopefully you will stop, take a breath, read my original bug
report, and think about what I am saying. Again, stop focusing (as I have
said before!) on my card, and start looking at my concerns about fallback
to an alternative -vo plugin, or allowing software scaling before XV
output.

Note, keeping aspect information by using -xy 720 does _not_ work, there
is a bug that still prevents playback, as listed above. Note that -xo
xv,x11 does not work.

Why do you not address these points? Why do you ignore them every time?
Please show a little more consideration than just brushing me off. Please
re-read my original bug report, and take these things into account.

Thanks

[reimar]

If you had, you would have seen that I am looking for mplayer to properly
handle fallback to an alternative -vo, or that I want mplayer to support
software scaling before XV.. both of which DO NOT WORK RIGHT NOW.

I am sorry, but your bug report left me completely confused as to what it
actually was about (and I was not the only one), so I answered those parts I
could answer. Had the summary been something like "fallback to x11 does not work
with -vo xv,x11" I wouldn't have missed it.
Unfortunately making fallback work properly in this case is very difficult and
unlikely to happen soon.

You can use software scaling (using something like -vf scale=1440:1080,
maybe you also need to set -aspect 1920/1080),

How will this enable mplayer to properly support keyboardless playing in a
media centre, as my bug report discussed at length? I can not enter the
-aspect information each time, as I do not know the video size ahead of
time.

Have you actually tested if -aspect is needed? That "maybe" was supposed to
indicate that I did not need it, but I am not sure if this is always the case.
And actually you should better try something like
-vf scale=1440:1080::::::2
Like this it will not do any scaling if the resolution is lower and the video
can be played without any scaling. The disadvantage is that you will need latest
SVN version for this to work.

Now you are insulting my hardware, when it is not crappy.

I really don't think hardware can be insulted, but if you really mind that much
please read "crappy" as "unsuited for the task", which is basically what I meant.

[bugzilla.mplayerhq.hu@…]

If you had, you would have seen that I am looking for mplayer to
properly handle fallback to an alternative -vo, or that I want mplayer
to support software scaling before XV.. both of which DO NOT WORK
RIGHT NOW.

I am sorry, but your bug report left me completely confused as to what
it actually was about (and I was not the only one), so I answered those
parts I could answer. Had the summary been something like "fallback to
x11 does not work with -vo xv,x11" I wouldn't have missed it.
Unfortunately making fallback work properly in this case is very
difficult and unlikely to happen soon.

No worries.

However, this bug report is not just about fallback to x11, and that's why
the bug report topic is not the one you list above. If it was, this bug
would be closed, because Mplayer is not likely to implement that change.

Fair enough. My goal is not to get fallback working, though. My goal is
to, via some means, find a way to get Mplayer working seamlessly without
keyboard intervention. If fallback can't happen, then perhaps allowing
scaling to happen before XV output is doable? Unfortunately, with the way
fullscreen works, I'm not sure if that's even possible. More below.

You can use software scaling (using something like -vf

scale=1440:1080, > maybe you also need to set -aspect 1920/1080),

How will this enable mplayer to properly support keyboardless playing
in a media centre, as my bug report discussed at length? I can not
enter the -aspect information each time, as I do not know the video
size ahead of time.

Have you actually tested if -aspect is needed? That "maybe" was supposed
to indicate that I did not need it, but I am not sure if this is always
the case.

Mplayer acts "weird" when it comes to handling rescaling and the like. I
can see why some of the weirdness is there, and that's without even
looking at code. Put another way, some of that weirdness is needed. My
initial report goes over it a bit, and I'll go over it here again.

Let's say someone wants to play a video larger than their screen size.
They get:

# mplayer foo.avi
...

VDec: vo config request - 800 x 400 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.00:1 - prescaling to correct movie aspect.
VO: [xv] 800x400 => 800x400 Planar YV12
[xv] Source image dimensions are too high: 800x400 (maximum is 768x576)
FATAL: Cannot initialize video driver.

...

Ok, fair enough. The video is too large, so we can't play it. So, let's
try to scale by various methods. Note, that I MUST pick one resolution to
rescale to, for if I am using keyboardless methods of play, this will have
to sit in a config file...

# mplayer -vf scale=768:576 foo.avi
...

VDec: vo config request - 800 x 400 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.00:1 - prescaling to correct movie aspect.

SwScaler: BICUBIC scaler, from Planar YV12 to Planar YV12 using MMX2
VO: [xv] 768x576 => 1152x576 Planar YV12
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
A: 0.2 V: 0.0 A-V: 0.166 ct: 0.000 1/ 1 ??% ??% ??,?% 0 0 88%

MPlayer interrupted by signal 11 in module: decode_video

• MPlayer crashed by bad usage of CPU/FPU/RAM.

...

So, here Mplayer is told to rescale to 768:576. However, it automatically
tries to scale to correct for movie aspect as well. This is logical, who
wouldn't want the movie to be at the correct playback aspect? However,
this completely over-rides the "Source image dimensions are too high"
check, and scales the video to a size well beyond what XV can handle on this
machine, and results in a crash. Effectively, it ignores my attempt to
scale the video to a dimension small enough so that XV can then play it.

This is the sort of concern I currently have. I am looking for a way to
get Mplayer to play videos reliably, without manual intervention, that are
larger than allowable XV size. This will become a problem for the
community at large, as more and more HD videos are released.

I have monkeyed about quite a bit, and have not found a method that is
workable in all situations. Note that it _must_ be reliable in all
situations, otherwise mplayer becomes non-workable in a keyboardless media
center.

I don't know, perhaps a new option is required? One such as -xvscale, so
that video out will be pre-scaled to as close as possible to the max dimensions
for XV out, before the video is pumped to XV out?

And actually you should better try something like -vf
scale=1440:1080::::::2 Like this it will not do any scaling if the
resolution is lower and the video can be played without any scaling. The
disadvantage is that you will need latest SVN version for this to work.

I do not believe the above will work, unless there has been significant
changes to the way XV output works on that version of mplayer. You can
see the results above of using a single resolution that is then
force-scaled to correct for aspect after...

Now you are insulting my hardware, when it is not crappy.

I really don't think hardware can be insulted, but if you really mind
that much please read "crappy" as "unsuited for the task", which is
basically what I meant.

It's just a standard laptop screen. ;) It has higher output resolutions
than many laptops out there. It is quite suited to the task, frankly.

[reimar]

Just as a note to developers: This is somewhat realted to bug #537.

[compn]

.