Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

[Carlos F. <cf...@gm...>]

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).