[vdr] bitstreamout 0.70 and vdr 1.3.22

Reinhard Nissl rnissl at gmx.de
Tue Mar 15 23:13:52 CET 2005


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 at gmx.de
-------------- 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


More information about the vdr mailing list