[MeeGo-touch-dev] grab XWindowID from MTF applications

[Zhao, Halley]

I fully agree with your concerns. GStreamer provides more flexibility.
In fact, the gap between your gst based application and Qt (QGraphicsview) is just a Qt video sink for GStreamer, which could render video frame as texture in QGraphicsView.
You can create such sink in a separated library refer to QGraphicsVideoItem in qt-mobility; then your video conference, TV player, camera, video player can build base on it.


-----Original Message-----
From: meego-touch-dev-bounces at meego.com [mailto:meego-touch-dev-bounces at meego.com] On Behalf Of Alexander Bokovoy
Sent: Tuesday, September 14, 2010 2:50 AM
To: Gerry LaChac
Cc: meego-touch-dev at meego.com
Subject: Re: [MeeGo-touch-dev] grab XWindowID from MTF applications

2010/9/13 Gerry LaChac <glachac at tethermedia.com>:
>
> I don't see how one could use qt-mobility solutions listed below if you only
> had a complex gstreamer interface you were porting over to Meego, but I'm
> hoping someone could point out what I might be missing.
>
> Take for example, the telepathy-qt4-farsight library.  It is used to create
> RTP video streams with remote clients and internally sets up gstreamer
> elements along a pipleline provided by the application.  Essentially after
> the connection is established the application is provided with a gstreamer
> source pad from the farsight library which needs to be connected to display
> the video.
>
> With this type of interface (at the level of a gstreamer pad), I'm not sure
> you could use any of the qt-mobility solutions since all the gstreamer
> features are hidden from you.  You are forced to deal with it at a much
> lower level and I do not believe one could connect the gstreamer pad to any
> of the widgets provide in qt-mobility.    Please correct me if I'm wrong, as
> I'd prefer to use the native solution, but I believe I cannot in this
> scenario.  I'm under the impression that the power of gstreamer is hidden in
> the plugin layer, and is not accessible at the application layer.
Yes, this is a very good example of real world cases where Qt Mobility
Multimedia API is unable to provide a solution because it wasn't
designed for such cases.

I've been trying to argue for this type of cases for long time.
Unfortunately, a goal of Qt Mobility Multimedia API isn't to give you
access to a particular media technology; rather than that, it tries to
level out different media technologies so that same level of a
functionality is accessible without knowing details of these
technologies. At least, in theory. I wouldn't say this is particularly
wrong or right, it is just for a different purpose.

Qt-wise, there is ongoing project, still in early phase, to provide Qt
bindings to GStreamer, QtGstreamer on gitorious.org.
http://gitorious.org/qtgstreamer. It tries to give you proper Qt
objects and Qt ways to communicate with GStreamer via signals and
slots so that to your application a gstreamer's pipeline and messages
will look similar to other Qt components.
-- 
/ Alexander Bokovoy
_______________________________________________
MeeGo-touch-dev mailing list
MeeGo-touch-dev at meego.com
http://lists.meego.com/listinfo/meego-touch-dev