Skip to main content

Rel C screen resolution

9 replies [Last post]
rdecker
Offline
Joined: 2009-02-25
Points: 0

The screen resolutions seems to have changed from Rel B to Rel C. In mpeenv.ini I have DISP.DEFAULT.CONFIG set to 5. I have a twb.cfg with

# The RI Emulator device width.
RI.Emulator.TvScreen.width = 960
# The RI Emulator device height.
RI.Emulator.TvScreen.height = 540

The screensize from the awt toolkit returns 960x540. The background config return 640x480, graphics config returns 640x480 and video config returns 720x480 (the channel is SD so this is probably correct). All three return an aspect ratio of 4:3

In Rel B the same channel is full screen and my app (which uses the Toolkit to size itself) is full screen. In Rel C both the channel and the app have pillar bars.

The latter actually sounds correct for an SD channel. Is this something that was fixed in Rel C?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sarendt
Offline
Joined: 2009-07-21
Points: 0

I didn't think that that area of the RI changed between the releases -- let me do some quick testing and get back to you.

sarendt
Offline
Joined: 2009-07-21
Points: 0

I just did a quick test with DISP.DEFAULT.CONFIG=5 and I got (gfx 960x540, vid 1920x1080, bg 1920x1080), which looks right for choice 5. It looks like the settings you are getting correspond to DISP.DEFAULT.CONFIG=0. Is it possible that you have DISP.DEFAULT.CONFIG defined more than once in mpeenv.ini? In the RILog, there are a few lines that give the chosen coherent config -- these lines are prefaced with "RI.Stack- DISP". Maybe looking in your logs for those messages will shed some light on whats going on.

rdecker
Offline
Joined: 2009-02-25
Points: 0

I search mpeenv.ini to make sure DISP.DEFAULT.CONFIG was only defined once and DISP.DEFAULT.GFXCONFIG is commented out.

How are you getting the values you are seeing?

I am expecting to get 720x480 for the SD ts I am tuned to. There is a discrepancy between what the AWT Toolkit returns (960x540) and the HGraphicsDevice config (640x480). This discreprancy was the same in Rel B. The only real difference is that in Rel C the video is shown with pillar bars, whereas the video filled the screen in Rel B.

The emulator window itself does appear to match the DISP.DEFAULT.CONFIG=5 setting in both Rel B & C.

I wrote a test to determine the device resolutions. When I size the HScene to 640x480 I get:

20100915 15:28:19.039 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:288 HBACKGROUNDDEVICE 0 org.cablelabs.impl.havi.port.mpe.HDBackgroundDevice@8f830c69 java.awt.Dimension[width=4,height=3]
20100915 15:28:19.059 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:293 HGRAPHICSDEVICE 0 org.cablelabs.impl.havi.port.mpe.HDGraphicsDevice@d4c30572 java.awt.Dimension[width=4,height=3]
20100915 15:28:19.089 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:298 HVIDEODEVICE 0 0x12a48fa0 java.awt.Dimension[width=4,height=3]
20100915 15:28:19.117 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:284 HBACKGROUNDCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=1,height=1],resolution=java.awt.Dimension[width=640,height=480]
20100915 15:28:19.154 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:284 HGRAPHICSCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=1,height=1],resolution=java.awt.Dimension[width=640,height=480]
20100915 15:28:19.167 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:284 HVIDEOCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=8,height=9],resolution=java.awt.Dimension[width=720,height=480]
20100915 15:28:19.181 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:144 TOOLKIT getScreenSize() java.awt.Dimension[width=640,height=480]

When I size the HScene to 960x540 I get:

20100915 15:39:08.246 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:291 HBACKGROUNDDEVICE 0 org.cablelabs.impl.havi.port.mpe.HDBackgroundDevice@e08053d2 java.awt.Dimension[width=4,height=3]
20100915 15:39:08.259 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:296 HGRAPHICSDEVICE 0 org.cablelabs.impl.havi.port.mpe.HDGraphicsDevice@95c41d5f java.awt.Dimension[width=4,height=3]
20100915 15:39:08.266 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:301 HVIDEODEVICE 0 0x129f8fa0 java.awt.Dimension[width=4,height=3]
20100915 15:39:08.271 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:287 HBACKGROUNDCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=1,height=1],resolution=java.awt.Dimension[width=640,height=480]
20100915 15:39:08.296 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:287 HGRAPHICSCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=1,height=1],resolution=java.awt.Dimension[width=640,height=480]
20100915 15:39:08.306 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:287 HVIDEOCONFIG flickerfilter=false,interlaced=false,aspectratio=java.awt.Dimension[width=8,height=9],resolution=java.awt.Dimension[width=720,height=480]
20100915 15:39:08.310 INFO RI.Stack.StdOut- _DEBUG org.ocapproject.xlet.HelloWorld:121 TOOLKIT getScreenSize() java.awt.Dimension[width=960,height=540]

sarendt
Offline
Joined: 2009-07-21
Points: 0

OK, so if I understand what you are saying, the correct coherent config is being chosen (selection 5) by the RI, but the SD video has pillar bars on the side when it is embedded in the HD video plane. And the pillars are only present in rel C and not in rel B.

That sounds like either the DFC is different or the DFC handling has been inadvertently changed in the RI. The pillar bars would come from DFC = pillar, while the full screen would come from DFC = full.

p.s. I got my resolution values from the log -- the chosen coherent confg is printed out in DISP log messages.

rdecker
Offline
Joined: 2009-02-25
Points: 0

Yes. I get this:

20100915 14:32:33.095 INFO RI.Stack- DISP: Initial device config:(gfx 960x540 16:9,vid 1920x1080 16:9,bg 1920x1080 16:9)

I'm reading up on the H*Device and Section 25.2.1.1 of the OCAP 1.1.3 spec to see if I can get a better understanding of what is occuring.

Is it that the H*Devices are defaulting to the minimum supported configuration?

I am only looking at the configuration returned by H*Device.getConfigurations().

I am trying to understand how the configuration would be selected and set. Would this be dependent on the implemention for a particular stb or would an MSO determine the settings via a monitor app, for example?

rdecker
Offline
Joined: 2009-02-25
Points: 0

It seems like Issue 211 may be the reason for the pillar bars. I remember seeing an HPermissionDenied exception on start up in Rel B that is now gone in Rel C.

But I still don't know if it's correct behaviour or not for the HGraphicsDevice to have pillar bars when the HVideoDevice.

rdecker
Offline
Joined: 2009-02-25
Points: 0

Section 5.2 of the Device Settings Extension indicates that the behaviour I am seeing in Rel C is correct. Section 5.2.5 sounds like what is happening:

"When resolution of the video output port is
dynamically changed, the aspect ratio of the HScreen and the resolution of HScreen devices are also changed..."

Thanks for pointing me in the right direction.

sarendt
Offline
Joined: 2009-07-21
Points: 0

One last note: H*Device.getConfigurations() returns an array of available configurations, while H*Device.getCurrentConfiguration() returns the actual current configuration, so getCurrentConfiguration sounds like the one you want.

rdecker
Offline
Joined: 2009-02-25
Points: 0

In the OCAP 1.1.3 spec on page 235 Figure 25-1 shows set#2 in the middle of the page with SD video input of 720x480 and a graphics device of 960x540.

On page 234 Table 25-2 shows the sets the implementation shall make available.

It seems to me that the scene I have sized to 960x540 for the graphics device as returned by the AWT Toolkit should be the size of the scene and not resized with pillar bars as the SD channel is (and should be).

Can someone confirm if my interpretation of the spec is correct?