intel / gstreamer-media-sdk

DISCONTINUATION OF PROJECT

This project will no longer be maintained by Intel.

Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.

Intel no longer accepts patches to this project.

If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project.

Contact: [email protected] GStreamer-MSDK

GStreamer plugins for Intel® Media SDK

Overview

GStreamer-MSDK consists of a collection of GStreamer plugins for Intel® Media SDK (MSDK). This allows users to use MSDK in their GStreamer-based applications with minimal knowledge of the MSDK API.

GStreamer-MSDK includes plugins to perform decode, encode, video postprocessing (VPP) and high performance rendering. Please refer to README.USAGE for more information about these plugins and their usage.

Features

• Decode H264 AVC, MPEG-2, JPEG, VC-1, HEVC, VP8 and VP9 videos
• Compatible with GStreamer-based video players such as Totem, Parole and gst-play through playbin element.
• Support for zero-copy rendering with glimagesink using EGL
• Support rendering using Wayland renderer
• Support rendering using X11 renderer with DRI3 backend
• Support X11 / Wayland rendering using EGL renderer
• Support VPP acceleration of dynamic procamp control during video playback
• Support for subtitles (text overlay) via MFX VPP surface composition
• Support all Media SDK postprocessing capabilities as exposed by the MSDK API
• Encode / transcode video into H.264, HEVC, MPEG-2 and JPEG formats

Requirements

Software requirements

• Media Server Studio 2016 Community / Professional Edition (Haswell / Broadwell)
  Media Server Studio 2017 Community / Professional Edition (Broadwell / Skylake)
  Media SDK 2017 for Yocto Embedded Edition (Apollo Lake)

• GStreamer 1.6.x (tested up to GStreamer 1.10.x)

• gst-plugins-* 1.6.x (tested up to GStreamer 1.10.x)

• CMake

• Renderers:
  Wayland (>=1.7)
  X11 (DRI 3)
  EGL

Hardware requirements

• Intel Haswell / Broadwell / Skylake with Intel HD / Iris Pro graphics
• Intel Apollo Lake

Compiling

GStreamer-MSDK uses the CMake build tool to build the plugins. Create a build folder within the source directory and run the CMake command to configure the out-of-source build.

mkdir build
cd build
cmake ..

To make a debug build:

cmake .. -DDEBUG=ON

To build the plugins for Media Server Studio 2016 Linux Edition:

cmake .. -DWITH_MSS_2016=ON

Only Media SDK 2017 Embedded Edition supports VP9 decode for now. To enable VP9 decode support:

cmake .. -DUSE_VP9_DECODER=ON

For a list of more options when configuring the build, refer to the CMakeLists.txt file inside the source directory.

Next step is to compile and install the GStreamer-MSDK plugins:

make
make install

To uninstall the plugins:

make uninstall

If you intend to rebuild the plugins after making changes to the source code or you would want to change some of the build options after uninstalling the plugins, it is highly recommended to simply delete the build folder that you have created and repeat the build process as above.

Usage

Please refer to README.USAGE for examples on how to accomplish various video-related tasks with the GStreamer-MSDK plugins.

TODO

• Microsoft® Visual Studio support for Windows 10 enablement

License

GStreamer-MSDK libraries and plugins are available under the terms of the GNU Lesser General Public License v2.1+.

Acknowledgements

This project is heavily based on the well-established GStreamer VAAPI architecture, hence we would like to publicly thank the GStreamer VAAPI developers for their hard work and contributions.

Reporting a security issue

Please mail to [email protected] directly for security issue.

gstreamer-media-sdk's Issues

Mfxh264enc crashed

Hi stacktrace is:

