« Return to Thread: WSS support now full-featured; testers needed

Re: WSS support now full-featured; testers needed

by Nicolas Boullis :: Rate this Message:

Reply to Author | View in Thread

Hi,

On Sun, Oct 26, 2008 at 05:45:05PM +0200, Ville Skyttä wrote:

>
> The aspect ratio button toggles between "Panasonic Auto", 16:9, 14:9, "Just",
> 4:3, "Zoom1", "Zoom2" and "Zoom3".
>
> IIRC "Panasonic Auto" tries to autodetect black borders around the image and
> get rid of them by cropping or something when needed, 16:9 is full screen,
> 14:9 and 4:3 add grey bars on the sides of the image, "Just" does something
> where 16:9 is displayed as is, and 4:3 is stretched to full screen so that
> the stretch increases towards sides of the picture, and there's not much (if
> any) at all stretching at the center.  The Zoom* do some zooming but I have
> never found them useful at all so I've ignored them.
>
> WSS affects all of these modes.  Some mode specific properties do stay in
> effect though, such as zoom levels with Zoom* or grey bars on the sides of
> the picture with 14:9 and 4:3.

I'm not sure I understand all this, but I guess it does not matter
much...
Just curious anyway, isn't there a "normal" mode were the TV follows the
modes specified with WSS? Or does WSS switches the TV from 16:9 to 4:3
and back?



> The changes I made to vdr-dxr3 should not affect anything if VDR is set to
> 4:3.  Before the changes, when VDR was set to 16:9, the plugin always set the
> aspect to 4:3 when cDxr3Interface::SetAspectRatio was called, no matter what
> the requested aspect ratio was - I don't see how that would ever be the
> desired behavior.  When VDR was set to 4:3, the driver was always asked to
> set 16:9 or 4:3 according to what was passed to SetAspectRatio.  Now it does
> that no matter if VDR is set to 16:9 or 4:3 which I think makes sense.  (I
> haven't had WSS enabled in the dxr3 plugin in a while nor the WSS patch
> applied to the drivers, so that's not a factor in these tests.)
>
> If things Just Work with VDR configured to 4:3 mode on 16:9 setups too, that's
> fine, but IMO it needs to Just Work also if VDR is configured to 16:9 mode.  
> I'd find it very odd if I had to configure VDR "wrong" for a 16:9 setup to
> get it to work correctly...

My understanding is that that "stange" behavior (setting the aspect
ratio to 4:3 no matter what the requested aspect ratio was, when VDR was
configured set to 16:9) was a workaround for a deficiency in the em8300
hardware/firmware/driver. (See below for my explanations...)

But with a better featured hardware/firmware/driver, it becomes a bug...


> > > I do get a bit annoyed when watching 4:3 video shown as plain 4:3 with
> > > black bars on the sides of the screen though, it's been a long time since
> > > I've seen that :).
> >
> > Hmmm... Here I'm not sure I understand you correctly... Does this mean
> > you like broken aspect ratio: 4:3 images stretched horizontally to 16:9?
>
> No, I mean that in my current setup which I described in my previous mail,

You mean with your patched vdr-dxr3 plugin, and using the
em8300-scale-n-crop branch?


> there's no stretching at all, and nothing's broken.  16:9 is full screen, 4:3
> is a unstretched 4:3 area in the middle of the screen, with black bars on
> left and right.  But the 4:3 box is a bit annoying (or maybe "unfamiliar"
> describes it better), I had got used to it being stretched to full screen
> with (IIRC) the "Just" mode which did a decent job with no WSS present by
> stretching 4:3 more from the sides and not at all from the center so that the
> result was full width picture.
>
> By the way, the old vdr-dxr3 WSS patch only set WSS for 16:9; for 4:3 it
> turned WSS off.  I don't know if it's better or worse than setting 4:3 WSS,
> but I thought I'd mention it.

My understanding is that WSS is used to tell the TV Set the aspect ratio
of the image. Then I would guess that turning WSS off would mean
something like "we don't know the aspect ratio of the image". Then I
would thing that setting 4:3 WSS is better than setting no WSS.

But I have no WSS-able TV set, and my understaning of WSS may be broken.
Hence your tests may be more valuable than my understandings...



> There are so many moving piecese that I don't know where to start... and even
> some inconsistency which does not help at all but here's something.  All of
> these have the vdr-dxr3 patch I posted applied.  For all these results I
> consider 16:9 correct if it's full screen, and 4:3 correct if it's shown in a
> 4:3 box at the center, with thick black bars at left and right
> (the "stretched" things below are relative to these assumptions).  TV is set
> to 16:9 all the time.

As for the "stretched" thing, I'd rather check whether the squares are
actually square. I might make a few MPEG2 streams that display squares
both in 4:3 and in 16:9, if you're willing to test thems. (And using a
ruler would help; it tends to be much more accurate than our eyes and
brain.)


