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
