From: Maxime Ripard <maxime.ripard@bootlin.com> To: Ayaka <ayaka@soulik.info> Cc: tfiga@chromium.org, acourbot@chromium.org, hans.verkuil@cisco.com, sakari.ailus@linux.intel.com, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, jenskuske@gmail.com, linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org, Paul Kocialkowski <paul.kocialkowski@bootlin.com>, Chen-Yu Tsai <wens@csie.org>, posciak@chromium.org, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Guenter Roeck <groeck@chromium.org>, nicolas.dufresne@collabora.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Subject: Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls. Date: Fri, 25 Jan 2019 13:47:47 +0100 [thread overview] Message-ID: <20190125124747.u32sgm3kto5uo3op@flea> (raw) In-Reply-To: <2C346EE9-7066-497C-BDE2-D4ED0BC3E8CF@soulik.info> [-- Attachment #1: Type: text/plain, Size: 3205 bytes --] On Thu, Jan 24, 2019 at 10:37:23PM +0800, Ayaka wrote: > >>>>> +#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'm not sure what is your point? > >> > >> I found I was wrong at the last email. > >> > >> 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. > > > > I'll remove the LONG_TERM flag then. We do need the other two for the > > Allwinner driver though. > > > > I would ask Paulk and check the manual and vendor library later. > > Even there are two register fields, it don’t mean they would be used > and required at the same times. Because it don’t follow ISO manual. It's not a matter of decoding per se, but how the hardware behaves. All the buffers needed for one particular frame to be decoded are uploaded to an SRAM, and the position of each buffer in that SRAM cannot change during the time when it has been decoded, and then later on when it's used as a reference. If you only have the frames needed to decode the current frame, you will have no idea which slot in the SRAM can be reused, whereas having the full DPB allows you to do that. And that's what _FLAG_ACTIVE gives you. > >> And I agree above with my last mail, so I would suggest to keep a property > >> as index for both frame_num and pic_num, as only one of them would be used > >> for a picture decoding once time. > > > > I'd really prefer to keep everything that is in the bitstream defined > > here. We don't want to cover the usual cases, but all of them even the > > one that haven't been designed yet, so we should be really > > conservative. > > As I mention in the other mail, a stateless decoder or encoder like > means the device won’t track the previous result. But you have no > idea on what data the device would need to process this picture. It > is hard to define a standard structure for it. > > As you see, even allwinner doesn’t obey all the standard the IOS > document said. It's not that it disobeys it, it's that it requires the full blown DPB to have a working driver. > In my original suggestion, I would just to add more reservation > fields then future driver can use it. This interface is not stable at the moment, so it doesn't really matter does it? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@bootlin.com> To: Ayaka <ayaka@soulik.info> Cc: linux-arm-kernel@lists.infradead.org, nicolas.dufresne@collabora.com, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, acourbot@chromium.org, linux-kernel@vger.kernel.org, tfiga@chromium.org, Paul Kocialkowski <paul.kocialkowski@bootlin.com>, linux-sunxi@googlegroups.com, hans.verkuil@cisco.com, jenskuske@gmail.com, sakari.ailus@linux.intel.com, Guenter Roeck <groeck@chromium.org>, Chen-Yu Tsai <wens@csie.org>, linux-media@vger.kernel.org, posciak@chromium.org, Laurent Pinchart <laurent.pinchart@ideasonboard.com> Subject: Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls. Date: Fri, 25 Jan 2019 13:47:47 +0100 [thread overview] Message-ID: <20190125124747.u32sgm3kto5uo3op@flea> (raw) In-Reply-To: <2C346EE9-7066-497C-BDE2-D4ED0BC3E8CF@soulik.info> [-- Attachment #1.1: Type: text/plain, Size: 3205 bytes --] On Thu, Jan 24, 2019 at 10:37:23PM +0800, Ayaka wrote: > >>>>> +#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'm not sure what is your point? > >> > >> I found I was wrong at the last email. > >> > >> 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. > > > > I'll remove the LONG_TERM flag then. We do need the other two for the > > Allwinner driver though. > > > > I would ask Paulk and check the manual and vendor library later. > > Even there are two register fields, it don’t mean they would be used > and required at the same times. Because it don’t follow ISO manual. It's not a matter of decoding per se, but how the hardware behaves. All the buffers needed for one particular frame to be decoded are uploaded to an SRAM, and the position of each buffer in that SRAM cannot change during the time when it has been decoded, and then later on when it's used as a reference. If you only have the frames needed to decode the current frame, you will have no idea which slot in the SRAM can be reused, whereas having the full DPB allows you to do that. And that's what _FLAG_ACTIVE gives you. > >> And I agree above with my last mail, so I would suggest to keep a property > >> as index for both frame_num and pic_num, as only one of them would be used > >> for a picture decoding once time. > > > > I'd really prefer to keep everything that is in the bitstream defined > > here. We don't want to cover the usual cases, but all of them even the > > one that haven't been designed yet, so we should be really > > conservative. > > As I mention in the other mail, a stateless decoder or encoder like > means the device won’t track the previous result. But you have no > idea on what data the device would need to process this picture. It > is hard to define a standard structure for it. > > As you see, even allwinner doesn’t obey all the standard the IOS > document said. It's not that it disobeys it, it's that it requires the full blown DPB to have a working driver. > In my original suggestion, I would just to add more reservation > fields then future driver can use it. This interface is not stable at the moment, so it doesn't really matter does it? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-25 12:47 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-15 14:56 [PATCH v2 0/2] media: cedrus: Add H264 decoding support Maxime Ripard 2018-11-15 14:56 ` Maxime Ripard 2018-11-15 14:56 ` [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls Maxime Ripard 2018-11-15 14:56 ` Maxime Ripard 2018-11-27 17:23 ` [linux-sunxi] " Jernej Škrabec 2018-11-27 17:23 ` Jernej Škrabec 2018-11-28 15:52 ` Maxime Ripard 2018-11-28 15:52 ` Maxime Ripard 2018-12-05 12:56 ` Hans Verkuil 2018-12-05 12:56 ` Hans Verkuil 2019-01-08 9:52 ` Randy 'ayaka' Li 2019-01-08 9:52 ` Randy 'ayaka' Li 2019-01-08 17:01 ` ayaka 2019-01-08 17:01 ` ayaka 2019-01-10 13:33 ` ayaka 2019-01-10 13:33 ` ayaka 2019-01-17 11:21 ` Maxime Ripard 2019-01-17 11:21 ` Maxime Ripard 2019-01-17 11:16 ` Maxime Ripard 2019-01-17 11:16 ` Maxime Ripard 2019-01-17 11:01 ` Maxime Ripard 2019-01-17 11:01 ` Maxime Ripard 2019-01-20 12:48 ` ayaka 2019-01-20 12:48 ` ayaka 2019-01-24 14:23 ` Maxime Ripard 2019-01-24 14:23 ` Maxime Ripard 2019-01-24 14:37 ` Ayaka 2019-01-24 14:37 ` Ayaka 2019-01-25 12:47 ` Maxime Ripard [this message] 2019-01-25 12:47 ` Maxime Ripard 2019-01-28 5:54 ` Alexandre Courbot 2019-01-28 5:54 ` Alexandre Courbot 2018-11-15 14:56 ` [PATCH v2 2/2] media: cedrus: Add H264 decoding support Maxime Ripard 2018-11-15 14:56 ` Maxime Ripard 2018-11-24 20:43 ` [linux-sunxi] " Jernej Škrabec 2018-11-24 20:43 ` Jernej Škrabec 2018-11-27 15:50 ` Maxime Ripard 2018-11-27 15:50 ` Maxime Ripard 2018-11-27 16:30 ` Jernej Škrabec 2018-11-27 16:30 ` Jernej Škrabec 2018-11-27 20:19 ` Jernej Škrabec 2018-11-27 20:19 ` Jernej Škrabec 2018-11-30 7:30 ` Maxime Ripard 2018-11-30 7:30 ` Maxime Ripard 2018-11-30 17:56 ` Jernej Škrabec 2018-11-30 17:56 ` Jernej Škrabec 2018-11-30 12:37 ` Paul Kocialkowski 2018-11-30 12:37 ` Paul Kocialkowski 2018-12-05 22:27 ` [linux-sunxi] " Jernej Škrabec 2018-12-05 22:27 ` Jernej Škrabec 2018-11-16 7:04 ` [PATCH v2 0/2] " Tomasz Figa 2018-11-16 7:04 ` Tomasz Figa 2018-11-16 7:04 ` Tomasz Figa 2018-11-19 14:12 ` Maxime Ripard 2018-11-19 14:12 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190125124747.u32sgm3kto5uo3op@flea \ --to=maxime.ripard@bootlin.com \ --cc=acourbot@chromium.org \ --cc=ayaka@soulik.info \ --cc=groeck@chromium.org \ --cc=hans.verkuil@cisco.com \ --cc=jenskuske@gmail.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-sunxi@googlegroups.com \ --cc=nicolas.dufresne@collabora.com \ --cc=paul.kocialkowski@bootlin.com \ --cc=posciak@chromium.org \ --cc=sakari.ailus@linux.intel.com \ --cc=tfiga@chromium.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=wens@csie.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.