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

[wm4]

On Thu, 27 Mar 2014 02:27:40 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Thu, Mar 27, 2014 at 02:13:33AM +0100, Vittorio Giovara wrote:
> > On Thu, Mar 27, 2014 at 1:51 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > >> > 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.
> > >
> > > that would be quite inconvenient, the motion vectors are associated
> > > with a frame not codec context.
> > > Consider a video filter that would want to display them or use them
> > > for some effects, its a lot more convenient if they are in the
> > > AVFrame for that. The same is true for a encoder which might want
> > > to use them as seeds for its motion estimation.
> > >
> > > Also with AVCodecContext and multithreading and frame reordering
> > > there would be the question of how to relate motion vectors stored
> > > in a AVCodecContext field to the frames
> > >
> > > It sure could be done somehow, i just dont think thats a design thats
> > > easy/convenient to use
> > 
> > You are right. How about AVFrameSideData? Even though it's not yet
> > been used to carry an AVBufferRef I think it could be doable.

That sounds like a deep API change. Until now, side data was simply
binary data, and did not need any magic like refcounting. Keep in mind
that not all library user use the AVPacket structure internally.

> > Then again, many do not like to use side data at all, so it's a tough choice.
> 
> The motion vector array itself could be stored in sidedata, iam not
> sure how "pretty" this would be but it should work.
> 
> I still think though simply undeprecating the
> motion_val + motion_subsample_log2 fields
> and giving them a clear and well written documentation with whatever
> else is needed (block size, stride, element type possibly, ...)
> would be the simplest solution
> all that could of course be put in side data instead if thats
> what people prefer ...

Personally, I'd argue for the side data approach, because it's really
obscure data only a few users need. Also, I'd require the user to
explicitly enable retrieval of this data to reduce the overhead for all
the other users who do not need this.