On Tue, Jun 6, 2017 at 3:59 PM Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint <c...@passwd.hu> wrote: > > > > On Tue, 6 Jun 2017, John Poet wrote: > > > >> ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC > >> frame: Add av_frame_get_side_data_at() to allow retrival of multiple > side > >> data of the same type. > > > > > > As far as I remember multiple side data of the same type is not > something we > > wanted to support. Why do you need it? Can't a single > AV_FRAME_DATA_A53_CC > > side data packet contain many CC entries? > > > > 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. If you would like me to go about this a different way, please give me some direction. Thank you, John _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
