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

[Michael Niedermayer]

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?

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140327/69075d0f/attachment.asc>