Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions
Brought to you by:
cfsmp3
|
From: Carlos F. <cf...@gm...> - 2014-05-28 14:58:55
|
On Wed, May 28, 2014 at 4:37 PM, Ruslan Kuchumov <kuc...@gm...> wrote: > everything is OK. But we need to reset. I don't know where else to check > this file. What happens in VLC? Only semi relevant part in CEA-608-E I could find: C.10 Style Switching (Regulatory) The FCC caption decoder rules are quite clear on how decoders should respond to commands which change the style from that which is currently displayed or most recently received. The purpose of this section is to summarize certain important aspects of the rules relative to style switching. The RCL command should have no effect except to select pop-on style. If roll-up or paint-on style is in effect, any displayed captioning shall be unaffected. The next data shall be loaded into the non-displayed memory. Similarly, the RDC command has no effect except to select paint-on style. Next data are written directly to the display upon receipt. If other captioning is already on the screen, the four-row limit is still in effect. (See Section C.6 for processing a fifth row.) The three roll-up commands -- RU2, RU3, and RU4 -- select roll-up style and move the cursor to column 1. The FCC requires further that, if pop-on or paint-on captioning is already present in either memory, it shall be erased. This required erasure seems reasonable, since display memory may have to be reorganized in order to prepare for roll-up style. The EOC command should have no effect except to (1) exchange displayed and non-displayed memories and (2) force the decoder into pop-on style (since EOC would make no sense otherwise). > There were already the condition for that (at line #535 ts_tables.c in > master) Not really. Consider this scenario: We first receive a PAT that contains programs 2, 3, 4 and we are in autoprogram mode. We process part of the stream, life is good, but at some point later we get a PAT with programs 1 and 2. The current code could switch to program 1 (even if program 2 was selected before and it's still the PAT) discarding whatever we have in the buffers and mixing output. Now if that's not the definition of a shitty implimentation :-) > Function parse_PMT() overwrites caption buffer variables. > So, to fix this bug we should remove clearing of this vars when new pat is > received. Nope...ONLY if a new PAT is received and the new PAT data invalidates the previous data (which I think only happens if our selected program is gone). |