GNOME Bugzilla – Bug 574290
[dshowvideosink] make set_xwindow_id() in PLAYING state work
Last modified: 2010-08-06 09:26:44 UTC
With the current version of dshowvideosink it's not possible to change the video-output-window via gst_x_overlay_set_xwindow_id() at running pipeline. Could this please be implemented?
Created attachment 156167 [details] [review] Fix gst_x_overlay_set_xwindow_id in PLAYING state This patch fixes updating window id when dshowvideosink is in PLAYING state.
Thanks for looking at this, but for me it only works one time. The second switch crashes. Can you switch the output windows back and forth?
Created attachment 156374 [details] [review] Fix gst_x_overlay_set_xwindow_id in PLAYING state I was able to reproduce the crashes, but for me it takes usually a lot more than two switches. With the attached patch I don't see any crashes in my application (I'm using gstreamer-java).
This works fine now, thank you very much! Only when switching to fullscreen i get "Changing caps at runtime is not yet supported". Any idea to solve this last problem too?
Bug 613346 has a patch that fixes updating video caps, which should fix the fullscreen problem: https://bugzilla.gnome.org/show_bug.cgi?id=613346
The patch looks good, but you need to close the original window if it's the one element created, something like: /* If we created a new window */ if (sink->is_new_window) { SendMessage (sink->window_id, WM_CLOSE, NULL, NULL); sink->is_new_window = FALSE; } I'll provide a patch in a few minutes.
Created attachment 166521 [details] [review] Rebase "Fix gst_x_overlay_set_xwindow_id in PLAYING state" Rebase original commit.
Created attachment 166522 [details] [review] Close our own window, if any, when we change to window id
Created attachment 166531 [details] [review] 0002-dshowvideosink-Close-our-own-window-when-changing-th Use "previous_window" instead of "sink->video_window" to send the WM_CLOSE message. I have tested these patches with longomatch omitting the "prepare-xwindow-id" in the player, so the sink creates a new window, and then setting the window id in the expose callback of the player's widget, which closes the created window and changes the window id properly.
Created attachment 166532 [details] [review] 0002-dshowvideosink-Close-our-own-window-when-changing-th Set sink->window_closed=FALSE after closing our window. The window has been closed, but a new one has been provided.
I'm not sure changing the window ID whilst in playing state is a particularly thing to do or support, but since it seems this is unlikely to break anything for people who don't do this, we may just as well commit it I guess. Please also note IRC comments below re. use of LONG_PTR / LONG etc. commit c2c32fe773aacfdcf823e6faf4a2327e6f997760 Author: Andoni Morales Alastruey <ylatuya@gmail.com> Date: Sun Jul 25 17:04:12 2010 +0200 dshowvideosink: close our own window when changing the window id If we created the window, it needs to be closed after setting a new window id. https://bugzilla.gnome.org/show_bug.cgi?id=574290 commit 7ab007bafeb5e3b32b0156235f51c1f4b4f442d9 Author: Raimo Jarvi <raimo.jarvi@gmail.com> Date: Sun Jul 25 17:01:19 2010 +0200 dshowvideosink: allow changing window ID whilst in PLAYING state https://bugzilla.gnome.org/show_bug.cgi?id=574290 <__tim> MikeS, any comments on https://bugzilla.gnome.org/show_bug.cgi?id=574290 ? <MikeS> __tim: it looks vaguely plausible, and doesn't look like it'd break anything that any sane user would ever do. <MikeS> (I have no idea why you'd ever want to call that in playing) ... <Mook_sb> random drive-by comment: please cast to LONG_PTR instead of LONG for the parameter of SetWindowLongPtr. Also, consider using SetWindowSubclass if you don't care about pre-XP. <MikeS> __tim: Mook_sb knows more about win32 than any sane person should; what he says is probably <__tim> Mook_sb, any chance you could put that into the bug? <Mook_sb> no, I just happen to occasionally be inside the crazy intersection of (gcc) and (win64)