[FFmpeg-devel] [DISCUSSION] Motion Estimation API/Library

[Alex Giladi]

I like the idea -- it will be then possible to link to hardware
acceleration.

I don't think R-D optimization (including taking VLC / CABAC into account)
belongs to the library -- this, as well as figuring out partitions, should
be up to the actual encoder.

On Thu, Aug 3, 2017 at 4:09 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:

> Hi,
>
> On Thu, Aug 3, 2017 at 5:32 PM, Davinder Singh <ds.mudhar at gmail.com>
> wrote:
>
> > On Tue, Aug 1, 2017 at 7:40 AM Davinder Singh <ds.mudhar at gmail.com>
> wrote:
> >
> > > [...]
> > >
> >
> > Keeping where the code lives, aside,
> >
> > main thing is API, so we need to talk about it.
>
>
> You're assuming that we know in advance what the API will have to do. I
> don't think that's the case.
>
> For example, what block sizes does it operate on? me_cc doesn't work for
> 64x64 blocks in HEVC, VP9 (and AV1?).
>
> Or what if we don't use VLC coding, but some arithmetic variation? Like all
> H.264, VP8-9, HEVC (and AV1?). Where perhaps the arithmetic coding can
> depend not just on intra/inter, but also on transform size, chroma/luma,
> etc.
>
> What if qscale is not uniform and allows per-coefficient matrix variations?
> How many sub-types of such variations will exist?
>
> My point is: designing it in advance for everything like this is insane.
> Just copy what is there, and prepare for the API to change _all the time_
> while we're molding it to fit in other problem shapes.
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>