> VDR set to 16:9, tv_aspect 16:9, script sets only WSS:
> Consistent results, both 16:9 and 4:3 work correctly

I really fail to understand how this can work. Does WSS have an effect
when your TV is set to 16:9; doesn't it force your TV to 16:9 no matter
what WSS says? Does it make a difference if you simply disable the
script?


> VDR set to 4:3, tv_aspect 4:3, script sets only WSS:
> Consistent results, 4:3 stretched to full screen, 16:9 has black bars at top
> and bottom (I assume this would be desired with a 4:3 TV)
>
> I thought I'd list here different things that happen with VDR set to 4:3 or
> 16:9 when the script sets both aspect and WSS, but they vary so wildly and I
> don't find any consistent pattern (except that the picture is almost always
> wrong in some way) that it makes no sense.  Maybe there's some kind of a race
> condition when both aspect and wss are set rapidly one after another that
> makes things go south?  Or maybe the dxr3 plugin when storing the internal
> state of the aspect "remembers" it wrong sometimes and things start failing
> from there?
>
> I'm too confused to be able to say anything more or continue testing at this
> point.

I'm confused as well, but here is my understanding, with the hope that
it will help...


The hardware/current firmware only know 2 display modes: full screen
and vertically compressed with black bars on the top and bottom 1/8s of
the screen. When it sees a 4:3 indication in the MPEG stream, it
switches to full screen; when it sees a 16:9 indication, it switches to
compressed with balck bars. With a TV set in 4:3 mode, everything
appears fine (except that if the TV set is 16:9 set to 4:3, and you are
playing a 16:9 video, you have black bars all aroud the image).

To improve things with owners of 16:9 TV sets, I think the author(s) of
the vdr-dxr3 plugin decided to force the fullscreen mode (misnamed 4:3)
when vdr is set to 16:9. Hence, 16:9 videos are output fullscreen as
would be expected. But 4:3 videos are also output fullscreen, so either
the image appears stretched or the user has to manually switch his/her
TV set to 4:3 mode. I think it was the best possible choice the the
em8300 hardware/firmware/driver lacked the ability to add black bars on
the sides to display a 4:3 video in a 16:9 output...

Now, my scale-n-crop code plays with the DICOM parameters to resize the
image, and always set the mode to fullscreen. It uses 2 parameters to
take its scaling decision: the output aspect ration (called "tv aspect
ratio") and the video's aspect ratio. If both are the same, the video is
output fullscreen. If the output aspect ratio is 4:3 while the video's
aspect ratio is 16:9, the DICOM parameters are changed to add black
borders on the top and bottom of the image. If the output aspect ratio
is 16:9 while the video's aspect ratio is 4:3, the DICOM parameters are
changed to add black borders on the left and right sides if the image.

All this assumes a constant output aspect ratio. The downside of this is
the loss of resolution of the image. So for a better image quality, the
video should always be output fullscreen and the TV set should be
expected to add the black borders as needed. That's where WSS (or SCART
pin 8) comes.

Then my script changes the output aspect ratio to match the video's
aspect ratio (to ensure the video is output fullscreen, so no quality
is lost), and uses WSS to tell the TV set what the output aspect ratio
is. If you disable the setting of the output aspect ratio in the screen,
then the output aspect ratio does not match what is told to the TV set,
and the image is expected to be distorted...


HTH,

Nicolas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

 « Return to Thread: WSS support now full-featured; testers needed