Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 16/02/18 17:53, James Zhu wrote: > Hi Mark, > > I couldn't reproduce the issue on my Polaris 11 to run mpv / ffmpeg about 1.5 > hours. > > one terminal run: > > ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 > -hwaccel_output_format vaapi -i video/Mr.Right.mp4 -an -c:v

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 13/02/18 16:38, James Zhu wrote: > Hi Mark, > > Did you still encounter hung issue? > > If yes, could you share me with your play and transcode streams and command > line, > then I can try to reproduce at my side. > > Thanks & Best Regards! > > James Zhu Yes, it does still happen with the

Re: [Mesa-dev] [PATCH v3 4/8] radeon/uvd:add uvd hevc enc hw ib implementation

On 09/02/18 20:35, James Zhu wrote: > Implement required IBs for UVD HEVC encode. > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1115 > +++ > 1 file changed, 1115 insertions(+) > create mode 100644

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 08/02/18 23:05, Mark Thompson wrote: > On 08/02/18 22:37, Alex Deucher wrote: >> On Thu, Feb 8, 2018 at 5:28 PM, Mark Thompson <s...@jkqxz.net> wrote: >>> On 06/02/18 20:05, James Zhu wrote: >>>> The whole series are the updated version. Changes are made ma

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 08/02/18 22:37, Alex Deucher wrote: > On Thu, Feb 8, 2018 at 5:28 PM, Mark Thompson <s...@jkqxz.net> wrote: >> On 06/02/18 20:05, James Zhu wrote: >>> The whole series are the updated version. Changes are made mainly based >>> on the comments from prevous code

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

On 06/02/18 20:05, James Zhu wrote: > The whole series are the updated version. Changes are made mainly based > on the comments from prevous code review from Alex, Leo and Boyuan > > James Zhu (8): > amd/common:add uvd hevc enc support check in hw query > winsys/amdgpu:add uvd hevc enc

Re: [Mesa-dev] [PATCH v2 5/8] radeon/uvd:add uvd hevc enc functions

On 06/02/18 20:05, James Zhu wrote: > Implement UVD hevc encode functions > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc.c | 370 > > 1 file changed, 370 insertions(+) > create mode 100644

Re: [Mesa-dev] [PATCH v2 4/8] radeon/uvd:add uvd hevc enc hw ib implementation

On 06/02/18 20:05, James Zhu wrote: > Implement required IBs for UVD HEVC encode. > > Signed-off-by: James Zhu > --- > src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1115 > +++ > 1 file changed, 1115 insertions(+) > create mode 100644

[Mesa-dev] [PATCH 2/2] st/va: Make the vendor string more descriptive

Include the Mesa version and detail about the platform. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- This gives: $ vainfo --display drm --device /dev/dri/renderD128 libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/local/l

[Mesa-dev] [PATCH 1/2] st/va: Enable vaExportSurfaceHandle()

It is present from libva 2.1 (VAAPI 1.1.0 or higher). Signed-off-by: Mark Thompson <s...@jkqxz.net> Acked-by: Christian König <christian.koe...@amd.com> --- Retested with up-to-date stuff, including unmodified git libva now. They have applied the version bump and it looks like 2.1 w

Re: [Mesa-dev] Please implement the vaapi-egl for vaapi hardware decoding, vdpau can't handle HEVC 10bit video.

On 04/12/17 16:33, Leo Liu wrote: > On 12/04/2017 04:32 AM, Emil Velikov wrote: >> On 2 December 2017 at 15:26, Julian Lai wrote: >>> Since the crappy vaapi-glx was dropped off by mpv-git player, there is no >>> way to play HEVC 10bit video with zero-copy hardware

Re: [Mesa-dev] [PATCH 2/3] st/va: use designated initialisers for VA driver functions

On 04/12/17 20:52, Leo Liu wrote: > Signed-off-by: Leo Liu > --- > src/gallium/state_trackers/va/context.c | 99 > - > 1 file changed, 49 insertions(+), 50 deletions(-) > > diff --git a/src/gallium/state_trackers/va/context.c >

