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). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
