Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length

Hi Helen >On 3/26/21 10:03 AM, John Cox wrote: >> Hi Helen >> >>> Hi John, >>> >>> On 3/25/21 7:20 AM, John Cox wrote: >>>> Hi >>>> >>>>> Always use dmabuf size when considering the length of the buffer. >&g

Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length

Hi Helen >Hi John, > >On 3/25/21 7:20 AM, John Cox wrote: >> Hi >> >>> Always use dmabuf size when considering the length of the buffer. >>> Discard userspace provided length. >>> Fix length check error in _verify_length(), which was handling

Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length

igger than are likely to ever be used. If you have a fixed pool of fixed size buffers allocated at the start of time this wastefulness is unavoidable, but dmabufs can be dynamically sized to be as big as required and so there should be no limitation on passing in buffers that are smaller than the maximum. It also seems plausible that dmabufs that are larger than the maximum should be allowed as long as their bytesused is smaller or equal. As an aside, even when using dynamically sized dmabufs they are often way larger than the data they contain and forcing cache flushes or maps of their entire length rather than just the used portion is also wasteful. This might be a use for the incoming size field. Regards John Cox

Re: [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec

On Thu, 25 Feb 2021 19:05:55 +0100, you wrote: >Dne ?etrtek, 25. februar 2021 ob 18:34:48 CET je Ezequiel Garcia napisal(a): >> Hey Jernej, >> >> On Thu, 2021-02-25 at 18:01 +0100, Jernej Škrabec wrote: >> > Hi Ezequiel, >> > >> > Dne ?etrtek, 25. februar 2021 ob 14:09:52 CET je Ezequiel Garcia

Re: [PATCH v2 1/9] media: hevc: Modify structures to follow H265 ITU spec

__u16 short_term_ref_pic_set_size; >+ __u16 long_term_ref_pic_set_size; > >- __u8padding; >+ __u8padding[5]; > > /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */ > struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]; >@@ -209,4 +221,21 @@ struct v4l2_ctrl_hevc_slice_params { > __u64 flags; > }; > >+#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC 0x1 >+#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC 0x2 >+#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR 0x4 >+ >+struct v4l2_ctrl_hevc_decode_params { >+ __s32 pic_order_cnt_val; >+ __u8num_active_dpb_entries; >+ struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]; >+ __u8num_rps_poc_st_curr_before; >+ __u8num_rps_poc_st_curr_after; >+ __u8num_rps_poc_lt_curr; >+ __u8rps_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]; >+ __u8rps_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]; >+ __u8rps_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]; >+ __u64 flags; >+}; >+ > #endif While you are adding stuff is there any chance you could also add: #define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT (1ULL << 9) to the slice flags? The rpi H265 decoder needs it to deal with cases where dependant_slice_segment is set in the slice header. Thanks John Cox

Re: [PATCH v2 4/9] media: uapi: Add a control for HANTRO driver

ip_lenght: header first bits offset >+ */ >+struct hantro_hevc_extra_decode_params { >+ __u32 hevc_hdr_skip_lenght; >+ __u8padding[4]; >+}; Can you clarify how hevc_hdr_skip_length differs from v4l2_ctrl_hevc_slice_params.data_bit_offset? At first sight they would