GNOME Bugzilla – Bug 786954
gst-validate scenarios case fail on DRM mode.
Last modified: 2017-09-01 20:51:39 UTC
By using gst-validate, some scenarios case fail: cmdline: gst-validate-launcher vaapi -t validate.file.playback.seek_forward.raw_video_mov fail case: validate.file.playback.seek_forward.raw_video_mov validate.file.playback.seek_forward.raw_video_mkv validate.file*.vorbis_vp8_1_webm error log can find in attach.
Created attachment 358649 [details] fail log
additional information: these case all pass on X mode.
You can also reproduce this with detail cmdline by using attach media. For example: DRM mode fail cmd: #GST_VALIDATE_SCENARIO='seek_forward' GST_GL_XINITTHREADS='1' /usr/bin/gst-validate-1.0 playbin uri=file:///root/raw_video.mov X mode pass cmd: #GST_VALIDATE_SCENARIO='seek_forward' GST_GL_XINITTHREADS='1' DISPLAY=':0.0' /usr/bin/gst-validate-1.0 playbin uri=file:///root/raw_video.mov
(In reply to Fei from comment #3) > You can also reproduce this with detail cmdline by using attach media. For > example: > > DRM mode fail cmd: > #GST_VALIDATE_SCENARIO='seek_forward' GST_GL_XINITTHREADS='1' > /usr/bin/gst-validate-1.0 playbin uri=file:///root/raw_video.mov > > X mode pass cmd: > #GST_VALIDATE_SCENARIO='seek_forward' GST_GL_XINITTHREADS='1' DISPLAY=':0.0' > /usr/bin/gst-validate-1.0 playbin uri=file:///root/raw_video.mov media upload failed for file size limitation, share it with goole drive: https://drive.google.com/drive/folders/0B-M3YNi0HORQbGpsd2JNWWVBeGc?usp=sharing
Easy way to reproduce the issue : gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy width=320 height=240 framerate=30/1 ! vaapisink display=drm Here the problem is that gst_vaapisink_set_caps() always return TRUE for drm display type with out even setting the plugin caps, pool and other attributes. Then in the render frame routine vaapisink trying to copy the raw data from input buffer to a va_surface backed sink buffer through gst_vaapi_plugin_base_get_input_buffer() which is obviously going to fail since we haven't created the sinkpad pool yet. We usually don't hit this issue since even for drm use case the pool is shared between upstream element and vaapisink (eg: decodebin ! vaapisink display=drm). This particular test case is different since there is no pool shared between the upstream element and vaapisink and eventually we have to copy the incoming raw data buffer to vaapisink buffer from the pool. Either we can just return from sink render function for drm display type or make sure that all sink attributes including caps, pool etc set in set_caps().
Created attachment 358796 [details] [review] vaapisink: fix rendering use case in drm display type
Review of attachment 358796 [details] [review]: Just a question, besides that it lgtm. ::: gst/vaapi/gstvaapisink.c @@ +1343,2 @@ gst_vaapisink_ensure_colorbalance (sink); gst_vaapisink_ensure_rotation (sink, FALSE); Is it required to ensure display's color-balance and rotation before bail out?
Review of attachment 358796 [details] [review]: Verified this fixes it for me. Thanks!
(In reply to Víctor Manuel Jáquez Leal from comment #7) > Review of attachment 358796 [details] [review] [review]: > > Just a question, besides that it lgtm. > > ::: gst/vaapi/gstvaapisink.c > @@ +1343,2 @@ > gst_vaapisink_ensure_colorbalance (sink); > gst_vaapisink_ensure_rotation (sink, FALSE); > > Is it required to ensure display's color-balance and rotation before bail > out? Ideally not, we invoke them in render_frame routine too. But I think it is better to follow the same code path for all display servers except that drm won't be doing any "rendering" by itself so that the structure attributes will show correct values even if it is not using anywhere.
Review of attachment 358796 [details] [review]: Pushed as commit 782184e7813ff4cd402bec0e556ce1f4d1187220