Thread 8 "udb_conn_video_" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddf72700 (LWP 11052)]
0x0000000000000000 in ?? ()
Missing separate debuginfos, use: dnf debuginfo-install GConf2-3.2.6-16.fc24.x86_64 bzip2-libs-1.0.6-21.fc25.x86_64 cairo-1.14.8-1.fc25.x86_64 dbus-glib-0.108-1.fc25.x86_64 dbus-libs-1.11.12-1.fc25.x86_64 dconf-0.26.0-1.fc25.x86_64 expat-2.2.0-1.fc25.x86_64 fontconfig-2.12.1-1.fc25.x86_64 freetype-2.6.5-9.fc25.x86_64 glib-networking-2.50.0-1.fc25.x86_64 glib2-2.50.3-1.fc25.x86_64 gmp-6.1.1-1.fc25.x86_64 gnutls-3.5.12-2.fc25.x86_64 js-1.8.5-25.fc25.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64 krb5-libs-1.14.4-7.fc25.x86_64 libX11-1.6.5-1.fc25.x86_64 libXau-1.0.8-6.fc24.x86_64 libXext-1.3.3-4.fc24.x86_64 libXfixes-5.0.3-1.fc25.x86_64 libXrender-0.9.10-1.fc25.x86_64 libblkid-2.28.2-2.fc25.x86_64 libcap-2.25-2.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64 libdrm-2.4.81-1.fc25.x86_64 libffi-3.1-9.fc24.x86_64 libgcc-6.3.1-1.fc25.x86_64 libgcrypt-1.6.6-1.fc25.x86_64 libglvnd-0.2.999-14.20170308git8e6e102.fc25.x86_64 libglvnd-egl-0.2.999-14.20170308git8e6e102.fc25.x86_64 libglvnd-glx-0.2.999-14.20170308git8e6e102.fc25.x86_64 libgpg-error-1.24-1.fc25.x86_64 libidn2-2.0.2-1.fc25.x86_64 libmodman-2.0.1-12.fc24.x86_64 libmount-2.28.2-2.fc25.x86_64 libpciaccess-0.13.4-3.fc24.x86_64 libpng-1.6.27-1.fc25.x86_64 libproxy-0.4.14-1.fc25.x86_64 libproxy-mozjs-0.4.14-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64 libsoup-2.56.0-2.fc25.x86_64 libstdc++-6.3.1-1.fc25.x86_64 libtasn1-4.12-1.fc25.x86_64 libunistring-0.9.4-3.fc24.x86_64 libuuid-2.28.2-2.fc25.x86_64 libva-1.7.3-3.fc25.x86_64 libwayland-client-1.12.0-1.fc25.x86_64 libwayland-cursor-1.12.0-1.fc25.x86_64 libxcb-1.12-1.fc25.x86_64 libxml2-2.9.4-2.fc25.x86_64 lz4-1.7.5-1.fc25.x86_64 mesa-libwayland-egl-17.0.5-2.fc25.x86_64 nettle-3.3-1.fc25.x86_64 nspr-4.14.0-2.fc25.x86_64 openssl-libs-1.0.2k-1.fc25.x86_64 p11-kit-0.23.2-4.fc25.x86_64 pcre-8.40-7.fc25.x86_64 pixman-0.34.0-2.fc24.x86_64 sqlite-libs-3.14.2-1.fc25.x86_64 systemd-libs-231-15.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64 zlib-1.2.8-10.fc24.x86_64

(gdb) bt
#0  0x0000000000000000 in  ()
#1  0x00007fffe05f67ca in  () at /opt/intel/mediasdk/lib64/iHD_drv_video.so
#2  0x00007fffe05f688d in  () at /opt/intel/mediasdk/lib64/iHD_drv_video.so
#3  0x00007fffe0637a0a in  () at /opt/intel/mediasdk/lib64/iHD_drv_video.so
#4  0x00007fffe0637c01 in  () at /opt/intel/mediasdk/lib64/iHD_drv_video.so
#5  0x00007fffe0638d56 in  () at /opt/intel/mediasdk/lib64/iHD_drv_video.so
#6  0x00007fffe8b94ca4 in vaCreateContext () at /lib64/libva.so.1
#7  0x00007fff633741db in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#8  0x00007fff633742ae in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#9  0x00007fff634ad3f9 in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#10 0x00007fff634b949a in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#11 0x00007fff634afcf3 in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#12 0x00007fff634afec8 in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#13 0x00007fff634b11e6 in  () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#14 0x00007fff6336004f in MFXVideoVPP_Query () at /opt/intel/mediasdk/lib64/libmfxhw64-p.so.1.21
#15 0x00007fffe923ca54 in configure_filters () at /usr/local/lib/gstreamer-1.0/libgstmfx.so
#16 0x00007fffe923d07b in gst_mfx_filter_prepare () at /usr/local/lib/gstreamer-1.0/libgstmfx.so
#17 0x00007fffe924d8fc in gst_mfx_encoder_start () at /usr/local/lib/gstreamer-1.0/libgstmfx.so
#18 0x00007fffe9239275 in gst_mfxenc_set_format () at /usr/local/lib/gstreamer-1.0/libgstmfx.so
#19 0x00007fffe96c6156 in gst_video_encoder_setcaps (caps=0x82f590, encoder=0x9c49f0) at gstvideoencoder.c:617
#20 0x00007fffe96c6156 in gst_video_encoder_sink_event_default (encoder=0x9c49f0, event=0x7fffc00062b0) at gstvideoencoder.c:969
#21 0x00007ffff6e3ff77 in gst_pad_send_event_unchecked (pad=pad@entry=0x9c1480, event=event@entry=0x7fffc00062b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5607
#22 0x00007ffff6e4040e in gst_pad_push_event_unchecked (pad=pad@entry=0x9c1240, event=0x7fffc00062b0, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5263
#23 0x00007ffff6e40810 in push_sticky (pad=pad@entry=0x9c1240, ev=ev@entry=0x7fffddf71780, user_data=user_data@entry=0x7fffddf717e0) at gstpad.c:3806
#24 0x00007ffff6e3e507 in events_foreach (pad=pad@entry=0x9c1240, func=func@entry=0x7ffff6e406c0 <push_sticky>, user_data=user_data@entry=0x7fffddf717e0) at gstpad.c:603
#25 0x00007ffff6e4aaa1 in check_sticky (event=0x7fffc00062b0, pad=0x9c1240) at gstpad.c:3863
#26 0x00007ffff6e4aaa1 in gst_pad_push_event (pad=pad@entry=0x9c1240, event=0x7fffc00062b0) at gstpad.c:5394
#27 0x00007ffff3c1a676 in gst_pad_set_caps (caps=0x82f590, pad=0x9c1240) at ../../../gst/gstcompat.h:58
#28 0x00007ffff3c1a676 in gst_base_transform_setcaps (trans=trans@entry=0x9e6330, pad=<optimized out>, incaps=<optimized out>) at gstbasetransform.c:1390
#29 0x00007ffff3c1baad in gst_base_transform_sink_eventfunc (trans=0x9e6330, event=0x7fff84002d90) at gstbasetransform.c:1946
#30 0x00007ffff6e3ff77 in gst_pad_send_event_unchecked (pad=pad@entry=0x9c1000, event=event@entry=0x7fff84002d90, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5607
#31 0x00007ffff6e4040e in gst_pad_push_event_unchecked (pad=pad@entry=0x9c0dc0, event=0x7fff84002d90, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5263
#32 0x00007ffff6e40810 in push_sticky (pad=pad@entry=0x9c0dc0, ev=ev@entry=0x7fffddf71ad0, user_data=user_data@entry=0x7fffddf71b30) at gstpad.c:3806
#33 0x00007ffff6e3e507 in events_foreach (pad=pad@entry=0x9c0dc0, func=func@entry=0x7ffff6e406c0 <push_sticky>, user_data=user_data@entry=0x7fffddf71b30) at gstpad.c:603
#34 0x00007ffff6e4aaa1 in check_sticky (event=0x7fff84002d90, pad=0x9c0dc0) at gstpad.c:3863
#35 0x00007ffff6e4aaa1 in gst_pad_push_event (pad=0x9c0dc0, event=event@entry=0x7fff84002d90) at gstpad.c:5394
#36 0x00007fffea055408 in gst_queue_push_one (queue=0x9dc0f0) at gstqueue.c:1434
#37 0x00007fffea055408 in gst_queue_loop (pad=<optimized out>) at gstqueue.c:1512
#38 0x00007ffff6e74b11 in gst_task_func (task=0x9d3830) at gsttask.c:334
#39 0x00007ffff73c758e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#40 0x00007ffff73c6b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#41 0x00007ffff7bc06ca in start_thread () at /lib64/libpthread.so.0
#42 0x00007ffff5043f7f in clone () at /lib64/libc.so.6

