[FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??

Don Moir donmoir at comcast.net
Fri Nov 29 15:40:43 CET 2013


----- Original Message ----- 
From: "Don Moir" <donmoir at comcast.net>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Friday, November 29, 2013 9:41 AM
Subject: Re: [FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??


>
> ----- Original Message ----- 
> From: "wm4" <nfxjfg at googlemail.com>
> To: <ffmpeg-devel at ffmpeg.org>
> Sent: Sunday, December 01, 2013 9:02 AM
> Subject: Re: [FFmpeg-devel] attribute_deprecated int avpicture_deinterlace ??
>
>
>> On Fri, 29 Nov 2013 09:18:07 -0500
>> "Don Moir" <donmoir at comcast.net> wrote:
>>
>>> 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 :)
>>
>> Actually, that's probably the simplest way to use them. You could just
>> use libavfilter to take care of all these things, and forget about
>> libswscale/lib{av,sw}resample (other than making sure they're enabled in
>> libavfilter).
>
> Possibly. Although I have no need for libavresample. Started out using it, but for my purposes it was just easier to do this 
> internally. Also, don't like the formulas used for downmixing. Yeah I know there is no absolute but I include the base channel and 
> a modified formula. Sounds good and I hear everything. Base channel is just a channel  and does contain speech at times. I also 
> provide some volume correction during resample if needed. Wonder if you could inject a formula to avresample?
>
>>> 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.
>>
>> Deinterlacing is a complicated process, and the old lavc deinterlacer
>> is the most crappy way to do it. Deinterlacing is an unsolved problem
>> too, so there's no "perfect" way to do it, but you can be sure that the
>> methods provided by libavfilter are far superior to what the old lavc
>> deinterlacer provides.
>
> Maybe yes. I did a little testing with yadif last night using some other programs and twice as slow with more about 70 percent 
> memory increase. Just too early for me to say as not very complete test but bothered me.
>
>>> 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.
>>
>> The lavc is not elegantly simple, it's just crappy and not even close
>> to a good deinterlacer, from what I've heard. I can't understand why
>> you are arguing why lavc should continue to provide this very crappy,
>> half-baked, inferior filter, while everything else that has to do with
>> conversion or post-processing is outside of lavc?
>
> Saying the interface avpicture_delinterlace is elegantly simple. Easy to turn on / off midstream and good control. Whats 
> underneath is something else. If it sucks underneath then it could be improved, so I am not arguing about what is underneath. I 
> already mentioned it could be improved, but seems to do an adequate job and its quick. In this case I think you need to ask 
> yourself what is the cost of absolute perfection (or close).
>
> You might think I sound a little anal about using this and that libraries, but if I put out something that suddenly does not work, 
> then it comes back to me and not you. Now you want me to use libavfilter? Sorry to say, but the most I can isolate the better off 
> I am.

Did some work with avpicture_deinterlace and I see its a bit weak. Would like to have a file though to look where yadif makes a 
difference. The interlaced files I have look fine with avpicture_deinterlace but know I don't have a very decient file set for that.

Appears you can flag this out for compile if you don't need it.

So looked at yadif some and tried that in VLC and SMPlayer. These two since they offer a convienent way to turn yadif on. Both of 
them showed a large increase in CPU on my slower machine and negligible on my fast machine.

For the following file, it runs about 10 to 28 percent CPU on my slow machine in VLC or SMPlayer. With yadif on, 50 to 60 percent. 
Doesn't occur on fast machine.

http://sms.pangolin.com/temp/anoha_0.ts  (110 mb)

Don't know what thats all about. yadif looks fine so just don't know. My own code runs it about 10 to 28 on slow machine with or 
without avpicture_deinterlace. zero on fast machine. 



More information about the ffmpeg-devel mailing list