On Mon, 26 Mar 2018 11:48:01 -0400 Devin Heitmueller <dheitmuel...@ltnglobal.com> wrote:
> Hello all, > > > On Mar 24, 2018, at 6:37 AM, Michael Niedermayer <mich...@niedermayer.cc> > > wrote: > > > > 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 > > Well, I really opened up a can of worms, eh? > > As someone who used to work on Linux video capture drivers in a former life, > I can appreciate how confusing interlaced formats can be, perhaps even among > some of the ffmpeg developers. It gets even worse when you have to deal with > the buffers delivered directly from embedded hardware such as SOCs, where the > formats can be even more esoteric than what you might find in various codecs > (most of which make at least some effort to normalize down to only a few > formats). > > For what it’s worth, there were similar such debates years ago on what sort > of definitions are necessary to specify interlaced formats, and this is what > we arrived at (and have been using for many years): > > https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html > <https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html> > > The enum values described on that page cover pretty much all the cases you > can come across, including buffers organized as interleaved versus separate > fields, etc. > > The above page is nice because it has some pictures/diagrams which allow you > to visualize the actual differences between the different modes. It also > gives a good summary of the differences between spatial ordering and temporal > ordering (which I suspect is a cause of much of the confusing). > > My goal was to solve an immediate business problem - making sure that when > playing a 1080i H.264 or MPEG-2 video that the decklink output gets properly > configured to 1080i59. The scope creep came in after I realized this data > had no means of being propagated through the filter framework. Now it’s > being suggested that we would have to redesign the whole way AVFieldOrder is > done, presumably including some sort of backward compatibility with the > existing system and API deprecation path for what is already there. > > I’m not confident I have the time required to achieve such a goal. This > presents several options: > > 1. Do nothing. I’ll maintain my patch out-of-tree and Decklink will > continue to make bad choices on setting the output format. > > 2. Somebody else create a replacement for AVFieldOrder, go through all the > rounds of feedback/debate, merge the functionality and fix all the various > codecs/demuxers/etc which would need to use the new framework. I’m happy to > rework my patch to use such replacement, but given ffmpeg has gone for many > years with AVFieldOrder in the state it’s in, I’m not confident there are > many volunteers willing to take on such an endeavor. > > 3. Try to get some variant of my patch upstream which leverages either the > existing AVFieldOrder or the AVFrame approach (i.e. > interlaced_frame/top_field_first struct members), and continue to live with > the deficiencies in the API. I don’t think this makes the situation any > worse, it lays the groundwork for propagating this data through pipelines > (which can be converted to use some other struct member at a later date), and > it solves all the use cases that I care about. > > I’m happy to contribute where I can, but part of me feels like let’s not let > “perfect be the enemy of good”. Just adding a new summary enum would probably be a good idea. I suggest you make a patch that's not too much effort, and that _only_ adds a new enum to libavutil (though it will probably need to list all possible variants). Whether merging all interlaced flag things into a single enum makes sense or not, no idea. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