libva output:

libva info: VA-API version 0.99.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.99 (libva 1.67.0.pre1)
vainfo: Driver version: 16.5.1.59511-ubit
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: <unknown entrypoint>
      VAProfileH264ConstrainedBaseline: <unknown entrypoint>
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : <unknown entrypoint>
      VAProfileH264Main               : <unknown entrypoint>
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : <unknown entrypoint>
      VAProfileH264High               : <unknown entrypoint>
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : <unknown entrypoint>
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileVP9Profile0            : <unknown entrypoint>
      <unknown profile>               : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : <unknown entrypoint>

Fix KW issue

In the gst_mfx_task_get_soft_reinit function, the task checking should be return false if the task is NULL.
Because this gboolean return function.

do not work on J1900 CPU

gst-inspect-1.0 --gst-plugin-load=gstmfx.dll mfx

2.0.0:

Plugin Details:
  Name                     mfx
  Description              MFX encoder/decoder/video post-processing plugins
  Filename                 gstmfx.dll
  Version                  2.0.0
  License                  LGPL
  Source module            gst_mfx
  Binary package           gst_mfx
  Origin URL               http://www.intel.com


  0 features:

1.5.0:

Plugin Details:
  Name                     mfx
  Description              MFX encoder/decoder/video post-processing plugins
  Filename                 gstmfx.dll
  Version                  1.5.0
  License                  LGPL
  Source module            gst_mfx
  Binary package           gst_mfx
  Origin URL               http://www.intel.com

  mfxh264dec: MFX H264 decoder
  mfxmpeg2dec: MFX MPEG2 decoder
  mfxvc1dec: MFX VC1 decoder
  mfxjpegdec: MFX JPEG decoder
  mfxdecode: MFX Video Decoder
  mfxvpp: MFX video postprocessing
  mfxsinkelement: MFX sink
  mfxsink: MFX Sink Bin
  mfxh264enc: MFX H.264 encoder
  mfxhevcenc: MFX H.265 encoder
  mfxmpeg2enc: MFX MPEG-2 encoder
  mfxjpegenc: MFX JPEG encoder
  mfxvc1parse: VC1 parser

  13 features:
  +-- 13 elements

Failed to play mpeg2 decode with simple profile format interlace stream with mfxvpp value set.

Play the mpeg2 video with simple profile and interlace clip with mfxvpp any parameter value set will cause the video fail to play.

[master] libgstmfx plugin not installed in gstreamer plugins directory

The gstmfx install target (libgstmfx.so) is currently installed directly into CMAKE_INSTALL_PREFIX. In order for gstreamer tools to detect it automatically, it needs to be installed into the gstreamer plugins directory instead.

