Skip to main content

Confusion over RecordingSession.elementaryStreamsToPidMapTable()

2 replies [Last post]
Joined: 2010-06-17
Points: 0

I'm trying to understand how this function works, and more importantly what it is meant to acheive.

It seems that given a bunch of of ElementaryStreamExt [streams] it then creates another bunch of PidMapEntry in a PidMapTable.

My question relates to the addition of the PCR stream.

There is a test to see if one of the entries in details [not the parameter streams which is used as a size parameter to the PidMapTable] has the same PID as the details PcrPID. If the PIDs match the pcrComponent is assigned to that component. Aside from repeated calls to details.getPcrPID(), which makes an asynchronous call to the SI Database, this seems reasonable.

Now, having found the PID of the PCR a final entry is added to the PidMapTable, but this still takes the stream type of the source component [and is not and cannot be MediaStreamType.PCR as there is no way to generate this value through PidMapEntry.streamTypeToMediaStreamType()] so that means the added PidMapEntry is of the type of the last component that had the same PID as the PCR. Therefore we could have a video stream type that is the genuine video and another video that is the same as the PCR pid, or a video stream type and an unknown type that is supposed to be the PCR.

So the question is, how do we actually get the PCR PID into the PidMapTable for use later on by decodeRecording() ?

Reply viewing options

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

A number of issues were found in the PidMapTable creation code. I have filed IT-495 to track the work.

Initial description:

After review of the code related to the forum post bugs were found in the PidMapTable creation logic in RecordingSession and TSBSession.

In both classes, the details member needs to be assigned before calling the method which builds the PidMapTable.

In RecordingSession, the elementaryStreamsToPidMapTable method needs to have an inner for-loop which compares the servicedetails component pid against the stream pid and only adds the entry if they match. The PCR pid may not be a pid in the service - it may be anywhere in the multiplex, so the creation of the PCR PidMapEntry should be unconditional.

Also, the PCR PidMapEntry creation logic should set mediatype to PCR, and set the elementary stream type to UKNOWN to represent the fact that the value is unused.

Joined: 2008-12-18
Points: 0

[Sorry for the reply latency. Once Scott and I had figured out that each of us thought the other was going to reply, the forum was down.]

All the MPEOS DVR methods use the same data structure for communicating stream lists to and from the platform (mpe_DvrPidInfo/mpe_DvrPidTable):

typedef struct _mpe_DvrPidInfo
mpe_DvrMediaStreamType streamType; /* Audio, Video, Data, PCR, etc... */
int16_t srcPid; /* requested pid */
int16_t recPid; /* actual recorded pid */
mpe_SiElemStreamType srcEltStreamType; /* defined in mpeos_si.h MPEG1, MPEG2, MHEG, etc..*/
mpe_SiElemStreamType recEltStreamType;
} mpe_DvrPidInfo;

For the methods that take this structure, there's one entry for each stream plus an entry identifying which PID carries the PCR. srcPid identifies the PID in the data source. The non-PCR entries also carry a srcEltStreamType to identify the particular MPEG2 stream type.

This is probably off-topic for this question, but for completeness, the recPid/recEltStreamType fields are only used when the structure is passed to methods that record on-disk (mpeos_dvrTsbBufferingStart() and mpeos_dvrTsbConvertStart()) to support platform-level PID re-mapping and transcoding.

The entry with streamType==MPE_DVR_MEDIA_PCR may or may not have a srcPid equal to another entry in the table (per MPEG, the PCR_PID in the PMT can refer to any stream in the multiplex). The srcEltStreamType value is ignored for this entry.