Skip to main content

Video device default resource contention is not sufficient

Please note these forums are being decommissioned and use the new and improved forums at
1 reply [Last post]
Joined: 2010-06-17

The default implementation of the resource contention handling gives a favor to the client which already owns the resource in the case when that client and the other client which asks for the resource are of the same priority.
This is especially a problem when both requests are originated by the same application.
Spec is silent on how resource management should be handled for such cases. It mostly cares of resource contention management between different apps rather than requests from the single app assuming the app should handle resource contention itself.

More specifically:

  • An application taken video device as part of the resource acquisition for the abstract player ( Such an acquisition is called implicit and produces special class of resource usage - ServiceContextResourceUsage. This resource remains busy until player is stopped (which normally never happens as some service is almost always presenting)
  • The same app when trying to change video configuration also needs to acquire video device (which is done automatically by the HVideoDevice.setVideoConfiguration() implementation. In this case ApplicationResourceUsage is constructed for the request.
  • Both requests are originated by the same app thus same priority, etc. The default contention handler will keep the resource for the first client, i.e. player and reject a request to change the video config.

This is really arbitrary thing which needs discussion.
Here are some thoughts/approaches.

  1. It can be an application responsibility to stop the player before accessing video device. In this case nothing has to change in the implementation.
  2. Implicit requests may have less priority for the default contention handler. In this case an ApplicationResourceUsage will get a favor over ServiceContextResourceUsage
  3. Specs says that the default contention handling can treat different resources differently. Thus the default contention logic for the video device can be modified to give a favor to the explicit application requests over implicit ones
  4. No resource management for the requests from the same app, the priority have the one who come last.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-12-18

This is a very complicated and troublesome topic.
MHP has language that makes it clear that the owner of the HVideoDevice (which is what is modeled in the DAVIC resource contention) is different from the "video controller". The OCAP_RI-240 bug has more detail on the issue.
Stopping the Player results in both the HVD and Controller reservations being released. So that will certainly work. But any solution in the ResourceContentionHandler space needs to be preceded by a determination of whether the HVD and Controller are one in the same or whether the Controller is modeled in the DAVIC RC space by a discreet (new) ResourceProxy type. Both will require spec language and (I presume) validation that they won't impact existing guide applications. I think the former has the best chance of not causing backward-compatibility issues.