[vdr] Question about Repacker in vdr-1.3.32
rnissl at gmx.de
Sat Sep 24 21:01:45 CEST 2005
> 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
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.
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
More information about the vdr