On 11/06/07 20:57, Reinhard Nissl wrote:
> Rolf Ahrenberg schrieb:
>> During the freeze VDR's transfer buffer gets full and VDR is clearing
>> transfer buffer to avoid overflows. This happens only on channels with
>> DVB subtitling.
> The problem for this issue is in cRemux::cRemux():
> new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result");
> IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet
> larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of
> the buffer which holds reading the buffer and will finally let the
> buffer run full.
After some testing I'm afraid this only works for Transfer Mode, but not
for live mode directly on the primary FF DVB card. In Transfer Mode the
result buffer is likely to have 32KB available because it also contains
video data. But in direct live mode it only holds subtitle data, which
usually takes a while to amount to 32KB. And the result buffer, if set
up with Margin=SUBTITLE_PACKS will only deliver data when it has at least
32KB available. Therefore the subtitles are displayed way to late (some
20 to 50 seconds, sometimes even more).
I do see the problems Rolf has reported in Transfer Mode, and using
SUBTITLE_PACKS for the repacker does help here. But we also need to make
it work in direct live mode.
One more thought: even in direct live mode the result buffer will only
return data if it has at least IPACKS bytes available (assuming the
change Reinhard suggested is not applied), which may mean that a small
subtitle packet may sit any wait in the buffer until more data arrives
and "washes" it out. This may explain why sometimes in live mode a
subtitle line is displayed for a long time when no new text follows it.
Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and
we should return to IPACKS, and bite the bullet and introduce a repacker
for subtitle data, as Reinhard already suggested...
vdr mailing list