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.