[vdr] bitstreamout 0.70 and vdr 1.3.22

[Reinhard Nissl]

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.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de