Hi I should have mentioned, the 0x80 video is DC-II (digicipher) - the system that is behind the whole "AC3 as type 0x81 problem" as described on TSReader's homepage that I saw someone mentioned when this topic came up before.
I'll try the new SVN and see how it goes. I was also looking at the streams after I posted yesterday, it seems another method of "bandwidth conservation" that's being employed here is just randomly dumping frames from the GOP, as every program that has debugging output I try on these streams complains about this. I suspect this is why most tools end up shortening the video, and the audio gets all out of sync. I may need to dig deeper into these streams to really figure out how they're butchering it. Thanks, Andrew On Mon, Mar 17, 2008 at 12:13 PM, Michael Riepe <[EMAIL PROTECTED]> wrote: > Hi! > > > Wolfram Gloger wrote: > > >>There is a 10MB sample at > >>http://www.andrewhakman.dhs.org/sp_dec5.ts.truncated . What is wrong > >>with this transport stream, and can dvbcut be made to correctly > >>identify the audio? > >> > >>The transport stream was recorded with TSReader, and there were no > >>continuity or TEI errors reported while recording the file. > >>PMT on 0x0020 with > >> PCR on PID 0x190 > >> ES Type 0x80 Video on PID 0x190 > > > > ^^^^ this type is certainly not in any official tables > > Only if you count "user defined" as part of the official tables. :-) > > > >> ES Type 0x81 AC-3 Audio on PID 0x191 > > Nor is this one. But since we detect 0x81 as legacy AC-3 audio, we > probably also should accept 0x80 for video. > > > > The problem is that the PMT is valid, but the stream type > > of 0x80 isn't mapped to MPEG2 video (should it? I can't > > find any indication but haven't looked hard). So dvbcut > > drops the entire PMT information, and later fails > > to auto-detect the audio because of unaligned syncwords. > > > > I think some information is better than nothing: check_si_tables() > > could process the audio streams and still return false, so that the > > auto-detection finds the rest. Patch appended (with the 0x80 type > > commented, this could be an alternative)-- maybe I overlooked > > something this could break.. > > It might return data from the wrong PMT. I've seen several streams that > contained PMTs for all programs in the original transport stream, > although only the recorded program was present. Some recorders seem to > just copy PAT and PMT instead of pruning them properly (as required for > partial transport streams). Therefore, check_si_tables runs through all > of them in an attempt to find the matching table, and discards anything > that doesn't contain both valid audio and video descriptors. > > I think it's better to include 0x80 as a valid video descriptor tag and > stay with the current table search procedure. > > Welcome to r119! > > -- > Michael "Tired" Riepe <[EMAIL PROTECTED]> > X-Tired: Each morning I get up I die a little > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > DVBCUT-user mailing list > DVBCUT-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dvbcut-user > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
