[FFmpeg-devel] Fwd: Re: [Libav-user] Motion estimation : replacement for deprecated AVFrame::motion_val ?

[Vittorio Giovara]

On Wed, Mar 26, 2014 at 3:29 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Mar 26, 2014 at 12:03:49AM +0530, Anshul wrote:
>>
>> > > So i've understood, but I don't really see why these values are not available anymore. I realize that messing with the internals of various codecs is not why libav is made for, but these fields are calculated anyway, so why not propagate it to the AVFrame ?
>> >
>> >  Because they're internal, and having them exposed hampers refactoring
>> > efforts. If you want stuff to remain "like before" then just use some
>> > specific old version of ffmpeg in your application (or even a specific
>> > commit)
>> >
>> >  /Tomas
>> >
>> > That's a rather evasive answer... I myself would too welcome if the API
>> > for access to internals such as DCTs and MVs was preserved (mostly for
>> > academical / experimental purposes, as I'm working on a bc thesis
>> > concerning video right now). Refactoring is a great thing, but it
>> > doesn't have to entail removing funcionality...
>>
>> As far as I know, the API was deprecated by Libav. Libav also removed
>> the implementation of these. FFmpeg merged the deprecation, but not the
>> removal of the implementation (or at least not all of it). So there's
>> hope for you to convince the developers to un-deprecate it.
>>
>>
>> I have missed the disscussion when it was removed, I will search old archive why this feature was deprecated, I just wanted to disscuss if it is really possible to know mv vector present in stream using avoption.
>
> the motion vectors should be available in AVFrame motion_val
> if they arent, thats a bug and a regression test for this is welcome
> either way
>
> Ive no plan to remove this feature, though the exact ABI may change
> for compatibility reasons
> That is if libav removes the field from the middle of the structure
> we wouldnt be able to leave the field in that position and be
> compatible with libav at the same time

There is also the unfathomable option for the users needing this to
actually speak to the developers who deprecrated this field (at
#libav-devel), understand why it has been marked for deprecration and
then seek a possible (and possibly correct) alternative, with the end
result of avoiding another point of idiosyncrasy between the
libraries.
jm2c
-- 
Vittorio