GNOME Bugzilla – Bug 171916
[PATCH] zoom in videos
Last modified: 2008-12-01 16:13:41 UTC
Distribution/Version: Debian It would be nice if totem would allow to zoom in the video. I have a 16:10 display and if i watch videos which have black borders i want to be able to cut them away
Upgrade your Totem, this is already in since version 0.100. *** This bug has been marked as a duplicate of 144929 ***
I use totem-gstreamer from debian unstable, version is 0.100 and neither r/t nor w/e does work
It's not implemented in the GStreamer backend (you didn't mention which one you were using).
Gstreamer has 2 plugins (videocrop, videoscale) that would allow such operation
I'm aware of them, as you would probably expect, but didn't have time to implement it yet. A patch would help a lot.
Created attachment 39846 [details] [review] Patch to add "zooming" - function This patch crops top and bottom from the video so you view without black bars.
This patch has two problems: A) it adds videocrop to totem instead of playbin B) videocrop is currently I420-only I'd like to fix both issues before committing.
Ok, i make a patch against playbin which adds a new property "zoom" and patch totem to use it. concerning videocrop, i don't know of a good way to handle both rgb and yuv-caps. i think of making the element videofilter-based. but croping of rgb is even simpler then yuv
Yes, making it videofilter based is the best solution. Regarding colorspaces, supporting 15-, 16-, 24-, 32- bits RGB and I420/YUY2 YUV should be enough for now. I know it's a lot already, but well, we have a lot of video outputs so we really need this. If you want to do it, please go for it. If not, I'll happily do the work required to make a videofilter-derived videocrop.
Ok, this makes sense. I've redone the now fairly trivial patch for totem and working at the required modifications for playbin. For the modifications in playbin i'll file a new bug against gst-plugins. feel free to begin the new videocrop element, i'll see if i have time after playbin
Created attachment 45459 [details] [review] New Patch against totem Right now untested and needs modificated playbin which will be filed in a seperate bug
So, Christoph, you will use the current videocrop? Please do file this bug as dependent on the gst-plugins bug btw, so I can keep track of stuff. :). Thanks.
Christoph, did you ever file a bug against gst-plugins?
*** Bug 334921 has been marked as a duplicate of this bug. ***
Tim, would you mind looking at that for the 0.10 backend?
*** Bug 352880 has been marked as a duplicate of this bug. ***
*** Bug 333405 has been marked as a duplicate of this bug. ***
*** Bug 360631 has been marked as a duplicate of this bug. ***
If both GStreamer and xine-lib implement zooming, the calls to bacon_video_widget_can_set_zoom should be removed, as well as the implementations of bacon_video_widget_can_set_zoom as well.
Tim, btw, are the playbin changes necessary for this in a release yet?
> Tim, btw, are the playbin changes necessary for this in a release yet? Nope. Videocrop itself is mostly ready (lacking some fixes for packed yuv formats, but I've got those locally), but hasn't been moved to -good yet. The main issue is renegotiation (ie. changing the cropping) during playback which is probably caused by something somewhere in GStreamer core (basetransform, or something else, no idea). Haven't had time to track it down yet. Should probably file a bug about this :) ~/gst-plugins-bad/tests/icles/test-videocrop demonstrates this issue sometimes (about one out of three times for me).
Tim, now that videocrop has been moved to -good, does this mean the above is fixed? If so, we can remove the conditionals about supporting zooming, and integrate it before 2.20.
I've implemented this the other day, but there are still some racy caps negotiation issues that need fixing/figuring out on the GStreamer side before it can go in. Ideally we'd implement this in the videosinks directly somehow, e.g. via an interface or though.
*** Bug 518165 has been marked as a duplicate of this bug. ***
Created attachment 121780 [details] [review] zoom by resizing the video_window How about this patch until a proper solution arrives in GStreamer? It implements the zoom function by simply also multiplying by the zoom factor when calculating the resize ratio for video_window (the GdkWindow). So when zoomed, the video_window may have negative x and y, and width and height which are bigger than the screen. It also works for videos which have borders at the sides (for which cropping only top and bottom doesn't work). The only minor hitch is that it doesn't look very smooth when zooming by holding Ctrl+R/T.
Any comments on my patch? I have been using Totem with the patch for some weeks and it works perfectly. The patch is also very small if you don't count the code that was moved to a new function.
The approach looks quite clever to me (didn't know you could use negative subwindow offsets), but on IRC the issue was raised that not all X drivers will handle the negative offsets very gracefully (read: crash). I'll see if I can find some X elders who can shed some light on this.
<ajax> the driver actually gets coordinates both ways (yay X), but they all seem to be using the clipped version I completely removed the use of _can_set_zoom(), and fixed a warning on startup. 2008-12-01 Bastien Nocera <hadess@hadess.net> * src/backend/bacon-video-widget-gst-0.10.c (resize_video_window), (bacon_video_widget_size_allocate), (bacon_video_widget_set_zoom), (bacon_video_widget_get_zoom): Patch from Robin Stocker <robin@nibor.org> to add zoom support to the GStreamer backend (Closes: #171916) * src/backend/bacon-video-widget-xine.c: * src/backend/bacon-video-widget.h: * src/totem.c (totem_callback_connect): Remove _can_set_zoom() function, both our backends can