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 136179 - totem/gst-player/libgstplay doesn't work with ximagesink
totem/gst-player/libgstplay doesn't work with ximagesink
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-03-04 13:43 UTC by Ronald Bultje
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
obvious patch (732 bytes, patch)
2004-03-06 22:15 UTC, Ronald Bultje
none Details | Review

Description Ronald Bultje 2004-03-04 13:43:56 UTC
Try ximagesink instead of xvimagesink. You'll see what I mean. I get a
16x16 window displayed, no matter what.

Proper gst-launch testcase for Dave/Benjamin to reproduce:

gst-launch videotestsrc ! ffcolorspace ! videoscale ! ximagesink

This one works, though:

gst-launch videotestsrc ! videoscale ! ffcolorspace ! ximagesink

(Assigned to plugins becayse I assume it's a plugin capsnego error... Might
as well be a player or core bug, though...)
Comment 1 David Schleef 2004-03-04 20:10:32 UTC
As always, if you don't like the default fixation, you need to provide
a fixate function in your application.  The following recommended
pipeline works well, btw:

gst-launch-0.7 videotestsrc ! video/x-raw-yuv, width=320, height=240,
framerate=30.0 ! ffcolorspace ! videoscale ! ximagesink
Comment 2 Ronald Bultje 2004-03-04 22:45:36 UTC
No, in this case, videoscale should passthrough the width/height.
Videoscale should *only* rescale if requested. Default should be
passthrough.
Comment 3 Ronald Bultje 2004-03-05 00:54:54 UTC
And don't forget that even if you're right, gst-player is still bugged
because it doesn't provide an application fixation function...

The window is 16x16. That's a bug. :).
Comment 4 David Schleef 2004-03-05 01:35:22 UTC
In the case you list as buggy, videoscale _is_ doing a passthrough. 
One side decided on 16x16, and convinced the other side to use the same.
Comment 5 David Schleef 2004-03-05 23:58:47 UTC
FWIW, the best way to fix stuff like this is to call
gst_pad_renegotiate() on one of the later links in a video pipeline. 
For example, gstplay should probably call it on the link before
$(gconf.videosink).  And the app should use the fixate signal to
encourage the best format.
Comment 6 Ronald Bultje 2004-03-06 22:03:33 UTC
I've noticed your fixes and they didn't help.

FWIW, I've tracked the bug down to the switch element. Giving that a
closer look, it seems that switch doesn't do any negotiation at all,
which explains a lot. Removing switch (replacing it by identity) in
the gstplay pipeline fixed totem and gst-player for me.
Comment 7 Ronald Bultje 2004-03-06 22:15:07 UTC
Created attachment 25278 [details] [review]
obvious patch
Comment 8 Ronald Bultje 2004-03-06 22:16:00 UTC
I'm not saying this is *the* proper fix (therefore, I'm not using the
PATCH keyword). But this makes stuff work for me. It's more useful to
fix the switch element, but I'll leave that decision on what/how to
Julien, or at least wait so he can comment on it.
Comment 9 Ronald Bultje 2004-03-19 15:12:40 UTC
Apparently, my switch was bugged locally. Dave thinks the other
pipeline is not a bug but a feature, so close...