The gstreamer plugins directory can be found with pkg-config: pkg-config --variable=pluginsdir gstreamer-1.0. Starting in CMAKE version 3.4.3, you can use pkg_get_variable (https://cmake.org/cmake/help/v3.4/module/FindPkgConfig.html) to get the pluginsdir value. In earlier versions of CMAKE, you'll have to parse pkg-config output directly. I would recommend updating cmake list scripts to require at least 3.4.3 for simplicity.

Fixes indirectly memory leak in gst_mfx_plugin_base_set_pool_config

Fixed AV out of sync issue

After the detected the frame from progressive changed to interlaced, the decoder will be reinit.
After reinit, it will cause the video and audio start out of sync. To avoid the decoder keep request small data information request to h264parse after reinit causing the latency, we will get information from the bitstream and re-send to decoder instead go thru upper layer request more data information again from h264parse.

Handle IDR I frame corruption in gst-msdk

The H264 video clip demux using gstreamer framework, the bitstream only have SPS and PPS information in first IDR frame. Following IDR frames does not contain any SPS PPS information.

If H264 video clip demux using ffmpeg, The bitstream will contain SPS and PPS information before each of IDR frame.

In order to force the SPS and PPS information exit before each of IDR frames. Propose to use H264parse from https://bugzilla.gnome.org/show_bug.cgi?id=766803 backporting this fixed into gst-plugin-bad-1.8.3.

In sample_decode from MSDK, it will reset decoder when incompatible params from the bitstream. Currently, we did same similar behavior as the sample_decode, implement in gst-msdk decoder plugin. The gst-msdk decoder need enable to handle incompatible params for decoder plugin as well.

In sample_decode, it will be shutdown decoder and re-init decoder, to kick start back the decoder. The gst-msdk decoder plugin also did same behavior. We found out during the process shutdown decoder, all the VASurfaces will be destroy, this will causing the green screen issue in gst-msdk during presenting output. This is due got 4 decode frames not yet been presented, the VASurfaces already destroy during. Currently, the gst-msdk plugin does not has VASurface tracking mechanism capable to track the which VASurfaces has been presenting before destroy its. At here, we keep the VASurfaces and re-use back VASurfaces instead of destroy its.

We found out during re-start gst-msdk decoder involved video seeking opration, it will causing run out of video memory. Because another 32 VASurfaces has been created for VPP task during init filter. The VPP never has been call to destroy. In this video clip issue, it does not involve any VPP task yet during reset. At here, we will check during reinit decoder function whether CSC and deinterlace got involved or not before do init filter.

[master] Added synchronization of decoded MFXSurfaces between multiple components.

In some specific case clip, the MSDK may overwrite the decoded surface if we didn't sync the decoded MFXSurfaces.

Especially the gst-play-1.0 or gst-launch-1.0 manual command pipeline added queue in between mfxdecode and mfxsink.

video clip: cat.mkv and sample.mp4 on H264 video format.

We will add synchronization of decoded MFXSurfaces between multiples components.

fixed return type of GstMfxEnc->format_buffer

This issue is found by Hallade, Xavier and fixed by him as well.

Fixes indirect memory leak in gst_mfx_find_preferred_caps_feature function.

The GstCaps memory allocated by gst_pad_peer_query_caps does not free up after exit gst_mfx_find_preferred_caps_feature function. This will cause around 1748 bytes indirect memory leak and 288 direct memory leak.

Prevent overflow happen in AspectRatioH and AspectRatioW passing down to MSDK from upstream plugin.

In avidemux plugin side:
Once the vprp ( Video Propertiies Header) detected exist in avidemux plugin, we can the see the aspect ratio is
16384:9223 which is aspect_n = 16384 and aspect_d = 9223.

Inside the avidemux plugin, under gst_avi_demux_parse_stream function (gstavidemux.c):
The pixel aspect ratio is using w/h and aspect ratio:
n = aspect_n * stream video height = 16384 * 720 = 11796480
d = aspect_d * stream video width = 9223 * 1270 = 11713210

In the GST_DEBUG message for avidemux, the gst_avi_demux_check_caps is using to check for caps values.
I found out the pixel-aspect-ratio=(fraction)1179648/1171321

The last digit totally gone. In gst-msdk, we retrieve the GstVideoInfo based on the caps, the vip.par_n = 1179648 and vip.par_d=1171321.
In the avidemux plugin side, may need to gstreamer deveoper side how he pixel-aspect-ratio calculate. It could be on certain format for avi file container checking for certain condition.

In the qtdemux, the formula is
n = display width * stream video height
d = display height * stream video width

In the h264parse plugin, the sps->vui_paramters.aspect_ratio_info_prresent_flag is equal to 1.
The h264parse also detect the parsed_par_n and parsed_par_d is different with sps->vui_parameters->par_n and sps->vui_parameters->par_d.
The h264parse updated the parsed_par_n and parsed_par_d to use the vui_parameters->par_n and vui_parameters->par_d.
But currently the upstream_par_n and upstream_par_d exist, the pixel-aspect-ratio caps will be chosen to use upstream_par_n and upstream_par_d instead
of the par_n and par_d extra from sps->vui_parameters.

The gst-vaapi got its own parse function, they can overwrite the pixel-aspect-ratio directly use the information from sps->vui_parameters.
On the gst-msdk side, looks like we need to extra out sps information check for vui_parameter exist or not.
To decide to use sps->vui_parameter sar_width and sar_height for par_n and par_d to fill in AspectRatioW and AspectRatioH inside the mfxFrameInfo struct.

In gst-msdk plugin side:
MSDK library has mfxFrameInfo struct contains member AspectRatioW and AspectRatioH with data type mfxU16 which is only 2 bytes. But the par_n and pard_d is gint which is 4 bytes.
Once the value larger than 2 bytes, the value assign to AspectRatioH and AspectRatioW will not correct anymore. The information are missing from 4 bytes to 2 bytes.
The decoder-params passing to MFXVideoDECODE_Init will return MFX_ERR_INVALID_VIDEO_PARAM (-15). This will lead to video fail to play. To prevent the issue happen again due overflow, we will
added check to ensure par_n and par_d passing from upstream is within 2 bytes before pass to MSDK, else will do shift 16 for par_n and par_d values over 2 bytes.

Added AVC stream-format support in H264

Added the H264 supported input AVC stream-format.

Segmentation fault, in JPEG decoder.

Maybe ofcose, i has problem with may build, or libraryes, but MFX samples normally working, and decode my JPEG.

Ubuntu 16.10, Plug-in version: v1.3.2-rc5, Gstreamer 1.8.3, MSSE 2017 R3.
command, runing gstreamer:

/usr/bin/gst-launch-1.0 -v filesrc location=/home/nick64/testgstreamer/3/video12zT.jpg ! image/jpeg,width=3264,height=2448,framerate=15/1 ! mfxjpegdec ! mfxsink
Установка конвейера в состояние PAUSED…
libva info: VA-API version 0.99.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
Подготовка конвейера (PREROLL)…
Получен контекст из элемента «mfxsink0»: gst.mfx.Aggregator=context, gst.mfx.Aggregator=(GstMfxTaskAggregator)NULL;
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = "image/jpeg\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxDec_jpeg:mfxdec_jpeg0.GstPad:sink: caps = "image/jpeg\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxDec_jpeg:mfxdec_jpeg0.GstPad:src: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)NV12\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt2020\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxSinkBin:mfxsinkbin0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)NV12\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt2020\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxSinkBin:mfxsinkbin0/GstMfxPostproc:mfxpostproc0.GstPad:src: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)BGRA\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ colorimetry\=\(string\)sRGB\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxSinkBin:mfxsinkbin0/GstMfxSink:mfxsink0.GstPad:sink: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)BGRA\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ colorimetry\=\(string\)sRGB\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxSinkBin:mfxsinkbin0/GstMfxPostproc:mfxpostproc0.GstPad:sink: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)NV12\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt2020\,\ framerate\=\(fraction\)15/1"
/GstPipeline:pipeline0/GstMfxSinkBin:mfxsinkbin0.GstGhostPad:sink: caps = "video/x-raw\(memory:MFXSurface\)\,\ format\=\(string\)NV12\,\ width\=\(int\)3264\,\ height\=\(int\)2448\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt2020\,\ framerate\=\(fraction\)15/1"
Caught SIGSEGV
Spinning.  Please run 'gdb gst-launch-1.0 3534' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
XIO:  fatal IO error 11 (Ресурс временно недоступен) on X server ":0"
      after 27 requests (27 known processed) with 2 events remaining.

