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.)
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?
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