Skip to main content

RI is including only audio and video pids for buffering/recording

1 reply [Last post]
aathisiva
Offline
Joined: 2011-01-19
Points: 0

The section 6.5 of spec (ETSI TS 102 816 V1.1.1 (2007-09)) says,

All streams within the service shall be recorded including those carrying dynamic data such as MHP
application signalling, DSMCC object carousel(s), stream events and MPEG-2 private sections to be accessed
via the section filtering API.

In loadPidMapTable() of TimeShiftWindow I could see the following code snippets,

if (!sce.isMediaStream())
{
continue;
}

This allows only audio and video pids to be added in to the pidMapTable.

Other pids like subtitles/data/sections are not added into the pidMapTable.

Is this done intentionally to include only audio and video streams? Why cant we include all the pids?

Awaiting your valuable replies.

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

[sorry for the delayed reply - I was out last week]

ETSI TS 102 816 is technically the MHP specification and doesn't apply to OCAP/tru2way.

The "common core" (MHP GEM DVR) is ETSI TS 102-817 and is incorporated into OCAP via OCAP-DVR-N-07.1017 (ECN-1017). Section 6.5 of this document doesn't contain the above requirement and only states "The definitions of which streams are to be recorded in timeshift recording is outside the scope of the present document and should be specified by GEM recording specifications."

However, the time-shifted application support described by ETSI 102-817 (Section 9) implies the ability to time-shift applications and MPEG table sections - but leaves it to the implementation to determine the most appropriate way to provide this support.

The RI does not currently support time-shifted applications as required by DVR GEM. This feature is on the RI "backlog" awaiting prioritization. The change described above would only be a small part of the change required for time-shifted application support and would be dependent on establishing the division of labor between the portable RI code (MPE/Java) and the platform-level code. e.g. time-shifted applications might be better supported utilizing the RI's already-existing application storage support - which would have the advantage of not requiring carousel storage and would work with applications delivered via HTTP and carousel.