Skip to main content

MediaAccessAuthorization for RecordedServicePresentation

1 reply [Last post]
vishaln
Offline
Joined: 2011-01-27
Points: 0

Currently in RI, MediaAccessAuthorization check is implemented for BroadcastServicePresentation, RecordedServicePresentation and TSBServicePresentation.
But for RecordedServicePresentation, updateMediaAccessAuthorization() method proceeds with authorization only if the boolean isLive is set. isLive is set only when a program at live point is being recorded.
Spec Reference: 21.2.1.22 Media Presentation Management (OC-SP-OCAP1.1.3-100603.pdf)
Spec indicates that a MediaAccessHandler can prevent the presentation of A/V service components when a new service is selected.
New service can be a "Recorded Service"! Authorization should be done for playback of a recording which is in progress and for playback of completed recording.
Can anyone please shed some light on the consequences of removal of isLive check in updateMediaAccessAuthorization() and mediaAccessAuthorizationRequired() methods of RecordedServicePresentation?

Reply viewing options

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

There are a couple issues with invoking the MediaAccessHandler for RecordedServices:

  1. The invocation of checkMediaAccessAuthorization() requires an ElementaryStream array reference. There's no text describing what an ElementaryStream looks like for a RecordedService. We could create an arbitrary object, but without spec definition, an application cannot do anything with them to determine if they should or shouldn't be authorized and populate the return MediaAccessAuthorization object.
  2. There's no DVR text describing which conditions leading to a MediaPresentationEvaluationTriggers need to be recorded by a DVR-enabled OCAP implementation (which would need to be in section 6.2.1.1.3 of DVR I06). e.g. There's no requirement that a DVR implementation is required to record data sufficient to signal the (mandatory) MediaPresentationEvaluationTrigger PMT_CHANGED. And if it did, it just leads back to (1): How does the implementation describe the components changed?
  3. It is not specified how MediaAccessConditionControl.conditionHasChanged() invocations are to be handled for RecordedService (or time-shift). e.g. If an application calls MACC.conditionHasChanged(USER_RATING_CHANGED), does this apply at the record point and the implementation should generate checkMediaAccessAuthorization() when the associated media-time is encountered on playback, or is checkMediaAccessAuthorization() called immediately? There are pros/cons to either - but it's not clear what the DVR semantics are.

The RI has already made assumptions outside the spec for time-shifted presentation (TSB presentation). But for RecordedServices, applications have the ability to utilize recording metadata for doing things like ratings association (using RecordingRequest.addAppData()). So extrapolating these assumptions even further seemed like a step too far into the unknown/unspecified when there's a viable alternative.