Skip to main content

DVRExerciser xlet on Tru2Way device

10 replies [Last post]
amirn
Offline
Joined: 2009-05-06
Points: 0

Hi,

I have started using DVRExerciser xlet on a Tru2Way device running RI.1.1.4RelA

I have noticed a some issues and would like to know if these are known issues or not.

1. Scaled Video does not seem to work (i.e video remains full screen). This works fine on the RI-Emulator. Note also that Scaled Video IS working with the Guide Application running on the Device.

2. The DVRTest xlet does not take OverScan into account. As a result the traces appears to far to the left.

3. There seemed to be alpha blending issues on the Recording selection screen (text is punching through the scaled video area). This seems to also happen on the RI-Emulator.

4. It looks like the trick play index is not exercised correctly.
From Pause -> Press rewind
Expected result is the rate should be -1. Instead it is set to 0.5, then goes to -1 (after another rewind key press).

Amir.

Message was edited by: amirn

Message was edited by: amirn

Message was edited by: amirn: add some more issues to the list

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
smallman
Offline
Joined: 2004-06-19
Points: 0

These changes to DVRExerciser are currently held up due to time spent testing Rel 1.1.4. We anticipate make the changes after the release.

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

I have started to look at these issues, particularly issue#3.

It turns out that the problem is more complicated than an alpha blending issue with the video (for example, the flickering occurs in areas outside the video quarter screen).

The flickering occurs when one of the graphics components (e.g. recording indicator) triggers a repaint of part of the screen that includes part of the Recording Selector. That part of the screen is cleared in preparation for the paint. But, the renderVisible method for HListGroupLook resets the clipping area of the Graphics instance that it receives to be the full visible area of the list box, when it should be the intersection of the visible area with the current graphics clipping area. The result is text being redrawn to an area of the screen that was not cleared. This redraw makes the text darker.

The flickering occurs when the full screen is repainted and the text returns to its non-dark correct state.

I have a fix already, and will check it in when our current code freeze is lifted.

I'll look into the other issues as well.

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

Here's the progress. Issues #1 - #3 are fixed. For issue #4, I could use some input.

#1: In rev 9081, I removed some "dead" code that was supposed to set the video to quarter screen, but which never worked.

#2: In rev 9081, I added code to shift the log text lines in a bit so that they can be displayed on a TV Screen (this is Amir's issue #2).

#3: I checked in the fix for the flickering screen -- it is in rev 9026 and is in a Havi class HListGroupLook.

#4: I see your point, but I don't see a way to change the UI so that it is still intuitive for the user to figure out how to go to half-speed forward. Any suggestions?

amirn
Offline
Joined: 2009-05-06
Points: 0

Regarding #4, I actually ended up not using the rate array, instead I have implemented separately all the playback methods.

You can set slow-motion rate (0.5) when user presses FAST-FORWARD from PAUSED state.

smallman
Offline
Joined: 2004-06-19
Points: 0

DvrExerciser is a handy tool for demonstrating the behavior of applications and ports and we want it to be useful beyond its original design.

Issue 1: You may modify DvrExerciser to fit your needs for scaled video. Is this acceptable?

Issue 2: The Xlet was designed primarily for use with the emulator. We do not run it on “real” STBs here so we do not have a way to test for this. Can you please recommend changes to take OverScan into account?

Issue 3: We see a slight flickering of the text. Is this the issue?

Issue 4: Trick play seems to be working correctly running with Rev 8368. Transitions between Pause and Rewind display as expected. Do you have a log?

amirn
Offline
Joined: 2009-05-06
Points: 0

Issue #1
This was identified as a platform issue. The way DVRExerciser sets scaled video bounds is by using VideoTransform. Which required the platform to cache the bounds and apply them when video decoding actually happens.
The platform MPEOS port was not setting the initial bounds.

There is still an issue with DVRExerciser: it is trying to also use AwtVideoSizeControl BEFORE a player is available. That doesn't work, because the control is not available until a JMF player is in realized/started state.

Issue #2
The fix is fairly simple and requires text coordinates to be 5% off the edge of the screen. That way it will be correctly seen on a TV screen.

Issue #3
The flickering is due to text pixels punching through the video. I believe this is problem is due to text color using an alpha value of < 255.

Issue #4
This is related to how trick modes are used by DVRExerciser.
Currently it seems to simply cycle through the array of trick mode rates.

So for example:
- current rate = 1.0 (normal play)
- press rewind : the rate going to 0.5 (previous rate in the array). So as a result
the video goes in slow forward instead of reverse.
The expected result would be for rate to go from 1.0 to (-1.0), then to (-2),etc...
If we press forward it should go back to (1.0) then (2.0),etc...

amirn
Offline
Joined: 2009-05-06
Points: 0

Okay. I noticed that DVRExerciser is using VideoTransformation. Isn't that only available with DeviceSettings Extension?

If DS is not enabled, I am assuming the Video will remain in full screen.

I also noticed that AWTSizeControl is being used in the Xlet, Is that used as a fall back, (i.e if DS extension is not available)?

In my case I don't see AWTSizeControl.setSize() being invoked.

Amir.

amirn
Offline
Joined: 2009-05-06
Points: 0

It turns out that VideoTransformation bounds are cached, regardless of DeviceSettings Extension. So everything in RI seems to be okay.

In DVRExerciser, both VideoTransformation and AWTVideoSizeControl are used.
However AWTVideoSizeControl is never going to work, because a Player is not available when the xlet is setting the bounds.

So the bounds are effectively set via VideoTransformation.

My conclusion is that problem #1 is an MPEOS or Platform issue and not a problem in RI implementation.

david_crandall
Offline
Joined: 2010-01-05
Points: 0

I'm seeing #1 happen as well with the lack of scaled video. I haven't bothered to look too deeply into it.

amirn
Offline
Joined: 2009-05-06
Points: 0

It looks xlet code is hard-coded to run only is 640x480 mode and is assuming the video is always Standard-Def.

Although the device is configured that way too, it seems like the scaled bounds are invalid. I will capture a log and see what's going on when AWTSizeControl is invoked.