I success build this from sources. And it normally working with h264 codec. But when i try use MJPEG video, it crash SIGSEG signal.
in file /gst-libs/mfx/gstmfxtask.c at 322 line:

static mfxStatus
gst_mfx_task_frame_get_hdl (mfxHDL pthis, mfxMemId mid, mfxHDL * hdl)
{
  GstMfxMemoryId *mem_id = (GstMfxMemoryId *) mid;

//at this line chrash, in this expression: mem_id->mid
// hdl==0; (*mem_id)==2, when it try go ro memory address 2, it crash.
  if (!mem_id || !mem_id->mid || !hdl) 
    return MFX_ERR_INVALID_HANDLE;

  *hdl = mem_id->mid;
  return MFX_ERR_NONE;
}

Local variables:

		hdl	0	mfxHDL
		mem_id	@0x1	GstMfxMemoryId
			info	<недоступно>	
			mid	<недоступно>	
mid	1	mfxMemId
		pthis	140160150978640	mfxHDL

mid- has wrong address, hdl - zerro, but it check after. JPEG received from camera, 3264x2448, it is linear jpeg, without restarts. Before this fault gst_mfx_task_frame_alloc called 2 times.

Increase the number of surfaces for decoder task on small frame and high frame rate video.

Increase number of surfaces for decoder task with condition as below:
i) width < 1281
ii) height < 721
iii) frame rate > 50

[topic lin & win] H264 video stuttering certain video clip contain max_num_ref_frames=16 in sps

gstreamer framework: 1.12.0
gst-msdk : topic_linux_and_window
environment: linux (wayland weston and X11 DRI3)

command:

1. gst-play-1.0 sample.mp4
2. gst-launch-1.0 filesrc location=/video/sample.mp4 ! qtdemux ! h264parse ! mfxdecode ! queue ! mfxsink

video clip: sample.mp4 , cat.mkv

Video playback by adding queue in between mfxdecode and mfxsink will be causing the video stuttering.

