Hi, Dr. Werner Fink wrote: >>I've just had a closer look into xine's sources (demux_mpeg_block.c) and >>it seems that my substream header is wrong most of the time. >> >>Byte 0: substream id => correct >>Byte 1: number of AC3 frames starting in this PES packet => wrong >>Byte 2+3: offset to first AC3 frame relative to PES payload => wrong Reading xine's source documenation again, it looks like I've interpreted it wrong. I've no idea why offset should be 5 for the first AC3 frame in a DVD's PES packet!? Anyway, source documentation doesn't match the code and actually they ignore offset completely and rely on "number of AC3 frames" to assign PTS to the correct AC3 frame. > Hmmm ..this is what I've from http://mpucoder.kewlhair.com/DVD/ > > [...] > > Audio Substream Headers > ----------------------- > All substreams in private stream 1 begin with the substream number. > The header described here immediately follows the substream number. > This header is not part of either MPEG or the respective audio > format standard. These are unique to DVD. > > All methods > ----------- > +-------------------+-------------------------------------------+ > |byte 0 | byte 1 byte 2 | > |-------------------+-------------------------------------------+ > |7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 | > |-------------------+-------------------------------------------+ > | FrmCnt | FirstAccUnit | > | number of frames | offset to frame which corresponds to PTS | > | which begin in | value offset 0 is the last byte of | > | this packet | FirstAccUnit. The value 0000 indicates | > | | there is no first access unit | > +-------------------+-------------------------------------------+ > > AC3 specific > ------------ > AC3 has no additional information which is DVD specific. > > > example > ------- > > +--------+-------+------------------------------------------------------------+ > | offset | value | meaning | > +--------+-------+------------------------------------------------------------+ > | 01f | 80h | AC3 substream number (audio stream 0) | > | 020 | 02 | this packet contains the beginning of 2 audio frames | > | 021 | 0001 | the frame corresponding to PTS begins at packet offset 023 | > | 023 | 0B77 | AC3 frame begins here (0B77 = AC3 sync word) | > +--------+-------+------------------------------------------------------------+ > > [...] > >>As cDolbyRepacker assures that 1 frame is put into 1 PES packet, byte 1 >>should be 1 and byte 3 should be 4. > > Byte 1 (or in the description above byte 0) should have 1, but the > byte 3 and 4 (or in the description above byte 1 and 2) should have > exactly 1 because the next byte is the first of an AC3 frame. > Don't ask me why the specs writer do begin to count with 0 as normal > programmers do :^) > > I've added a check now for the value 0 (simply adding 1 and checking > for the magic AC3 bytes 0x0b 0x77 at position 1), this because with > a real value 0 there is no beginning AC3 frame after the sub audio > header. > >>But what about extremely large AC3 frames, e. g. 1920 words = 3840 >>bytes. By assuring that PES packets don't get larger than 2048 bytes it >>can happen that such a PES packet contains just the "middle" of an AC3 >>frame. How should bytes 1 to 3 be set in such a case? > > This should also work, because then you have to set 0 for the offset > and it is very unlikly to find a 0x0b 0x77 within the middle of an > AC3 data frame. Thank you very much for this explanation. The attached patch against VDR-1.3.22 fixes all known issues of cDolbyRepacker so far. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.3.22-dolbyrepacker.patch Type: text/x-patch Size: 4479 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050315/9debbe64/vdr-1.3.22-dolbyrepacker-0001.bin
