On Wed, Jul 5, 2017 at 3:30 PM Marton Balint wrote:
>
> On Fri, 9 Jun 2017, Devin Heitmueller wrote:
>
> > Hello Marton,
> >
> > On Tue, Jun 6, 2017 at 5:45 PM, Marton Balint wrote:
> >
> >> As far as I remember multiple side data of the same type is not
> something we
> >> wanted to support. Wh
On Fri, 9 Jun 2017, Devin Heitmueller wrote:
Hello Marton,
On Tue, Jun 6, 2017 at 5:45 PM, Marton Balint wrote:
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 ma
On Fri, Jun 9, 2017 at 11:41 AM Devin Heitmueller <
dheitmuel...@kernellabs.com> wrote:
> Hello Marton,
>
> On Tue, Jun 6, 2017 at 5:45 PM, Marton Balint wrote:
>
> > 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
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
sh
Hello Marton,
On Tue, Jun 6, 2017 at 5:45 PM, Marton Balint wrote:
> 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?
Could you please expand on w
On Tue, Jun 6, 2017 at 4:48 PM John P Poet wrote:
> On Tue, Jun 6, 2017 at 4:40 PM Kieran Kunhya wrote:
>
>> >
>> > 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
On Tue, Jun 6, 2017 at 4:40 PM Kieran Kunhya wrote:
> >
> > 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.
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
sh
>
> 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
On Tue, Jun 6, 2017 at 3:59 PM Hendrik Leppkes wrote:
> On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint 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 o
On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint 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 remem
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
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.
---
libavcodec/mpeg12enc.c | 52 ++
libavutil/frame.c | 8
libavu
13 matches
Mail list logo
