[FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??

[Don Moir]

----- Original Message ----- 
From: "Hendrik Leppkes" <h.leppkes at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Saturday, November 30, 2013 4:10 PM
Subject: Re: [FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??


On Sat, Nov 30, 2013 at 6:54 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
>
>
> On 30.11.2013, at 15:37, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
>> On Sat, Nov 30, 2013 at 2:17 PM, Stefano Sabatini <stefasab at gmail.com> wrote:
>>> On date Friday 2013-11-29 08:30:51 -0500, Don Moir encoded:
>>>>
>>>> ----- Original Message ----- From: "Stefano Sabatini"
>>>> <stefasab at gmail.com>
>>>> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
>>>> Sent: Friday, November 29, 2013 8:09 PM
>>>> Subject: Re: [FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??
>>>>
>>>>
>>>>> On date Friday 2013-11-29 09:06:57 -0500, Don Moir encoded:
>>>>>> deinterlacing is directly related to decoding in that you want a
>>>>>> properly decoded image and not some effect.
>>>>>>
>>>>>> Looks like we are now pointed to avlibfilter and yadif. I have no
>>>>>> use for avlibfilter so I should link it so I can deinterlace ?
>>>>>> avlibfilter is just excess baggage from my viewpoint.
>>>>>>
>>>>>> Hate to bring this up late but seems silly or am I the only one that
>>>>>> thinks that? Hope I am misunderstanding something.
>>>>>
>>>>> Possibly: we could extract the yadif code and move it somehow to the
>>>>> library (libavfilter public low-level API or something, so you don't
>>>>> need to build a filtergraph to apply it). It might be non trivial.
>>>>
>>>> Would be good if avpicture_deinterlace was improved possibly using
>>>> yadif and left where it is. Other than that, I would probably roll
>>>> my own rather than use avfilter if avpicture_deinterlace goes away.
>>>
>>> What's exactly your problem with libavfilter (please no trolling)? The
>>> main problem seems that you are not willing to configure a filtergraph
>>> for that, so the alternative I proposed is a low level deinterlacing
>>> API, based on yadif which could be used without filters.
>>
>> A simple filtergraph just for deinterlacing is so trivial that I
>> wouldn't let this argument count for anything.
>
> I don't know. If it's more than 5 lines of code (and I suspect it's a lot more) it might be useful to have a function that just 
> passes things through one single filter...
> Though it would probably still need a create and destroy function in addition, so I don't know if such a simplified API is worth 
> it...


>With error checks its probably 20-30 lines of code for the filtergraph
>setup, and 5 lines of code for filtering the frame.

>Anyhow, it looks like the API isn't even his issue, more of the
>concept that yadif is in lavfi, which I hope noone considers changing
>on one persons opinion (or ever, really).
>Its a video filter, it belongs in the video filtering library. Even if
>you consider deinterlacing quite essential, its still a
>post-processing filter.

>Hendrik

If post-processing means it's a filter and belongs in lavfi, then everything in swscale and resample should also be in lavfi because 
those are post-processes as well. Don't take me literally though :)

Just saying that deinterlace is special case of post-processing. In other words, it is more or less mandatory to produce the proper 
frame image. Nothing else in lavfi is needed to produce the proper frame image and those are just after effects.

Now if you need to call some code to do essentially the same thing, there is a procedure for it and you already know that and you 
already have the library structure in place. I suppose one person decided it was a good idea to phase avpicture_deinterlace out and 
move the functionality of that to the sore thumb lavfi library so we can burdoned with carrying that baggage around. You (whoever) 
are proposing taking something that is elegantly simple and moving it to a library that is anything but.