[Mesa-dev] [PATCH] st/va: Enable vaExportSurfaceHandle()

It will be present from libva 2.1 (VAAPI 1.1.0 or higher). Signed-off-by: Mark Thompson <s...@jkqxz.net> --- See: <https://github.com/01org/libva/commit/fcb9cc881596d7ff809adf5f6ff631c708d407e3> <https://github.com/01org/libva/commit/51e98b1224794a44ba097baa7a1b4e35c3596d0c> A

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

On 14/11/17 10:53, Andy Furniss wrote: > Zhang, Boyuan wrote: >> >> >> -Original Message- >> From: Zhang, Boyuan >> Sent: November-13-17 11:41 AM >> To: Andy Furniss; Koenig, Christian; Mark Thompson; >> mesa-dev@lists.freedesktop.org >&g

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

On 08/11/17 18:08, boyuan.zh...@amd.com wrote: > From: Boyuan Zhang > > Implement encoding of sps, pps, and silce headers using the newly added h.264 > header coding descriptors functions based on h.264 specs. > > Signed-off-by: Boyuan Zhang > --- >

[Mesa-dev] [PATCH] st/va: Disable vaExportSurfaceHandle()

This is not in libva 2.0, so it shouldn't be enabled yet. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- On 15/10/17 20:06, Leo Liu wrote: > On 2017-10-15 07:23 AM, Mark Thompson wrote: >> This reverts commit c4ed39f85b1ebd062eaa51880fcc79cfbcb4e5c3. > > Can w

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

(Leo). Add guards to allow building with libva1. v4: Adjust target version - this is no longer in libva 2.0. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- (Testing only for now, not to be applied yet.) src/gallium/state_trackers/va/context.c| 5 +- src/gallium/state_track

[Mesa-dev] [PATCH 1/2] Revert "st/va: Implement vaExportSurfaceHandle()"

This reverts commit c4ed39f85b1ebd062eaa51880fcc79cfbcb4e5c3. --- Apparently the feature set of libva 2.0 was finalised inside Intel several weeks ago without communicating it externally, and this was not included. Therefore revert support for it here. This should be applied before the Mesa

[Mesa-dev] [PATCH 1/2] st/va: Fix config entrypoint handling

Consistently use it as a PIPE_VIDEO_ENTRYPOINT. v2: Return an error if the entrypoint is not set (Christian). Signed-off-by: Mark Thompson <s...@jkqxz.net> --- On 10/10/17 08:32, Christian König wrote: > Am 09.10.2017 um 22:45 schrieb Mark Thompson: >> C

[Mesa-dev] [PATCH 2/2] st/va: Return correct width and height for encode/decode support

Previously this would return the largest possible buffer size, which is much larger than the codecs themselves support. This caused confusion when client applications attempted to decode 8K video thinking it was supported when it isn't. Signed-off-by: Mark Thompson <s...@jkqxz.net> ---

[Mesa-dev] [PATCH 1/2] st/va: Fix config entrypoint handling

Consistently use it as a PIPE_VIDEO_ENTRYPOINT. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- src/gallium/state_trackers/va/config.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_track

