From: Torsten J. <t....@gm...> - 2011-10-27 12:59:14
Attachments:
hdtv_subtitles.diff
|
Some of my dvb subs got rejected because * dvbsub display descriptor caused unsupported feature abort, and * segments are 1280x48 in size (too wide). Furthermore, that sophisticated pts filter code seems to work perfectly here (subs appear in sync with dialogues). Torsten -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
From: Petri H. <phi...@us...> - 2011-10-27 15:17:25
|
Torsten Jager wrote: > Some of my dvb subs got rejected because > > * dvbsub display descriptor caused unsupported feature abort, and > * segments are 1280x48 in size (too wide). Thanks, both applied. I changed max size to 1920x1080. > Furthermore, that sophisticated pts filter code seems to work > perfectly here (subs appear in sync with dialogues). Does this require any additional patches ? I'll apply pts change too unless someone can tell why pts is currently unused ... - Petri |
From: Torsten J. <t....@gm...> - 2011-10-31 15:42:25
|
> Thanks, both applied. I changed max size to 1920x1080. Maybe we should check against actual video size? >> Furthermore, that sophisticated pts filter code seems to work >> perfectly here (subs appear in sync with dialogues). > Does this require any additional patches ? Well, lets say my "pes.diff" is highly recommended. > I'll apply pts change too unless someone can tell why pts is currently > unused ... Background: Old pes buffering delays all pes payloads until the next one starts. Audio/video comes in continuously enough to not make problems there. Subtitle payloads naturally have long gaps between them (because nobody is talking on screen currently). Thus some of them will outdate even before the decoder sees them when we stick to sent pts. See pes.diff. But I like using actual pts for another reason too. Some stations dispatch subtitles in bursts, expecting TV set to chain them up correctly. Forgot to mention that pes.diff also makes full use of actual fifo buffer sizes (8kb instead of only 2). The slightly longer audio latency seems not to harm. Perhaps the real reason for that ancient limitation was to (partly) compensate side effects of not sending known size pes payloads ASAP? Anyway, the effect on memory usage is overwhelming. Now only 800 video bufs suffice for everything here :-)) Even reduced that min setting in net_buf_ctrl.c. BTW. I think I know the reason why satellite radio dont uses its own embedded pcr (or audio pcr in general) officially. ITU spec says pcr has to be updated at least once per 100 ms. Audio comes in bursts > 300 ms which is too sparse for synchronizing broadcast routers. However, pcr is still in there because it was used for inserting that audio into final sat multiplex. Torsten -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |