aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
AgeCommit message (Collapse)AuthorFilesLines
2021-10-19media: cedrus: Don't kernel map most buffersJernej Skrabec1-49/+64
Except for VP8 probability coefficients buffer, all other buffers are never accessed by CPU. That allows us to mark them with DMA_ATTR_NO_KERNEL_MAPPING flag. This helps with decoding big (like 4k) videos on 32-bit ARM platforms where default vmalloc size is relatively small - 240 MiB. Since auxiliary buffer are not yet efficiently allocated, this can be easily exceeded. Even if allocation is optimized, 4k videos will still often exceed this limit. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-01-26media: cedrus: Fix H264 decodingJernej Skrabec1-1/+1
During H264 API overhaul subtle bug was introduced Cedrus driver. Progressive references have both, top and bottom reference flags set. Cedrus reference list expects only bottom reference flag and only when interlaced frames are decoded. However, due to a bug in Cedrus check, exclusivity is not tested and that flag is set also for progressive references. That causes "jumpy" background with many videos. Fix that by checking that only bottom reference flag is set in control and nothing else. Tested-by: Andre Heider <a.heider@gmail.com> Fixes: cfc8c3ed533e ("media: cedrus: h264: Properly configure reference field") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-05media: cedrus: h264: Fix check for presence of scaling matrixJernej Skrabec1-1/+1
If scaling matrix control is present, VPU should not use default matrix. Fix that. Fixes: b3a23db0e2f8 ("media: cedrus: Use H264_SCALING_MATRIX only when required") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: cedrus: Use H264_SCALING_MATRIX only when requiredEzequiel Garcia1-0/+6
Baseline, Main and Extended profiles are specified to not support a scaling matrix. Also, High profiles can optionally specify a scaling matrix, using SPS and PPS NAL units. To meet this expectation, applications are required to set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT flag only when a scaling matrix is specified for a picture. Implement this on cedrus, which has hardware support for this case. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: cedrus: h264: Fix frame list constructionJernej Skrabec1-6/+9
Current frame list construction algorithm assumes that decoded image will be output into its own buffer. That is true for progressive content but not for interlaced where each field is decoded separately into same buffer. Fix that by checking if capture buffer is listed in DPB. If it is, reuse it. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: cedrus: h264: Properly configure reference fieldJernej Skrabec1-4/+2
When interlaced H264 content is being decoded, references must indicate which field is being referenced. Currently this was done by checking capture buffer flags. However, that is not correct because capture buffer may hold both fields. Fix this by checking newly introduced flags in reference lists. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Clean slice invariants syntax elementsEzequiel Garcia1-5/+4
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 <ezequiel@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Drop SLICE_PARAMS 'size' fieldEzequiel Garcia1-4/+3
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 <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Split prediction weight parametersEzequiel Garcia1-9/+3
The prediction weight parameters are only required under certain conditions, which depend on slice header parameters. As specified in section 7.3.3 Slice header syntax, the prediction weight table is present if: ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ (weighted_bipred_idc == 1 && slice_type == B)) Given its size, it makes sense to move this table to its control, so applications can avoid passing it if the slice doesn't specify it. Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight is 772 bytes. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Update reference listsJernej Skrabec1-3/+3
When dealing with interlaced frames, reference lists must tell if each particular reference is meant for top or bottom field. This info is currently not provided at all in the H264 related controls. Change reference lists to hold a structure, which specifies an index into the DPB array and the field/frame specification for the picture. Currently the only user of these lists is Cedrus which is just compile fixed here. Actual usage of will come in a following commit. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-24media: cedrus: h264: Fix 4K decoding on H6Jernej Skrabec1-1/+5
Due to unknown reason, H6 needs larger intraprediction buffer for 4K videos than other SoCs. This was discovered by playing 4096x2304 video, which is maximum what H6 VPU is supposed to support. Fixes: 03e612e701a6 ("media: cedrus: Fix H264 4k support") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-11-10media: cedrus: Fix H264 4k supportJernej Skrabec1-8/+83
H264 decoder needs additional or bigger buffers in order to decode 4k videos. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-11-10media: cedrus: Properly signal size in mode registerJernej Skrabec1-1/+1
Mode register also holds information if video width is bigger than 2048 and if it is equal to 4096. Rework cedrus_engine_enable() to properly signal this properties. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2019-11-09media: cedrus: Use correct H264 8x8 scaling listJonas Karlman1-2/+2
Documentation now defines the expected order of scaling lists, change to use correct indices. Fixes: 6eb9b758e307 ("media: cedrus: Add H264 decoding support") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2019-11-09media: cedrus: Use helpers to access capture queueJernej Skrabec1-2/+6
Accessing capture queue structue directly is not safe. Use helpers for that. Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2019-11-09media: cedrus: Fix decoding for some H264 videosJernej Skrabec1-3/+27
It seems that for some H264 videos at least one bitstream parsing trigger must be called in order to be decoded correctly. There is no explanation why this helps, but it was observed that two sample videos with this fix are now decoded correctly and there is no regression with others. Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2019-10-21media: cedrus: h264: Support multiple slices per frameJernej Skrabec1-1/+11
With recent changes, support for decoding multi-slice frames can be easily added now. Signal VPU if current slice is first in frame or not and add information about first macroblock coordinates. When frame contains multiple slices and driver works in slice mode, it's more efficient to hold capture buffer in queue until all slices of a same frame are decoded. Add support for that to Cedrus driver by exposing and implementing V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> [hverkuil-cisco@xs4all.nl: rewritten to use v4l2_m2m_buf_done_and_job_finish] [hverkuil-cisco@xs4all.nl: removed unnecessary (u32) cast] [hverkuil-cisco@xs4all.nl: use new_frame v4l2_m2m_ctx bool] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-13media: cedrus: Remove dst_bufs from contextJernej Skrabec1-2/+2
This array is just duplicated capture buffer queue. Remove it and adjust code to look into capture buffer queue instead. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-05-29media: cedrus: Add H264 decoding supportMaxime Ripard1-0/+576
Introduce some basic H264 decoding support in cedrus. So far, only the baseline profile videos have been tested, and some more advanced features used in higher profiles are not even implemented. Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

Privacy Policy