[MPlayer-cvslog] r28546 - in trunk/libvo: video_out.c video_out.h vo_direct3d.c vo_xv.c vo_xvmc.c

[The Wanderer]

Reimar Döffinger wrote:

> On Sun, Feb 22, 2009 at 09:14:09AM -0500, The Wanderer wrote:
> 
>> reimar wrote:
>> 
>>> Author: reimar
>>> Date: Thu Feb 12 18:40:53 2009
>>> New Revision: 28546
>>> 
>>> Log:
>>> Add a calc_src_dst_rects that calculates from window size, panscan etc.
>>> which part of the video source must be scaled onto which part of the window.
>>> Direct3D and (future) VDPAU need this, for XvMC it makes it easier to add
>>> cropping support and Xv is changed to keep the diff to XvMC small.
>> 
>> This revision broke fullscreen (and possibly some scaled
>> non-fullscreen) playback for me.
>> 
>> Prior to this, I get what appears to be normal, correct playback.
>> 
>> With this revision and after, when using either '-fs' or '-xy (my
>> monitor X resolution)', the top of the image is visibly further
>> down from the top of the screen than it should be, and the bottom
>> of the image is visibly cut off by the bottom of the screen - by
>> enough to cut off all subtitles in at least one case I tested, and
>> by more with '-fs' than with the other option. The left edge of the
>> image may also be shifted right similarly, but because of the
>> aspect ratios I have immediately available (320x240 files,
>> 2560x1600 monitor) it's difficult to tell.
>> 
>> This behaviour occurs at least with -vo {xv,vdpau}, I haven't tried
>>  others yet.
>> 
>> I don't see any obvious differences between the console output of
>> the two versions.
>> 
>> Any suggestions on how to pin down the cause?
> 
> Not really, I just tried again with a 352x288 video on a 1680x1050
> screen, using latest NVidia drivers.

I'm using not-quite-latest - 180.22, vs. the current 180.29. But it
works perfectly fine with older revisions, and in all other respects in
the current revision (aside from a strange issue with -vo vdpau which
looks like a refresh-rate problem, but that should be entirely
separate), so I'd be hesitant to suspect that as the cause.

> I also added -aspect 2 and -aspect 0.7 and the video is exactly
> (well, as much as I can tell) centered for all cases.
> 
> -xy does not even enable the code that creates borders, so if you use
> only -xy (not -fs or switched to fullscreen otherwise) I can't see
> how this should be possible...

I've just tested with the "known good" revision, and -xy 2560 cuts off
the edge of the image even there; that appears to be a red herring. Now
that I think about it, that part is almost certainly because a 4/3 image
with X=2560 is going to be taller than a 16:10 screen will be able to
fit...

> Have you checked that there are not some custom patches applied that
> might cause issues?

I've never applied any custom patches as far as I remember, but just in
case, I just checked out a clean copy and compiled that to the latest
revision; it happens there exactly the same way, as far as I can tell at
a glance.

I can provide my config file (nothing especially unusual AFAIK) and any
desired level of verbose output if you'd like, but I'm not sure how much
good either would do.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.