Re: [Libva] keep Nalu start code in VASliceDataBufferType data

Hi, On 31.08.2016 05:31, Randy Li wrote: On 08/31/2016 09:52 AM, Xiang, Haihao wrote: On Tue, 2016-08-30 at 08:59 +0800, Randy Li wrote: Hi all: When I just doing the driver for us chip, we would request the Nalu header present in the data to be process. But I found the data be Rendered

Re: [Libva] [PATCH] i965_device_info: add CBR and VBR rate control flags for vdenc

On 12.08.2016 20:19, Sean V Kelley wrote: On Fri, 2016-08-12 at 16:20 +0300, Sreerenj wrote: On 12.08.2016 14:20, Sreerenj wrote: On 11.08.2016 19:47, Sean V Kelley wrote: On Thu, 2016-08-11 at 14:55 +0300, sreerenj.balachand...@intel.co m wrote: From: Sreerenj Balachandran

[Libva] [PATCH] i965_device_info: add CBR and VBR rate control flags for vdenc

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> Low power encode through VDENC supports both CBR and VBR. Make sure vaGetConfigAttribute correctly returns the supported list of rate control modes in VAEntrypointEncSliceLP entrypoint. --- src/i965_device_info.c | 2 +-

[Libva] [PATCH] encode: h264, h265: Remove unnecessary warning

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> The warning "Input ref list is Wrong" is generating based on assumption that reference frames provided in VAEncPictureParameterBuffer are in align with ref_pic_list included in VAEncSliceParameterBuffer

Re: [Libva] [PATCH 2/3] Encoding: Add ROI example

On 30.06.2016 04:49, Pengfei Qu wrote: From: Zhao Yakui v1: add --roi-test for test only for ROI. default only one region(0,0,120,120) has been test. Signed-off-by: Zhao Yakui Signed-off-by: pjl Signed-off-by: ceciliapeng

Re: [Libva] [PATCH] Keep backward compatibility with VA API 0.38.1

rom: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of Sean V Kelley Sent: Wednesday, December 9, 2015 1:39 PM To: Balachandran, Sreerenj Cc: libva@lists.freedesktop.org Subject: Re: [Libva] [PATCH] Keep backward compatibility with VA API 0.38.1 Hi, On Dec 9, 2015, at 8:38 AM

Re: [Libva] [PATCH] Keep backward compatibility with VA API 0.38.1

On 09.12.2015 04:27, Xiang, Haihao wrote: On Mon, 2015-12-07 at 18:51 +0200, Sreerenj wrote: IMHO, the name "VA_RT_FORMAT_YUV420_10BPP" is confusing... This chroma type is not just for 10Bitsper channel , but includes the whole set of "> 8bitis per channel 420 for

[Libva] RELEASE: GStreamer VA-API Plugins 0.7.0

-> gstreamer-vaapi product. == Contributors == This release was brought to you by: Gwenole Beauchesne, Jan Schmidt, Lim Siew Hoon, Mark Nauwelaerts, Olivier Crete, Sreerenj Balachandran, Víctor Manuel Jáquez Leal. Thanks! -- Thanks Sree ---

Re: [Libva] [PATCH] Keep backward compatibility with VA API 0.38.1

