On Thu, Oct 4, 2018 at 9:46 PM Paul Kocialkowski <contact@xxxxxxxx> wrote: > > Hi, > > Here are a few minor suggestion about H.264 controls. > > Le jeudi 04 octobre 2018 à 17:11 +0900, Alexandre Courbot a écrit : > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst > > index a9252225b63e..9d06d853d4ff 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -810,6 +810,31 @@ enum v4l2_mpeg_video_bitrate_mode - > > otherwise the decoder expects a single frame in per buffer. > > Applicable to the decoder, all codecs. > > > > +.. _v4l2-mpeg-h264: > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SPS`` > > + Instance of struct v4l2_ctrl_h264_sps, containing the SPS of to use with > > + the next queued frame. Applicable to the H.264 stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_PPS`` > > + Instance of struct v4l2_ctrl_h264_pps, containing the PPS of to use with > > + the next queued frame. Applicable to the H.264 stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX`` > > For consistency with MPEG-2 and upcoming JPEG, I think we should call > this "H264_QUANTIZATION". I'd rather stay consistent with H.264 specification, which uses the wording as defined in Alex's patch. Otherwise it would be difficult to correlate between the controls and the specification, which is something that the userspace developer would definitely need to understand how to properly parse the stream and obtain the decoding parameters. > > > + Instance of struct v4l2_ctrl_h264_scaling_matrix, containing the scaling > > + matrix to use when decoding the next queued frame. Applicable to the H.264 > > + stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM`` > > Ditto with "H264_SLICE_PARAMS". > It doesn't seem to be related to the spec in this case and "params" sounds better indeed. Best regards, Tomasz
