[vdr] Question about Repacker in vdr-1.3.32

[Reinhard Nissl]

Hi,

C.Y.M wrote:

> When I watch the syslog as vdr is running, sometimes I start to see messages
> about cAudioRepacker dropping packets over and over.  Eventually this can also
> lead to the buffer filling up and a "clearing transfer buffer to avoid
> overflows" occurs to prevent VDR from crashing.  Now, this is not at the
> beginning of a channel change, as I can see how that would occur up initial
> tuning.  cAudioRepacker will just start dropping data after being tuned for a
> while.  On a side note, I never see this happen with cVideoRepacker (only the
> audio).

Well, cAudioRepacker works different than cVideoRepacker. cAudioRepacker 
looks for an audio frame header, calculates the frame length and then 
reads that number of data without further interpretation. An audio 
frame's length depends on several parameters like bitrate, sample rate, 
audio layer, etc. and is for example 372 bytes. In the case where a TS 
packet (of size 188 bytes) get's lost for any reason, it has a 
tremendous impact on the current audio frame and cAudioRepacker must 
resync on the next audio frame.

A video stream's pictures don't contain any length information. They are 
delimited by finding suitable start codes like the picture start code. 
And as for example a picture has a size of 50 kB, it is not that likely 
that a lost TS packet hits any of the start codes used for resyncing. 
cVideoRepacker reports only a resync message if a slice start code is 
followed by a non slice start code and if that start code is not a 
sequence, group or picture start code. So in general, it is unlikely 
that lost TS packets cause a resync message.

Concerning the buffer filling: there were bugs in earlier versions of 
the repacker family. If you can reproduce this issue, please contact me 
for further debugging instructions.

> So my question is, how does cAudioRepacker and cVideoRepacker affect those users
> with only FF cards?  Is cAudioRepacker/cVideoRepacker only useful for fixing
> packets sent to softdevices, such as Xine?

Well, the repacker family has an impact on recordings. As VDR's index 
file adresses frames on PES packet level, it seems reasonable to me that 
  the addressed information starts immediately at that position and that 
the data of the previous unit ends just before that position. As result, 
cutting does no longer break any audio frames and soft devices are fed 
with "complete" data.

And in the case of transfer mode, it makes it easier for other plugins 
(e. g. the radio plugin) to access certain data as it is already broken 
and assembled into useful pieces.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de