YES! It works. The audio is detected now, and the exported cut mpeg stays in sync right to the end!
This is the ONLY tool that handles these streams properly and can actually produce proper output! Hopefully I can help give back and contribute to this project more during the summer when I don't have impossible RF projects, data mining projects, and a chip layout deadline coming in May. Never an idle moment as a grad student :( I've done some QT programing before, but I hardly ever have time to work on my own projects anymore. Thanks Andrew On Mon, Mar 17, 2008 at 1:30 PM, Andrew Hakman <[EMAIL PROTECTED]> wrote: > 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
