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

[Vittorio Giovara]

On Thu, Mar 27, 2014 at 12:58 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Mar 26, 2014 at 10:33:32PM +0100, Vittorio Giovara wrote:
>> 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
>
> well, iam no user of libav but you do realize that libav
> deprecated that without speaking with the authors who wrote it?

And yet it had been merged, and stayed like that until now, so the
message is the authors agreed with that.

> But lets forget about that and just design a better system
> what issues do you see in it, what do you suggest to improve it?
> the addition of a AVBufferRef is obvious

I would definitely not store anything related to a decoder internal
inside an AVFrame, maybe an AVBufferRef like you suggest but in
AVCodecContext.
But that's just my humble opinion, maybe there are other
technicalities I am not seeing.

Cheers,
-- 
Vittorio