[vlc-devel] [PATCH] cc: Only reset line position if rollup mode changed

[Devin Heitmueller]

Hello Francois,

Thank you for taking the time to review.  See my comments inline:

>> 
>> IIRC, the changing of the rollup shouldn’t actually clear the line.  I believe the WGBH reference stream actually demonstrates that case where the rollup is changed to some other value and it isn’t supposed to clear the existing captions.  That said, I haven’t really tested this use case and while this patch improves the situation considerably (the captions go from “completely unwatchable” to “pretty good”) there may be other improvements/fixes which are warranted.
> 
> Changing the rollup does not clear any line. The chars just get
> rewritten because the cursor resets.

Pardon, I misspoke.  Yes, I did not intend to infer that the line should be cleared.  This is all about the cursor being reset when a rollup is received.

> 
> Rollup command should "Precede each new row of text".
> The issue is WGBH not following the spec as per B.8.1 where RU commands
> should be followed by PAC.
> 
> "To continue painting the current row, assuming the relocation occurred
> in the middle of a row, the PAC used should indent to the same column
> number where the cursor resided prior to the move or to the nearest
> indent to the left of that column.”

Ok, so you're going to make me dig into the spec to explain why the stream plays properly in all the other decoders I've tried but not in VLC.

Bear in mind we're not talking about some exotic source of content.  The broadcast I provided to you privately is sent to a city of eight million people every day and the problem occurs every day during their main news broadcast.  I don't know what tool they used to generate the live captions, but given the size of the organization I'm willing to bet it's going to be one of the more popular and expensive ones.

In short, we can argue about what the spec says, or we can talk about how to make a stream render properly in VLC that renders correctly in every other television and application I've tested with.

> 
> BTW, the 708 decoder has no issue as all with the 708 encoded version.
> Wondering if that goes under the radar because US devices use 708 by
> default.

Almost no product sold in the US renders 708 by default.  Because the spec requires 608 to also be present, and because the quality of 708 decoders varies wildly across products, in general the 608 streams are used by default, and while 708 is an option almost nobody ever turns it on.

Devin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20180726/30479944/attachment.html>