kernel/git/stable/linux.git/include/media/h264-ctrls.h, branch master

media: uapi: move H264 stateless controls out of staging

2020-12-03T11:27:33+00:00

The H.264 stateless 'uAPI' was staging and marked explicitly in the V4L2 specification that it will change and is unstable. Note that these control IDs were never exported as a public API, they were only defined in kernel-local headers (h264-ctrls.h). Now, the H264 stateless controls is ready to be part of the stable uAPI. While not too late, let's rename them and re-number their control IDs, moving them to the newly created stateless control class, and updating all the drivers accordingly. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: Move the H264 stateless control types out of staging

2020-12-03T11:27:33+00:00

Move the H264 stateless control types out of staging, and re-number them to avoid any confusion. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: Move parsed H264 pixel format out of staging

2020-12-03T11:27:33+00:00

Since we are ready to stabilize the H264 stateless API, start by first moving the parsed H264 pixel format. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: controls: Validate H264 stateless controls

2020-12-03T11:27:33+00:00

Check that all the fields that correspond or are related to a H264 specification syntax element have legal values. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: Rename stateful codec control macros

2020-12-03T11:27:32+00:00

For historical reasons, stateful codec controls are named as {}_MPEG_{}. While we can't at this point sanely change all control IDs (such as V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER), we can least change the more meaningful macros such as classes macros. Signed-off-by: Ezequiel Garcia Tested-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: h264: Add documentation to the interface header

2020-11-16T09:31:07+00:00

In preparation for making the interface public, document all the structures. Special care is taken to annotate those fields that depart from the H264 syntax. This commit only adds documentation and doesn't affect functionality in any way. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENT

2020-09-01T12:13:28+00:00

Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX if a non-flat scaling matrix applies to the picture. This is the case if SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag are set, and should be handled by applications. On one hand, the PPS bitstream syntax element signals the presence of a Picture scaling matrix modifying the Sequence (SPS) scaling matrix. On the other hand, our flag should indicate if the scaling matrix V4L2 control is applicable to this request. Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with bitstream syntax element pic_scaling_matrix_present_flag, and clarify the meaning of our flag. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: h264: Clean slice invariants syntax elements

2020-09-01T12:13:28+00:00

The H.264 specification requires in section 7.4.3 "Slice header semantics", that the following values shall be the same in all slice headers: pic_parameter_set_id frame_num field_pic_flag bottom_field_flag idr_pic_id pic_order_cnt_lsb delta_pic_order_cnt_bottom delta_pic_order_cnt[ 0 ] delta_pic_order_cnt[ 1 ] sp_for_switch_flag slice_group_change_cycle These bitstream fields are part of the slice header, and therefore passed redundantly on each slice. The purpose of the redundancy is to make the codec fault-tolerant in network scenarios. This is of course not needed to be reflected in the V4L2 controls, given the bitstream has already been parsed by applications. Therefore, move the redundant fields to the per-frame decode parameters control (DECODE_PARAMS). Field 'pic_parameter_set_id' is simply removed in this case, because the PPS control must currently contain the active PPS. Syntax elements dec_ref_pic_marking() and those related to pic order count, remain invariant as well, and therefore, the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size are also common to all slices. Signed-off-by: Ezequiel Garcia Reviewed-by: Nicolas Dufresne Tested-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: h264: Clarify SLICE_BASED mode

2020-09-01T12:13:28+00:00

Currently, the SLICE_BASED and FRAME_BASED modes documentation is misleading and not matching the intended use-cases. Drop non-required fields SLICE_PARAMS 'start_byte_offset' and DECODE_PARAMS 'num_slices' and clarify the decoding modes in the documentation. On SLICE_BASED mode, a single slice is expected per OUTPUT buffer, and therefore 'start_byte_offset' is not needed (since the offset to the slice is the start of the buffer). This mode requires the use of CAPTURE buffer holding, and so the number of slices shall not be required. On FRAME_BASED mode, the devices are expected to take care of slice parsing. Neither SLICE_PARAMS are required (and shouldn't be exposed by frame-based drivers), nor the number of slices. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: uapi: h264: Drop SLICE_PARAMS 'size' field

2020-09-01T12:13:28+00:00

The SLICE_PARAMS control is intended for slice-based devices. In this mode, the OUTPUT buffer contains a single slice, and so the buffer's plane payload size can be used to query the slice size. To reduce the API surface drop the size from the SLICE_PARAMS control. A follow-up change will remove other members in SLICE_PARAMS so we don't need to add padding fields here. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab