Re: [xine-devel] mpeg_pes & AC3 audio: sending large data as small chunks

[Reinhard N. <rn...@gm...>]

Hi,

James Courtier-Dutton wrote:

> Reinhard Nissl wrote:
> 
>> I've discovered the following problem: if a stream contains MPEG PES 
>> packets with a size (e.g. 9010 bytes) larger than the buffer size 
>> (8192 bytes) then the remaining bytes are lost, which causes for 
>> example CRC errors.
>>
>> One solution would be to increase the buffer sizes, but as a PES 
>> packet contains up to 64 kb of data, this would increase xine's memory 
>> consumption by a factor of 8. That's not a very desireable solution.
>>
>> In my case, the PES stream is supplied by VDR. VDR repacks the data of 
>> large PES packets into smaller ones of 2048 bytes, so xine's buffers 
>> are large enough. This repacking thinks of PES packets just as of data 
>> containers: it should be possible to replace a large PES packet by two 
>> smaller ones just by splitting the data into two packets plus 
>> supplying them new headers with reduced size.
>>
>> But this only works, if higher level stages (e. g. at decoder level) 
>> rely only on the transported data and not on any header data, like the 
>> length field of the PES packet. This seems to be true for common 
>> decoding hardware, but for xine it seems to work only for normal audio 
>> and video streams, but not for AC3 streams.
>>
>> The reason is, that the mpeg_pes demuxer expects to get AC3 data in a 
>> single PES packet and therefore determines the AC3 data length from 
>> the PES length field.
>>
>> I think, the length information should be taken from the AC3 data and 
>> the demuxer should continue to consider PES packets of that stream as 
>> AC3 data until the specified number of bytes is reached.
>>
>> Finally, in the case where the above mentioned procedure works, how 
>> could the AC3 data be put into the audio fifo in several chunks, as 
>> the collected data would exceed xine's buffer size?
> 
> I will fix the xine-lib demux_mpeg_pes.c to handle these "Jumbo" PES 
> packets for AC3/A52 audio from the VDR.
> 
> I already had Jumbo detection in the code, but it just truncated the 
> packet. I will now make it cut the packet up into as many bits as is 
> needed. The liba52 decoder does not care about how the packet is broken 
> up, so it will just re-assemble the A52 frames as needed.

Thank you very much for doing this. Then it's up to me to either assemble 
VDR's packets into jumbo packets or to split them, so that each PES packet 
just contains one AC3 packet. It seems to me, that jumbo packets seem to be 
easier achieveable, due to lack of documentation for the other way.

BTW: you didn't write anything about my suggestion (see above) to handle VDR's 
2048 byte (and therefore split AC3) packets in your demuxer. I really would be 
interested in your opinion.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...