GNOME Bugzilla – Bug 763042
gen75_vpp_vebox.c:1415: hsw_veb_pre_format_convert: Assertion `0' failed.
Last modified: 2017-04-12 18:33:03 UTC
Decoding mjpeg together with vaapipostproc, we get this Assertion: gen75_vpp_vebox.c:1415: hsw_veb_pre_format_convert: Assertion `0' failed. How to reproduce: Working: gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob ! vaapisink sync=false NOT working: gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob format=nv12 ! vaapisink sync=false The only difference is "format=nv12" for vaapipostproc. Using "format=i420" it also works. Our setup: gst-inspect-1.0 --version gst-inspect-1.0 version 1.6.3 gst-inspect-1.0 vaapipostproc |grep Version Version 1.6.0 libva info: VA-API version 0.38.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/va/i965_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.38 (libva 1.6.2) vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Mobile - 1.6.2
It's quite related with error handling done with asserts in libva-intel-driver, like with bug 762500 Yesterday I found a similar one with mpeg2 when exporting from one format to another: gst-play-1.0 /home/vjaquez/patterns/burosch1.mpg --videosink=ximagesink Nonetheless, in this case, using libva 1.6.2.pre2, and libva-intel-driver 1.6.2, setting to format=nv12 works just fine, but when setting format=i420 the pipeline fails as you said. I wonder why would you like to change the format of the vaapi surface, if it can be handled as a "opaque" structure. It does matter when you want to map it and read the raw data in it, but this is not the case since you are using vaapisink.
In our product we have a appsink and use different formats. RGBA also doesn't work. The nv12 format was only an example, if anybody wants to reproduce this issue.
(In reply to frank.huber from comment #2) > In our product we have a appsink and use different formats. RGBA also > doesn't work. > The nv12 format was only an example, if anybody wants to reproduce this > issue. Ah, this is somehow related with bug 762546.
In my opinion it is not related with bug 762546. It is independent of the sink. It has nothing to do with stride information, which is mentioned in bug 762546. Is's a bug in vaapipostproc. vaapipostproc is not able to do the color space transformation when there is a vaapidecode with jpeg input data before vaapipostproc. There are two possibilities - the pipeline is invalid, then the negotiation should fail - the pipeline is valid, then there should be no assertion (and we should see a video)
Hi, I had just retested your pipelines, modifying them according to current master, and both work: gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapijpegdec ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob format=nv12 ! vaapisink sync=false and gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapijpegdec ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob ! vaapisink sync=false But, this is because the postprocessor always choose video/x-raw(memory:VASurface) if the next element supports it, and it doesn't care the format (it always set it to NV12) Now, if the pipeline is changed to use ximagesink (forcing the color conversion), the assertion is executed: gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapijpegdec ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob ! ximagesink sync=false -v This is clearly a problem in the intel's driver. The workaround is to insert a software video converter and force the NV12 format in the postprocessor: gst-launch-1.0 souphttpsrc location="http://88.53.197.250/axis-cgi/mjpg/video.cgi?resolution=320x240" ! multipartdemux ! jpegparse ! vaapijpegdec ! vaapipostproc deinterlace-mode=1 deinterlace-method=bob format=nv12 ! videoconvert ! ximagesink sync=false -v
The original issue described in comment #1 is fixed using recent version of the driver (1.7 or the recent 1.8), as stated in comment #5. Thus I'm closing the bug. The assertion discovered in comment #5 is fixed in current master of the driver, but still it is not working correctly (no frames are rendered when vaapipostproc converts to RGB from NV12). But that's another issue in the driver.