It just occurred to me that VLC player probably is using it's own CC user 
packet reader.

However it still helps to read the user packet properly instead of counting by 
full frames. Also this code shows how to read cc_count properly. It's not 
incorrect by any means, it was just mis-interpreted by the original code.

The original code would return an extra 0x0000 in the side data because of the 
way it counts the words, the extra 0x0000 likely coming from the next start 
code following the CC packet. I'd rather the side data contain only the CC 
data, then downstream code has less filtering to worry about.

As a bonus the code will tell you at the debug log level if the number of 
caption words is wrong given the cc_count. If you're writing code to generate 
this packet it helps to have the library tell you your cc_count is wrong.

On 10/13/2016 02:50 AM, Carl Eugen Hoyos wrote:
> 2016-10-13 8:29 GMT+02:00 Jonathan Campbell <>:
>> I just realized this has been sitting in my inbox for awhile.
>> Here's the clip in question.
>> If you play it in VLC player with "Closed Captions 1" selected, you'll 
>> notice that some of the text in the captions is missing.
> I tested the following command line with and without your patch:
> $ ffmpeg -f lavfi -i movie=bighero6.evenoddfieldcc.vob[out0+subcc] out.ass
> Output is identical, what do I miss?
> Thank you, Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
ffmpeg-devel mailing list

Reply via email to