diff options
author | Maxime Ripard <maxime.ripard@bootlin.com> | 2018-07-16 14:28:25 +0200 |
---|---|---|
committer | Maxime Ripard <maxime.ripard@bootlin.com> | 2018-07-17 15:30:33 +0200 |
commit | e7c09a336f74a688e6fb3609afd8c2687dee03c4 (patch) | |
tree | 924966b8a778a0cec122b45c66423ec2fca70f68 /src/h264.h | |
parent | dadb3d344f5327b0e27c559f46051ca522887077 (diff) | |
download | libva-v4l2-request-e7c09a336f74a688e6fb3609afd8c2687dee03c4.tar.gz libva-v4l2-request-e7c09a336f74a688e6fb3609afd8c2687dee03c4.tar.bz2 libva-v4l2-request-e7c09a336f74a688e6fb3609afd8c2687dee03c4.zip |
h264: Implement local cache of the latest decoded pictures
The libva only provides the reference images needed to decode the current
picture, but not the full DPB. However, some codecs need that whole DPB in
order to decode a picture.
For example, the Allwinner hardware codec has an internal SRAM, with each
picture getting a slot in that SRAM, and during each decoding process, some
metadata will then be generated from that SRAM content to a separate
buffer. Therefore, each frames must be located at the same SRAM position
each time so that the metadata are then re-used properly.
However, since libva will only pass a few reference images, we can end up
in a situation where multiple, subsequent, frames will have the same
reference images set, but might all be used as reference later on and
cannot therefore be located at the same position.
And from a more theorical point of view, Linux expects a full blown DPB in
its H264 control.
In order to work around this, we can create a shadow of the DPB by simply
maintaining a list of 16 decoded images, each associated with their
VAPictureH264 and an age. This age is the last time we used that frame as
reference. When a new picture is decoded, either we assign it to a free
slot, or we reuse the slot from the frame that hasn't been used as a
reference for the longest time.
This is a much simpler approach than the one documented in the H264 spec,
but this shouldn't really be a problem since we don't handle the reference
frames ourselves, but just re-use the one from the libva, and taken from
the bitstream before. As such, frames that are not supposed to be used for
reference will not be anymore, their age will not increase, and therefore
after a while we will garbage-collect their slot to store a much newer
frame.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Diffstat (limited to 'src/h264.h')
-rw-r--r-- | src/h264.h | 19 |
1 files changed, 19 insertions, 0 deletions
@@ -27,10 +27,29 @@ #ifndef _H264_H_ #define _H264_H_ +#include <stdbool.h> + +#include <va/va.h> + struct object_context; struct object_surface; struct cedrus_data; +#define H264_DPB_SIZE 16 + +struct h264_dpb_entry { + VAPictureH264 pic; + unsigned int age; + bool used; + bool valid; + bool reserved; +}; + +struct h264_dpb { + struct h264_dpb_entry entries[H264_DPB_SIZE]; + unsigned int age; +}; + int h264_set_controls(struct cedrus_data *data, struct object_context *context, struct object_surface *surface); |