GNOME Bugzilla – Bug 720970
Clips appear as half on display for Full Screen Video Playback using GST 1.0 on extended mode
Last modified: 2015-06-19 11:48:13 UTC
When I play video in fullscreen mode in vaapsink in extended display mode, the video will be become half size of the screen. The video not fit into the screen got shifted. (Any video format video clip also able to reproduce the issue). This issue don’t see using gstreamer-0.10 only happen on gstreamer-1.0. Gst_vaapisink_set_caps get call twice in gstreamer-1.0 But only get call in once in gstreamer-0.10. gst_vaapisink_ensure_window_size(sink, &win_width, &win_height); if (sink->window) { if (!sink->foreign_window || sink->fullscreen) gst_vaapi_window_set_size(sink->window, win_width, win_height); } else { gst_vaapi_display_lock(sink->display); gst_video_overlay_prepare_window_handle(GST_VIDEO_OVERLAY(sink)); gst_vaapi_display_unlock(sink->display); if (sink->window) return TRUE; if (!gst_vaapisink_ensure_window(sink, win_width, win_height)) return FALSE; gst_vaapi_window_set_fullscreen(sink->window, sink->fullscreen); gst_vaapi_window_show(sink->window); gst_vaapi_window_get_size(sink->window, &win_width, &win_height); } sink->window_width = win_width; sink->window_height = win_height; GST_DEBUG("window size %ux%u", win_width, win_height); return gst_vaapisink_ensure_render_rect(sink, win_width, win_height); Question: Looks like gst_vaapisink_ensure_window_size function will get full screen size of the framebuffer width and height. Or should be retrieve the display width and height thru the crtc? I still haven’t deep down go thru how GstVaapiDisplayPriv & GstVaapiDisplay working at here. In extended mode, that width will be primary width + secondary width . In vertical extended mode, that height will be primary height + secondary height. Current gstreamer-vaapi play in fullscreen for extended mode, is on 1 screen (primary display/ secondary display) or fullscreen mode here is for both display will be show out the video (mean half video in primary display and another half video in secondary display) ? gst_vaapi_window_get_size will retrieve correct window width and window height thru x11_get_geometry. The win_width and win_height pass thru the gst_vaapisink_ensure_render_rect will be using to calculate location destx and desty for video display output. Seeing this issue because the 2nd time gst_vaapisink_set_caps get call will be go thru if(sink->window). The win_width and win_height using pass thru gst_vaapsink_ensure_render_rect will be calculate wrong destx or desty. (depend in extended or vertical extended). In gstreamer-0.10 is only call 1 times gst_vaapisink_set_caps which will go thru else statement call gst_vaapi_window_get_size to retrieve correct win_width and win_height. Now I don’t idea how to get a proper fix for this issue right now. Quick and not proper fix could be just add gst_vaapi_window_get_size inside if(sink->window) statement to overwrite the win_width and win_height retrieve from gst_vaapisink_ensure_window_size. Can you guy provide me advice at here? I’m using gstreamer-vaapi from master branch recently code base. Command pipeline: gst-launch-1.0 -v filesrc location=/root/Videos/frog.mpg ! mpegpsdemux ! vaapidecode ! vaapisink fullscreen=true
Hi, I think you need a recent GStreamer 1.0 stack that contains mpeg2 video parser fixes. This rings a bell, but I cannot immediately know what specific changes. Does your issue also happen with an h264 video? The way the X11 renderer works (GstVaapiDisplayX11) is totally independent from any of the GStreamer stack (0.10, 1.0, or 1.2). So, behaviour should be consistent here and the only issue I was aware of was that videoparser issue for mpeg2 when we fixed the codecparser.
Hi, This issue able to reproduce using different video clip format. It only happen in extended display mode. I also saw this issue in h264 / VC1 /MPEG2 video clip. I remember the last i test try out using gst-launch-0.10 don't see this issue.
It is could be related to X11 renderer works. Because I don't see this issue in Tizen 3.0 IVI using weston. The issue that I submitted at here is tested using Fedora18 with X11.
Hi, I had a test with this in KDE environment(ubuntu 14.04). Connected the lap top with an external monitor and run gst-pipeline in full-screen mode (h264 video). Haven't seen any issues. Video is playing in full-screen mode in both screens.
Created attachment 279735 [details] ExtModeDisplay_videoDecodeOutput Able to see in 2nd display output, video playback in fullscreen mode, the output is shifted to left. It should be look like the output same as clone mode display output result.
Created attachment 279736 [details] CloneModeDisplay_videoDecodeOutput Correctly video decode rendering output result.
Hi, I'm still able to reproduce the issue in KDE environment Fedora18. Video decode output is shifted, can check with ExtModeDisplay_videoDecodeOutput image. Expecting the correct result should be same like CloneModeDisplay_videoDecodeOutput image. Already tested with FC18 in KDE environment, this issue still able reproduce. This issue only happen on gst-launch-1.0 not gst-launch-0.10. Enviroment setup in my system: Fedora 18 Kernel 3.8 (Gnome or KDE) Graphics Force Fallback mode: off libva 1.3.1 Intel VA driver 1.3.1 Gstreamer-1.2.3 gst-plugin-base-1.2.3 gst-plugin-bad-1.2.3 gst-plugin-good-1.2.3 gst-plugin-ugly-1.2.3 Gstreamer-vaapi 0.5.8
I have connected my laptop with an external monitor via mini_displayport-to-displayport and tested with a couple of combinations (with external monitor to the left, right and bottom of laptop screen) What I am getting is a consistent behavior for both software_decoder+renderer pipeline and hardware_decoder+renderer pipeline. -- fullscreen=true the video will render only in once screen (where my terminal is running) -- fullscreen=false , i can move the video-window back and forth or even play the video with half in first screen and second half in second screen. Again if I try to maximize the window (by clicking on the maximize button) it will just shift to only once screen. This is the same I am getting for avdec_h264+xvimagesink combination in software_decoder+renderer pipeline. I am no sure whether it is the intended behavior. If not, we need fix in both upstream gstreamer(xvimagesink) and gstreamer-vaapi. This might not be related with this, but in case If you try to test the vaapidecode+vaapisink pipeline with gst-launch, the winodow resize won't work at all since we are not handling the xwindow events in vaapisink if the winodow has been created by vaapisink itself .And this issue is tracked here: https://bugzilla.gnome.org/show_bug.cgi?id=711478.
If the second screen is in clone mode, I don't think there is any way to intervene from an application level. So, if both screens have the same resolution, I am not sure this is an application bug?
BTW, please try against 0.5.9 there is a patch to reconfigure the logical size against the real and current size of the window. Though, comment #9 holds. There is even support code to address a specific display/screen.
Closing this as Won't fix. Please feel free to re-open if needed.