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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
