Skip to main content

Media time check for notifying BeginningOfContent event in trickplay scenario

6 replies [Last post]
ssathish
Offline
Joined: 2011-05-26
Points: 0

For trickplay scenarios, AbstractDVRServicePresentation.doStartSession() method has a logic to trigger BeginningOfContent event (BOC).

Existing condition:
-------------------
public void doStartSession(...
....
if (mediaTime.getNanoseconds() <= startMediaTimeNanos + (ONE_SECOND_NANOS * rate)){
.....
getDVRContext().notifyBeginningOfContent();
.....
}

For rewind speed and pause(0.0) rates:
--------------------------------------
- BOC event has to trigger if start media time is greater than or equal to current media time. Hence, the check should be:

if(mediaTime.getNanoseconds() + (ONE_SECOND_NANOS * rate) <= startMediaTimeNanos).

Please confirm whether the above mentioned condition is a prediction logic to avoid the platform side to identify the BOC and trigger the event.

Scenario to reproduce:
----------------------
- Select a service and expect TIME_SHIFT_CONTENT
- Wait for 2 seconds to build the buffering (though it is less time for -30x speed, to reproduce the issue we can keep 2 seconds).
- Set the player rate to -30.x speed.

I have attached the RI log for the above scenario. <>

Please share your comments or suggestions.

AttachmentSize
Log_17Jul2012.zip173.98 KB

Reply viewing options

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

The code referenced above is intended to ensure BeginningOfContentEvent is posted when the requested mediatime is outside of the bounds of available buffered content.

The media time passed in during a call to setRate is the current mediatime, so there is no 'jump' outside of buffered content.

If the platform does encounter the beginning of buffered content, possibly before the rate change has had a chance to take effect, the platform is expected to send an MPE_DVR_EVT_START_OF_FILE notification, which would result in a BeginningOfContentEvent being posted.

To summarize, when setRate is called, no BeginningOfContentEvent is expected because there was no 'jump' in mediatime (it is expected that buffered content from the current playback position will be rendered, but just at a new rate).

ssathish
Offline
Joined: 2011-05-26
Points: 0

Thanks for reply.
If the condition is intended to check whether the media time position lies in buffered content's boundary, then could you please clarify on why rate-to-set is considered in the condition check?

My understanding here is, the stack code could predict the occurrence of BOC by considering media time and rate-to-set together, instead of platform side to identify it after applying the requested rate (which will trigger DVR.START_OF_FILE).

cpratt
Offline
Joined: 2008-12-18
Points: 0

Note that it's not really possible for the stack to predict when/where BOC is fired as a platform is allowed to buffer more content than is pre-allocated in the TSB (up to maxDuration parameter specified in mpeos_dvrTsbBufferingStart()). This functionality is a reflection of OCAP's "implicit time-shift buffering" requirement, which allows platforms to implement "elastic" time-shift buffering (e.g. to buffer additional content when there's sufficient free space on the disk).

srinivasrk
Offline
Joined: 2011-10-31
Points: 0

Now, we understood that this check is intended for setMediaTime call and not for setRate. But as per the current code, this check will be run for setRate call as well. This can be avoided using the boolean variable 'mediaTimeChangeRequest'. Otherwise this code will be run for setRate and there are some edge cases where it can result in BOC.

mediaTime <= startMediaTime + (ONE_SECOND_NANOS * rate)
1.3 <= 1 + 0.5

In the above case, this check is true and it triggers BOC. This can be prevented by guarding this check with 'mediaTimeChangeRequest' variable.

srinivasrk
Offline
Joined: 2011-10-31
Points: 0

Any updates on this? I am able reproduce the above edge case using auto DVR Xlet by changing the rate to 0.5 immediately after the service selection. With the 'mediaTimeChangeRequest' check, this case is not happening.

scottdeboy
Offline
Joined: 2009-02-02
Points: 0

Yes, that change needs to be applied. Thanks for creating a Jira issue, I'll take care of it.