Hi Werner,

...

The recording should be OK because mplayer can decode the AC3 stream. Live-ac3 and replaying of older recordings does work, too.

Q: Does the recording include AC3, that means that the setup should be configured with UseDolbyDigital = `yes'.

yes the recording contains AC3: mplayer can replay the file with ac3 vdr -a 'ac3dec -P' can replay it, too

I've figured out if I replay the file with vdr, the bso(replay) thread doesn't start with newer recordings

AC3 replay is done then over the spdif of the dvb-card but my receiver doesn't support the strange bitformat (AC3 frames wrapped in PCM)

Roland

...

I've figured out if I replay the file with vdr, the bso(replay) thread doesn't start with newer recordings

And you have choosen the AC3 audio track during replay the recording with the green button? I've this question because this is the first report of that kind.

yes i've tested it several times. I've tracked down the problem a little bit. Data is sent to the plugin but the replay thread doesn't start because ScanPayOfPS1 fails.

I've commented out these two lines: case 0x0b: // if ((uint_16)dvb != AC3magic) // break; and now it works.

The bitformat over the dvb-card is exactly the same as in the bso plugin. The only difference is that the bso plugin force the sound card to set the nonlinear status bit in the S/P-DIF transport layer. This can not be done in the firmware of the dvb-card. Also the S/P-DIF transport layer is not identical with the PCM stream its self, e.g. for every PCM word (16bit, 20bit, 24bit) a 32bit word in the S/P-DIF transport layer is used.

I think it's the nonlinear bit. My receiver switches to DD, shows the correct stream information but i get no sound. It's like i've pressed the mute button.

Roland

Hi,

Dr. Werner Fink wrote:

On Mon, Mar 14, 2005 at 06:01:02PM +0100, Roland Praml wrote:

...

...

...

I've figured out if I replay the file with vdr, the bso(replay) thread doesn't start with newer recordings

And you have choosen the AC3 audio track during replay the recording with the green button? I've this question because this is the first report of that kind.

yes i've tested it several times. I've tracked down the problem a little bit. Data is sent to the plugin but the replay thread doesn't start because ScanPayOfPS1 fails.

I've commented out these two lines: case 0x0b: // if ((uint_16)dvb != AC3magic) // break; and now it works.

Hmmm ... this implies that the offset

      off_t   o  = (off_t) (ul & 0x0000ffff) + 3;

is not correct because the stream is moved forward

      dvb += o;

to the start of the magic word of the frame which should start there. As this works with stuff from DVD trailers I assume that something goes wrong elsewhere, e.g. in the cDolbyRepacker class.

[seeking VDR sources]

OK it _is_ a bug in the cDolbyRepacker class, therefore I've added Reinhard to CC.

IMHO the declaration of AppendSubStreamID includes an error:

void cDolbyRepacker::AppendSubStreamID(void) { if (subStreamId) { pesHeader[pesHeaderLen++] = subStreamId; pesHeader[pesHeaderLen++] = 0x00; pesHeader[pesHeaderLen++] = 0x00; pesHeader[pesHeaderLen++] = 0x00; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The minimal size is 0x01 and never 0x00 } }

... OK, in the firmware I've included a workaround for such broken sub audio header. Nevertheless this should be corrected :^) ... Reinhard?

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

As cDolbyRepacker assures that 1 frame is put into 1 PES packet, byte 1 should be 1 and byte 3 should be 4.

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?

Bye.

Hi,

On Mon, Mar 14, Dr. Werner Fink wrote:

The bitformat over the dvb-card is exactly the same as in the bso plugin. The only difference is that the bso plugin force the sound card to set the nonlinear status bit in the S/P-DIF transport layer.

can this be done with loopthrough, so that the soundcard set this bit ?

or may it be possible to grab the data in userspace area and redirect it to the soundcard in realtime. So the soundcard has to generate new headers and is able to set the nonlinear status bit and the sound will be in synca ?

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.