[vdr] Understanding AC-3
dvb at flensrocker.de
Thu Sep 2 19:42:32 CEST 2010
Am 02.09.2010 19:05, schrieb Rob Davis:
> On 02/09/10 11:05, L. Hanisch wrote:
>> Just an additional info for the ones who want to help - the
>> pvrinput-plugin passes through the TS from the HD PVR to vdr, there's
>> nothing changed.
>> So hopefully the plugin is not the one to blame for... :-)
>> I posted a sample PAT and PMT of the HD PVR in february, perhaps it can
>> be used to clarify something.
> How do you create the PAT and PMT files and then understand them.
> I'm pretty sure that sample file was only mp3 input instead of AC3 digital which is what I use now..
Yes, you may be right. Just 'cat' a sample video into a file and use 'hexdump' to format the output.
One TS packet has a length of 188 bytes, I like 4 lines with 47 bytes.
This will output the first 6 packets (6 * 188 = 1128):
hexdump -e '"" 47/1 " %02x" "\n"' -n 1128 test.ts
If every fourth line starts with the TS sync byte 0x47 you'll know you've done that right.
This will help you understand the first 4 bytes, esp. the PID is the 5 lower bits of the second byte and the 8 bits of
the third byte:
The PAT will always have PID 0, in the PAT will be the PID of the PMT. There may be more than one PMT-PID in the PAT,
one for each programme.
After staring some hours at those bytes you'll see the "matrix"... ;-)
>> Am 02.09.2010 15:21, schrieb Rob Davis:
>>> Hi Guy's,
>>> How do you go about understanding AC-3 within a VDR context?
>>> (apart from reading up on it online - which now has my head spinning).
>>> I have a Hauppauge PVR-HD and two ATSC cards. The ATSC cards work as
>>> they should and with the new atsc/dn patch on
>>> 1.7.15 now have the correct dpids.
>>> However, if I turn on add new transponders or update pids, then my
>>> Hauppauge PVR channels lose their dpid values..
>>> Sep 1 19:10:33 oac vdr:  changing pids of channel 920 from
>>> 4113+4097=27:0;4352=eng at 106:0:0 to 4113+4097=27:0:0:0
>>> If I keep automatic channel updates off, then xineliboutput and
>>> streamdev work for these channels, but vdr-vnsi (xbmc)
>>> and vdr-xine don't (no audio)..
>>> I'm assuming vdr parses the ac3 headers in some way and sends
>>> information onto the playback frontend. How would I go
>>> about seeing what those headers might be and looking into patching
>>> pat.c accordingly?
>>> I noticed all the comments about e-ac3 and wonder if a similar patch
>>> should be made for this device.
>>> As an aside, vdr recordings from these channels play back fine in
>>> So, more specifically, I suppose I would like to know how to find out
>>> the STREAMTYPE:
>>> I'm pretty sure it falls under this:
>>> case 6: // STREAMTYPE_13818_PES_PRIVATE
>>> But I'd be interested in seeing the flow through this section of pat.c
>>> and what is happening.. Mainly to see if
>>> something needs to be forced on?
>>> I can create a five second VDR recording if someone wants to see what
>>> the TS stream looks like.. But I'd be interested
>>> in diagnosing it myself..
>> vdr mailing list
>> vdr at linuxtv.org
More information about the vdr