lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Oct 2021 18:10:35 +0800 From: Jammy Huang <jammy_huang@...eedtech.com> To: Paul Menzel <pmenzel@...gen.mpg.de> CC: "eajames@...ux.ibm.com" <eajames@...ux.ibm.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, "joel@....id.au" <joel@....id.au>, "andrew@...id.au" <andrew@...id.au>, "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>, "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 4/6] media: aspeed: Support aspeed mode to reduce compressed data Dear Paul, Thanks for your help. On 2021/10/18 下午 05:34, Paul Menzel wrote: > Dear Jammy, > > > Am 18.10.21 um 10:51 schrieb Jammy Huang: > >> On 2021/10/14 下午 02:47, Paul Menzel wrote: >>> Am 14.10.21 um 05:48 schrieb Jammy Huang: >>>> aspeed support differential jpeg format which only compress the parts >>> support*s* >>> >>>> which are changed. In this way, it reduces both the amount of data to be >>>> transferred by network and those to be decoded on the client side. >>> Please mention the datasheet name and revision and section, where this >>> functionality is described. >> Sorry but our datasheet is confidential. The basic idea of this >> feature is that we can just compress the blocks which is different >> with previous frame rather than full frame. This idea is similar to >> the I & P frame in multimedia. > It’s still good to have the name and revision of the datasheet, the code > was developed against documented. (Public datasheets would be even > better, also for review.) You can reference to the datasheet of ast2600 revision 9 at section 36, Video Engine. > >>> Which chips support it? >> AST2400/2500/2600 all support it. >>>> 4 new ctrls are added: >>>> *Aspeed JPEG Format: to control aspeed's partial jpeg on/off >>>> *Aspeed Compression Mode: to control aspeed's compression mode >>>> *Aspeed HQ Mode: to control aspeed's HQ mode on/off >>>> *Aspeed HQ Quality: to control the quality of aspeed's HQ mode >>> Please add a space after the bullet points. >>> >>> Excuse my ignorance, how can these options be controlled? >> * Aspeed JPEG Format: to control jpeg format >> 0: standard jpeg, 1: aspeed jpeg >> * Aspeed Compression Mode: to control aspeed's compression mode >> 0: DCT Only, 1: DCT VQ mix 2-color, 2: DCT VQ mix 4-color >> This is AST2400 only. It will adapt JPEG or VQ encoding method according >> to the context automatically. >> * Aspeed HQ Mode: to control aspeed's HQ mode on/off >> 0: disabled, 1: enabled >> * Aspeed HQ Quality: to control the quality(0~11) of aspeed's HQ mode, >> only usefull if Aspeed HQ mode is enabled > Thank you. So some sysfs file? This is a v4l2 based driver, so I prefer to use v4l2 control interface rather than sysfs. The user can iterate v4l2 control by V4L2_CTRL_FLAG_NEXT_CTRL to know what is available. For example, the following is the information that aspeed_video driver supports [User Controls ] Aspeed JPEG Format : type=1, minimum=0, maximum=2, step=1, default_value=0 Aspeed Compression Mode : type=1, minimum=0, maximum=2, step=1, default_value=0 Aspeed HQ Mode : type=2, minimum=0, maximum=1, step=1, default_value=0 Aspeed HQ Quality : type=1, minimum=0, maximum=11, step=1, default_value=0 [JPEG Compression Controls ] Chroma Subsampling : type=3, minimum=0, maximum=2, step=1, default_value=0 Compression Quality : type=1, minimum=0, maximum=11, step=1, default_value=0 > >>>> Aspeed JPEG Format requires an additional buffer, called bcd, to store >>>> the information that which macro block in the new frame is different >>> s/that which/which/ >>> >>>> from the old one. >>>> >>>> To have bcd correctly working, we need to swap the buffers for src0/1 to >>>> make src1 refer to previous frame and src0 to the coming new frame. >>> How did you test it? What do the clients need to support? >>> >>> Did you test, how much bandwidth is saved? Some numbers would be nice. >> I tested it by aspeed's kvm client which support decoding the aspeed >> format. Currently, I am porting this feature to novnc to have openbmc >> support it. > Nice. >> The bandwidth saved is variant. It depends on how many blocks is >> different between new and old frame.If the new frame is identical >> with the previous one, the compressed frame only needs 12 Bytes. > Thank you for the explanation. > > > Kind regards, > > Paul
Powered by blists - more mailing lists