[FFmpeg-devel] Moving enum AVFieldOrder to libavutil?

[Michael Niedermayer]

On Sat, Mar 24, 2018 at 01:07:48AM +0100, Marton Balint wrote:
> 
> 
> On Fri, 23 Mar 2018, Devin Heitmueller wrote:
> 
> >Hello,
> >
> >I am in the process of reworking libavfilter to pass along the field order
> >across links.  For the moment I followed the model found in AVFrame where
> >there are two int fields: “interlaced_frame” and “top_field_first”.
> >However it seems like it would be more appropriate to use the enum
> >AVFieldOrder, which is a single field and provides more flexibility
> >(including being able to be set to “unknown” if appropriate).
> >
> >Does anyone have an objection to moving the definition of AVFieldOrder to
> >libavutil, so it can be taken advantage of by libavfilter?  Right now it’s
> >in libavcodec, and from what I understand libavfilter does not depend on
> >libavcodec.
> 

> AVFieldOrder is already a mess, 

+1


> so I would not use that directly. There was
> a discussion why it is currently inconsistent between codecs:
> 
> https://patchwork.ffmpeg.org/patch/4699/
> 
> Maybe cleaner to introduce a new enum which defines the semantics better.
> Also, as far as I understand, an AVFrame is always storing the fields as
> interleaved, so strictly speaking an AVFrame (AVFilter) field order and
> AVCodecParameters field order is not entirely the same thing, that is one
> more reasone for a separate (new) type.

If a new system is added it should support specifiying
not just "unknown" but also "interlaced, order unknown" as well as some
parameter about where the information comes from.
interlaced info can come from codec coding choices, metadata, or image
analysis. Files with wrong interlacing flags are not uncommon, or maybe
one should say, progressive material coded for display on interlaced devices
or standard.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180324/628e60a9/attachment.sig>