True. 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 <jonat...@impactstudiopro.com>: >> 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. >> >> https://www.dropbox.com/s/orrzn9vfcjmk7vb/bighero6.evenoddfieldcc.vob?dl=0 > > 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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
