Re: [PATCH v5] media: vicodec: add support for CROP and COMPOSE selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/03/2019 04:15 PM, Dafna Hirschfeld wrote:
> On Wed, Jan 2, 2019 at 12:22 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote:

<snip>

>>>     >       if (frm->components_num >= 3) {
>>>     > -             u32 chroma_h = frm->height / frm->height_div;
>>>     > -             u32 chroma_w = frm->width / frm->width_div;
>>>     > +             u32 chroma_h = height / frm->height_div;
>>>     > +             u32 chroma_w = width / frm->width_div;
>>>     > +             u32 chroma_coded_width = frm->coded_width / frm->width_div;
>>>
>>>     chroma_stride = frm->stride / frm->width_div;
> 
> This calculation of chroma_stride does not work for formats such as
> YUYV where  frm->width_div = 2 but the chromas are not in separate
> planes.
> How do I calculate the stride in general ?

For interleaved formats like YUYV the stride is equal to bytesperline.
To be more precise: bytesperline is the stride for the first plane. Since YUYV
formats have only one plane, that stride is valid for all color components.

> For yuv420 for example, where the chromas are in separate planes, is
> 'chroma_stride = stride / 2' ?

Yes.

> 
>>>
>>>     >               unsigned int chroma_size = chroma_h * chroma_w;
>>>     >
>>>     >               rlco_max = rlco + chroma_size / 2 - 256;
>>>     >               encoding |= encode_plane(frm->cb, ref_frm->cb, &rlco, rlco_max,
>>>     >                                        cf, chroma_h, chroma_w,
>>>     > -                                      frm->chroma_step,
>>>     > +                                      chroma_coded_width, frm->chroma_step,
>>>     >                                        is_intra, next_is_intra);
>>>     >               if (encoding & FWHT_FRAME_UNENCODED)
>>>     >                       encoding |= FWHT_CB_UNENCODED;
>>>     > @@ -778,7 +784,7 @@ u32 fwht_encode_frame(struct fwht_raw_frame *frm,
>>>     >               rlco_max = rlco + chroma_size / 2 - 256;
>>>     >               encoding |= encode_plane(frm->cr, ref_frm->cr, &rlco, rlco_max,
>>>     >                                        cf, chroma_h, chroma_w,
>>>     > -                                      frm->chroma_step,
>>>     > +                                      chroma_coded_width, frm->chroma_step,
>>>     >                                        is_intra, next_is_intra);
>>>     >               if (encoding & FWHT_FRAME_UNENCODED)
>>>     >                       encoding |= FWHT_CR_UNENCODED;
>>>     > @@ -788,8 +794,8 @@ u32 fwht_encode_frame(struct fwht_raw_frame *frm,
>>>     >       if (frm->components_num == 4) {
>>>     >               rlco_max = rlco + size / 2 - 256;
>>>     >               encoding |= encode_plane(frm->alpha, ref_frm->alpha, &rlco,
>>>     > -                                      rlco_max, cf, frm->height, frm->width,
>>>     > -                                      frm->luma_alpha_step,
>>>     > +                                      rlco_max, cf, height, width,
>>>     > +                                      frm->coded_width, frm->luma_alpha_step,
>>>     >                                        is_intra, next_is_intra);
>>>     >               if (encoding & FWHT_FRAME_UNENCODED)
>>>     >                       encoding |= FWHT_ALPHA_UNENCODED;
>>>     > @@ -801,7 +807,7 @@ u32 fwht_encode_frame(struct fwht_raw_frame *frm,
>>>     >  }
>>>     >
>>>     >  static void decode_plane(struct fwht_cframe *cf, const __be16 **rlco, u8 *ref,
>>>     > -                      u32 height, u32 width, bool uncompressed)
>>>     > +                      u32 height, u32 width, u32 coded_width, bool uncompressed)
>>>
>>>     coded_width is OK here since you are writing into 'ref' and not the vb2 capture buffer.
> 
> 
> Actually I think coded_width is not needed at all for the decoder
> because it only use the internal ref_frame buffer.
> So the width and height are enough.

I'm not 100% certain. Specifically for 4:2:0 formats where the width/height
has to be a multiple of 16 instead of 8. So you might need the coded_width/height
to handle that correctly. You would have to check this carefully.

Regards,

	Hans



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux