On 4/30/2025 11:03 AM, Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics wrote: >> -----Original Message----- >> From: ffmpeg-devel On Behalf Of James >> Almer >> Sent: środa, 30 kwietnia 2025 02:40 >> To:ffmpeg-devel@ffmpeg.org >> Subject: [FFmpeg-devel] [PATCH] avcodec: add APV encoder using liboapv >> >> From: Dawid Kozinski >> >> Co-authored-by: James Almer >> Signed-off-by: James Almer >> --- >> Touched up Dawid's patch to fix several issues. The most important one > being >> the image rescaling code that's out of place in an encoder. >> liboapv does not seem to properly support 12bit content yet (Which is why > the >> scaling code was added, to reduce the input to 10bit), so i removed it >> altogether. Same with all the references to GRAY, 420P, A444P, and Y210, > which >> are also not supported. >> > Thank you for the review and your changes. We are aware that the encoder is > not the best place for data rescaling. However, the oapve_encode() function > requires data which size is a multiple of 16. Any suggestions for resolving > this problem? I allocated the oapv_imgb_t with dimensions aligned to a multiple of 16. The input frame data is then copied to it, leaving the padding zeroed. A variation of your attempt, like this: imgb->aw[i] = FFALIGN(imgb->w[i], OAPV_MB_W); imgb->s[i] = imgb->aw[i] * OAPV_CS_GET_BYTE_DEPTH(cs); imgb->ah[i] = FFALIGN(imgb->h[i], OAPV_MB_H); imgb->padr[i] = imgb->aw[i] - imgb->w[i]; imgb->padb[i] = imgb->ah[i] - imgb->h[i]; imgb->bsize[i] = imgb->s[i] * imgb->ah[i]; imgb->a[i] = imgb->baddr[i] = av_mallocz(imgb->bsize[i]); Where imgb->w[i] and imgb->h[i] are the actual (not necessarily multiple of 16) image plane dimensions.