Indeed, multiple entries of the same type are really a bad idea and we
basically made them impossible with stream sidedata, although maybe
not with frame side data yet. We should not add API for them or
encourage their use.
If there is a real need for multiple of the same type, maybe the type
should be expanded to hold more information.
The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption
constructs" will fit in a "block". Testing this with 1080i60 material, I
found that 2 or 3 blocks was often necessary to hold all of the CC data.
I tried ignoring that limit of 31 "constructs" per block, and ended up with
corrupt captions. By preserving the 2 or 3 separate blocks I observed
from the original source, the captions are perfect.
According to CEA-708, in the case of 1080i60, the correct number for
cc_count is 10. The highest number that cc_count is allowed to be is 30
in the case of repeating a frame three times for film mode. Exceeding
the correct cc_count for the frame rate would cause the CC channel data
rate to exceed 9,600bps.
~Brian
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
