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