[Bug 753591] [encoders] implement "direct-uploading"

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Oct 18 17:01:00 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=753591

--- Comment #2 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
Right now, disabling USE_NATIVE_FORMATS, the usage of vaDeriveImage is
activated:

diff --git a/gst/vaapi/gstvaapivideomemory.c b/gst/vaapi/gstvaapivideomemory.c
index 3b2b4d8..271b738 100644
--- a/gst/vaapi/gstvaapivideomemory.c
+++ b/gst/vaapi/gstvaapivideomemory.c
@@ -37,7 +37,7 @@ GST_DEBUG_CATEGORY_STATIC (gst_debug_vaapivideomemory);
 #endif

 /* Defined if native VA surface formats are preferred over direct rendering */
-#define USE_NATIVE_FORMATS 1
+#define USE_NATIVE_FORMATS 0

 /* ------------------------------------------------------------------------ */
 /* --- GstVaapiVideoMemory                                              --- */


Nonetheless, right now it only works for some streams when only using
vaapi<codec>dec (in other words, disabling vaapipostproc and vaapidecodebin).

Some streams are not rendered correctly because of the difference of caps
negotiation and allocation caps. In this case the negotiation caps seems to be
the same as the negotiation caps.

When vaapipostproc is enabled, all fails. It seems that our logic of direct
rendering is not valid for the case of vaapipostroc.

*In the case of encoding*  (videotestsrc ! vaapih264enc) I got this error log:

0:00:51.658394439 27976       0x81b4a0 DEBUG                  vaapi
gstvaapiencoder_objects.c:517:gst_vaapi_enc_picture_encode: encode picture
0x04000009
0:00:51.658423732 27976       0x81b4a0 DEBUG                  vaapi
gstvaapiutils.c:53:vaapi_check_status: vaBeginPicture(): surface is in use
0:00:51.658450228 27976       0x81b4a0 ERROR                  vaapi
gstvaapiencoder.c:347:gst_vaapi_encoder_put_frame: failed to encode frame
(status = -1)
0:00:51.658487580 27976       0x81b4a0 ERROR            vaapiencode
gstvaapiencode.c:558:gst_vaapiencode_handle_frame: failed to encode frame 0
(status -1)

This is interesting, since the upstream element could map the derived image
correctly and copy the data into it. But when the encoder encodes, it cannot
read the input surface.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list