On Mon, Mar 14, 2005 at 09:38:34PM +0100, Reinhard Nissl wrote: > > Looks like you got me, Werner ;-) > > 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 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 descritption above byte 0) should have 1, but the byte 3 and 4 (or in the descritption 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 middel of an AC3 data frame. Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 ------------------------------------------------------------------ "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
