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 <rsbul...@gmail.com> wrote: > Hi, > > On Thu, Aug 3, 2017 at 5:32 PM, Davinder Singh <ds.mud...@gmail.com> > wrote: > > > On Tue, Aug 1, 2017 at 7:40 AM Davinder Singh <ds.mud...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
