Hi, On Sat, Jan 14, 2023 at 10:16 AM Nuo Mi <nuomi2...@gmail.com> wrote:
> On Sat, Jan 14, 2023 at 10:28 PM Ronald S. Bultje <rsbul...@gmail.com> > > How come vvcdsp has only 8/10 bits/component code but vvcpred has > 8/9/10/12 > > bits/component code? > > I will remove it. > Not sure how applicable this is, but for AV1 (dav1d), most high-bitdepth (non-8 bits/component) code has the same container type requirements (e.g. "fits in int16_t"), so we add a "limit" (analogous "bitdepth") argument to relevant functions and then only have to implement it once for all non-8 bits/component implementations. This is different from *_template.c versions, because the binary size is actually significantly reduced. A further advantage is that implementing hand-written arch-specific implementations (asm) for one higher bitdepth automatically works for all. Best of all: there's no runtime penalty. Maybe you want to consider that for vvc also. (It's probably too late to fix ffh264/hevc/vp9.) I can elaborate further if you're interested (maybe IRC?). The more complex the codec gets (vvc > hevc > h264 > mpeg, and av1 > vp9 > vp8), the higher the (binary) codesize gains from such an implementation choice. FFmpeg is already huge so it's worth trying to trim its fat a bit. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
