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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
