Advanced search
Log In
New Account
Home My Page Project Cloud Code Snippets Project Openings Canola
Summary Forums Tracker Lists Tasks Docs News Files Home Page Wiki

Feature Requests: Browse | Download .csv

[#213] Export CnlSystem API

Please login

2006-12-02 03:29
Submitted By:
Ted Zlatanov (tzz)
Assigned To:
Gustavo Barbieri (barbieri)
Export CnlSystem API

Detailed description
For movies for example, mplayer might be wanted.  Just let the user associate a hander with a file extension.


Date: 2006-12-02 06:19
Sender: Gustavo Barbieri

You can have full support for mplayer in plugin, even seek and
non-fullscreen. However we need to be allowed to release the
class interface you have to implement.

It's almost as simple as fork()/exec(). If you just want to control,
you can use popen(). If you want to also present current position,
you need more code in order to connect to both process stdin/out.
Date: 2006-12-02 04:49
Sender: Ted Zlatanov

II have no problem with the DSP/gstreamer approach, and I 
think  it will work well.  I would use mplayer for specific files
that Canola doesn't handle.  No need for full integration.  Just
fork, exec and let the user worry about the rest.  If that can
be done in a plugin, I look forward to implementing it.
Date: 2006-12-02 04:28
Sender: Gustavo Barbieri

Hi Ted,

I worked on Freevo ( project before I finished
university and joined INdT. There we have the same thing you
want, association of extensions/mime-types and players. We used
xine for dvd, mplayer for almost everything else. You can even
find my patches to export sound (-af export) so you can use some
visualization library (I had mpav at that time, then helped people
to start libvisual) or bmovl and bmovl2.

While it's good on one side, because MPlayer is rock solid and
works good, with broad codec support, it's not as extensible
as we need. It's hard to choose a subwindow where it can draw
(you can just use a Xwindow id) and drawing over its surface
is a pain (see bmovl and bmovl2), so you cannot get OSD. And
you have not much control: you can just read it's stdout and
send commands to stdin if you use -slave.

Also, Nokia is putting huge efforts to have some codecs implemented
in DSP, freeing the CPU for other uses, like Canola's UI. We
would like to benefit from this, but Nokia's way of doing things
with Gstreamer is non-usual... but it's improving for the next

So, while we see Mplayer as an alternative option, we see a plain
gstreamer as a more correct approach. After we release final
1.0 we'll take some time to fix major problems, like thumbnail
support and our own player (fixes non-fs video, id3 for remote
media, extra codecs, ...).

BTW, I'll try to get managers to allow me to release some of
our APIs, so you can create plugins yourself. Canola UI is great,
but the real beauty is within our plugin framework... you can
change players just writing a GObject class implementing our
virtual methods/interface.
Date: 2006-12-02 03:40
Sender: Marcelo Eduardo

Hi Ted,

We already started playing with the Mplayer as it's quality would
be great for canola. But we just didn't have enough time to test
it and make sure our code using it wouldn't break.

We have some real things going on for the media part of canola
and we want to give the best available thing on the platform.

Thanks for all the feedback, and if you need more technical
information gustavo is working with the Mplayer based backend
for canola.

Attached Files:

Name Download
No Files Currently Attached


Field Old Value Date By
close_date2007-12-19 20:462007-12-19 20:46chenca
status_idOpen2007-12-19 20:46chenca
ProductNone2006-12-12 01:44barbieri
close_date1970-01-01 00:002006-12-12 01:44barbieri
summaryexternal handlers needed2006-12-12 01:44barbieri
priority32006-12-12 01:44barbieri
assigned_tonone2006-12-02 04:28barbieri

Terms of Use    Privacy Policy    Contribution Guidelines    Feedback

Powered By GForge Collaborative Development Environment