Dear Jammy,You can reference to the datasheet of ast2600 revision 9 at section 36, Video Engine.
Am 18.10.21 um 10:51 schrieb Jammy Huang:
On 2021/10/14 下午 02:47, Paul Menzel wrote:It’s still good to have the name and revision of the datasheet, the code
Am 14.10.21 um 05:48 schrieb Jammy Huang:Sorry but our datasheet is confidential. The basic idea of this
aspeed support differential jpeg format which only compress the partssupport*s*
which are changed. In this way, it reduces both the amount of data to bePlease mention the datasheet name and revision and section, where this
transferred by network and those to be decoded on the client side.
functionality is described.
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.
was developed against documented. (Public datasheets would be even
better, also for review.)
This is a v4l2 based driver, so I prefer to use v4l2 control interface rather than sysfs.
Thank you. So some sysfs file?Which chips support it?AST2400/2500/2600 all support it.
* Aspeed JPEG Format: to control jpeg format4 new ctrls are added:Please add a space after the bullet points.
*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
Excuse my ignorance, how can these options be controlled?
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
Nice.I tested it by aspeed's kvm client which support decoding the aspeedAspeed JPEG Format requires an additional buffer, called bcd, to stores/that which/which/
the information that which macro block in the new frame is different
from the old one.How did you test it? What do the clients need to support?
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.
Did you test, how much bandwidth is saved? Some numbers would be nice.
format. Currently, I am porting this feature to novnc to have openbmc
support it.
The bandwidth saved is variant. It depends on how many blocks isThank you for the explanation.
different between new and old frame.If the new frame is identical
with the previous one, the compressed frame only needs 12 Bytes.
Kind regards,
Paul