Clear QAM DC-II video question (2 Viewers)

[jonesdb]

OK, so here is an update after a little investigation into the 0x80 stream type. It turns out that there is a standard out there for this, at least in American cable systems. The document link is ANSI/SCTE 57. Check out page 86, table 7.4 Seems that the cable guys are following their own standards here in the US.
So, now that we know there is a standard defining 0x80 as DC-II video how do we develop support for it without breaking the LPCM 0x80 stream type (I'm guessing that there is some standard somewhere that defines this, though I haven't checked around for one).?

 

[tourettes]

OK, so here is an update after a little investigation into the 0x80 stream type. It turns out that there is a standard out there for this, at least in American cable systems. The document link is ANSI/SCTE 57. Check out page 86, table 7.4 Seems that the cable guys are following their own standards here in the US.

It's always bad when there are conflicting standards. If the stream is really MPEG2 it should be tagged as MPEG2 stream. Anything else is just plain stupid.

So, now that we know there is a standard defining 0x80 as DC-II video how do we develop support for it without breaking the LPCM 0x80 stream type (I'm guessing that there is some standard somewhere that defines this, though I haven't checked around for one).?

Blu-ray at least defines the 0x80 to be LPCM, not sure is DVB does it as well (as I haven't encountered any such streams yet).

I really don't like of an idea that the user needs to change some setting (no one knows that it should be changed and some users might change it by an accident). So, a better way needs to be find how to determine if the 0x80 is video or audio.

Currently I'm busy with lot of other things, so I dont have time to look at the issue, but if anyone is interested in it please have a look on the PMT parsers (on TsReader and TsWriter).

 

[mizzourob]

I have to wonder if some of the other complaints heard throughout the forums about missing channels might be related (at least for north American users).

jonesdb who is your cable provider?

mine is a small local firm in kansas, Sunflower Broadband

 

[jonesdb]

mizzourob:
I suspect that there are many others with the same issue. My cable provider is Comcast, so that is one example of a large nationwide provider. Since the US standard for cable providers calls out DC-II to be labeled as 0x80 I suspect we would find it in many systems. I suspect that it was easier for the cable providers to implement when obtaining the stream from some of the "cable channel providers". In my case, History, Halmark, SciFi and TruTV all carry the 0x80 tag. Interestingly, not all streams within the physical channel are tagged this way. Some are encrypted, some are MPEG2 and some DC-II. I haven't found any logic behind which channels are tagged 0x80 and which are tagged 0x2.

tourettes:
I ran a search for "SERVICE_TYPE" on the DirectShowFilters solution for 1.1 Alpha and didn't find anything defining 0x80 anywhere, let alone in the pmtParsers for TSReader and TSWriter. The search results are in the attached txt file. I also didn't find anyting defining LPCM. The LPCM search only returned some references to some mediasubtype stuff (looks like DVD related, though still no pmt type of 0x80 as far as I can tell.)
I'm aware of the use of LPCM in BluRay DVD, but don't see any references to this in MP.
Thoughts on where to go from here?

 

[mizzourob]

would it be possible to have a directshow filter that assigns DCII to MPEG2 and then load it as a TV post processor?

 

[mizzourob]

I found trying TSReader Lite that indeed my issue is with DCII video streams, and it identifies it as such. I'm not sure if there is a way to reverse engineer TSReader Lite into MediaPortal's TSReader? Here is a screen shot of TSReader Lite with a DCII channel

 

[mizzourob]

I'm guessing this probably should get listed in Mantis and added onto the roadmap since not being able to render channels seems like a significant bug?

I tried to add this to the Bug report section in the forums, but I keep getting an error when I try to open a new thread saying "you do not have permission to access this page"

 

[tourettes]

Here's a quick test version. TsReader is patched to use the 0x80 as MPEG2 stream ID.

When testing, you need to use TsReader Lite to record a valid .ts file that should contain the 0x80 video PID and some audio PID that is supported by MP (AC-3 or MPEG).

 

[jonesdb]

I'll give it a try in the morning and let you know the results. Thanks!

 

[jonesdb]

tourettes
The quick TSReader test worked fine with the file recorded by TSReader Lite of the program with the 0x80 DC-II video. It doesn't work with the other files recorded by MP, but that may have been by design as I don't know how you implemented the change. Anyway, thanks again for the effort.
Any thoughts on how to move forward on the recording side as well? I know there is still this problem of conflicting standards with BluRay LPCM audio to resolve. Maybe the PMT PID for a particular program can be scanned for elementary stream types. If elementary stream types 0x1b (MPEG-4 AVC/H.264) or 0xea (SMPTE VC-1) are found (both used in BluRay) then elementary stream type 0x80 can be assumed to be LPCM audio (also used with BluRay). If those stream types are not found and elementary stream type 0x02 (MPEG-2) are not found then you could assume elementary stream type 0x80 is DC-II and can be treated similar to 0x02 (MPEG-2).
Thoughts?