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.