GNOME Bugzilla – Bug 734665
vaapipostproc with BGRx input format doesn't work
Last modified: 2015-01-28 09:13:58 UTC
I want to use vaapipostproc to convert BGRx to NV12 format which can be used by vaapiencode_h264. 'gst-inspect-1.0 vaapiposproc' tells me that it understands BGRx at the sink pad. Now I've tried the following pipeline: $ gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx,width=800,height=600 ! vaapipostproc ! fakesink libva info: VA-API version 0.35.1 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_0_35 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapipostproc0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: streaming task paused, reason error (-5) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... It doesn't work. If I try with YUV input, the pipeline works: $ gst-launch-1.0 videotestsrc ! video/x-raw,format=YUY2,width=800,height=600 ! vaapipostproc ! fakesink libva info: VA-API version 0.35.1 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_0_35 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapipostproc0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:01.936353746 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... This works.
I can see in gst_vaapi_plugin_base_get_input_buffer() that there is the following check: if (!GST_VIDEO_INFO_IS_YUV (&plugin->sinkpad_info)) goto error_invalid_buffer; So here it fails, if I have an BGRx buffer.
Hi, (In reply to comment #1) > I can see in gst_vaapi_plugin_base_get_input_buffer() that there is the > following check: > > if (!GST_VIDEO_INFO_IS_YUV (&plugin->sinkpad_info)) > goto error_invalid_buffer; > > So here it fails, if I have an BGRx buffer. Thanks for investigating this. I have fixed a couple more bugs. Would you mind testing the following: https://github.com/gbeauchesne/gstreamer-vaapi/ ("vpp.fixes" branch)? Tested as: $ gst-launch-1.0 -v videotestsrc ! video/x-raw,format=BGRx ! vaapipostproc ! vaapisink $ gst-launch-1.0 -v videotestsrc ! video/x-raw,format=BGRx ! vaapisink
commit 7e9ac1cb980eb441c0669d81d2ca2f9a1f698d80 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Wed Aug 20 11:43:08 2014 +0200 plugins: fix detection of raw video caps. Use the new gst_caps_has_vaapi_surface() helper function to better detect raw video caps, and in particular those from RGB colorspace. https://bugzilla.gnome.org/show_bug.cgi?id=734665
Reopened this bug because with the commit 493337c4b154a789b5f5e9d86f95b4015d07b57e the pipeline does not work anymore. Also the following pipeline should work because vaapiencode_h264 reports to understand BGRx at the input: gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx,width=800,height=600 ! vaapiencode_h264 ! fakesink This also does not work.
Hi, (In reply to comment #4) > Reopened this bug because with the commit > 493337c4b154a789b5f5e9d86f95b4015d07b57e the pipeline does not work anymore. > Also the following pipeline should work because vaapiencode_h264 reports to > understand BGRx at the input: > gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx,width=800,height=600 ! > vaapiencode_h264 ! fakesink > This also does not work. Sorry for getting back to you late but if you are trying on Ivybridge or Hasell, you need to upgrade your libva-intel-driver to the current git master branch. The patch of interest was committed in earlier in September as commit 8d20776. Unfortunately, this hasn't reached an official release yet. Do you confirm that this works for you with the above mentioned patch? Thanks. Locally tested here at home on Ivybridge.
I've tested it with the git master of today from gstreamer-vaapi, libav and intel-driver. But I can't get the pipeline running: gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx,width=800,height=600 ! vaapiencode_h264 ! fakesink Setting pipeline to PAUSED ... libva info: VA-API version 0.36.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_36 libva info: va_openDriver() returns 0 Pipeline is PREROLLING ... Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; ERROR: from element /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: GStreamer error: negotiation problem. Additional debug info: gstvideoencoder.c(1474): gst_video_encoder_chain (): /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: encoder not initialized ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... It was tested on a Intel(R) Core(TM) i5-3550S CPU @ 3.00GHz (Ivybridge)
(In reply to comment #6) > I've tested it with the git master of today from gstreamer-vaapi, libav and > intel-driver. But I can't get the pipeline running: > > gst-launch-1.0 videotestsrc ! video/x-raw,format=BGRx,width=800,height=600 ! > vaapiencode_h264 ! fakesink > Setting pipeline to PAUSED ... > libva info: VA-API version 0.36.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_36 > libva info: va_openDriver() returns 0 > Pipeline is PREROLLING ... > Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, > display=(GstVaapiDisplay)NULL; > ERROR: from element > /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: GStreamer error: > negotiation problem. > Additional debug info: > gstvideoencoder.c(1474): gst_video_encoder_chain (): > /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: > encoder not initialized > ERROR: pipeline doesn't want to preroll. > Setting pipeline to NULL ... > Freeing pipeline ... > > It was tested on a Intel(R) Core(TM) i5-3550S CPU @ 3.00GHz (Ivybridge) Thanks for your feedback, there are actually a couple of issues: 1. vaapiencode_* element will only accept VA surfaces in "native" format, i.e. generally NV12 on Intel HD Graphics hardware. If you want to support other formats, they need to be converted to NV12 first. So, an easy way to do that is to simply insert a vaapipostproc element before vaapiencode_*. 2. The vaapipostproc element however would not submit proper framerate caps on the src pad, which are required for encoding. I will prepare a patch for that. 3. On the Intel VA driver side, there are also additional fixes to make, most notably to correctly reports RGBx chroma formats for VPP purposes. I will prepare a patch for that too, but that one should matter to use as gstreamer-vaapi is not strictly checking the underlying capabilities it seems. This means, I will probably have to strengthen this check too.
Created attachment 290909 [details] [review] plugins: preserve framerate when updating src caps video format This is a fix to (1). There may be other occurrences that I have not fully analyzed yet. Though, you should get unlocked for ! vaapipostproc ! vaapiencode_h264 pipelines.
(In reply to comment #8) > Created an attachment (id=290909) [details] [review] > plugins: preserve framerate when updating src caps video format > > This is a fix to (1). There may be other occurrences that I have not fully > analyzed yet. Though, you should get unlocked for ! vaapipostproc ! > vaapiencode_h264 pipelines. to (2) actually. :)
commit a4d88db0fdf208bb5c999cf2cca2742993b17cd8 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Tue Nov 18 14:57:02 2014 +0100 plugins: preserve framerate when updating src caps video format. In the current implementation, gst_video_info_set_format() would reset the whole GstVideoInfo structure first, prior to setting video format and size. So, coleteral information like framerate or pixel-aspect- ratio are lost. Provide and use a unique gst_video_info_change_format() for overcome this issue, i.e. only have it change the format and video size, and copy over the rest of the fields. https://bugzilla.gnome.org/show_bug.cgi?id=734665
Lets close this bug then.. Thomas, Could you please try the current git master? I can't reproduce this issue any more,,
Closing this for now, please feel free to re-open if the issue persists.