WSS support now full-featured; testers needed

[Nicolas Boullis]

Hi,

Warning: WSS (WideScreen Signalling) only works if your Hollywood+ or
DXR3 board has an ADV7170 video encoder (ADV7175A end BT865 don't
support WSS), and if your TV set understands it (my good old 4:3 CRT TV
does not).

I think I have achieved a functional support for WSS with the em8300
driver. Not that this is not available yet in the main repository, but
only in my
  http://freehg.org/u/nboullis/em8300-scale-n-crop/
repository.

This support works with userspace callback programs that are called
whenever the aspect ratio is set. A callback program that sets the TV
aspect ratio to match the stream aspect ratio + set WSS accordingly is
provided in scripts/aspectratio_wss_callback.sh (installed in
/usr/share/em8300/aspectratio_wss_callback.sh). It needs to be enabled
by loading the em8300 module with the
"aspect_ratio_callback=/path/to/aspectratio_wss_callback.sh" parameter.

Note that this architecture allows to use any callback function. Since
my TV set does not support WSS, but does support aspect ratio selection
through SCART pin 8, I'm planning to build some homebrew hardware +
build a dedicated script to switch my TV's aspect ratio that way.

The good news is that all this does not require any change in the
userspace applications. For example, no need to patch the dxr3 plugin
for vdr. Just set your application as if you TV set was 4:3.

Since I can't test WSS, I need some feedback!


Some planned improvements are:
 - allow to set the callback function when the module is already loaded
   (probably through sysfs)
 - merge into the main repository


Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Ville Skyttä]

On Saturday 31 May 2008, Nicolas Boullis wrote:
>
> I think I have achieved a functional support for WSS with the em8300
> driver. Not that this is not available yet in the main repository, but
> only in my
>   http://freehg.org/u/nboullis/em8300-scale-n-crop/
> repository.

I (finally!) got around to testing this after applying some changesets from
the main repository to get it to compile.  catting 7 and 8 to encoder/wss
appears to work as expected, my TV does adjust the picture.

However:

> This support works with userspace callback programs that are called
> whenever the aspect ratio is set. A callback program that sets the TV
> aspect ratio to match the stream aspect ratio + set WSS accordingly is
> provided in scripts/aspectratio_wss_callback.sh (installed in
> /usr/share/em8300/aspectratio_wss_callback.sh). It needs to be enabled
> by loading the em8300 module with the
> "aspect_ratio_callback=/path/to/aspectratio_wss_callback.sh" parameter.
>
> Note that this architecture allows to use any callback function. Since
> my TV set does not support WSS, but does support aspect ratio selection
> through SCART pin 8, I'm planning to build some homebrew hardware +
> build a dedicated script to switch my TV's aspect ratio that way.
>
> The good news is that all this does not require any change in the
> userspace applications. For example, no need to patch the dxr3 plugin
> for vdr. Just set your application as if you TV set was 4:3.

The results of this were not too good for me with a 16:9 TV with VDR, neither
when VDR set to 4:3 nor 16:9 mode.  It's quite hard to explain exactly what
was wrong, there are a lot of settings involved (TV settings, VDR settings,
vdr-dxr3 settings, what the script does internally, what vdr-dxr3 does
internally) so I won't even try at the moment because I can't remeber the
exact problems that occurred with various settings and testing everything
again would take hours...  But anyway changing the script so that it never
writes anything to tv_aspectratio (i.e. only writes to encoder/wss) and
applying the attached patch to the vdr-dxr3 sources (latest on vdr-dxr3-0-2
branch in CVS) makes things work well here.

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 :).  Note to self: maybe the "force letterbox" setting of vdr-dxr3
should be changed into a persistent config entry instead of just a menu
toggle.

Based on this (little) experience, I find the script approach a bit
cumbersome - couldn't the driver just do the WSS thing itself if the script
is not enabled by the module option, and outsource everything to the script
if it is enabled?

[attachment removed]
-------------------------------------------------------------------------
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

[Nicolas Boullis]

Hi,

On Sat, Oct 25, 2008 at 11:54:43AM +0300, Ville Skyttä wrote:
>
> I (finally!) got around to testing this after applying some changesets from
> the main repository to get it to compile.  catting 7 and 8 to encoder/wss
> appears to work as expected, my TV does adjust the picture.

That's already good news! ;-)


> The results of this were not too good for me with a 16:9 TV with VDR, neither
> when VDR set to 4:3 nor 16:9 mode.  It's quite hard to explain exactly what
> was wrong, there are a lot of settings involved (TV settings, VDR settings,
                                                   ^^^^^^^^^^^
Does this mean that your TV settings change the behavior? I would have
thought that that WSS thing would override the TV settings.
Out of curiosity, what king of things can you configure on your TV?


> vdr-dxr3 settings, what the script does internally, what vdr-dxr3 does
> internally) so I won't even try at the moment because I can't remeber the
> exact problems that occurred with various settings and testing everything
> again would take hours...  But anyway changing the script so that it never
> writes anything to tv_aspectratio (i.e. only writes to encoder/wss) and
> applying the attached patch to the vdr-dxr3 sources (latest on vdr-dxr3-0-2
> branch in CVS) makes things work well here.

Hmmm... that really sounds strange. There might be something I badly
misunderstood about WSS...
What is your tv_aspectratio set to? 16:9?