IMHO, the name "VA_RT_FORMAT_YUV420_10BPP" is confusing... This chroma type is not just for 10Bitsper channel , but includes the whole set of "> 8bitis per channel 420 formats", right? On 07.12.2015 07:20, Xiang, Haihao wrote: I mean Keep backward compatibility with VA API 0.38.0 :(

Re: [Libva] gstreamer-vaapi strange issue

. I tried exactly avenc. I don`t how is it bug or not. Is it possible to ask you do make same experiment as I did. I can prepare all source data and commands that I have used. 11.11.2015, 15:27, "Sreerenj" <sreerenj.balachand...@intel.com>: HI Nikita, Please always start a new

Re: [Libva] [ANNOUNCE] libva-intel-driver-1.6.1

Hi Michel, On 12.10.2015 10:31, Michel Memeteau - EKIMIA wrote: Hi, Thanks, I now have only from vainfo : vainfo: Supported profile and entrypoints VAProfileVP9Profile0: VAEntrypointVLD Might sound like a silly question for you but will I be able to use the hybrid

[Libva] [PATCH 3/5] intel_batchbuffer: Add utility fuction for supporting 48-bit address relocations in Gen8+

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> There are Gen8+ instruction which requires 48bit address relocation (eg: Surface State Address in STATE_BASE_ADDRESS instruction). Add the batchbuffer utility funcation for the relocation based on Mesa's batch buffer implemen

[Libva] [PATCH 1/5] vpp/gen8: Fix the incorrect loading of kernel module.

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> The correct i965 kernel interface index for pp_pl3_load_save_pl3_gen8 is PP_PL3_LOAD_SAVE_PL3. Signed-off-by: Sreerenj Balachandran <sreerenj.balachand...@intel.com> --- src/gen8_post_processing.c | 2 +- 1 file changed,

[Libva] [PATCH 5/5] vpp/gen9: Use 48 bit address relocation for STATE_BASE_ADDRESS

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> Use 48 bit address relocation for Surface state address, Dynamic state address and Instruction base address. Signed-off-by: Sreerenj Balachandran <sreerenj.balachand...@intel.com> --- src/gen9_post_proce

[Libva] [PATCH 2/5] vpp/gen9: Fix the incorrect loading of kernel module.

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> The correct i965_kernel interace index for pp_pl3_load_save_pl3_gen9 is PP_PL3_LOAD_SAVE_PL3. Signed-off-by: Sreerenj Balachandran <sreerenj.balachand...@intel.com> --- src/gen9_post_processing.c | 2 +- 1 file changed,

[Libva] [PATCH 4/5] vpp/gen8: Use 48 bit address relocation for STATE_BASE_ADDRESS

From: Sreerenj Balachandran <sreerenj.balachand...@intel.com> Use 48 bit address relocation for Surface state address, Dynamic state address and Instruction base address. Signed-off-by: Sreerenj Balachandran <sreerenj.balachand...@intel.com> --- src/gen8_post_proce

Re: [Libva] gst-vaapi, uploading to own textures

Hi, If you want to feed textures, then vaapisink is not the option ;) You have to use GstVideoGLTextureUploadMeta in the renderer Either use upstream "glimagesink" or use clutter-gst On 29.09.2015 15:38, Dolevo Jay wrote: Hi, In my device, I receive video streams from different

Re: [Libva] Compilation of vaapiparse elements

shot. Could you please assist me what is the problem? Regards. Regards. On 9 September 2015 at 11:13, Sreerenj <sreerenj.balachand...@intel.com <mailto:sreerenj.balachand...@intel.com>> wrote: Hi Firat, Thanks for catching this. Here the local video p

Re: [Libva] Gstreamer-vaapi: about the option --with-gstreamer-api

Should be fine I think... Please provide the patch through bugzilla: https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi On 14.08.2015 10:00, Lim, Siew Hoon wrote: Hi, --with-gstreamer-api is not valid option in gstreamer-vaapi anymore but I found out that debian.upstream/rules

[Libva] [GStreamer VA-API][ANNOUNCE] gstreamer-vaapi-0.6.0

Beauchesne, Jacobo Aragunde Pérez, Jan Schmidt, Julien Isorce, Lim Siew Hoon, Martin Sherburn, Michael Olbrich, Olivier Crete, Simon Farnsworth, Sreerenj Balachandran, Víctor Manuel Jáquez Leal, Wind Yuan. Thanks! -- Thanks Sree

Re: [Libva] Horizontal stripes on low bitrates

HI, I can't reproduce the mentioned issue- distorted video output with horizontal stripes in my Haswell , but I hit some other issues while enabling cbr mode encoding.. Could you please file a bug against gstreamer-vaapi in gnome bugzilla,

[Libva] [PATCH] HEVC: Fix the Wrong slice type usage

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Don't mix the slice_type values of h264 and h265. The SLICE_TYPE values of H264 and HEVC are different. H264: Bslice_type = 1, Pslice_type = 0 HEVC: Bslice_type = 0, Pslice_type = 1 Signed-off-by: Sreerenj Balachandran

[Libva] [PATCH 2/2] va_enc_hevc.h: Fix the description for slice_segment_address

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The slice_segment_address field indicates the starting CTU address for the corresponding slice. Signed-off-by: Sreerenj Balachandran sreerenj.balachand...@intel.com --- va/va_enc_hevc.h | 2 +- 1 file changed, 1 insertion(+), 1

[Libva] [PATCH 1/2] va_dec_hevc.h: Fix the misleading documentation

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The slice data buffer should always include the start code prefix. The comment section of VASliceParameterBufferHEVC is saying that the accompanying slice_data_buffer should include start code prefix. But the comment above

[Libva] [PATCH 0/2] Fix the misleading descriptions

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Sreerenj Balachandran (2): va_dec_hevc.h: Fix the misleading documentation va_enc_hevc.h: Fix the description for slice_segment_address va/va_dec_hevc.h | 1 - va/va_enc_hevc.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions

[Libva] [PATCH 0/3] HEVC fixes

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Sreerenj Balachandran (3): HEVC: Fix the Wrong slice type usage HEVC: Fix the nal unit type generation in packed slice header. HEVC: encoder_utils: Fixes for packed slice header generation. src/gen6_mfc_common.c| 4 ++-- src

[Libva] [PATCH 1/3] HEVC: Fix the Wrong slice type usage

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Don't mix the slice_type values of h264 and h265. The SLICE_TYPE values of H264 and HEVC are different. H264: Bslice_type = 1, Pslice_type = 0 HEVC: Bslice_type = 0, Pslice_type = 1 --- src/gen6_mfc_common.c| 4 ++-- src

[Libva] [PATCH 2/3] HEVC: Fix the nal unit type generation in packed slice header.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Generate the Nal unit type for packed slice headers based on idr_pic_flag and reference_pic_flag. --- src/i965_encoder_utils.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/i965_encoder_utils.c b

[Libva] [PATCH 3/3] HEVC: encoder_utils: Fixes for packed slice header generation.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com -- Write no_output_of_prior_pics_flag to bitstream header for IRAP pictures -- The slice_temporal_mvp_enabled_flag should only presnt in non-IDR frames. -- Write collocated_from_l0_flag to bitstream header for B slice

[Libva] [PATCH 3/3] jpeg_enc: Fix the column raster conversion of quatization matrix.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Use temp array for the new raster order calculation, otherwise it simply generate wrong values. Note: There is opportunity for more optimization, for eg we can avoid the usage of mulitple for loops here and there. --- src/gen8_mfc.c

[Libva] [PATCH 1/3] jpeg_enc: Avoid integer overflow while doing quality factor scaling

From: Sreerenj Balachandran sreerenj.balachand...@intel.com For eg: The uint8_t will simple overflow if submitted quality factor is 1 (5000/1). --- src/gen8_mfc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gen8_mfc.c b/src/gen8_mfc.c index 314b882..698dcae

[Libva] [PATCH 2/3] jpeg_enc: Fix the quatisation matrix scaling.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The misplaced parentheses are causing wrong value assignment to the quatization matrix. This will allow the ecoding when quality 50. Otherwise it will simply generate garbage in encoded video for any quality factor greater than 50

Re: [Libva] [PATCH 1/3] jpeg_enc: Avoid integer overflow while doing quality factor scaling

On 05.03.2015 09:12, Gwenole Beauchesne wrote: Hi, 2015-03-04 19:09 GMT+01:00 sreerenj.balachand...@intel.com: From: Sreerenj Balachandran sreerenj.balachand...@intel.com For eg: The uint8_t will simple overflow if submitted quality factor is 1 (5000/1). And is the resulting value (5000

[Libva] [PATCH 2/3] jpeg_enc: Fix the quatisation matrix scaling.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The misplaced parentheses are causing wrong value assignment to the quatization matrix. This will allow the ecoding when quality 50. Otherwise it will simply generate garbage in encoded video for any quality factor greater than 50

[Libva] [PATCH 3/3] jpeg_enc: Fix the column raster conversion of quatization matrix.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Use temp array for the new raster order calculation, otherwise it simply generate wrong values. Note: There is opportunity for more optimization, for eg we can avoid the usage of mulitple for loops here and there. --- src/gen8_mfc.c

[Libva] [PATCH 1/3] jpeg_enc: Avoid integer overflow while doing quality factor scaling

From: Sreerenj Balachandran sreerenj.balachand...@intel.com For eg: The uint8_t will simple overflow if submitted quality factor is 1 (5000/1). Note: Also removed a lot of whitespaces here and there. There are even more whitespaces all around the jpeg enc source code. --- src/gen8_mfc.c | 43

Re: [Libva] gstreamer-vaapi with gstreamer 0.10

Hi, GStreamer-0.10 support has made obsolete from gstreamer-vaapi-0.5.9 release onwards. There is no guarantee that it is going to work with 0.10.x ! Even though you have hacks to make it work, it will end-up in other issues. The 0.10.x is something which is not maintaining in upstream(the

[Libva] [PATCH] Fix the GetConfigAttributes() for JPEGBaseline profile

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Advertise the PACKED_RAW_DATA header support for JPEGEncoding. --- src/i965_drv_video.c | 4 1 file changed, 4 insertions(+) diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c index 7039dd3..5c48460 100644 --- a/src

Re: [Libva] Reverse playback problem

Hi, This might be a bug in gstreamer-vaapi Could you please file a bug against gstreamer-vaapi in gnome-bugzilla for the same, we are tracking bugs through gnome-bugzilla. https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi On 12.01.2015 21:15, Engin Firat wrote: Hello, I

[Libva] [PATCH 1/3] encoder: h264: Fix skip_emul_byte_count while inserting SEI header

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The skip_emul_byte_count should include the start code and nal_unit type, which is equl to five when the driver insert SEI headers. --- src/gen6_mfc_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src

[Libva] [PATCH 2/3] gen6_mfc_common: Do not use the reserved nal unit types

From: Sreerenj Balachandran sreerenj.balachand...@intel.com The nal_unit_type 21 is reserved, don't take this into account while doing the nal unit header bytes counting. --- src/gen6_mfc_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gen6_mfc_common.c b/src

Re: [Libva] gen7 h264 encode bitrate behaviour

I have noticed some issues with CBR mode encoding in gstreamer-vaapi too. This is tracking here: https://bugzilla.gnome.org/show_bug.cgi?id=734992 https://bugzilla.gnome.org/show_bug.cgi?id=722734 On 18.08.2014 20:19, Chris Healy wrote: Well after taking a look at the behaviour again this

[Libva] [PATCH] Fix the GetConfigAttributes() for H264SteroHighProfile

From: Sreerenj Balachandran sreerenj.balachand...@intel.com --- src/i965_drv_video.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c index bae70d5..e31cae2 100755 --- a/src/i965_drv_video.c +++ b/src/i965_drv_video.c @@ -652,6 +652,7

Re: [Libva] [PATCH 2/3] Encode: Don't mess up the index handling of packed raw data with packed slice header

On 29.05.2014 03:42, Zhao, Yakui wrote: On Wed, 2014-05-28 at 15:02 -0600, sreerenj.balachand...@intel.com wrote: From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed slice header index as packed raw data index. This patch is a preparation for submitting all

Re: [Libva] [PATCH 2/3] Encode: Don't mess up the index handling of packed raw data with packed slice header

On 30.05.2014 11:48, Zhao, Yakui wrote: On Fri, 2014-05-30 at 11:06 +0300, Sreerenj wrote: On 29.05.2014 03:42, Zhao, Yakui wrote: On Wed, 2014-05-28 at 15:02 -0600, sreerenj.balachand...@intel.com wrote: From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed slice

[Libva] [PATCH] Encode: Don't mess up the index handling of packed raw data with packed slice header

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed slice header index as packed raw data index. This is necessary for handling the use case of having only packed slice header and no packed raw data feeding from user. --- src/i965_drv_video.c | 7 +-- 1 file

Re: [Libva] [PATCH] Encode: Don't mess up the index handling of packed raw data with packed slice header

Hi, On 28.05.2014 11:07, Zhao, Yakui wrote: On Wed, 2014-05-28 at 10:10 +0300, sreerenj.balachand...@intel.com wrote: From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed slice header index as packed raw data index. This is necessary for handling the use case

Re: [Libva] [PATCH] Encode: Don't mess up the index handling of packed raw data with packed slice header

On 28.05.2014 11:35, Zhao, Yakui wrote: On Wed, 2014-05-28 at 11:14 +0300, Sreerenj wrote: Hi, On 28.05.2014 11:07, Zhao, Yakui wrote: On Wed, 2014-05-28 at 10:10 +0300, sreerenj.balachand...@intel.com wrote: From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed

[Libva] [PATCH 3/3] Encoding: Add support for grouped submission of packed slice headers

From: Sreerenj Balachandran sreerenj.balachand...@intel.com This is adding the necessary fixes to provide support for the grouped submission of all packed slice headers (packed slice headers are not paired with the submission of VAEncSliceParameterBuffer) from the upper layer in multiple slice

[Libva] [PATCH 1/3] Fix the segfault while encoding multiple slice per frame.

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Zero initialize the packed raw data index array and packed slice header index array during each preallocation. --- src/i965_drv_video.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/i965_drv_video.c b/src

[Libva] [PATCH 2/3] Encode: Don't mess up the index handling of packed raw data with packed slice header

From: Sreerenj Balachandran sreerenj.balachand...@intel.com Avoid storing packed slice header index as packed raw data index. This patch is a preparation for submitting all the packed slice headers as a group , instead of pairing with VAEncSliceParameterBuffer in multi slice per frame encoding

[Libva] [PATCH] Fix the segfault while inserting packed slice header

From: Sreerenj Balachandran sreerenj.balachand...@intel.com --- src/gen6_mfc_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gen6_mfc_common.c b/src/gen6_mfc_common.c index 936b4ef..bf15865 100644 --- a/src/gen6_mfc_common.c +++ b/src/gen6_mfc_common.c

Re: [Libva] (H264) Reference Picture selection

On 14.05.2014 10:51, Xiang, Haihao wrote: On Mon, 2014-05-12 at 07:34 +0200, Gwenole Beauchesne wrote: 2014-05-12 7:29 GMT+02:00 Zhao, Yakui yakui.z...@intel.com: On Sun, 2014-05-11 at 22:41 -0600, Gwenole Beauchesne wrote: Hi, 2014-05-12 3:34 GMT+02:00 Zhao Yakui yakui.z...@intel.com: On

[Libva] libva-clarification regarding the comment.

.. . Where can I see the gst-gltexture? some private repository? Sreerenj Balachandran, Linux Software Engineer, Intel Open Source Technology Center, Finland - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki