Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
4fc81c58 |
| 02-Nov-2022 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: Remove cedrus_codec enum
Last user of cedrus_codec enum is cedrus_engine_enable() but this argument is completely redundant. Same information can be obtained via source pixel format.
media: cedrus: Remove cedrus_codec enum
Last user of cedrus_codec enum is cedrus_engine_enable() but this argument is completely redundant. Same information can be obtained via source pixel format. Let's remove this argument and enum.
No functional changes intended.
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
fec94f8c |
| 19-Oct-2022 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: h264: Optimize mv col buffer allocation
Currently allocation for mv col buffer pool is very wasteful. It allocates memory for worst case which is a lot more than it's needed for typic
media: cedrus: h264: Optimize mv col buffer allocation
Currently allocation for mv col buffer pool is very wasteful. It allocates memory for worst case which is a lot more than it's needed for typical use. Fix that by replacing pool with individual allocations when such buffer is really needed. At that time all needed information for determining optimal mv col buffer size is also known.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
Revision tags: v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56 |
|
#
e21cde40 |
| 18-Jul-2022 |
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> |
media: cedrus: Use vb2_find_buffer
Use the newly introduced vb2_find_buffer API to get a vb2_buffer given a buffer timestamp.
Cc: Maxime Ripard <mripard@kernel.org> Cc: Paul Kocialkowski <paul.koci
media: cedrus: Use vb2_find_buffer
Use the newly introduced vb2_find_buffer API to get a vb2_buffer given a buffer timestamp.
Cc: Maxime Ripard <mripard@kernel.org> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
Revision tags: v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49 |
|
#
4af46bcc |
| 20-Jun-2022 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: Add error handling for failed setup
During decoding setup stage for complex codecs like HEVC driver can detect inconsistent values in controls or some other task, like allocating memo
media: cedrus: Add error handling for failed setup
During decoding setup stage for complex codecs like HEVC driver can detect inconsistent values in controls or some other task, like allocating memory, can fail.
Currently setup stage has no way of signalling error. Change return type of setup callback to int and if returned value is not zero, skip decoding and finish job immediately with error flag.
While currently there is only one place when setup can fail, it's expected that there will be more such cases in the future, when HEVC decoding is improved.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
Revision tags: v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24 |
|
#
fecd363a |
| 14-Feb-2022 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: h264: Fix neighbour info buffer size
According to BSP library source, H264 neighbour info buffer size needs to be 32 kiB for H6. This is similar to H265 decoding, which also needs dou
media: cedrus: h264: Fix neighbour info buffer size
According to BSP library source, H264 neighbour info buffer size needs to be 32 kiB for H6. This is similar to H265 decoding, which also needs double buffer size in comparison to older Cedrus core generations.
Increase buffer size to cover H6 needs. Since increase is not that big in absolute numbers, it doesn't make sense to complicate logic for older generations.
Issue was discovered using iommu and cross checked with BSP library source.
Fixes: 6eb9b758e307 ("media: cedrus: Add H264 decoding support") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
Revision tags: v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12 |
|
#
5db127a5 |
| 10-Oct-2021 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: Don't kernel map most buffers
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
media: cedrus: Don't kernel map most buffers
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>
show more ...
|
#
56dcb548 |
| 14-Feb-2022 |
Jernej Skrabec <jernej.skrabec@gmail.com> |
media: cedrus: h264: Fix neighbour info buffer size
[ Upstream commit fecd363ae2d5042553370b0adf60c47e35c34a83 ]
According to BSP library source, H264 neighbour info buffer size needs to be 32 kiB
media: cedrus: h264: Fix neighbour info buffer size
[ Upstream commit fecd363ae2d5042553370b0adf60c47e35c34a83 ]
According to BSP library source, H264 neighbour info buffer size needs to be 32 kiB for H6. This is similar to H265 decoding, which also needs double buffer size in comparison to older Cedrus core generations.
Increase buffer size to cover H6 needs. Since increase is not that big in absolute numbers, it doesn't make sense to complicate logic for older generations.
Issue was discovered using iommu and cross checked with BSP library source.
Fixes: 6eb9b758e307 ("media: cedrus: Add H264 decoding support") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
73bc0b0c |
| 23-Dec-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Fix H264 decoding
During H264 API overhaul subtle bug was introduced Cedrus driver. Progressive references have both, top and bottom reference flags set. Cedrus reference list expects
media: cedrus: Fix H264 decoding
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>
show more ...
|
#
ae584fbb |
| 23-Dec-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Fix H264 decoding
commit 73bc0b0c2a96b31199da0ce6c3d04be81ef73bb9 upstream.
During H264 API overhaul subtle bug was introduced Cedrus driver. Progressive references have both, top an
media: cedrus: Fix H264 decoding
commit 73bc0b0c2a96b31199da0ce6c3d04be81ef73bb9 upstream.
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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17 |
|
#
9ac924b9 |
| 21-Oct-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: h264: Fix check for presence of scaling matrix
If scaling matrix control is present, VPU should not use default matrix. Fix that.
Fixes: b3a23db0e2f8 ("media: cedrus: Use H264_SCALIN
media: cedrus: h264: Fix check for presence of scaling matrix
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>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
b3a23db0 |
| 24-Aug-2020 |
Ezequiel Garcia <ezequiel@collabora.com> |
media: cedrus: Use H264_SCALING_MATRIX only when required
Baseline, Main and Extended profiles are specified to not support a scaling matrix. Also, High profiles can optionally specify a scaling mat
media: cedrus: Use H264_SCALING_MATRIX only when required
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>
show more ...
|
#
46e8893e |
| 24-Aug-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: h264: Fix frame list construction
Current frame list construction algorithm assumes that decoded image will be output into its own buffer. That is true for progressive content but not
media: cedrus: h264: Fix frame list construction
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>
show more ...
|
#
cfc8c3ed |
| 24-Aug-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: h264: Properly configure reference field
When interlaced H264 content is being decoded, references must indicate which field is being referenced. Currently this was done by checking c
media: cedrus: h264: Properly configure reference field
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>
show more ...
|
#
d9358563 |
| 24-Aug-2020 |
Ezequiel Garcia <ezequiel@collabora.com> |
media: uapi: h264: Clean slice invariants syntax elements
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
media: uapi: h264: Clean slice invariants syntax elements
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>
show more ...
|
#
f6f0d58e |
| 24-Aug-2020 |
Ezequiel Garcia <ezequiel@collabora.com> |
media: uapi: h264: Drop SLICE_PARAMS 'size' field
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 pay
media: uapi: h264: Drop SLICE_PARAMS 'size' field
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>
show more ...
|
#
eb44c6c9 |
| 24-Aug-2020 |
Ezequiel Garcia <ezequiel@collabora.com> |
media: uapi: h264: Split prediction weight parameters
The prediction weight parameters are only required under certain conditions, which depend on slice header parameters.
As specified in section 7
media: uapi: h264: Split prediction weight parameters
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>
show more ...
|
#
e000e1fa |
| 24-Aug-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: uapi: h264: Update reference lists
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 pro
media: uapi: h264: Update reference lists
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>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26 |
|
#
ea755701 |
| 15-Mar-2020 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: h264: Fix 4K decoding on H6
Due to unknown reason, H6 needs larger intraprediction buffer for 4K videos than other SoCs. This was discovered by playing 4096x2304 video, which is maxim
media: cedrus: h264: Fix 4K decoding on H6
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>
show more ...
|
Revision tags: v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10 |
|
#
03e612e7 |
| 06-Nov-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Fix H264 4k support
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
media: cedrus: Fix H264 4k support
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>
show more ...
|
#
3aef46bd |
| 10-Nov-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Properly signal size in mode register
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 si
media: cedrus: Properly signal size in mode register
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>
show more ...
|
Revision tags: v5.3.9, v5.3.8 |
|
#
a6b8feae |
| 28-Oct-2019 |
Jonas Karlman <jonas@kwiboo.se> |
media: cedrus: Use correct H264 8x8 scaling list
Documentation now defines the expected order of scaling lists, change to use correct indices.
Fixes: 6eb9b758e307 ("media: cedrus: Add H264 decoding
media: cedrus: Use correct H264 8x8 scaling list
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>
show more ...
|
#
1fd50a2c |
| 26-Oct-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Use helpers to access capture queue
Accessing capture queue structue directly is not safe. Use helpers for that.
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-of
media: cedrus: Use helpers to access capture queue
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>
show more ...
|
#
61ad1233 |
| 26-Oct-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Fix decoding for some H264 videos
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 wh
media: cedrus: Fix decoding for some H264 videos
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>
show more ...
|
Revision tags: v5.3.7, v5.3.6 |
|
#
eabf10e5 |
| 11-Oct-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: h264: Support multiple slices per frame
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
media: cedrus: h264: Support multiple slices per frame
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>
show more ...
|
Revision tags: v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
633eadc9 |
| 30-May-2019 |
Jernej Skrabec <jernej.skrabec@siol.net> |
media: cedrus: Remove dst_bufs from context
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 <j
media: cedrus: Remove dst_bufs from context
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>
show more ...
|