[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    State of the Noatun
From:       Charles Samuels <charles () kde ! org>
Date:       2001-10-24 20:40:22
[Download RAW message or body]


I'm going to now outline the expected features of Noatun2.

1) Automatic Tag Reading (Done)

2) Rewritten Playlist Archetecture (Done?)

3) Video Embedding

4) Proper playlist handling

Plugins:

5) Winamp Skins

6) Streaming icecast/shoutcast (Works in noatun, not arts)



Obviously, if you have more suggestions on what should be in libnoatun, now 
it should be proposed.  Bringing up ideas on new codecs will not fly with me, 
and if you suggest a new plugin, I'll ask you to write it yourself :)


1) Tag Reading

Actually, this is a plugin, but I have a standard library handler for it.  
It's really quite nice.  The best part is that I have a long regexp in noatun 
now too.  You know how I feel about regexps.

2) Rewritten Playlist Arch.

Neil suggested that the playlist have reference counting.  That sure turned 
out to be a good idea.  This should make complicated playlists (like, say, 
SQL based lists) much easier.  SPL is turning out to be about 25% faster, 
just as a cheap hack on the old version.  Once Tron is rewritten properly, 
I'm expecting it to be about 50% faster.  Neil, are you still having problems?

3) Video Embedding

I have a game plan for this.  Stefan's main problem with noatun is the 
"multiple-interface" thing.  My solution is that each plugin can inherit from 
a, say, VideoWidget (more or less) which will use the arts interface to 
reparent the video window.

Since there are more than one plugins, there can be more than one of these 
widgets.  The catch is that each has a "name" (E.g., "Excellent" as a name, 
or "Milk Chocolate").  The user can then select which widget gets control.  
If none of these widgets exist, then there is no reparenting.  So it'l behave 
the same as it does now.

4) Proper Playlist Handling

I've been speaking with the author of AlsaPlayer (my player of choice after 
Noatun and mpeglibartsplay :)  We settled on a standard XML format for 
playlists:

http://noatun.kde.org/formats/xmlplaylist.phtml

At the least, a playlist *should* be able to export and import this format.  
Tron will use this format natively (in fact, my "spec" is based on Tron's 
format).  I'll do this for SPL, eventually.  I loathe dealing with QDom.

The other problem is with m3u playlists, the "pls" format used by shoutcast.  
How should this be dealt with?  I think a --playlist option for noatun, with 
the argument being the playlist to open.

How can this be dealt with in a powerful, but playlist-plugin friendly manner?

Oh, and it looks like Liszt is going out of the release, because
a) nobody knows how to use it
b) it doesn't actually work anyway

5) Winamp skins

Apparently there are two efforts at this.  The 
NickBetcherMartinVogtFrankNichols approach (winskin in CVS), which seems to 
be unmaintained.  I heard rumors that Martin was going to maintain that.

The second effort is by a person named "Phalanx" on IRC.  He tells me that 
he's met the completeness of Winskin.  He doesn't seem to get on IRC a lot, 
and I don't know much more about that.  If he doesn't make any effort on 
getting it to cvs, and someone doesn't want to get winskin release-worthy 
(and it's close!), then no winskin for 3.0.

6) Streaming

I managed to get streaming to work.  However, I uncovered a flaw in the 
KPlayObject design: The serious lack of buffering; it's downright awful.  It 
skips like you wouldn't believe, with low or large amounts of simple load.  I 
think this is the latency from the MCOP calls of the playobject asking noatun 
for the next download sample (the KIO request).  Stefan knows about this: 
have you made any progress?


"It just sounds better in noatun"

-Charles
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]