[vlc-devel] Re: SoC Propositions.

Jean-Baptiste Kempf jb at videolan.org
Tue Mar 6 08:14:38 CET 2007


On Tue, Mar 06, 2007, Derk-Jan Hartman wrote :
> >----------------------------------------
> >/* GUI intfs for the browsers plugins */
> >----------------------------------------
> Note that although possible, replacing browserplugins is a tad  
> dangerous, because it's non-configurable. Mozilla plugins are quite  
> stupid when it comes to multiple plugins handling the same MIME type.  
> I'm not sure how ActiveX does that.
> 
> Also. Is it realistic for one person to work on interfaces in  
> multiple OS'es ? Or do we ask for Windows/Linux or just Linux ?
Quovodis may know. I don't.

> >---------------------------
> >/* Fullscreen Controller */
> >---------------------------
> >This project would provide a fullscreen controller for Linux/Unix and
> >Windows, as VLC media player already has on MacOS X.
> >
> >It should be draggable, clickable and support the classic buttons.
> >
> >Proposed mentor: Dnumgis
> 
> This can hardly be a 3 month job. should be expanded upon with other  
> interface capabilities perhaps.
> "non-flicker" vout changing springs to mind
Well, to have it both on Linux and Windows might be some work after all.
But if we can add the non-flicker thing, great !

> >----------------------
> >/* Subtitle support */
> >----------------------
> This is a whole LOT of different stuff.
> * SSA renderer
> * more freetype formatting options
> * a common "formatting language" for non SSA subs
> * implementation of subtitle rendering in the vout as an overlay/ 
> separate window.
> * karaoke subs (thats more a libass project)
> * subtitle file muxing
> 
> I don't think this is realistic. The redesigned vout rendering should  
> be either a separate assignment, or not there at all, it's very big  
> and touches on a lot of VLC. Karaoke is not something for VLC.
So, what do you propose ?

SSA renderer and different formating might be easy if you use libass for
rendering and add the few missing formating things.
The Vout rendering might be complex, do we just take it off ?

 
> >/* MKV */
> 
> I doubt Robux has the time for this.
Well, he told us he could.

> And it looks like a strong ffmpeg project.
> We will fix our ffmpeg muxer eventually. (it's on fridays bughunting  
> list actually)
So let it be a ffmpeg project and we shall adapt afterwards.

> >/* RTSP */
> 
> This is a big and important one in my eyes that should definitely be  
> in in SoC:
> possibilities:
> * TCP framing for our RTSP VLM server
> * HTTP tunneling for our RTSP server
> * RTCP usage (BYE partly implemented)
> * Improved accounting options for our server (per asset accounting)
> * Merge of the RTP packetizers of VLM/Sout
All right, let's add it to the list.

> Another big one that i'm missing is Windows DBA implementation (DVB  
> support). It might be difficult to find people with DBA equipment,  
> but i'd really like to see this in VLC some day.
Well, I did not add DBA because kenS and a few ppl on forum are working
on that one and it would NOT be nice to 'cut the grass under their feet'
(do we say that in english?)
So yes, it would be a good idea, but I would prefer letting KenS working
on it.

> My personal favorites are in order: RTSP, plugin GUIs, VLC.framework,  
> subtitles, DBA
oki.

Applications have opened and will close next monday night. What about we
apply tomorrow night? Thursay? Or sunday? I would prefer the sooner, since we
will be able to change the wiki page afterwards.

And by the way, I need your Google Accounts for the mentors. :D

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html



More information about the vlc-devel mailing list