In gst-msdk plugin (master branch) also having the same issue, but we added the synchronization of decoded MFXSurfaces between multiple components (#54 ) take care it.

[HSD-ES 1504637644]

Fixed VA Surface ID to GstMfxId casting issue

In gst_mfx_surface_vaapi_from_task function, the surface->surface_id is invalid casted. Right now, we are casting to VASurfaceID first, followed by casting to GstMfxID.

H264 video paused when seek during playback

command: gst-play-1.0 DAL_Shabet.mp4
Using arrow key "<" and arrow key ">" to seek video.
It will cause the video pause once we seek the video. This issue introduced by the patches we enable AVC stream-format.

gst-msdk 1.3.3 version : Enable option to turn off the H265 10 bit decoder plugin.

gst-msdk version: 1.3.3 (master branch).
MSDK library does not support for H265 10 bit HW decoder for APL-I platform. The gst-msdk plugin added use H265 10bit SW decoder plugin. If the MSDK H265 10bit SW decoder does not exist, it will lead to H265-10bit playback crash in gst-msdk.

Currently, propose to enable alternative option to allow disable H265 10bit video decoder in gst-msdk.
The user still can got option switch back to use H265 10bit SW decoder plugin (avdec_h265 plugin) from Gstreamer framework plugins in gst-play-1.0 or playbin.

Correct the bitstream pointer and size after remove partially

The problem is beginning of data pointer in bitstream does not point correctly after remove. Correct the bistream pointer and size after remove partially data bitstream.

Fixed the wrong order checking statement in gst_mfx_video_buffer_pool_alloc_buffer

In gst_mfx_video_buffer_pool_alloc_buffer function, the buffer checking NULL statement should do it first. If the buffer is NULL, it shoud straight called error_create_buffer and exit. Instead of go if buffer checking NULL statement to decide enter gst_buffer_set_mfx_video_meta.

[topic lin & win] RES memory keep increasing hen running gst-play-1.0 with playlist

Gstreamer framework: 1.12.3
gst-msdk : topic_linux_and_window
Environment: wayland weston.

The test.list contains 200 sequence of H264 video
command: gst-play-1.0 --playlist /test.list --videosink="mfxsink"

The memory is measured using "top -d 1 | grep -i gst".

The RES is keeping increase when running using gst-play-1.0.

This two fixed patch required to include in gst-plugins-base and gst-plugin-good.
https://bugzilla.gnome.org/show_bug.cgi?id=789547
https://bugzilla.gnome.org/show_bug.cgi?id=788759

The RES no long keep increasing after apply this two patches fixed gst-plugins-base and gst-plugins-good for software decode, gst-msdk plugin (master branch), but the RES still keep increase in topic_linux_and_window branch.

[HSD-ES: 1805749008]

Possible race in wayland_sync

Text copied from upstream vaapi bug, code is the same here.

If you have a second thread that registers a second queue on the wayland display and that will call wl_display_flush, it can happen that the frame callbacks are already triggered by the while loop in https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapiwindow_wayland.c#n174. So it can happen that after

https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapiwindow_wayland.c#n178

the priv->num_frames_pending is already 0 and we will be stuck in gst_poll_wait forever.

Fix memory leak in mfxvc1parse

Remove duplicate caps that calling from gst_pad_get_current_caps that forget to free up.

Fixed compiler warning

porting the code fixed from Hallade, Xavier.

video and goes out of sync

When transcoding a linear stream the video and audio goes out of sync after couple of hours.

this is the pipeline we used:
gst-launch-1.0 souphttpsrc location="http://localhost:80/oranews_HD/mpegts" is-live=true ! tsdemux name=demux ! queue max-size-buffers=1200 max-size-buffers=0 max-size-time=0 ! h264parse ! mfxh264dec ! mfxvpp width=1280 height=720 framerate=25/1 ! mfxh264enc rate-control=1 bitrate=1700 ! flvmux streamable=true name=mux ! rtmpsink location="rtmp://localhost:1935/pushrtmp/mfxtesasfht1s live=1" demux. ! queue max-size-buffers=1200 max-size-buffers=0 max-size-time=0 ! mpegaudioparse ! queue ! avdec_mp2float plc=true ! audioconvert ! queue ! voaacenc bitrate=128000 ! mux.

We also tried using avdec_h264 instead of mfxh264dec and there is no out of sync issue so there must be something wrong with mfxh264dec.

Remove the defined HAVE_XCBX11 checking in X11 render window

Using meson and ninja to build gst-msdk verified and work in Fedora25.
This new defined HAVE_XCBX11 checking is causing failures to play any video in Yocto matchbox X11. Before this new build option integrates into here, didn't include HAVE_XCBX11 checking in gst_mfx_window_x11_render. Currently remove out first. Once meson and ninja have done integrate into Yocto image, we will re-verify this new build option that using meson and ninja. function.

Add checking for raw or mfx surface during update sink caps and set caps in mfxvpp

1. Add the checking for the raw or mfx surface during sinkpad update.
2. Check for both sink and source caps changed during update.

Fixed wrong using vpp->hue under PROP_SATURATION to checking.

coding error.

Support for Windows?

Title says it all.

Update master to latest GST-MFX codebase

The new GST-MFX 2.0 codebase is leaner, cleaner and even more feature-complete compared to the current 01.org master. It also is cross-platform with full hardware acceleration on both Windows and Linux. There is no reason why the current 01.org GStreamer Intel Media SDK implementation should not move to the new GST-MFX implementation as explained. Is there a timeline as to when the migration will occur?

Fixed indirectly memory leak issue in mfxpostproc

Running MPEG2 decoder with mfxvpp found out there is memory leak issue: The indirectly lost will keep increasing.

use valgrind check:
==32461== LEAK SUMMARY:
==32461== definitely lost: 16,456 bytes in 2 blocks
==32461== indirectly lost: 884 bytes in 21 blocks
==32461== possibly lost: 6,108 bytes in 91 blocks
==32461== still reachable: 1,769,199 bytes in 21,664 blocks
==32461== of which reachable via heuristic:
==32461== length64 : 1,320 bytes in 24 blocks
==32461== newarray : 1,664 bytes in 24 blocks
==32461== suppressed: 0 bytes in 0 blocks
==32461== Reachable blocks (those to which a pointer was found) are not shown.
==32461== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32461==
==32461== For counts of detected and suppressed errors, rerun with: -v
==32461== ERROR SUMMARY: 92 errors from 92 contexts (suppressed: 0 from 0)

Pass in wrong vaapi_surface into gst_mfx_surface_vaapi_derive_image function.

gst_mfx_surface_vaapi_derive_image function accept GstMfxSurface type instead of GstMfxSurfaceVaapi.
Correct it by pass in GstMfxSurface.

Clean up unused variable in gst_mfx_find_preferred_caps_feature

Remove unused variable and initialize the pointer GstCaps to NULL.

Fixed bad arg indirection in QueryIOSurf call in gstmfxfilter.c

This issue is found by Hallade, Xavier and fixed by him as well.

Error initializing internal MFX session

I am getting this error when running any of the mfx elements.

ERROR                    mfx gstmfxtaskaggregator.c:150:gst_mfx_task_aggregator_create_session: Error initializing internal MFX session

Here is my vainfo.

libva info: VA-API version 0.99.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /usr/lib/iHD_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.99 (libva 1.67.0.pre1)
vainfo: Driver version: 16.7.3.64751-ubit
vainfo: Supported profile and entrypoints
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncFEIIntel
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncFEIIntel
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncFEIIntel
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : <unknown entrypoint>
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStatisticsIntel

I am using github.com/01org/iotg-lin-gfx-libva at 9430287e9e1563777e3d51ba730636e78ed10796
I am using github.com/01org/iotg-lin-gfx-libdrm at release/mr3
msdk 16.7
msdk-media 16.7.3

H264 multi-stream decode question ?

According to the release note

Intel Atom® SoC E3900 Family, Intel® Celeron® Processor N3350, and Intel® Pentium® Processor N4200 Board Support Package for Yocto Project*—MR3.1 Release (August 2017)

3.2.5 Unsupported or discontinued features (p17)

GStreamer VA PI multi-stream decode with H264 not more supported ?????

Is somebody doing multi-stream H264 decoding on Apollo Lake I ???

Is this an issue related to the gstreamer-media-SDK

Support for GStreamer 1.12?

Your documentation says 1.10. Unfortunately, I need 1.12. Any plans to support it?

Fixed CL compilation issue with marco expansions

This issue reported by Xavier, Hallade and code fixed from him as well.

Wrong args order for g_slice_free1 in configure_filters()

This issue found by Xavier Hallade and also fixed by him.

Fixed wrong args in gst_mfx_surface_allocate_default function.

Fixes the different argument in between function header vs function in GstMfxSurfaceAllocateFunc and gst_mfx_surface_allocate_default function.

Fixed definitely memory leak detected by valgrind on gst-msdk

execute command: valgrind --tool=memcheck --leak-check=full --log-file=output.log gst-play-1.0 --playlist videoplaylist.m3u

==1236== 72 bytes in 1 blocks are definitely lost in loss record 4,528 of 6,301
==1236== at 0x4C2AC55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1236== by 0xC7C9A82: ??? (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xC7C9F44: wl_proxy_marshal_array_constructor_versioned (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xC7CA269: wl_proxy_marshal_constructor (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xB7D1B70: wl_drm_create_prime_buffer (wayland-drm-client-protocol.h:225)
==1236== by 0xB7D215C: gst_mfx_window_wayland_render (gstmfxwindow_wayland.c:234)
==1236== by 0xB7CC58A: gst_mfx_window_put_surface (gstmfxwindow.c:456)
==1236== by 0xB7B71AC: gst_mfxsink_render_surface (gstmfxsink.c:110)
==1236== by 0xB7B999F: gst_mfxsink_show_frame (gstmfxsink.c:1044)
==1236== by 0x6DC12B1: ??? (in /usr/lib/libgstbase-1.0.so.0.803.0)
==1236== by 0x6DC26FF: ??? (in /usr/lib/libgstbase-1.0.so.0.803.0)
==1236== by 0x57F4237: ??? (in /usr/lib/libgstreamer-1.0.so.0.803.0)

==1236== 120 (88 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 5,504 of 6,301
==1236== at 0x5AE4A63: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.4400.1)
==1236== by 0x5ACD2E6: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.4400.1)
==1236== by 0x5AD07C8: g_param_spec_boolean (in /usr/lib/libgobject-2.0.so.0.4400.1)
==1236== by 0xB7C1913: gst_mfx_sink_bin_class_init (gstmfxsinkbin.c:280)
==1236== by 0xB7C1132: gst_mfx_sink_bin_class_intern_init (gstmfxsinkbin.c:95)
==1236== by 0x5AE189C: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.4400.1)
==1236== by 0x5AC8FCC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.4400.1)
==1236== by 0x57E0464: gst_element_factory_create (in /usr/lib/libgstreamer-1.0.so.0.803.0)
==1236== by 0x8039D83: ??? (in /usr/lib/gstreamer-1.0/libgstplayback.so)
==1236== by 0x7611F9F: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
==1236== by 0x7611A0A: ffi_call (in /usr/lib/libffi.so.6.0.4)
==1236== by 0x5AC29E8: g_cclosure_marshal_generic (in /usr/lib/libgobject-2.0.so.0.4400.1)

==1236== 216 bytes in 3 blocks are definitely lost in loss record 5,942 of 6,301
==1236== at 0x4C2AC55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1236== by 0xC7C9A82: ??? (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xC7C9F44: wl_proxy_marshal_array_constructor_versioned (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xC7CA269: wl_proxy_marshal_constructor (in /usr/lib/libwayland-client.so.0.3.0)
==1236== by 0xB7D1A34: wl_surface_frame (wayland-client-protocol.h:1873)
==1236== by 0xB7D22D3: gst_mfx_window_wayland_render (gstmfxwindow_wayland.c:260)
==1236== by 0xB7CC58A: gst_mfx_window_put_surface (gstmfxwindow.c:456)
==1236== by 0xB7B71AC: gst_mfxsink_render_surface (gstmfxsink.c:110)
==1236== by 0xB7B999F: gst_mfxsink_show_frame (gstmfxsink.c:1044)
==1236== by 0x6DC12B1: ??? (in /usr/lib/libgstbase-1.0.so.0.803.0)
==1236== by 0x6DC26FF: ??? (in /usr/lib/libgstbase-1.0.so.0.803.0)
==1236== by 0x57F4237: ??? (in /usr/lib/libgstreamer-1.0.so.0.803.0)

[master] Use pkgconfig to find MFX library

https://github.com/Intel-Media-SDK/MediaSDK provides a pkg-config (mfx.pc) file upon install for the MFX library. In cmake/FindMediaSDK.cmake, please consider adding an additional option to find the mfx library via pkg_check_modules function.

[topic lin & win] USB Video Playback returns error on mfxfilter

gstreamer framework: 1.12.3
gst-msdk : topic_linux_and_window
environment: linux (wayland weston and X11 DRI3)

There is an issue when MPEG2 Decode + VPP plugins with parameter value set.

Example command:
gst-launch-1.0 filesrc location=/home/root/MPEG-1\ System_mpg_MPEG-2_Simple\ Profile-Main\ Profile_320x240_3007Kbps_24.000fps.mpeg ! tsdemux ! mpegvideoparse ! mfxmpeg2dec ! mfxvpp hue=70 ! mfxsink
Get a return MFXVideoVPP_RunFrameVPPAsync return error

This issue is introduced by :
commit id: 8103535
gstmfxfilter: Use the output crop height instead of input crop height.

It overwrites the vpp output height for GST_MFX_FILTER_REINTERLACING to replace the high use vpp output crop height. It will pass wrong information to MFXVideoVPP_RunFrameVPPAsync in gst_mfx_filter_process function.

Requires commit id 1e9316b from master branch to fix this issue.

[HSD-ES: 1504492239]

using with windows 10 intel media sdk

Hello
my programm using gstreamer-vaapi on linux and i search for for multiplatform solution to
hardware decode mjpeg (jpeg) streams

can i use this gstreamer plugin on windows 10? i have no windows developer experience :/

mfxdecode / mfxh264dec h.264 on seek doesn't work

mfxdecode of h.264 stream after seek gives error "More data". The pipeline works fine if we use avdec_h264, so we don't suspect any issue with pipeline.

Add checking for GstMfxDecoder that possible NULL

This issue found by Xavier Hallade and also fixed by him.

mfxjpegdec output grey picture on windows

grey picture:

gst-launch-1.0 --gst-plugin-load=gstmfx.dll -v ksvideosrc device-index=0 ! mfxjpegdec ! videoconvert ! autovideosink

color picture:

gst-launch-1.0 --gst-plugin-load=gstmfx.dll -v ksvideosrc device-index=0 ! jpegdec ! videoconvert ! autovideosink

Artifacts while encoding

I ran the following command:

gst-launch-1.0 -e videotestsrc pattern=18 ! queue ! mfxh264enc ! queue ! mpegtsmux ! filesink location=4k.mp4

When playing back the video, I am getting artifacts.

video.mp4.zip

Are the some encoder properties I could tweak with to fix this problem?

I am using a 7th gen i7. More info here.

> vainfo
libva info: VA-API version 0.99.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /usr/lib/iHD_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.99 (libva 1.67.0.pre1)
vainfo: Driver version: 16.7.3.64751-ubit
vainfo: Supported profile and entrypoints
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncFEIIntel
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncFEIIntel
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncFEIIntel
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : <unknown entrypoint>
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStatisticsIntel

Fix wrong alignment for frame height on HEVC decoder

For HEVC decoder is should align with 32 instead using 16. This follows the 32 alignments done in MSDK library side for HEVC decoder.