> Question: Does Motion Adaption implementation (unlike Bob) require two
> distinct source surfaces plus an ADDITIONAL surface for the result?
Yes. A new surface is required for the result surface.
> -Original Message-
> From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf
Hi,
This patch series fixes and optimizes support for H.grayscale streams
encoded in H.264 (Patch8). This is backwards compatible with solutions
that incorrectly request for YUV 4:2:0 formats instead of the
appropriate Y800 one.
Tested with gstreamer-vaapi and FFmpeg/vaapi on Ivybridge. No
regres
Introduce a new i965_destroy_surface_storage() helper function to
unreference the underlying GEM buffer object, and any associated
private data, if any.
Signed-off-by: Gwenole Beauchesne
---
src/i965_decoder_utils.c | 6 +-
src/i965_drv_video.c | 14 +++---
src/i965_drv_video.h
Optimize support for grayscale surfaces in two aspects: (i) space
by only allocating the luminance component ; (ii) speed by avoiding
initialization of the (now inexistent) chrominance planes.
Keep backward compatibility with older codec layers that only
supported YUV 4:2:0 and not grayscale forma
Add new avc_ensure_surface_bo() helper function to factor out the
allocatiion and initialization processes of the reconstructed VA
surface buffer stores.
Keep preferred native format (NV12) and initialize chroma values
to 0.0 (0x80) when needed for "fake" grayscale (Y800) surfaces
implemented on t
Factor out code to validate profile/entrypoint per the underlying
hardware capabilities. Also fix vaGetConfigAttributes() to really
validate the profile/entrypoint pair.
Signed-off-by: Gwenole Beauchesne
---
src/i965_drv_video.c | 145 +++
1 file c
Fix size of the allocated buffer used to represent grayscale (Y800)
surfaces. Only the luminance component is needed, thus implying a
single plane.
Likewise, update render routines to only submit the first plane.
The existing render kernels readily only care about that single
plane.
Signed-off-by
If the hardware supports JPEG decoding, then we have to expose the
right set of chroma formats for the output (decoded) VA surface. In
particular, we could support YUV 4:0:0, 4:1:0, 4:2:2 and 4:4:4.
v2: export support for YUV 4:0:0 (grayscale) too [Haihao]
Signed-off-by: Gwenole Beauchesne
---
Only validate the user-defined chroma format (VAConfigAttribRTFormat)
attribute, if any. Don't override it. i.e. append a pre-defined value
only if it was not defined by the user beforehand.
Propertly return VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT if the supplied
chroma format is not supported.
Sig
From: Zhong Li
Signed-off-by: Zhong Li
(cherry picked from commit 9f9c505ed5212ae0704f71f45532b9716ac0bd51)
---
src/i965_drv_video.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
index 4315324..c700776 100755
--- a/src/i965_drv_video.c
+++
2014-05-15 10:53 GMT+02:00 Gwenole Beauchesne :
> Hi,
>
> 2014-05-15 10:45 GMT+02:00 Xiang, Haihao :
>>
>> Could you make your patches against the staging branch first ? On the
>> one hand, the nightly testing can check whether the patches result in
>> regression first, one the other hand, the hw i
Hi,
2014-05-15 10:45 GMT+02:00 Xiang, Haihao :
>
> Could you make your patches against the staging branch first ? On the
> one hand, the nightly testing can check whether the patches result in
> regression first, one the other hand, the hw info has been moved to a
> separated file on the staging b
2014-05-15 10:31 GMT+02:00 Xiang, Haihao :
> On Wed, 2014-05-14 at 15:13 +0200, Gwenole Beauchesne wrote:
>> If the hardware supports JPEG decoding, then we have to expose the
>> right set of chroma formats for the output (decoded) VA surface. In
>> particular, we could support YUV 4:1:0, 4:2:2 and
Could you make your patches against the staging branch first ? On the
one hand, the nightly testing can check whether the patches result in
regression first, one the other hand, the hw info has been moved to a
separated file on the staging branch, your patches might introduce a lot
of conflict whe
2014-05-15 10:25 GMT+02:00 Xiang, Haihao :
> On Wed, 2014-05-14 at 15:13 +0200, Gwenole Beauchesne wrote:
>> Optimize support for grayscale surfaces in two aspects: (i) space
>> by only allocating the luminance component ; (ii) speed by avoiding
>> initialization of the (now inexistent) chrominance
On Wed, 2014-05-14 at 15:13 +0200, Gwenole Beauchesne wrote:
> If the hardware supports JPEG decoding, then we have to expose the
> right set of chroma formats for the output (decoded) VA surface. In
> particular, we could support YUV 4:1:0, 4:2:2 and 4:4:4.
We could support YUV 4:0:0 for jpeg de
On Wed, 2014-05-14 at 15:13 +0200, Gwenole Beauchesne wrote:
> Optimize support for grayscale surfaces in two aspects: (i) space
> by only allocating the luminance component ; (ii) speed by avoiding
> initialization of the (now inexistent) chrominance planes.
>
> Keep backward compatibility with
Hi,
2014-05-15 9:10 GMT+02:00 Xiang, Haihao :
> On Thu, 2014-05-15 at 14:26 +0800, Zhao, Yakui wrote:
>> On Thu, 2014-05-15 at 00:05 -0600, Gwenole Beauchesne wrote:
>> > Hi,
>> >
>> > 2014-05-15 7:24 GMT+02:00 Zhao, Yakui :
>> > > On Wed, 2014-05-14 at 22:28 -0600, Gwenole Beauchesne wrote:
>> >
On Thu, 2014-05-15 at 14:26 +0800, Zhao, Yakui wrote:
> On Thu, 2014-05-15 at 00:05 -0600, Gwenole Beauchesne wrote:
> > Hi,
> >
> > 2014-05-15 7:24 GMT+02:00 Zhao, Yakui :
> > > On Wed, 2014-05-14 at 22:28 -0600, Gwenole Beauchesne wrote:
> > >> Hi,
> > >>
> > >> 2014-05-15 3:34 GMT+02:00 Zhao,
19 matches
Mail list logo