My understanding was that everything was expected to be fine with an
unpatched vdr-dxr3 plugin with vdr set to 4:3 and WSS disabled in the
plugin.


> 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?


> Note to self: maybe the "force letterbox" setting of vdr-dxr3
> should be changed into a persistent config entry instead of just a menu
> toggle.
>
> Based on this (little) experience, I find the script approach a bit
> cumbersome - couldn't the driver just do the WSS thing itself if the script
> is not enabled by the module option, and outsource everything to the script
> if it is enabled?

I don't think it would be a good idea to use WSS by default on cards
with ADV7170 chips, for 2 reasons:
 1) it would mean that with default configuration, cards with ADV7170
    behave very differently from other cards;
 2) not all TV sets understand WSS (mine does not); if it were used by
    default, then aspect ratios would appear broken for users of such TV
    sets.

With my code:
 1) by default, everything works the same for all cards (like in main
    branch);
 2) one can choose his/her output aspect ratio and have black bars when
    needed (better than in main branch that only supports black bars for
    16:9 -> 4:3);
 3) those with the needed hardware can use a specific configuration
    (either WSS, or any other special setup) and let their TV do the
    required scaling for a better image quality;
 4) those who like distorted images can use a script that always
    displays fullscreen, even with no support from the player.

As for doing this in userspace vs kernelspace, I think that most people
feel it easier to hack their own script for special needs than to hack
the module code. I think that people would be especially willing to have
some special setup if AFD could be used.

For example, if the image is 4:3 with shoot and protect 14:9 centre:
 - most users with a 4:3 TV set will want to see the full image
 - some users with a 16:9 TV set will want to see the full image, with
   big black borders on the sides
 - some users with a 16:9 TV set will want to see the image cropped to
   14:9 with small black borders on the side
 - some users with a 16:9 TV set may want to see the image cropped to
   16:9, no matter if they loose some valuable parts of the image
 - some users with a 16:9 TV set may want to see the image cropped to
   16:9 and slightly distorted to display fullscreen
 - some users with a 16:9 TV set may want to see the full image
   distorted to display fullscreen
 - anything else I could not imagine...

I don't think I can write a reasonnable list of possible setups that
would fit everyone's needs. That's why I thought that using a userspace
script was the besto solution.


Cheers,

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

[Ville Skyttä]

On Sunday 26 October 2008, Nicolas Boullis wrote:

> Does this mean that your TV settings change the behavior?

Well, yes and no.

> I would have
> thought that that WSS thing would override the TV settings.

It does to some extent.  See below.

> Out of curiosity, what king of things can you configure on your TV?

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.

> > vdr-dxr3 settings, what the script does internally, what vdr-dxr3 does
> > internally) so I won't even try at the moment because I can't remeber the
> > exact problems that occurred with various settings and testing everything
> > again would take hours...  But anyway changing the script so that it
> > never writes anything to tv_aspectratio (i.e. only writes to encoder/wss)
> > and applying the attached patch to the vdr-dxr3 sources (latest on
> > vdr-dxr3-0-2 branch in CVS) makes things work well here.
>
> Hmmm... that really sounds strange. There might be something I badly
> misunderstood about WSS...
> What is your tv_aspectratio set to? 16:9?

Yes.

> My understanding was that everything was expected to be fine with an
> unpatched vdr-dxr3 plugin with vdr set to 4:3 and WSS disabled in the
> plugin.

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...

> > 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,
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.

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.

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

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.

-------------------------------------------------------------------------
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

[Ville Skyttä]

On Sunday 26 October 2008, Ville Skyttä wrote:

> I'm too confused to be able to say anything more or continue testing at
> this point.

And now even more, even the setup I had working no longer does after a reboot.  
I'm back to release versions for now.

I still don't understand why vdr-setting the card always to 4:3 mode when VDR
is in 16:9 mode is desirable, but the plugin does exactly that, and things
seem to work that way.  Sigh.

-------------------------------------------------------------------------
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

[Nicolas Boullis]

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

[Ville Skyttä]

On Monday 27 October 2008, Nicolas Boullis wrote:
> On Sun, Oct 26, 2008 at 05:45:05PM +0200, Ville Skyttä wrote:

> 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?

I guess the 16:9 mode is what you're after with "normal".

> > > 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?

Yes, those, plus the the aspect ratio script changed to touch only
encoder/wss.  (But as I noted in a later mail, this did not work after a
reboot any more :()

> 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.)

Sure, I can test them.

> > 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?

No, it obeys WSS (I suppose).  16:9 video is shown full screen, as is.  4:3
video is shown in the middle of the screen, full height, reduced width, black
bars on left and right.  But this result might be subject to inconsistency as
well, as said, it started behaving oddly after a reboot.

> Does it make a difference if you simply disable the
> script?

I haven't tried that, will do when I find time to try out again.

> 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. [...]

Thanks a bunch for the lengthy explanation, I'm sure it'll be helpful when I
can find the time to digest it better :)

> fullscreen mode (misnamed 4:3)

Hmm.  Do you mean that it would be more accurate to call
EM8300_ASPECTRATIO_4_3 for example EM8300_$something_FULLSCREEN (ditto other
EM8300_ASPECTRATIO_* renamed to something similarly more descriptive)?  If
yes, that would have saved me some confusion...

-------------------------------------------------------------------------
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