GNOME Bugzilla – Bug 751623
vaapidecode: GstVideoGLTextureUploadMeta is not always configured
Last modified: 2016-07-27 14:01:41 UTC
Same pipeline (vaapidecode + glimagesink) results in GstVideoGLTextureUploadMeta being configured for some mp4 files but not for other mp4 files. GST_PLATFORM=glx GST_GL_WINDOW=x11 GST_GL_API=opengl GST_DEBUG=3,*vaapi*:5 gst-launch-1.0 -v filesrc location=/opt/video.mp4 ! qtdemux ! vaapidecode ! glimagesink In the successful configuration case, gst_vaapi_decode_update_src_caps is called twice. The second time (which includes GstVideoGLTextureUploadMeta) the function is called from gst_vaapi_decoder_state_changed) due to changed size height (from 360 to 368 pixels). Is it expected that this meta would be configured properly because of a size change? $ cat log-success | grep -i "new src caps" 0:00:00.222310443 3223 0x21f76d0 INFO vaapidecode gstvaapidecode.c:227:gst_vaapidecode_update_src_caps:<vaapidecode0> new src caps = video/x-raw, format=(string)I420, width=(int)480, height=(int)360, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)25/1 0:00:00.226220321 3223 0x21f76d0 INFO vaapidecode gstvaapidecode.c:227:gst_vaapidecode_update_src_caps:<vaapidecode0> new src caps = video/x-raw(meta:GstVideoGLTextureUploadMeta), format=(string)RGBA, width=(int)480, height=(int)368, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)25/1 In the file case where we don't get the meta (radeon or fglrx case), gst_vaapi_decode_update_src_caps is only called once, in the normal activation of the decoder (first gst_vaapidecode_handle_frame call). $ cat log-failure | grep -i "new src caps" 0:00:00.254439104 3242 0x20e56d0 INFO vaapidecode gstvaapidecode.c:227:gst_vaapidecode_update_src_caps:<vaapidecode0> new src caps = video/x-raw, format=(string)I420, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)bt709, framerate=(fraction)24/1 Is it possible that a reconfigure event is not properly set on a vaapidecode pad in the general case, and so it is only added coincidentally if there is another decode_state_changed reason? Or does the meta configuration really depend on some video caps or size? The 2 videos have different caps as you can see above. If gst_vaapi_decoder_state_changed/gst_vaapi_decode_update_src_caps is forced to be called unconditionally a second time, the GstVideoGLTextureUploadMeta meta is always added, but I am not sure if that's a safe thing to do. (Actually running with GstVideoGLTextureUploadMeta results in XBadDrawable or XBadPixMap erros on radeon/fglrx with api=opengl, but that is a subject for other tickets) All tests with current master. log of file with meta configuration: http://pastebin.com/qvSKmdyj log of file without meta configuration: http://pastebin.com/Q6LvMKZL Tested with ATI (radeon and fglrx), and intel cards (i915), logs are for radeon
Created attachment 306528 [details] [review] Always trigger decoder change and src caps update Not a real solution, only a workaround for always updating src caps. The meta is always added with this patch.
Sorry I didn't getit, Is it an issue only with ATI (not in intel platform) ?? The source caps needs to be updated only when there is an input caps change(width/height/framerate/pixel-aspect-ratio/interlrace-mode).. The update_src_caps needs be invoked (and eventually the GLTextureUploadMeta will get configured in src caps as required) only when any of the following happens -- if the configured output caps is different from what we get as query caps in decide_allocation -- any change in input caps parameter -- if decoder is not active while we reach handle_frame() Please share the sample file too...
thanks for the reply, (In reply to sreerenj from comment #2) > Sorry I didn't getit, Is it an issue only with ATI (not in intel platform) > ?? > > The source caps needs to be updated only when there is an input caps > change(width/height/framerate/pixel-aspect-ratio/interlrace-mode).. > > The update_src_caps needs be invoked (and eventually the GLTextureUploadMeta > will get configured in src caps as required) only when any of the following > happens > > -- if the configured output caps is different from what we get as query caps > in decide_allocation > -- any change in input caps parameter > -- if decoder is not active while we reach handle_frame() The last case (decoder not active) always happens, but the meta is never set o nthis first update_Src_caps call. Why does GLTextureUploadMeta configuration depend on input caps change (width/height/framerate/par etc.) ? Since it describes how to upload a buffer into an opengl texture, shouldn't it always be configured (during allocation or caps query) between vaapidecode + glimagesink elements? > > Please share the sample file too... Video 1 (radeon does not pick GLTextureUploadMeta, i915 stops with error) https://www.dropbox.com/s/56d8acp3d98q27h/nometa.mp4?dl=0 radeon: http://pastebin.com/LvqKp0BE i915: http://pastebin.com/kzJNWZTZ Video 2 (both radeon and i915 pick GLTextureUploadMeta) https://www.dropbox.com/s/or3z1k9ttagnnb3/meta.mp4?dl=0 radeon: http://pastebin.com/ZNqwH4dp i915: http://pastebin.com/tc7m9YbX (I think I had another video which was playing with both radeon and i915, and without configuring the meta in both cases. I 'll repost a new link if I find it) The overall goal is to see if using this meta will bring better performance for vaapidecode ! glimagesink pipeline.
Moving to Product:GStreamer, Component:gstreamer-vaapi
Resuming this issue: 1\ Nowadays the drivers that are not intel or gallium are blacklisted and considered as not supported 2\ I have just tested the samples with current master with intel's backend, and they work as expected (negotiating the texture upload meta). Thus closing this issue. Thanks for your patience.