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? Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
