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 706890 - [glimagesink] problem with pixel aspect ratio
[glimagesink] problem with pixel aspect ratio
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-gl
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-27 13:56 UTC by Julien Isorce
Modified: 2013-09-27 12:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Julien Isorce 2013-08-27 13:56:24 UTC 
* steps to reproduce: gst-launch-1.0 videotestsrc ! "video/x-raw, width=10, height=10" ! videoscale ! "video/x-raw, width=10, height=500" ! glimagesink -v

* actual result:
/GstPipeline:pipeline0/GstGLImageSink:glimagesink0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)10, height=(int)500, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)50/1

* expected result:
/GstPipeline:pipeline0/GstGLImageSink:glimagesink0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)10, height=(int)500, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1

Aspect ratio should be 1/1 as we get when replacing glimagesink by imagesink:
Comment 1 Matthew Waters (ystreet00) 2013-08-27 14:27:06 UTC 
This looks like a videoscale bug.

xvimagesink gives the exact same result with videoscale.  Replacing videoscale with gleffects effect=0 produces what you're expecting and I think is the correct result.
Comment 2 Sebastian Dröge (slomo) 2013-08-27 14:38:27 UTC 
Why should it be 1/1? The sink claims to support any pixel-aspect-ratio so that should not make a difference.
Comment 3 Sebastian Dröge (slomo) 2013-08-27 14:43:40 UTC 
Not sure why xvimagesink and glimagesink are scaling everything that much though, it does not seem a bug though. Both outputs are correct according to what you requested in the pipeline.
Comment 4 Sebastian Dröge (slomo) 2013-09-04 10:48:21 UTC 
So what do we do with this here? Does anybody have reasons to say it is a bug? Should we define sink behaviour for this to be handled properly?

The problem here is mostly what is taken as window size for the internally created window... and if the sink supports any pixel-aspect-ratio.
Comment 5 Sebastian Dröge (slomo) 2013-09-27 12:31:25 UTC 
Let's just close this then...