On Wed, Feb 13, 2019 at 01:28:34PM -0300, Ezequiel Garcia wrote:

On Wed, 2019-02-13 at 12:02 +0900, Tomasz Figa wrote:

quoted

On Wed, Feb 13, 2019 at 6:22 AM Ezequiel Garcia [off-list ref] wrote:

quoted

Hey Tomasz,

On Tue, 2019-02-12 at 21:50 +0900, Tomasz Figa wrote:

quoted

Hi Maxime,

On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
[off-list ref] wrote:

quoted

Hi,

Here is a new version of the H264 decoding support in the cedrus
driver.

Thanks for working on this. Please see my comments below.

quoted

As you might already know, the cedrus driver relies on the Request
API, and is a reverse engineered driver for the video decoding engine
found on the Allwinner SoCs.

This work has been possible thanks to the work done by the people
behind libvdpau-sunxi found here:
https://github.com/linux-sunxi/libvdpau-sunxi/

I've tested the various ABI using this gdb script:
http://code.bulix.org/jl4se4-505620?raw

And this test script:
http://code.bulix.org/8zle4s-505623?raw

The application compiled is quite trivial:
http://code.bulix.org/e34zp8-505624?raw

The output is:
arm:    builds/arm-test-v4l2-h264-structures
        SHA1: 88cbf7485ba81831fc3b93772b215599b3b38318
x86:    builds/x86-test-v4l2-h264-structures
        SHA1: 88cbf7485ba81831fc3b93772b215599b3b38318
x64:    builds/x64-test-v4l2-h264-structures
        SHA1: 88cbf7485ba81831fc3b93772b215599b3b38318
arm64:  builds/arm64-test-v4l2-h264-structures
        SHA1: 88cbf7485ba81831fc3b93772b215599b3b38318

Let me know if there's any flaw using that test setup, or if you have
any comments on the patches.

Maxime

Changes from v2:
  - Simplified _cedrus_write_ref_list as suggested by Jernej
  - Set whether the frame is used as reference using nal_ref_idc
  - Respect chroma_format_idc
  - Fixes for the scaling list and prediction tables
  - Wrote the documentation for the flags
  - Added a bunch of defines to the driver bit fields
  - Reworded the controls and data format descriptions as suggested
    by Hans
  - Reworked the controls' structure field size to avoid padding
  - Removed the long term reference flag

This and...

Maxime has dropped this because of Ayaka's mail about long term references
not making much sense in stateless decoders.

I haven't seen any argument confirming that thesis, though. I should
have kicked in earlier, sorry.

OK, in that case, we need to have this flag back.

quoted

quoted

I noticed that RK3399 TRM has a field to specify long term refs and
so was wondering about this item as well.

quoted

quoted

  - Reintroduced the neighbor info buffer
  - Removed the ref_pic_list_p0/b0/b1 arrays that are redundant with the
    one in the DPB

these are used in our Rockchip VDEC driver.

Could you elaborate on the reasons why they got removed?

If I understood correctly, there are two reference picture lists.
P-frames will populate ref_pic_list0 and B-frames will populate both.

According to this, v4l2_ctrl_h264_slice_param.ref_pic_list0 and .ref_pic_list1
should be enough and ref_pic_list_p0/b0/b1 are not needed.

What do you think?

The lists in v4l2_ctrl_h264_slice_param are expected to be past the
per-slice modification stage (which is quite complicated and better
done in userspace),

The fact that these are RefPicList0 and RefPicList1, after
the reordering stage should be better documented.

quoted

while the ones in v4l2_ctrl_h264_decode_param just
in the original order. Rockchip VPU expects them in the original order
and does the modification in the hardware.

OK, I see.

So, we have RefPicList0 and RefPicList1, and there is an initialization
stage and a modification/reordering process.

One could argue that it's more generic to just pass the initial list,
but that would mean doing in the kernel something that is easier
done in userspace (and parsers doing this are already available).

The question would be what is the most generic way of passing
the RefPicList0 and RefPicList1 in its initial state.

1/ We create additional controls for these.

2/ We put them on some of the other controls. Putting them on
v4l2_ctrl_h264_decode_param didn't seem too wrong.

Any objections to put them back in there?

None. i'll put them back in.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel