GNOME Bugzilla – Bug 789476
vaapi plugins: append allocator in allocation query
Last modified: 2018-03-01 23:54:43 UTC
$ gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, format=(string)NV12, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive" ! gdppay ! filesink location=test.nv12 $ gst-launch-1.0 filesrc location=nv12.gdp ! gdpdepay ! imagefreeze ! vaapisink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ** (gst-launch-1.0:8183): CRITICAL **: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx1"; Caught SIGSEGV Spinning. Please run 'gdb gst-launch-1.0 8183' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Obviously test.nv12 should read nv12.gdp in the first pipeline, sorry.
The problem is not vaapisink, but gdpdepay: it assumes that downstream allocator always use the virtual alloc method, and that's not true. Thus, when requesting a new buffer, it got NULL and then a segmentation fault.
Created attachment 367571 [details] [review] gdpdepay: don't allocate query if caps are ANY When querying downstream for allocation, and the source caps hasn't set a caps, using ANY by default, it raises a critical message in console: CRITICAL **: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed This patch bails out the decide_allocation() if the caps are still ANY.
Created attachment 367572 [details] [review] gdpdepay: don't use allocator if it has custom alloc gdpdepay element uses the decide_allocation to fetch the downstream allocator. Nonetheless it is possible that allocate uses a custom alloc function, which is not usable by gdpdepay, crashing later the application when the allocater buffer is NULL. This patch checks for the allocator flags and reset it if the allocator has a custom alloc function.
Review of attachment 367572 [details] [review]: Seems correct.
Tested here, works great.
Created attachment 367691 [details] [review] gdpdepay: don't allocation query if caps aren't fixed When querying downstream for allocation, and the source caps hasn't set its caps, using ANY by default, it raises a critical message in console: CRITICAL **: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed This patch bails out decide_allocation() if the caps aren't fixed.
Created attachment 367692 [details] [review] gdpdepay: don't use allocator if it has custom alloc gdpdepay element uses the decide_allocation to fetch the downstream allocator. Nonetheless it is possible that allocate uses a custom alloc function, which is not usable by gdpdepay, crashing later the application when the allocater buffer is NULL. This patch checks for the allocator flags and reset it if the allocator has a custom alloc function.
Attachment 367691 [details] pushed as f04b20e - gdpdepay: don't allocation query if caps aren't fixed Attachment 367692 [details] pushed as f6cb16a - gdpdepay: don't use allocator if it has custom alloc
for branch 1.12 * b8ef897d0 gdpdepay: don't use allocator if it has custom alloc * 198b3703e gdpdepay: don't allocation query if caps aren't fixed
This patch is really horrible. Can't you just not return this custom allocator in the allocation query if you can't use it anyway?
Other elements upstream could potentially understand that custom allocator and do something meaningful with it. IIRC the idea is that if you only have a custom allocator (that does not work normally, like this one here) to return, you *first* put the sysmem allocator in the query response... and only afterwards the custom one. The first allocator in the query response must always be sysmem/etc compatible unless custom caps features are negotiated.
My apology, I totally failed to notice the context of this. Indeed, without caps feature, first allocator cannot be custom. Even the second being custom is probably not the best idea.
D'accord. What would be plan then? If I understand correctly, it would be 1. Revert this patch 2. Change the summary of this bug and reassign it to gstreamer-vaapi 3. Now gstreamer-vaapi should set three) allocators in the propose_allocation()'s query, if the upstream negotiated caps is raw video: system's, dmabuf and the vaapi one. 4. but my question is how the vaapi buffer pool will know which allocator will use when at set_config() ???
According to bufferpool.md > The allocation query can also return an allocator object when the buffers are > of different sizes and can't be allocated from a pool. So, the simplest approach is NOT sharing any allocator in the allocation query from the gstremaer-vaapi perspective.
V4L side seems to hardcore it's allocator internally.
Created attachment 367959 [details] [review] plugins: don't share allocator in query VA-API allocator uses a custom alloc function, which only can be used by VA-API elements which know the API. When an allocator is shared, it must behaive as the system allocator so other elements could use it. Otherwise, to share it doesn't make sense. This patch remove the VA-API allocator sharing.
I disagree with this change. Sharing the allocator can be useful for elements that actually understand VAAPI. But you must not put it as the first allocator, the first allocator always must be sysmem compatible.
Created attachment 367974 [details] [review] vaapivideomemory: remove unused macro GST_VAAPI_VIDEO_ALLOCATOR_NAME was added in commit 5b11b8332 but it was never used, since the native VA-API allocator name has been GST_VAAPI_VIDEO_MEMORY_NAME. This patch removes GST_VAAPI_VIDEO_ALLOCATOR_NAME macro.
Created attachment 367975 [details] [review] plugins: handle vaapi allocator in allocation query In propose_allocation() if the numer of allocation params is zero, the system's allocator is added first, and lastly the native VA-API allocator. In decide_allocation(), the allocations params in query are travered, looking for a native VA-API allocator. If it is found, it is reused as src pad allocator. Otherwise, a new allocator is instantiated and appended in the query.
Created attachment 368131 [details] [review] plugins: handle vaapi allocator in allocation query In propose_allocation() if the numer of allocation params is zero, the system's allocator is added first, and lastly the native VA-API allocator. In decide_allocation(), the allocations params in query are travered, looking for a native VA-API allocator. If it is found, it is reused as src pad allocator. Otherwise, a new allocator is instantiated and appended in the query.
Attachment 367974 [details] pushed as 8855a92 - vaapivideomemory: remove unused macro Attachment 368131 [details] pushed as 4481055 - plugins: handle vaapi allocator in allocation query
gdpdepay commits were also reverted
branch 1.12 * c0826fdc plugins: handle vaapi allocator in allocation query * b31b773a vaapivideomemory: remove unused macro
This commit breaks vaapipostproc: gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx ! vaapipostproc ! video/x-raw,format=NV12 ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1"; Caught SIGSEGV
(In reply to Tomas Rataj from comment #25) > This commit breaks vaapipostproc: > > gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx ! vaapipostproc ! > video/x-raw,format=NV12 ! fakesink > > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, > gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; > Got context from element 'vaapipostproc0': gst.vaapi.Display=context, > gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ > vaapidisplaydrm1"; > Caught SIGSEGV Hi Tomas, What backend are you using? libva version? Why DRM display is used? Can you upload the backtrace?
GstVideoInfo * old in gst_video_info_changed is NULL. ==11868== Thread 4 videotestsrc0:sr: ==11868== Invalid read of size 8 ==11868== at 0x7E745B0: gst_video_info_changed (gstvaapipluginutil.c:754) ==11868== by 0x7E7EA60: gst_vaapi_video_buffer_pool_set_config (gstvaapivideobufferpool.c:174) ==11868== by 0x4E79D01: gst_buffer_pool_set_config (gstbufferpool.c:687) ==11868== by 0x7C279C3: gst_base_src_decide_allocation_default (gstbasesrc.c:3071) ==11868== by 0x776FC61: gst_video_test_src_decide_allocation (gstvideotestsrc.c:860) ==11868== by 0x7C2BC7F: gst_base_src_prepare_allocation (gstbasesrc.c:3134) ==11868== by 0x7C2BC7F: gst_base_src_negotiate (gstbasesrc.c:3272) ==11868== by 0x7C2BC7F: gst_base_src_loop (gstbasesrc.c:2691) ==11868== by 0x4EDEB88: gst_task_func (gsttask.c:335) ==11868== by 0x563800F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.3) ==11868== by 0x5637644: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.3) ==11868== by 0x5CEC519: start_thread (pthread_create.c:465) ==11868== by 0x5FF83EE: clone (clone.S:95) ==11868== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==11868== Caught SIGSEGV libva info: VA-API version 1.0.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_0 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.0 (libva 2.0.0) vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.0.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD
Created attachment 369166 [details] [review] vaapivideobufferpool: fix regression The allocator in the config may be not VAAPI (videotestsrc, for example) and it will not have a video info configuration.
pushed for branch 1.12: * c00b35fe vaapivideobufferpool: fix regression