[confirm] HD channels and some SD channels are not working (1 Viewer)

[riksmith]

demuxing in TS reader is going wrong...

Unless the PMT info is not valid in the stream. Then it is a problem in the stream itself. It would be intresting to see what the PIDs contain as data. Is 0x80 containing the audio data or the actual audio PID.

It is hard to know what each PID contains. When I load the sample in tsMuxeR one of the streams is rejected, leaving one MPEG-2 video stream and one MPEG-audio stream. I can't seem to get any information about which PIDs those streams are. Like I said, I have to completely demux (ie. demux to elementary streams) and then remux to get a playable stream...

Regarding the 0x80, the original sample contains the following PIDs:

09-06-2011 22:09:12.796 [db0] pcr pid: 31
09-06-2011 22:09:12.796 [db0] pmt pid: 20
09-06-2011 22:09:12.796 [db0] video pid: 30 type: [0x80 -> MPEG2]
09-06-2011 22:09:12.796 [db0] video pid: 31 type: MPEG2
09-06-2011 22:09:12.796 [db0] audio pid: 40 language: UNK type: MPEG1 - audio

After remuxing:

09-06-2011 22:12:41.609 [db0] pcr pid: 1001
09-06-2011 22:12:41.609 [db0] pmt pid: 100
09-06-2011 22:12:41.609 [db0] video pid: 1011 type: MPEG2
09-06-2011 22:12:41.609 [db0] audio pid: 1100 language: UNK type: MPEG2 - audio

So the 0x80 PID is removed by the remuxing I think...

Why do you think that "ignoring" the 0x80 PID doesn't make any difference? I notice that tsMuxeR inserts a PCR PID. Could that have anything to do with it?

Is the MPEG1 vs MPEG2 audio a typo?

 

[mm1352000]

Good point Rik - hadn't noticed that! No it isn't a typo. I'll try hacking the audio type...

 

[mm1352000]

Well, hacking the audio to MPEG 2 doesn't work either.

 

[mm1352000]

Further update: I've confirmed that the problem is with the demuxing of the audio. Any audio packets that are demuxed are deleted. The investigation is ongoing...

[Edit: I take that back - this code is a little complex. Looked like packets were being deleted, but they were being transferred from a temp buffer to the pin buffer.]

 

[Lbr_Lion]

I don't know or this will help, but I looked a little further into the different streams and it looks like that stream 0x80 is an extension of the DVB standard to add support for DVB Scrambling Algorithm version 3. http://www.dvb.org/technology/standards/a125_CSA3_dTR101289.v1.2.1.pdf

So this is not a video or audio stream. (See also the attached image)