On 11/10/07 15:22, Reinhard Nissl wrote:
> Hi,
> Klaus Schmidinger schrieb:
>> 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.
> Well, I recall a personal email several months ago where I reported that
> the last packet in the result buffer cannot be retrieved for the above
> reason. This is not a matter for normal use, but I had this behavior in
> a program for testing repackers where the fed in data was shortened for
> each pass.
>> 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...
> I had a look into the specs and there is no need for a repacker. The
> packets are already properly aligned. And splitting the packets into
> smaller pieces (some of about 20 - 30 bytes) wouldn't help in the above
> issue.
> A simple hacked solution might be to put an additional padding packet of
> size IPACKS into the result buffer whenever it contains less than IPACKS
> bytes of data. These padding packets (stream ID 0xBE) should be dropped
> by the recorder and by PlayPESPacket().
> Though, a cleaner solution would be to fix the result buffer to allow
> retrieving any packet as soon as it is completely available in the
> buffer (final subtitle packets are about 100 bytes in size).

That sounds like the right thing to do.
Can you suggest a patch for this?


vdr mailing list

Reply via email to