Hi,

On Wed, Jan 09, 2019 at 01:01:22AM +0800, ayaka wrote:

On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:

quoted

On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:

quoted

From: Pawel Osciak <redacted>

Stateless video codecs will require both the H264 metadata and slices in
order to be able to decode frames.

This introduces the definitions for a new pixel format for H264 slices that
have been parsed, as well as the structures used to pass the metadata from
the userspace to the kernel.

Co-Developed-by: Maxime Ripard <redacted>
Signed-off-by: Pawel Osciak <redacted>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Maxime Ripard <redacted>
---
  Documentation/media/uapi/v4l/biblio.rst       |   9 +
  .../media/uapi/v4l/extended-controls.rst      | 364 ++++++++++++++++++
  .../media/uapi/v4l/pixfmt-compressed.rst      |  20 +
  .../media/uapi/v4l/vidioc-queryctrl.rst       |  30 ++
  .../media/videodev2.h.rst.exceptions          |   5 +
  drivers/media/v4l2-core/v4l2-ctrls.c          |  42 ++
  drivers/media/v4l2-core/v4l2-ioctl.c          |   1 +
  include/media/v4l2-ctrls.h                    |  10 +
  include/uapi/linux/v4l2-controls.h            | 166 ++++++++
  include/uapi/linux/videodev2.h                |  11 +
  10 files changed, 658 insertions(+)
+#define V4L2_H264_DPB_ENTRY_FLAG_VALID		0x01
+#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE		0x02
+#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM	0x04
+
+struct v4l2_h264_dpb_entry {
+	__u32 tag;
+	__u16 frame_num;
+	__u16 pic_num;

Although the long term reference would use picture order count
and short term for frame num, but only one of them is used
for a entry of a dpb.

Besides, for a frame picture frame_num = pic_num * 2,
and frame_num = pic_num * 2 + 1 for a filed.

I mistook something before and something Herman told me is wrong, I read the
book explaining the ITU standard.

The index of a short term reference picture would be frame_num or POC and
LongTermPicNum for long term.

But stateless hardware decoder usually don't care about whether it is long
term or short term, as the real dpb updating or management work are not done
by the the driver or device and decoding job would only use the two list(or
one list for slice P) for reference pictures. So those flag for long term or
status can be removed as well.

Stateless decoder would care about just reference index of this picture and
maybe some extra property for the filed coded below. Keeping a property here
for the index of a picture is enough.

It doesn't look like it's part of the bitstream, the rockchip driver
seem like it's using the long term flags in the chromeos
driver. Tomasz, do you know why it's needed?

Maxime

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