Am 02.09.2010 19:05, schrieb Rob Davis:

On 02/09/10 11:05, L. Hanisch wrote:

...

Hi,

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.

...

http://www.linuxtv.org/pipermail/vdr/2010-February/022400.html

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: http://en.wikipedia.org/wiki/MPEG_transport_stream

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. http://en.wikipedia.org/wiki/Program_Specific_Information

After staring some hours at those bytes you'll see the "matrix"... ;-)

Lars.

...

Lars.

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: [8186] changing pids of channel 920 from 4113+4097=27:0;4352=eng@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 vdr-xine.

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..

Thanks.

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr