[linux-dvb] Re: tech questions

[Ralph Metzler <rjkm@convergence.de>]

Arpi writes:
 > Hi,
 > 
 > > Arpi writes:
 > >  > 
 > >  > If limiting packet size (so using PS instead of PES) to 32k or 2048 bytes,
 > >  > I got shorter playback time, hangup comes earlier.
 > >  > Without limiting packet size (real PES), got about 20-30 mins of playback
 > >  > before hang.
 > > 
 > > The driver send PES of size 2048 bytes or smaller to the firmware. So an
 > > optimal PES size would be 2048 bytes (including header) or smaller. Of
 > > course, you would want to start a frame at the beginning of a PES, so
 > > that the PES before that is usually smaller than 2048 bytes, but
 > > that's ok. You don't have to use padding. Other PES sizes should be ok
 > > too, the driver repacks the PES, but it can only make them smaller.
 > 
 > Hmm, good to know... I thought the driver puts anything to card's buffer,
 > and the card handle any size of packets.
 > 
 > Changed my PES packetizer to create 2048 byte packets _including_ headers,
 > and it seems to work better now. At least my favourite stream which hanged
 > after 12 sec still playing (over 5 mins).
 > 
 > Maybe a memleak or other overflow in the driver's re-packetizer?

That could be. The re-packer is in dvb_firm.c 
If you find something please tell us.


The 2048+header bytes packets also always result in one packet with 2048
bytes and one very small one with just the header size. 
Copying just those few bytes is very slow compared to copying 
2048 byte blocks and the ARM only has 40 MHz. 
You will also notice that the PES data coming from the board
has stuffing bytes to 4-byte (DWORD) align the payload to
the payload in the internal buffers similar as it was done in the
AVPES format. Copying non-aligned data is slow on ARMs.


Ralph


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.