[FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[wm4]

On Wed, 23 May 2018 16:46:17 +0100
Rostislav Pehlivanov <atomnuker at gmail.com> wrote:

> On 23 May 2018 at 16:18, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > Patrick Keroulas <patrick.keroulas at savoirfairelinux.com> wrote:
> >  
> > > ----- Original Message -----  
> > > > From: "Rostislav Pehlivanov" <atomnuker at gmail.com>
> > > > To: "FFmpeg development discussions and patches" <  
> > ffmpeg-devel at ffmpeg.org>  
> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for  
> > packets with top/bottom field  
> > >  
> > > > On 18 May 2018 at 22:17, wm4 <nfxjfg at googlemail.com> wrote:  
> > >
> > >
> > >  
> > > > > But I think a new side data type would be much saner. We could even
> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > > > something. It's apparently just packet data which somehow couldn't go
> > > > > into the packet data.  
> > >
> > >  
> > > > I agree, a generic ancillary side data type sounds better. It would  
> > have to  
> > > > be handled the same way as mastering metadata (e.g. to allocate it  
> > you'd  
> > > > need to use a separate function), since the size of the data struct  
> > can't  
> > > > be part of the API if we intend to add fields later.
> > > > Patrick, if you're okay with that you should submit a patch which bases
> > > > such side data on libavutil/mastering_display_metadata.h/.c  
> > >
> > > No problem for transmitting field flags through side data. But the given
> > > example (libavutil/mastering_display_metadata.h/.c) attaches data to
> > > AVFrame, not AVPacket, so I'm not sure where to place this separate
> > > allocator function. Do you recommend to create a new
> > > libavcodec/ancillary.c/h utility?  
> >
> > The example you mentioned exists for AVPacket too (it's just not easy
> > to see how it can end up in AVPacket, because no demuxer does that
> > directly).
> >
> > Anyway, ancillary side data would just be an untyped byte array, so I
> > don't think it needs any helpers. Just an addition to the packet side
> > data enum (I think it's somewhere in avcodec.h).
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> I'd rather have it as a well defined typed array rather than a bunch of
> bytes. Otherwise we'd start sending unknown side data info and users
> wouldn't know what to do with it.

Unless you're adding some meta object system for describing arbitrary
types at runtime I don't know how you'd do that.