[Libva] [Libva-intel-driver][PATCH] Enable AVC VDEnc on BXT
I verified AVC VDEnc with the HuC loading patch from https://patchwork.freedesktop.org/api/1.0/series/16584/revisions/1/mbox/ Signed-off-by: Xiang, Haihao--- src/i965_device_info.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/i965_device_info.c b/src/i965_device_info.c index 13ac49c..73602ae 100644 --- a/src/i965_device_info.c +++ b/src/i965_device_info.c @@ -419,6 +419,9 @@ static struct hw_codec_info bxt_hw_codec_info = { .has_hevc10_decoding = 1, .has_vp9_decoding = 1, .has_vpp_p010 = 1, +.has_lp_h264_encoding = 1, + +.lp_h264_brc_mode = VA_RC_CQP, .num_filters = 5, .filters = { -- 1.9.1 ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?
Something I have forgotten, On Thu, Dec 15, 2016 at 8:14 PM, Peter Frühbergerwrote: > Hi Veeranna, > > On Thu, Dec 15, 2016 at 6:03 PM, ViruS Tadala < > tadala.veerannab...@gmail.com> wrote: > >> Hi Peter, >> >> Thanks for your quick response. >> >> Mentioned figures are GPU load values. I have ran the intel_gpu_top >> command to get the same. >> >> I didn't check any clock details. Used below pipeline and ran multiple >> instances. >> >> gst-launch-1.0 videotestsrc is-live=true pattern=22 horizontal-speed=20 ! >> 'video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, >> framerate=(fraction)10/1' ! vaapiencode_h264 min-qp=20 ! queue ! >> vaapidecode ! queue ! appsink >> >> Please let me know if you need more information. >> >> Best Regards, >> Veeranna. >> >> >> >> On Thu, Dec 15, 2016 at 11:47 AM, Peter Frühberger >> wrote: >> >>> Hi Veeranna, >>> >>> i cannot even interpret your figures. Is that the CPU load? If yes - did >>> you check the clocks? >>> Which benchmark did you use? Where did the data come from, where was it >>> encoded to? Was it stored? Which format? >>> >>> In short: Without more details you most likely get the following answer: >>> >>> Depends! >>> >>> Best regards >>> Peter >>> >>> On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadala < >>> tadala.veerannab...@gmail.com> wrote: >>> Hi, I have done some benchmarking on both platforms & observed that braswell did lesser number of channels(decode + re-encode using vaapi) than baytrail. 60-65% for 6channels on braswell. 60-66 % for 10channels on baytrail. Please let me know whether we can expect better GPU performance on braswell than baytrail or not? Best Regards, Veeranna. ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva >>> >> >> >> -- >> Best Regards, >> ViruS >> > > Does this kernel patch help: > > > From 32c513eeafa681f798b04488524994fe47355cad Mon Sep 17 00:00:00 2001 > From: fritsch > Date: Sat, 13 Aug 2016 22:56:37 +0200 > Subject: [PATCH] drm/i915: intel-pm enable thresholds > > --- > drivers/gpu/drm/i915/intel_pm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 06e5596..38e613c 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4982,8 +4982,7 @@ static void valleyview_set_rps(struct drm_i915_private > *dev_priv, u8 val) > > if (val != dev_priv->rps.cur_freq) { > vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val); > - if (!IS_CHERRYVIEW(dev_priv)) > - gen6_set_rps_thresholds(dev_priv, val); > + gen6_set_rps_thresholds(dev_priv, val); > } > > dev_priv->rps.cur_freq = val; > -- > 2.7.4 > > > > Best regards > > Peter > > And also check this: /sys/class/drm/card0/gt_min_freq_mhz while benchmarking, it might simply be that the gpu is not clocking correctly. You can increase the min clock by doing: echo 600 > /sys/class/drm/card0/gt_min_freq_mhz ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake
Hi Vasavee, .ivf format is not the same as .webm https://wiki.multimedia.cx/index.php?title=IVF yamiencode does not output in webm format. Hope it helps. Thanks, Jayesh Kumar -Original Message- From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of Vijayaraghavan, Vasavee Sent: Thursday, December 15, 2016 10:02 AM To: Xiang, Haihao; Charles, Daniel Cc: libva@lists.freedesktop.org Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake Hi Haihao, I think I mislead you by not stating the problem correctly, sorry about that! I will rephrase the issue that I am facing: - OTC graphics stack (Ubuntu 16.10 (kernel 4.8), libdrm 2.4.68, libva 1.7.2 and libyami/libyami-utils) - Command line used for encode: ./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 -o output.ivf (or output.webm) I wanted to play the output.ivf (output.webm) file to verify whether it was encoded properly. Tried looking at the encoded output using ffplay/ VLC/ Dragging and dropping in chrome browser I am unable to view this encoded video completely (able to see only first and last frame of the video - chrome browser is not able to play the video even for the first and last frames) On the other hand, decoding this output.ivf (/output.webm) back to yuv doesn’t give any issue to me. The decoded yuv plays back fine and looks similar to the original input yuv that I have used. Also, I did not use ffmpeg for anything but just for using the player (ffplay) so I assume the issue is not related to ffmpeg in my case. -Thanks Vasavee -Original Message- From: Xiang, Haihao Sent: Thursday, December 15, 2016 12:08 AM To: Charles, Daniel ; Vijayaraghavan, Vasavee Cc: libva@lists.freedesktop.org Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake Hi Vasavee, Maybe it is not a yami issue. I encountered another issue for VP8 video which is encoded by another vaapi based tool. I saw double frames when transcoding the video back to YUV using ffmpeg, however vpxdec works well for me, so I guess there are some issues in FFmpeg. Could you try vpxdec with your VP9 video? I think it is not yami issue if vpxdec works for you. Thanks Haihao > Hi Daniel, > > Sure, will do that! Thank you for the pointers. > > -Best Regards, > Vasavee > > -Original Message- > From: Charles, Daniel [mailto:daniel.char...@intel.com] > Sent: Monday, December 12, 2016 10:53 AM > To: Vijayaraghavan, Vasavee > Cc: Xiang, Haihao ; libva@lists.freedesktop.o > rg > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode > on KabyLake > > Hi Vasavee, > > Can you file a bug on libyami for your observation? > > https://github.com/01org/libyami/issues > > Thanks. > > -- > Daniel. > > On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee jayaragha...@intel.com> wrote: > > Hi Haihao, > > > > I might have missed setting the PKG_CONFIG_PATH while trying to use > > './configure --prefix=/usr --exec-prefix=/'. > > But like Daniel suggested, I did a clean install with default paths > > and it works fine for me. > > > > I have installed libyami and libyami utils to test VP9 encode and > > decode. I am able to run VP9 encode and decode using the pre-built > > binaries located in libyami-utils/tools (yamiencode and yamidecode). > > I am facing issues in playing back the VP9 encoded video. > > Say test.ivf is my VP9 encoded output, when I playback the file > > using ffplay or VLC player, I am able to see only the first and last > > frame of the encoded video (though the video shows to have 500 > > frames - same as the input yuv; verified the number of frames using > > ffprobe). Although, when I decode it back to yuv, the yuv is exactly > > the same as original input yuv and plays all the frames fine. > > > > At this point, I haven’t added any quality control factor to encode > > the video and hence I have used a simple command line: > > $cd /home/user/libyami-utils/tools > > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 > > -o test.ivf > > > > Am I missing something in the commandline which is why I am unable > > to play the output? > > > > Note: I tried playing pre-encoded test_vp9.ivf files available > > through MediaSDK samples and they played without an issue. > > > > -Thanks > > Vasavee > > > > -Original Message- > > From: Xiang, Haihao > > Sent: Wednesday, December 7, 2016 8:07 PM > > To: Charles, Daniel ; Vijayaraghavan, > > Vasavee > > Cc: libva@lists.freedesktop.org > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode > > on KabyLake > > > > > > I think './configure --prefix=/usr --exec-prefix=/' should work too, > >
Re: [Libva] g45-h264 branch status
On Thu, 2016-12-15 at 20:05 +0200, Bob Bib wrote: > On 15/12/16 09:44, Xiang, Haihao wrote: > > It was removed for this git repository. Please check https://lists. > > free > > desktop.org/archives/libva/2016-June/004018.html . You may fork > > g45- > > h264 branch from git://people.freedesktop.org/~haihao/libva-intel- > > driver. > > Thanks for the info. > > I've checked it, and the last commit dates back to October 2014. It's > no > longer supported, right? We do not actively work on it, unfortunately. But if you have questions or patches or changes feel free to voice them on this list. Thanks, Sean ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [PATCH 2/3] H.265 main 10 encoder supports only 10bpp render targets
On Thu, 2016-12-15 at 13:04 +, Mark Thompson wrote: > On 05/12/16 17:54, Mark Thompson wrote: > > Signed-off-by: Mark Thompson> > --- > > The supported surface formats are already correct (i.e. only P010); > > this makes the render target format right as well (before this, it > > declares that it supports only YUV 4:2:0 8-bit). > > > > src/i965_drv_video.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c > > index d83427c..9e1c92a 100644 > > --- a/src/i965_drv_video.c > > +++ b/src/i965_drv_video.c > > @@ -880,6 +880,8 @@ > > i965_get_default_chroma_formats(VADriverContextP ctx, VAProfile > > profile, > > break; > > > > case VAProfileHEVCMain10: > > +if (HAS_HEVC10_ENCODING(i965) && entrypoint == > > VAEntrypointEncSlice) > > +chroma_formats = VA_RT_FORMAT_YUV420_10BPP; > > if (HAS_HEVC10_DECODING(i965) && entrypoint == > > VAEntrypointVLD) > > chroma_formats |= i965->codec_info- > > >hevc_dec_chroma_formats; > > break; > > > > Ping. (The other patches in this series have been considered > separately.) Yes this is a good catch. It was overlooked with the addition of 10bit support. We may need to make further adjustment when we roll in new encoder formats too. lgtm. applied. Sean > Thanks, > > - Mark > > ___ > Libva mailing list > Libva@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libva ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] g45-h264 branch status
On 15/12/16 09:44, Xiang, Haihao wrote: It was removed for this git repository. Please check https://lists.free desktop.org/archives/libva/2016-June/004018.html . You may fork g45- h264 branch from git://people.freedesktop.org/~haihao/libva-intel- driver. Thanks for the info. I've checked it, and the last commit dates back to October 2014. It's no longer supported, right? -- Best wishes, Bob ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake
Hi Haihao, I think I mislead you by not stating the problem correctly, sorry about that! I will rephrase the issue that I am facing: - OTC graphics stack (Ubuntu 16.10 (kernel 4.8), libdrm 2.4.68, libva 1.7.2 and libyami/libyami-utils) - Command line used for encode: ./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 -o output.ivf (or output.webm) I wanted to play the output.ivf (output.webm) file to verify whether it was encoded properly. Tried looking at the encoded output using ffplay/ VLC/ Dragging and dropping in chrome browser I am unable to view this encoded video completely (able to see only first and last frame of the video - chrome browser is not able to play the video even for the first and last frames) On the other hand, decoding this output.ivf (/output.webm) back to yuv doesn’t give any issue to me. The decoded yuv plays back fine and looks similar to the original input yuv that I have used. Also, I did not use ffmpeg for anything but just for using the player (ffplay) so I assume the issue is not related to ffmpeg in my case. -Thanks Vasavee -Original Message- From: Xiang, Haihao Sent: Thursday, December 15, 2016 12:08 AM To: Charles, Daniel; Vijayaraghavan, Vasavee Cc: libva@lists.freedesktop.org Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake Hi Vasavee, Maybe it is not a yami issue. I encountered another issue for VP8 video which is encoded by another vaapi based tool. I saw double frames when transcoding the video back to YUV using ffmpeg, however vpxdec works well for me, so I guess there are some issues in FFmpeg. Could you try vpxdec with your VP9 video? I think it is not yami issue if vpxdec works for you. Thanks Haihao > Hi Daniel, > > Sure, will do that! Thank you for the pointers. > > -Best Regards, > Vasavee > > -Original Message- > From: Charles, Daniel [mailto:daniel.char...@intel.com] > Sent: Monday, December 12, 2016 10:53 AM > To: Vijayaraghavan, Vasavee > Cc: Xiang, Haihao ; libva@lists.freedesktop.o > rg > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode > on KabyLake > > Hi Vasavee, > > Can you file a bug on libyami for your observation? > > https://github.com/01org/libyami/issues > > Thanks. > > -- > Daniel. > > On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee jayaragha...@intel.com> wrote: > > Hi Haihao, > > > > I might have missed setting the PKG_CONFIG_PATH while trying to use > > './configure --prefix=/usr --exec-prefix=/'. > > But like Daniel suggested, I did a clean install with default paths > > and it works fine for me. > > > > I have installed libyami and libyami utils to test VP9 encode and > > decode. I am able to run VP9 encode and decode using the pre-built > > binaries located in libyami-utils/tools (yamiencode and yamidecode). > > I am facing issues in playing back the VP9 encoded video. > > Say test.ivf is my VP9 encoded output, when I playback the file > > using ffplay or VLC player, I am able to see only the first and last > > frame of the encoded video (though the video shows to have 500 > > frames - same as the input yuv; verified the number of frames using > > ffprobe). Although, when I decode it back to yuv, the yuv is exactly > > the same as original input yuv and plays all the frames fine. > > > > At this point, I haven’t added any quality control factor to encode > > the video and hence I have used a simple command line: > > $cd /home/user/libyami-utils/tools > > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 > > -o test.ivf > > > > Am I missing something in the commandline which is why I am unable > > to play the output? > > > > Note: I tried playing pre-encoded test_vp9.ivf files available > > through MediaSDK samples and they played without an issue. > > > > -Thanks > > Vasavee > > > > -Original Message- > > From: Xiang, Haihao > > Sent: Wednesday, December 7, 2016 8:07 PM > > To: Charles, Daniel ; Vijayaraghavan, > > Vasavee > > Cc: libva@lists.freedesktop.org > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode > > on KabyLake > > > > > > I think './configure --prefix=/usr --exec-prefix=/' should work too, > > otherwise it might have issue. Actually this configuration works > > fine for me when I build libva and libva-intel-driver. I set > > PKG_CONFIG_PATH variable to /lib/pkgconfig because libva.pc is > > installed in /lib/pkgconfig which is not in the default pkg-config > > search path. > > > > Thanks > > Haihao > > > > > Hi Daniel, > > > > > > That was right. I messed up a bit with the paths, uninstalling and > > > then re-installing with the default path in configure worked fine > > > this time. > > > Thanks! > > > > > > -best Regards, > >
Re: [Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?
Hi Veeranna, i cannot even interpret your figures. Is that the CPU load? If yes - did you check the clocks? Which benchmark did you use? Where did the data come from, where was it encoded to? Was it stored? Which format? In short: Without more details you most likely get the following answer: Depends! Best regards Peter On Thu, Dec 15, 2016 at 4:19 PM, ViruS Tadalawrote: > Hi, > > I have done some benchmarking on both platforms & observed that braswell > did lesser number of channels(decode + re-encode using vaapi) than baytrail. > > 60-65% for 6channels on braswell. > > 60-66 % for 10channels on baytrail. > > Please let me know whether we can expect better GPU performance on > braswell than baytrail or not? > > Best Regards, > > Veeranna. > > ___ > Libva mailing list > Libva@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libva > > ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
[Libva] Can we expect better GPU performance on braswell(Intel celeron N3160) than baytrail(Intel celeron J1900)?
Hi, I have done some benchmarking on both platforms & observed that braswell did lesser number of channels(decode + re-encode using vaapi) than baytrail. 60-65% for 6channels on braswell. 60-66 % for 10channels on baytrail. Please let me know whether we can expect better GPU performance on braswell than baytrail or not? Best Regards, Veeranna. ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [PATCH 2/3] H.265 main 10 encoder supports only 10bpp render targets
On 05/12/16 17:54, Mark Thompson wrote: > Signed-off-by: Mark Thompson> --- > The supported surface formats are already correct (i.e. only P010); this > makes the render target format right as well (before this, it declares that > it supports only YUV 4:2:0 8-bit). > > src/i965_drv_video.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c > index d83427c..9e1c92a 100644 > --- a/src/i965_drv_video.c > +++ b/src/i965_drv_video.c > @@ -880,6 +880,8 @@ i965_get_default_chroma_formats(VADriverContextP ctx, > VAProfile profile, > break; > > case VAProfileHEVCMain10: > +if (HAS_HEVC10_ENCODING(i965) && entrypoint == VAEntrypointEncSlice) > +chroma_formats = VA_RT_FORMAT_YUV420_10BPP; > if (HAS_HEVC10_DECODING(i965) && entrypoint == VAEntrypointVLD) > chroma_formats |= i965->codec_info->hevc_dec_chroma_formats; > break; > Ping. (The other patches in this series have been considered separately.) Thanks, - Mark ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction
On 15/12/16 08:54, Xiang, Haihao wrote: > > Hi Mark, > > Thanks for your patch, is there any benefit to use a fraction? using > 100 as framerate_den works well in the driver. Everything the driver interacts with directly, on both sides, uses a fraction: * In VAAPI, VAEncMiscParameterFrameRate contains a 16 / 16 fraction. * Newer hardware uses a fraction directly where it requires a framerate (gen9_vp9_encoder.c:1204, gen9_vdenc.c:1648). * H.264 and H.265 streams contain num_units_in_tick / time_scale. * gstreamer (GstVideoInfo.fps_[nd]), libyami (VideoFrameRate.frameRate{Num,Denom}) and libavcodec (AVCodecContext.{time_base,framerate} are fraction structures) all represent framerate as a fraction. The driver should use a fraction as well to preserve the exact value and be consistent with everything it interacts with. Do you have any other concerns about the patch? If there are additional references outside the core driver code which I have missed somehow then I would be happy to update them as well. Thanks, - Mark ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [PATCH 1/4] i965_encoder: consistently represent framerate as a fraction
Hi Mark, Thanks for your patch, is there any benefit to use a fraction? using 100 as framerate_den works well in the driver. Regards Haihao > Update references in both H.264 encoders (gen6_mfc and gen9_vdenc). > > Signed-off-by: Mark Thompson> --- > src/gen6_mfc_common.c | 11 ++ > src/gen9_vdenc.c | 29 ++-- > src/gen9_vdenc.h | 3 ++- > src/i965_encoder.c| 61 +-- > > src/i965_encoder.h| 3 ++- > 5 files changed, 72 insertions(+), 35 deletions(-) > > diff --git a/src/gen6_mfc_common.c b/src/gen6_mfc_common.c > index 68d030e..c29817e 100644 > --- a/src/gen6_mfc_common.c > +++ b/src/gen6_mfc_common.c > @@ -119,16 +119,19 @@ static void intel_mfc_brc_init(struct > encode_state *encode_state, > > if (i == 0) { > bitrate = encoder_context->brc.bits_per_second[0]; > -framerate = (double)encoder_context- > >brc.framerate_per_100s[0] / 100.0; > +framerate = (double)encoder_context- > >brc.framerate_num[0] / (double)encoder_context- > >brc.framerate_den[0]; > } else { > bitrate = (encoder_context->brc.bits_per_second[i] - > encoder_context->brc.bits_per_second[i - 1]); > -framerate = (double)(encoder_context- > >brc.framerate_per_100s[i] - encoder_context- > >brc.framerate_per_100s[i - 1]) / 100.0; > +framerate = ((double)encoder_context- > >brc.framerate_num[i] / (double)encoder_context- > >brc.framerate_den[i]) - > +((double)encoder_context->brc.framerate_num[i - 1] / > (double)encoder_context->brc.framerate_den[i - 1]); > } > > if (i == encoder_context->layer.num_layers - 1) > factor = 1.0; > -else > -factor = (double)encoder_context- > >brc.framerate_per_100s[i] / encoder_context- > >brc.framerate_per_100s[encoder_context->layer.num_layers - 1]; > +else { > +factor = ((double)encoder_context->brc.framerate_num[i] > / (double)encoder_context->brc.framerate_den[i]) / > +((double)encoder_context->brc.framerate_num[i - 1] / > (double)encoder_context->brc.framerate_den[i - 1]); > +} > > hrd_factor = (double)bitrate / encoder_context- > >brc.bits_per_second[encoder_context->layer.num_layers - 1]; > > diff --git a/src/gen9_vdenc.c b/src/gen9_vdenc.c > index 8009b31..b2d0b21 100644 > --- a/src/gen9_vdenc.c > +++ b/src/gen9_vdenc.c > @@ -851,7 +851,8 @@ > gen9_vdenc_update_misc_parameters(VADriverContextP ctx, > if (vdenc_context->internal_rate_mode != I965_BRC_CQP && > encoder_context->brc.need_reset) { > /* So far, vdenc doesn't support temporal layer */ > -vdenc_context->frames_per_100s = encoder_context- > >brc.framerate_per_100s[0]; > +vdenc_context->framerate_num = encoder_context- > >brc.framerate_num[0]; > +vdenc_context->framerate_den = encoder_context- > >brc.framerate_den[0]; > > vdenc_context->vbv_buffer_size_in_bit = encoder_context- > >brc.hrd_buffer_size; > vdenc_context->init_vbv_buffer_fullness_in_bit = > encoder_context->brc.hrd_initial_buffer_fullness; > @@ -927,7 +928,8 @@ gen9_vdenc_update_parameters(VADriverContextP > ctx, > !vdenc_context->vbv_buffer_size_in_bit || > !vdenc_context->max_bit_rate || > !vdenc_context->target_bit_rate || > - !vdenc_context->frames_per_100s)) > + !vdenc_context->framerate_num || > + !vdenc_context->framerate_den)) > vdenc_context->brc_enabled = 0; > > if (!vdenc_context->brc_enabled) { > @@ -1565,7 +1567,8 @@ > gen9_vdenc_get_profile_level_max_frame(VADriverContextP ctx, > tmpf = max_mbps / 172.0; > > max_byte_per_frame0 = (uint64_t)(tmpf * bits_per_mb); > -max_byte_per_frame1 = (uint64_t)(((double)max_mbps * 100) / > vdenc_context->frames_per_100s *bits_per_mb); > +max_byte_per_frame1 = (uint64_t)(((double)max_mbps * > vdenc_context->framerate_den) / > + (double)vdenc_context- > >framerate_num * bits_per_mb); > > /* TODO: check VAEncMiscParameterTypeMaxFrameSize */ > ret = (unsigned int)MIN(max_byte_per_frame0, > max_byte_per_frame1); > @@ -1586,12 +1589,12 @@ > gen9_vdenc_calculate_initial_qp(VADriverContextP ctx, > > frame_size = (vdenc_context->frame_width * vdenc_context- > >frame_height * 3 / 2); > qp = (int)(1.0 / 1.2 * pow(10.0, > - (log10(frame_size * 2.0 / 3.0 * > ((float)vdenc_context->frames_per_100s) / > - ((float)(vdenc_context- > >target_bit_rate * 1000) * 100)) - x0) * > + (log10(frame_size * 2.0 / 3.0 * > vdenc_context->framerate_num / > + ((double)vdenc_context- > >target_bit_rate * 1000.0 * vdenc_context->framerate_den)) - x0) * >
Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode on KabyLake
Hi Vasavee, Maybe it is not a yami issue. I encountered another issue for VP8 video which is encoded by another vaapi based tool. I saw double frames when transcoding the video back to YUV using ffmpeg, however vpxdec works well for me, so I guess there are some issues in FFmpeg. Could you try vpxdec with your VP9 video? I think it is not yami issue if vpxdec works for you. Thanks Haihao > Hi Daniel, > > Sure, will do that! Thank you for the pointers. > > -Best Regards, > Vasavee > > -Original Message- > From: Charles, Daniel [mailto:daniel.char...@intel.com] > Sent: Monday, December 12, 2016 10:53 AM > To: Vijayaraghavan, Vasavee> Cc: Xiang, Haihao ; libva@lists.freedesktop.o > rg > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated encode/decode > on KabyLake > > Hi Vasavee, > > Can you file a bug on libyami for your observation? > > https://github.com/01org/libyami/issues > > Thanks. > > -- > Daniel. > > On Mon, Dec 12, 2016 at 10:45 AM, Vijayaraghavan, Vasavee jayaragha...@intel.com> wrote: > > Hi Haihao, > > > > I might have missed setting the PKG_CONFIG_PATH while trying to use > > './configure --prefix=/usr --exec-prefix=/'. > > But like Daniel suggested, I did a clean install with default paths > > and it works fine for me. > > > > I have installed libyami and libyami utils to test VP9 encode and > > decode. I am able to run VP9 encode and decode using the pre-built > > binaries located in libyami-utils/tools (yamiencode and > > yamidecode). > > I am facing issues in playing back the VP9 encoded video. > > Say test.ivf is my VP9 encoded output, when I playback the file > > using ffplay or VLC player, I am able to see only the first and > > last frame of the encoded video (though the video shows to have 500 > > frames - same as the input yuv; verified the number of frames using > > ffprobe). Although, when I decode it back to yuv, the yuv is > > exactly the same as original input yuv and plays all the frames > > fine. > > > > At this point, I haven’t added any quality control factor to encode > > the video and hence I have used a simple command line: > > $cd /home/user/libyami-utils/tools > > $./yamiencode -c VP9 -i input.yuv -W <> -H <> -s I420 -f 30 -N 500 > > -o > > test.ivf > > > > Am I missing something in the commandline which is why I am unable > > to play the output? > > > > Note: I tried playing pre-encoded test_vp9.ivf files available > > through MediaSDK samples and they played without an issue. > > > > -Thanks > > Vasavee > > > > -Original Message- > > From: Xiang, Haihao > > Sent: Wednesday, December 7, 2016 8:07 PM > > To: Charles, Daniel ; Vijayaraghavan, > > Vasavee > > Cc: libva@lists.freedesktop.org > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated > > encode/decode > > on KabyLake > > > > > > I think './configure --prefix=/usr --exec-prefix=/' should work > > too, otherwise it might have issue. Actually this configuration > > works fine for me when I build libva and libva-intel-driver. I set > > PKG_CONFIG_PATH variable to /lib/pkgconfig because libva.pc is > > installed in /lib/pkgconfig which is not in the default pkg-config > > search path. > > > > Thanks > > Haihao > > > > > Hi Daniel, > > > > > > That was right. I messed up a bit with the paths, uninstalling > > > and > > > then re-installing with the default path in configure worked fine > > > this time. > > > Thanks! > > > > > > -best Regards, > > > Vasavee > > > > > > > > > -Original Message- > > > From: Charles, Daniel [mailto:daniel.char...@intel.com] > > > Sent: Wednesday, December 7, 2016 5:25 PM > > > To: Vijayaraghavan, Vasavee > > > Cc: Xiang, Haihao ; libva@lists.freedeskt > > > op.o > > > rg > > > Subject: Re: [Libva] Evaluate VP9 Hardware accelerated > > > encode/decode > > > on KabyLake > > > > > > That's not expected, libdrm should also compile ok on the > > > defaults. > > > Normally what I see Ubuntu users do is to run $sudo make install > > > > > > If you just want to install it on a custom folder, -- > > > prefix= should be sufficient for all packages you > > > listed, > > > no need to mess up with --exec-dir > > > > > > -- > > > Daniel. > > > > > > > > > > > > On Wed, Dec 7, 2016 at 5:07 PM, Vijayaraghavan, Vasavee > > > wrote: > > > > Hi Daniel. > > > > I believe so, I used this configuration because my libdrm > > > > doesn’t > > > > build if I use the default config options. > > > > > > > > -Thanks > > > > Vasavee > > > > > > > > -Original Message- > > > > From: Charles, Daniel [mailto:daniel.char...@intel.com] > > > > Sent: Wednesday, December 7, 2016 3:36 PM > > > > To: Vijayaraghavan, Vasavee > > > > Cc: Xiang, Haihao ;