After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 797205 - glimagesink last sample orientation
glimagesink last sample orientation
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-09-25 22:42 UTC by Nicola
Modified: 2018-11-03 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (4.88 KB, text/x-csrc)
2018-09-25 22:42 UTC, Nicola
Details

Description Nicola 2018-09-25 22:42:26 UTC
Created attachment 373762 [details]
test case

please take a look at the attached test app, 

basically glvideoflip ! glimagesink displays the right image but if video flip orientation does not change the image size (for example GST_VIDEO_ORIENTATION_180) the snapshot taken from last-sample has a wrong orientation.

I discussed about this issue with ystreey00 today and it seems there isn't a simple solution

"""
it's one of those edge cases that I'm not sure exactly where to fix it
"""

I added a workaround in my application (a videoflip element in the snapshot pipeline) but since xvimagesink (and probably d3dvideosink too) works as expected this behaviour should be at least documented. Thanks!
Comment 1 Nicola 2018-09-26 08:32:51 UTC
the video directions that produce a snapshot with bad orientation are:

- GST_VIDEO_ORIENTATION_180
- GST_VIDEO_ORIENTATION_HORIZ
- GST_VIDEO_ORIENTATION_VERT

for the other ones the snapshot orientation is the expected one
Comment 2 Nicola 2018-09-26 12:27:40 UTC
as pointed by ystreet00, removing this line

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/gl/gstglimagesink.c#n1921

solves the issue, but this is probably a workaround and not a proper solution
Comment 3 Nicolas Dufresne (ndufresne) 2018-09-26 13:11:52 UTC
Is the affine transform also using a capsfeature? As in this case, you could also workaround with a capsfilter.
Comment 4 Nicola 2018-09-26 13:30:21 UTC
I don't think so, here are the caps printed by attached test app

snap from sample: 0x562a6f4d9d80 caps: video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D

the only caps feature seems memory:GLMemory
Comment 5 GStreamer system administrator 2018-11-03 12:10:26 UTC
-- 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-base/issues/488.