GNOME Bugzilla – Bug 765039
[AVC][decode] Failed to configure the buffer pool.
Last modified: 2016-10-31 14:20:20 UTC
1. Testing Steps: ======================================================================== gst-launch-1.0 filesrc location=/media/h264//HPCAMOLQ_BRCM_B.264 '!' h264parse '!' video/x-h264,stream-format=avc,alignment=au '!' vaapidecode '!' vaapisink sync=false 2.error log: root@x-kbl01:/GFX/Test/Infrastructure/infrastructure# gst-launch-1.0 filesrc location=/media/h264//HPCAMOLQ_BRCM_B.264 '!' h264parse '!' video/x-h264,stream-format=avc,alignment=au '!' vaapidecode '!' vaapisink sync=false libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'pipeline0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)NULL; Redistribute latency... 0:00:00.057534433 22655 0x121a370 ERROR vaapivideomemory gstvaapivideomemory.c:778:gst_vaapi_video_allocator_new: failed to allocate VA image pool 0:00:00.057605976 22655 0x121a370 ERROR vaapivideopool gstvaapivideobufferpool.c:222:gst_vaapi_video_buffer_pool_set_config: failed to create GstVaapiVideoAllocator object ERROR: from element /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0: Failed to configure the buffer pool Additional debug info: gstvaapipluginbase.c(771): gst_vaapi_plugin_base_decide_allocation (): /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0: Configuration is most likely invalid, please report this issue. ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... root@x-kbl01:/GFX/Test/Infrastructure/infrastructure# 3. Testing Env: ======================================================================== gst_plugins_vaapi: (master)506c9e2b5bbc50730b0083598b346b0fcc41ec78 libva: (master)2339d10b9a39ba4f7173053b9eab8d6a151717a5 Libva_intel_driver: (master)2c1bec03889fe759a33c087a7c107ad84bbb72fb 4. Frequency of Occurence: ======================================================================== 100% 5. fail case: Media_Dec_AVC_Gstreamer/HPCAMOLQ_BRCM_B.264 FAIL Media_Dec_AVC_Gstreamer/HPCVMOLQ_BRCM_B.264 FAIL
This behavior starts with the commit: 75a20de vaapidecode: Use video format derived from decoded surface as default... That commit exposes some deficiencies in gstreamer-vaapi and vaapi/intel-driver regarding GRAY8 (Y800) videos. When you vaDeriveImage() with a surface from the failing video you get back an image with fourcc==Y800 (even though that format isn't returned by vaQueryImageFormats()). The only change I see needed to gstreamer-vaapi to work with this video is adding GRAY8 to all the caps. Some changes in vaapi/intel-driver will be required though, see: https://bugs.freedesktop.org/show_bug.cgi?id=94943
(In reply to Scott D Phillips from comment #1) > This behavior starts with the commit: > > 75a20de vaapidecode: Use video format derived from decoded surface as > default... > > That commit exposes some deficiencies in gstreamer-vaapi and > vaapi/intel-driver regarding GRAY8 (Y800) videos. When you vaDeriveImage() > with a surface from the failing video you get back an image with > fourcc==Y800 (even though that format isn't returned by > vaQueryImageFormats()). > > The only change I see needed to gstreamer-vaapi to work with this video is > adding GRAY8 to all the caps. Some changes in vaapi/intel-driver will be > required though, see: > > https://bugs.freedesktop.org/show_bug.cgi?id=94943 May be this could be the better option: https://bugzilla.gnome.org/show_bug.cgi?id=764607#c11
In my staging branch [1] I have a commit [2] which honours the negotiated color format and fixes this case, using vaapisink (memory:VASurface) because the color format is hidden by the VA surface. But, when linking to a ximagesink, the drivers tries to convert from GRAY8 to NV12 (which is the negotiated color format, because GRAY8 is not exposed in the caps template), and it fails: there is not a code path for this conversion in the intel driver. Though, I found a bug in my staging branch: it should not remove the requested surface format. I'm reworking it. My staging branch aims to fix bug 752958 in a sensible way. 1. https://github.com/ceyusa/gstreamer-vaapi/commits/staging 2. https://github.com/ceyusa/gstreamer-vaapi/commit/f39c7620
I have filed bug 765223 with the reworked patches from my staging branch related with the colour format negotiation. With those patches, this use case is fixed. Though, as I already said in comment #3, if instead of vaapisink, ximagesink is used, it still fails, since the Intel driver is not capable to perform colour conversions from GRAY8: 0:00:00.744320650 24719 0x813940 DEBUG vaapi gstvaapiutils.c:53:vaapi_check_status: vaGetImage(): the requested function is not implemented Neither the VA Images support that colour format, so it is not possible to map it. It is a dead-end alley. It has to be fixed in the driver.
I have pushed bug 765223, so this test case shall be fixed. Though, if we use ximagesink we get the typical assert in the libva-intel-driver jh gst-play-1.0 ~/patterns/bug765039.264 --videosink="videoconvert ! ximagesink" Press 'k' to see a list of keyboard shortcuts. Now playing /home/vjaquez/patterns/bug765039.264 libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/gnome/jh/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Redistribute latency... gst-play-1.0: i965_post_processing.c:6056: VAStatus i965_proc_picture(VADriverContextP, VAProfile, union codec_state *, struct hw_context *): Assertion `status == 0x00000000' failed. Aborted Because it doesn't have a color convert path for GRAY8, so either the driver is fixed or we support (and enforce) this color format for these cases.
@Fei can you re-test this use-case? in my opinion it is already fixed with the current master
@Victor, Use 8e7ebaa505a4a6554549d47c454d17a2eb31269a commit, this error disappear. And without any regression, all 168 cases pass. So close this bug.