However, since some broadcasters in the DVB sphere simply adopt US streams including the SI without adjusting it, your software may be able to handle it.
if you are not familiar with it, it will take several weeks to dig through it, understand it and find what you need for your purpose.Ĭoncerning the stream type 0x06 -> 0x81 patch: Of course an ATSC stream type should not be used in a DVB transport stream. You need to pay for it, except if you can find it in some dark web corner.
Is there any information / instruction on how to find and edit the stream type identifiers, as well as calculating & editing PMT CRC?Ī PDF with 150 pages containing technical specifications for experts, particularly the transport stream format basics. Maybe parsing the PMT and changing stream type 0x06 (Private PES) to 0x81 (ATSC stream type for AC3) in certain cases would do the trick, but after that the PMT checksum (CRC32) would be wrong and had to be recalculated - quite a lot of hassle without guarantee for success.
unfortunately there is no easy way to add the missing information on the fly. However, a scanner only reads the SI tables, so it can't know. That's why the recorded (unscrambled) stream appears as AC3 in the PID list of the Analyzer, though there is no AC3 indication in the PMT. DVBViewer is able to do it when reading a TS file, and also the TransEdit Analyzer in a more limited way. eventually it comes down to "good guessing", based on a quite sophisticated analysis. This requires an unscrambled stream, of course. In your case there is no indication at all for AC3, so the only way to detect the content is looking for typical byte patterns in the elementary stream, like 0B 77, which may be the start of an AC3 audio frame. so the PMT must specify what's inside, usually by adding a descriptor, as the following example shows: A private PES with stream type 0x06 can contain different things, e.g. The problem is caused by insufficient service information (SI) data, or more specifically, the PMT (Program Map Table, read more about it here). fix the ts file "real time" when recording? Here's a transponder dump using TE, and a sample of recorded file (using Media Server) after "my dirty fix" to the channel list.Ģ.
I checked the PES start code - it's the correct 00 00 01 BD, not sure what's wrong this time.
Initially I thought it was the same as this issue, but seems not the case. TMPGEnc seems to be the only software can correct these streams. Suspect it could be the broadcaster's fault - these "buggy" AC3 streams shown as "Private PES" in TransEdit before recording after "my dirty fix" they show as AC3 in TransEdit but cannot be recognized by VideoRedo or TSDoctor. duplicate the channel then change the audio PID and codec ("my dirty fix"), it could be recognized and playback & record without any problem. However, if I manually edit the channel list in DVBViewer, i.e. The channels have 2 audio streams (AC3 5.1 and MPA 2.0), but after a scan using TransEdit, the AC3 streams are missing, only MPA recognized. Encountered a strannge problem with missing AC3 audio stream: