[Gstreamer-bugs] [Bug 143030] - [PATCH] improve gstplay

[<bug...@bu...>]

http://bugzilla.gnome.org/show_bug.cgi?id=143030
GStreamer | gst-plugins | Ver: HEAD CVS





------- Additional Comments From rb...@ro...  2004-05-24 13:24 -------
Julien, I re-added the mode (GstPlayType, but different ;) ) for a simple
reason: players are different.

I'm not sure if it's the best solution to the problem, but I basically see it as
follows: there's multiple types of players. Now, I could just let the
application figure out if it wants to set a visualization element, an audio sink
and/or a video sink and select a mode based on that. However, I figured this
would require a lot of checks. The mode allows me to do a clean'n'mean
switch/case with g_return_if_fail()s for sinks in each mode (MODE_AUDIO requires
an audio sink, MODE_VIDEO requires a video sink as well). The result is less and
cleaner code. Like I said, I don't think it's optimal, but it's the best I could
think of.

I'll look at videobalance and volume tonight. I know they're missing as of now.
Reason is that I'm unsure how to handle them best. In some cases, they should
not be added. Either because we're using a hardware audio output that handles
volume itself *and* the application doesn't mind touching system volume instead
of only the stream volume (this is application-dependent!), or because the
element output already provides it (xvimagesink vs. colorbalance/ximagesink). I
might want the application to set such "interface emulation elements" instead of
making them part of libgstplay. Again, I'm unsure here. Feel free to give your
opinions/thoughts.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.