Re: [Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

On 07/10/17 15:23, Leo Liu wrote: > On 2017-10-01 01:40 PM, Mark Thompson wrote: >> This is a new interface in libva2 to support wider use-cases of passing >> surfaces to external APIs.  In particular, this allows export of NV12 and >> P010 surfaces. >> >> v2

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

On 28/09/17 04:41, Lukas Rusak wrote: > Hello all, > > I'm bumping this to layout some progress that has been made on our (Kodi) > side and hopefully we can create a road map for what needs to be done on > the amd side to get it working with our vaapi implementation. > > I have merged the

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

(Leo). Add guards to allow building with libva1. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- src/gallium/state_trackers/va/context.c| 5 +- src/gallium/state_trackers/va/surface.c| 148 + src/gallium/state_trackers/va/va_private.h | 1 + 3

[Mesa-dev] [PATCH 1/2] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

On 29/09/17 17:25, Leo Liu wrote: > On 09/29/2017 11:37 AM, Leo Liu wrote: >> On 09/29/2017 10:45 AM, Andy Furniss wrote: >>> Marek Olšák wrote: Can you test this? >>> >>> My mpv test case is fixed by >>> >>> radeonsi/uvd: fix planar formats broken since f70f6baaa3bb0f8b280ac2eaea69bb >> >>

Re: [Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

- Mark >> >> Thanks, >> Marek >> >> On Fri, Sep 29, 2017 at 1:51 AM, Andy Furniss <adf.li...@gmail.com> wrote: >>> Mark Thompson wrote: >>>> >>>> This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840. >>> >>>

[Mesa-dev] [PATCH 3/3] Revert "gallium/radeon: consolidate PIPE_BIND_SHARED/SCANOUT handling"

This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840. --- This commit broke VAAPI surface export (found by bisection). I think the observed behaviour with playback is consistent with surfaces not being updated some of the time, so something to do with sharing? I tried setting

[Mesa-dev] [PATCH 2/3] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- On 22/09/17 10:17, Christian König wrote: > Am 21.09.2017 um 21:00 sch

[Mesa-dev] [PATCH 1/3] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c

Re: [Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

On 20/09/17 09:14, Christian König wrote: > Am 20.09.2017 um 00:01 schrieb Mark Thompson: >> This is a new interface in libva2 to support wider use-cases of passing >> surfaces to external APIs.  In particular, this allows export of NV12 and >> P010 surfaces. > >

Re: [Mesa-dev] [PATCH 00/14] Patches for VA-API State Tracker Postproc

On 21/09/17 03:17, Leo Liu wrote: > On 09/20/2017 06:11 PM, Mark Thompson wrote: >> On 19/09/17 20:04, Leo Liu wrote: >>> This series are for VA-API State Tracker Postproc, including: >>> >>> Deinterlacing I video for transcode; >>> Scaling support

Re: [Mesa-dev] [PATCH 00/14] Patches for VA-API State Tracker Postproc

On 19/09/17 20:04, Leo Liu wrote: > This series are for VA-API State Tracker Postproc, including: > > Deinterlacing I video for transcode; > Scaling support in postproc for transcode; > Frame grabber in postproc > > Thanks Andy Furniss for lots of testing on these. > > Leo

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- Trivial update for a minor change requested on libva side (1/2 identical).

[Mesa-dev] [PATCH 2/2] st/va: Implement vaExportSurfaceHandle()

This is a new interface in libva2 to support wider use-cases of passing surfaces to external APIs. In particular, this allows export of NV12 and P010 surfaces. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- This implements a new interface I am proposing for libva2, which will allow

[Mesa-dev] [PATCH 1/2] st/dri: Add definitions to allow importing 16-bit surfaces

Necessary to support P010/P016 surfaces for video. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- src/gallium/state_trackers/dri/dri2.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c

[Mesa-dev] [PATCH v2] st/va: Fix scaling list ordering for H.265

Mesa here requires the scaling lists in diagonal scan order, but VAAPI passes them in raster scan order. Therefore, rearrange the elements when copying. v2: Move scan tables to vl_zscan.c. Fix type in size assertion. Signed-off-by: Mark Thompson <s...@jkqxz.net> --- On 14/07/17

[Mesa-dev] [PATCH] st/va: Fix scaling list ordering for H.265

Mesa here requires the scaling lists in diagonal scan order, but VAAPI passes them in raster scan order. Therefore, rearrange the elements when copying. (This ordering was likely inherited from VDPAU, which does pass them in diagonal scan order.) Signed-off-by: Mark Thompson <s...@jkqxz.

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

workaround). After that, everything I would expect to work does and the series is Reviewed-by: Mark Thompson <s...@jkqxz.net>. Thanks, - Mark ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

s that makes sense. Any objections merging that into my original patch > and adding your signed-of-by line? Sure, please do. Thanks, - Mark > Am 08.03.2017 um 22:36 schrieb Mark Thompson: >> >> On 08/03/17 21:32, Mark Thompson wrote: >>> On 08/03/17 12:29, Christian

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

On 08/03/17 21:32, Mark Thompson wrote: > On 08/03/17 12:29, Christian König wrote: >> From: Christian König <christian.koe...@amd.com> >> >> Advertise 10bpp support if the driver supports decoding to a P016 surface. >> >> Signed-off-by: Christian König &l

Re: [Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding

On 08/03/17 12:29, Christian König wrote: > From: Christian König > > Advertise 10bpp support if the driver supports decoding to a P016 surface. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/va/config.c | 15

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI v2

On 08/03/17 12:29, Christian König wrote: > Hi guys, > > I finally found time testing this and hammering out (hopefully) all the > remaining bugs. Playing a 10bit HEVC file through VAAPI with mpv/ffmpeg git > master from about two days ago now works flawlessly and has only about 15% CPU > load on

[Mesa-dev] [PATCH] st/omx: Set end-of-frame flag on bitstream output buffers

Since all output buffers are whole frames, this should always be set. Technically, setting this flag is is optional (see OpenMAX IL section 3.1.2.7.1), but some clients assume that it will be used and therefore buffer indefinitely thinking that all output buffers are fragments of the first frame

[Mesa-dev] [PATCH] st/omx: Fix port format enumeration

From OpenMAX IL section 4.3.5: "The value of nIndex is the range 0 to N-1, where N is the number of formats supported by the port. There is no need for the port to report N, as the caller can determine N by enumerating all the formats supported by the port. Each port shall support at least one

Re: [Mesa-dev] [PATCH] st/va: Support fractional framerate in misc parameter

On 27/01/17 22:03, Mark Thompson wrote: > Signed-off-by: Mark Thompson <s...@jkqxz.net> > --- > See <https://cgit.freedesktop.org/libva/tree/va/va.h#n1277> - this is a > recent addition, but is backwards-compatible. > > Depends on Andy's patch > <https://lis

[Mesa-dev] [PATCH] st/va: Fix forward/backward referencing for deinterlacing

from other implementations, in particular the i965 driver and the gstreamer client. In order to match those other implementations, this patch swaps the meaning of forward and backward references as they currently appear for motion-adaptive deinterlacing. Signed-off-by: Mark Thompson &l

Re: [Mesa-dev] [PATCH v2] st/va encode handle ntsc framerate rate control

On 29/01/17 14:22, Andy Furniss wrote: > Tested with ffmpeg and gst-vaapi. Without this bits per > frame is set way too low for fractional framerates. > > v2: Mark Thompson: simplify calculation. > Use float. > > Signed-off-by: Andy Furniss <adf.li...@gmail.c

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

On 27/01/17 22:06, Andy Furniss wrote: > Mark Thompson wrote: >> On 26/01/17 18:26, Andy Furniss wrote: >>> Tested with ffmpeg and gst-vaapi. Without this bits per >>> frame is set way too low. >>> >>> Signed-off-by: Andy Furniss <adf.li...@gmail.

[Mesa-dev] [PATCH] st/va: Support fractional framerate in misc parameter

Signed-off-by: Mark Thompson <s...@jkqxz.net> --- See <https://cgit.freedesktop.org/libva/tree/va/va.h#n1277> - this is a recent addition, but is backwards-compatible. Depends on Andy's patch <https://lists.freedesktop.org/archives/mesa-dev/2017-January/142242.html> f

Re: [Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

On 26/01/17 18:26, Andy Furniss wrote: > Tested with ffmpeg and gst-vaapi. Without this bits per > frame is set way too low. > > Signed-off-by: Andy Furniss > --- > src/gallium/state_trackers/va/picture.c | 32 > 1 file changed, 24

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 27/01/17 14:27, Christian König wrote: > Am 27.01.2017 um 13:51 schrieb Mark Thompson: >> On 26/01/17 16:59, Christian König wrote: >>> Am 26.01.2017 um 13:14 schrieb Mark Thompson: >>>> [SNIP] >>> The problem here is I need to know what will be d

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 26/01/17 16:59, Christian König wrote: > Am 26.01.2017 um 13:14 schrieb Mark Thompson: >> On 26/01/17 11:00, Christian König wrote: >>> Hi Peter, >>> >>> Am 25.01.2017 um 19:45 schrieb Peter Frühberger: >>>> >>>> Peter,

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 25/01/17 14:41, Christian König wrote: > Hi guys, > > ok this is completely work in progress and untested except for a compile run. > > Most of the stuff necessary should be there for VDPAU, but I'm honestly not > sure how to approach VAAPI. > > My main problem at the moment is that I can't

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

On 26/01/17 11:00, Christian König wrote: > Hi Peter, > > Am 25.01.2017 um 19:45 schrieb Peter Frühberger: >> >> >> Peter, Rainer any idea what I'm missing here? Do you guys use some >> modified ffmpeg for Kodi or how does that work for you? >> >> >> do you set the format correctly, e.g.:

Re: [Mesa-dev] [PATCH 7/7] st/va: start of P016 support

On 25/01/17 14:42, Christian König wrote: > From: Christian König > > Most likely only partially correct, but at least a start. > > Signed-off-by: Christian König > --- > src/gallium/state_trackers/va/config.c | 9 ++--- >

Re: [Mesa-dev] [PATCH] st/va: set default rt formats when calling vaCreateConfig

VaFourcc(vpp_surface_formats[j]); > i++; > } > - } else if (config->rt_format == VA_RT_FORMAT_YUV420) { > + } > + if (config->rt_format & VA_RT_FORMAT_YUV420) { > attribs[i].type = VASurfaceAttribPixelFor

Re: [Mesa-dev] [PATCH] st/va: Default to YUV420 RT format when creating a config

On 17/10/16 16:13, Julien Isorce wrote: > Hi Mark, > > Yes I actually saw that too in the intel driver though I think it does not add > VA_RT_FORMAT_RGB32 ? Or I missed something ? > Maybe this is a bug. In any case yes as said before " the intel va driver > always > return the full list for

Re: [Mesa-dev] [PATCH] st/va: Default to YUV420 RT format when creating a config

On 17/10/16 15:42, Mark Thompson wrote: > The default will only be used if the VAConfigRTFormat attribute is not > provided by the user. > --- > On 17/10/16 15:21, Julien Isorce wrote: >> Hi Mark, >> >> Thx for the patch. I can see it has already landed. >> >

[Mesa-dev] [PATCH] st/va: Default to YUV420 RT format when creating a config

The default will only be used if the VAConfigRTFormat attribute is not provided by the user. --- On 17/10/16 15:21, Julien Isorce wrote: > Hi Mark, > > Thx for the patch. I can see it has already landed. > > I just tried it with gstreamer-vaapi and it causes problem since they create > the >

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

On 13/10/16 08:20, Christian König wrote: > Am 13.10.2016 um 00:52 schrieb Mark Thompson: >> The encoder attributes are needed for a user of the encoder to be >> able to configure it sensibly without internal knowledge. > > Reviewed-by: Christian König <christian.koe..

[Mesa-dev] [PATCH 4/5] st/va: Baseline profile is not supported

Constrained baseline profile is supported, so use that instead. This matches what the encoder already does (constraint_set1_flag is always set in the output bitstream). --- src/gallium/state_trackers/va/va_private.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH 2/5] st/va: Save surface chroma format in config

Both YUV420 and RGB32 configurations are supported, so we need to be able to distinguish which is being used. --- src/gallium/state_trackers/va/config.c | 20 +++- src/gallium/state_trackers/va/va_private.h | 1 + 2 files changed, 20 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

The encoder attributes are needed for a user of the encoder to be able to configure it sensibly without internal knowledge. --- src/gallium/state_trackers/va/config.c | 47 +++--- 1 file changed, 38 insertions(+), 9 deletions(-) diff --git

[Mesa-dev] [PATCH 5/5] st/va: Fix H.264 PicOrderCnt value

TopFieldPicOrderCnt is exactly the PicOrderCnt value for a frame - see H.264 section 8.2.1. --- src/gallium/state_trackers/va/picture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c index

[Mesa-dev] [PATCH 3/5] st/va: Return surface formats depending on config chroma format

This makes the supported format actually match the configuration, and allows the user to observe that NV12 is supported for video processing where previously they couldn't (though it did always work if they blindly tried to use it anyway). --- src/gallium/state_trackers/va/surface.c | 12

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 28/09/16 11:47, Andy Furniss wrote: > Andy Furniss wrote: >> Andy Furniss wrote: >> >>> I started to get some numbers but found a possible bug = I made a 1000 >>> frame 15mbit 1080p50 mkv with ffmpeg/libx264. >>> >>> Using it as source for transcode (s/w or h/w dec) it came out far too >>> low

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 27/09/16 16:48, Andy Furniss wrote: > Ok, thanks, so with that I am back to where I was before it stopped working. > > In summary baseline works but JM ref decoder doesn't like the pocs. > > b frames don't work properly, but then they don't with gst vaapi either. They > do work with gst omx.

Re: [Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

On 27/09/16 00:49, Andy Furniss wrote: > Mark Thompson wrote: >> --- >> A simple fix to the problem described here: >> <https://lists.freedesktop.org/archives/mesa-dev/2016-September/128076.html>. >> >> With this applied, the driver no longer hangs/cra

[Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

--- A simple fix to the problem described here: . With this applied, the driver no longer hangs/crashes when vaSyncSurface() is called in places other than for the first time after an encode operation (including a

[Mesa-dev] [PATCH] st/va: H.264 baseline profile is not supported

H.264 constrained baseline is, so use that instead. --- On decode, FMO doesn't work - it's commented out at , and I doubt it is supported by the hardware anyway. On encode, it seems to use constrained

[Mesa-dev] [PATCH 1/3] st/va: Return more useful config attributes

--- On 20/09/16 10:55, Christian König wrote: >> +if (profile == VAProfileHEVCMain10) >> + value = VA_RT_FORMAT_YUV420_10BPP; > We actually don't support that yet. Main10 profiles dither down the 10bit > output to 8bits before writing it to the VA-API surface at the

[Mesa-dev] [PATCH 3/3] st/va: return surface formats depending on config chroma format

Also allows NV12 to be returned as a supported format for video processing. --- The useful change is that we can now see that NV12 is supported by the video processor, so things like decode-scale-encode are known to be possible. Again, there might be more supported things here which could be

[Mesa-dev] [PATCH 2/3] st/va: Save surface chroma format in config

--- We need this stored somewhere to be able to return useful information from vaQuerySurfaceAttributes() in the following patch. src/gallium/state_trackers/va/config.c | 23 +-- src/gallium/state_trackers/va/va_private.h | 1 + 2 files changed, 22 insertions(+), 2

[Mesa-dev] [PATCH 1/3] st/va: Return more useful config attributes

--- More chroma formats might be supportable, I've kept this to YUV420 + RGB for now. Also, B-frames might be supported in some configurations? That could be conditional on the GPU being used somehow if necessary. src/gallium/state_trackers/va/config.c | 53

Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

Hi, This patch (applied as ) changes the meaning of vaSyncSurface() in a way I don't think is quite right. The way it is implemented appears to make vaSyncSurface() mean "given a surface with an