回复：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_u
Locked
回复：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_u
 
|
I tried to look into bacon-video-widget.c and totem-object.c 1. bacon-video-widget.c is a clutter based backend for totem, it is possible to create other backend (follow the interface defined in bacon-video-widget.h); right? the backend should subclass from GtkWidget and implement the interface defined in bacon-video-widget.h. for example, we can implement another backend to render video directly to native window, like xvimagesink or waylandsink. the custom GtkWidget could be a GtkContainer which includes a GtkDrawing area for video rendering and some other buttons for control. here, I have some question against current Gtk/Gdk implementation. a GtkWidget/GdkWindow maps to a native window like XWindow/wl_surface, right? (GtkWidget isn't like ClutterActor to share the same XWindow/wl_surface for all the Actor of the same Stage, right?) 2. we can also implement another backend basing on gtkglsink to render video as texture. since gtkglsink draw video to the GtkGlArea, which is also a GtkWidget; what's the advantage comparing to rendering video directly to XWindow/wl_surface as xvimagesink/waylandsink does? Is it possible to draw controls on top of the video(GtkGlArea)? like some controls are drawn as ClutterActor on top of video. -------------------------------- ----- 原始邮件 ----- 发件人：Matthew Waters <[hidden email]> 收件人：[hidden email], Discussion of the development of and with GStreamer <[hidden email]> 主题：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_used_instead? 日期：2019年09月15日 08点40分 You can probably do that for
wayland-specific things however X11 is still used by people as
well as the cross-platform concerns for MacOS or windows that one
wouldn't want to preclude by relying specifically on wayland.
Also, resizes with wayland subsurfaces are somewhat tricky to keep synchronised and require extra API. Cheers -Matt On 12/9/19 10:16 am, HalleyZhao wrote:
gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: 回复：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_u
|
|
Le jeudi 19 septembre 2019 à 19:22 +0800, HalleyZhao a écrit :
> > I tried to look into bacon-video-widget.c and totem-object.c > > 1. bacon-video-widget.c is a clutter based backend for totem, it is possible to create other backend (follow the interface defined in bacon-video-widget.h); right? > the backend should subclass from GtkWidget and implement the interface defined in bacon-video-widget.h. > for example, we can implement another backend to render video directly to native window, like xvimagesink or waylandsink. the custom GtkWidget could be a GtkContainer which includes a GtkDrawing area for video rendering and some other buttons for control. > here, I have some question against current Gtk/Gdk implementation. a GtkWidget/GdkWindow maps to a native window like XWindow/wl_surface, right? > (GtkWidget isn't like ClutterActor to share the same XWindow/wl_surface for all the Actor of the same Stage, right?) > > 2. we can also implement another backend basing on gtkglsink to render video as texture. > since gtkglsink draw video to the GtkGlArea, which is also a GtkWidget; what's the advantage comparing to rendering video directly to XWindow/wl_surface as xvimagesink/waylandsink does? > Is it possible to draw controls on top of the video(GtkGlArea)? like some controls are drawn as ClutterActor on top of video. Be aware that GtkGLArea renders to CPU and it's final composition is done in software using cairo. I don't really have an windows manager agnostic solution to propose appart from moving to GTK4 as soon as it's ready. Meanwhile, one could expriment with alpha enabled window and underlays (locking another windows, or sub-surface in wayland, under the existing window and using the alpha channel to punch through). regards, Nicolas > > -------------------------------- > > > ----- 原始邮件 ----- > 发件人：Matthew Waters <[hidden email]> > 收件人：[hidden email], Discussion of the development of and with GStreamer <[hidden email]> > 主题：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_used_instead? > 日期：2019年09月15日 08点40分 > > You can probably do that for wayland-specific things however X11 is still used by people as well as the cross-platform concerns for MacOS or windows that one wouldn't want to preclude by relying specifically on wayland. > > Also, resizes with wayland subsurfaces are somewhat tricky to keep synchronised and require extra API. > > Cheers > -Matt > > On 12/9/19 10:16 am, HalleyZhao wrote: > > thanks Matthew。 > > > > I know little about totem/gtk3, just wonder why not use waylandsink to render video directly to a wl_surface/wl_sub_surface. > > it means to create a gtk widget which associates with a wl_sub_surface, it is a child of the main window but skip gl composition inside app. > > > > for a dedicated video player app, texture video is just the favor of developer, not the interest of end-user. > > > > > > -------------------------------- > > > > > > ----- 原始邮件 ----- > > 发件人：Matthew Waters <[hidden email]> > > 收件人：[hidden email], Discussion of the development of and with GStreamer <[hidden email]> > > 主题：Re: if we plan to remove TEXTURE_UPLOAD, what will be used instead? > > 日期：2019年09月11日 17点10分 > > > > Hi, > > > > 1. clutter is effectively unmaintained and is really the only major user of the gl upload meta so the first move is to remove the clutter dependency inside totem. There are replacement Gtk sink elements (gtkglsink and gtksink) for Gtk3 that can be used. For Gtk4, the equivalent elements would need to written. > > 2. The general case for OpenGL within a Gstreamer context is to use the libgstgl-1.0 library and the associated elements (glupload, glcolorconvert, etc). One can pass OpenGL textures between elements using GstGLMemory with much more information than was ever possible with the upload meta. Currently libgstgl does include a upload meta implementation however that implementation will only be used if nothing else is found (except for upload from system memory). > > > > Cheers > > -Matt > > > > On 11/9/19 6:24 pm, HalleyZhao wrote: > > > Hi experts: > > > from the following thread, I notice that community plans to remove TEXTURE_UPLOAD/GstGLUploadTextureMeta. > > > then what will be used instead? > > > take totem as example, it is problemtic to use clutter-sink with hardware accerelated decoder. > > > then what's the decent way to render video in totem? > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/137 > > > Maintainer > > > > TEXTURE_UPLOAD as deprecated for next gst 1.18 > > > > > > > > > > TEXTURE_UPLOAD is planned to be removed for 2.0 > > > > > > I removed TEXTURE_UPLOAD support in Wayland from gstreamer-vaapi for release 1.14, if I recall correctly, but for Canonical it was a regression, and Daniel van Vught devoted a lot of time to make it work, but as we confirm now, only for Intel's driver. > > > > > > We are devoting a lot of time supporting a deprecated transfer mechanism because people demand it. Every time I think about it, I realized that I have said "no" when Daniel pushed for it. > > > > > > -------------------------------- > > > > > > > > > _______________________________________________ > > > gstreamer-devel mailing list > > > [hidden email] > > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: 回复：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_u
|
|
In reply to this post by HalleyZhao
Did you check gtksink and gtkglsink?
vmjl On Thu, 19 Sep 2019 at 19:22, HalleyZhao wrote: > > I tried to look into bacon-video-widget.c and totem-object.c1. bacon-video-widget.c is a clutter based backend for totem, it is possible to create other backend (follow the interface defined in bacon-video-widget.h); right?the backend should subclass from GtkWidget and implement the interface defined in bacon-video-widget.h.for example, we can implement another backend to render video directly to native window, like xvimagesink or waylandsink. the custom GtkWidget could be a GtkContainer which includes a GtkDrawing area for video rendering and some other buttons for control.here, I have some question against current Gtk/Gdk implementation. a GtkWidget/GdkWindow maps to a native window like XWindow/wl_surface, right? (GtkWidget isn't like ClutterActor to share the same XWindow/wl_surface for all the Actor of the same Stage, right?)2. we can also implement another backend basing on gtkglsink to render video as texture.since gtkglsink draw video to the GtkGlArea, which is also a GtkWidget; what's the advantage comparing to rendering video directly to XWindow/wl_surface as xvimagesink/waylandsink does?Is it possible to draw controls on top of the video(GtkGlArea)? like some controls are drawn as ClutterActor on top of video. > -------------------------------- > > > ----- 原始邮件 ----- > 发件人：Matthew Waters <[hidden email]> > 收件人：[hidden email], Discussion of the development of and with GStreamer <[hidden email]> > 主题：Re: 回复：Re: if we plan to remove TEXTURE_UPLOAD,_what_will_be_used_instead? > 日期：2019年09月15日 08点40分 > > > You can probably do that for > wayland-specific things however X11 is still used by people as > well as the cross-platform concerns for MacOS or windows that one > wouldn't want to preclude by relying specifically on wayland. > > > Also, resizes with wayland subsurfaces are somewhat tricky to keep > synchronised and require extra API. > > > Cheers > > -Matt > > > On 12/9/19 10:16 am, HalleyZhao wrote: > > > thanks Matthew。 > > > I know little about totem/gtk3, just wonder why not use > waylandsink to render video directly to a > wl_surface/wl_sub_surface. > it means to create a gtk widget which associates with a > wl_sub_surface, it is a child of the main window but skip gl > composition inside app. > > > for a dedicated video player app, texture video is just the > favor of developer, not the interest of end-user. > > > -------------------------------- > > > > > > ----- 原始邮件 ----- > > 发件人：Matthew Waters <[hidden email]> > > 收件人：[hidden email], Discussion of the development of and > with GStreamer <[hidden email]> > > 主题：Re: if we plan to remove TEXTURE_UPLOAD, what will be used > instead? > > 日期：2019年09月11日 17点10分 > > > Hi, > > > 1. clutter is effectively unmaintained and is really the only > major user of the gl upload meta so the first move is to > remove the clutter dependency inside totem. There are > replacement Gtk sink elements (gtkglsink and gtksink) for Gtk3 > that can be used. For Gtk4, the equivalent elements would > need to written. > > 2. The general case for OpenGL within a Gstreamer context is > to use the libgstgl-1.0 library and the associated elements > (glupload, glcolorconvert, etc). One can pass OpenGL textures > between elements using GstGLMemory with much more information > than was ever possible with the upload meta. Currently > libgstgl does include a upload meta implementation however > that implementation will only be used if nothing else is found > (except for upload from system memory). > > > Cheers > > -Matt > > > On 11/9/19 6:24 pm, HalleyZhao wrote: > > > Hi experts: > from the following thread, I notice that community plans > to remove TEXTURE_UPLOAD/GstGLUploadTextureMeta. > then what will be used instead? > take totem as example, it is problemtic to use > clutter-sink with hardware accerelated decoder. > then what's the decent way to render video in totem? > > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/137 > > Maintainer > > > > > > TEXTURE_UPLOAD > as deprecated for next gst 1.18 > > TEXTURE_UPLOAD is planned to be removed for > 2.0 > I removed TEXTURE_UPLOAD support in Wayland > from gstreamer-vaapi for release 1.14, if I recall > correctly, but for Canonical it was a regression, and > Daniel van Vught devoted a lot of time to make it > work, but as we confirm now, only for Intel's driver. > We are > devoting a lot of time supporting a deprecated > transfer mechanism because people demand it. Every > time I think about it, I realized that I have said > "no" when Daniel pushed for it. > > > > > > -------------------------------- > > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |