[FFmpeg-devel] Moving enum AVFieldOrder to libavutil?

Marton Balint cus at passwd.hu
Sat Mar 24 02:07:48 EET 2018



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, 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.

>
> For what it’s worth, it looks like I’ve basically got it working - I’ve 
> extended buffersrc/buffersink/AVFilterLink and ffmpeg, and I’m now able 
> to propagate the interlaced state all the way from the H.264 decoder to 
> the Decklink output during write_header(), and thus select the proper 
> output format.  This includes it being preserved through any video 
> filters that might be in the pipeline.  At this point it’s largely just 
> a question of how to rework the patch to be as non-invasive as possible 
> so it can be accepted upstream.

Seems reasonable.

Regards,
Marton


More information about the ffmpeg-devel mailing list