GNOME Bugzilla – Bug 765310
player: Handle zoom/crop & forced aspect ratio
Last modified: 2018-11-03 13:49:08 UTC
See https://github.com/sdroege/gst-player/issues/91 and https://github.com/sdroege/gst-player/issues/92
*** Bug 765513 has been marked as a duplicate of this bug. ***
See also https://bugzilla.gnome.org/show_bug.cgi?id=765513#c2 I think ideally this should be implemented inside playsink and GstPlayer just exposes the API for that in a meaningful way.
*** Bug 765413 has been marked as a duplicate of this bug. ***
(In reply to Sebastian Dröge (slomo) from comment #2) > See also https://bugzilla.gnome.org/show_bug.cgi?id=765513#c2 > > I think ideally this should be implemented inside playsink and GstPlayer > just exposes the API for that in a meaningful way. I just check the 1.8.0 code and I think element "playsink" already have "force-aspect-ratio" property. I am a bit confused as you said, "it should have inside playsink". So here is my understanding: since playsink already have "force-aspect-ratio", we need to just add getter/setter in GstPlayer element and handle playsink's property from that function. Please suggest.
See my comment in the other bug. Just this boolean is pretty useless as you usually want a more high-level setting: From an application point of view you want more than this boolean usually. You usually want to be able to override the aspect ratio, not have it completely loose. The common case is that you have a video that is recorded 4:3 but is actually 16:9 and then want to have this actual aspect ratio enforced by the player. Or even worse, you have that case but also have to crop/zoom in. Take a look at how totem or VLC are handling this for example.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/373.