Re: [gst-devel] Mozilla & gstreamer

[Christopher B. <bli...@mo...>]

Yeah, the relicensing question feels a _little_ early.  David is  
interested in some of this stuff for Thunderbird but there are parts  
that we definitely want for Firefox as well.  In particular the video  
roadmap that I would like to see in place includes:

0. Improving the video APIs that we have in the browser so that we can  
do frame-by-frame rendering and stepping.  Also better control over  
buffering and connecting clips together.  This would allow us to build  
effects in HTML, SVG + JS and is the first step to an online editor.    
We can connect that to 1 below and do encoding + upload as well.   
Michael can do this with firefogg today I think, but I want this built  
into the browser as something anyone can do.  (Note: this goes way  
beyond the HTML5 stuff so we'll have to be willing to do that.)

1. An html-based camera + video capture API.  This isn't just an add- 
on like interface for JS people but also includes preview + style like  
we have with the html5 video element.  Think of it as a file upload on  
steroids.  An image interface is easy - just encode to jpg or png or  
whatever, and upload it.  Video is more challenging and where the  
opportunity is.  I would like to see us include capture for mac,  
windows + linux, encode to Theora and upload via the file upload API  
that we have today.  This brings video production to browsers (like we  
have text + image production today via blogs, etc.) but also continues  
the path to make ogg, theora and vorbis part of the underlying  
structure of the web.

2. Longer term (and I haven't been able to get much traction inside of  
Mozilla for this besides "that would be nice") is to include some kind  
of real time p2p protocol that's also exposed like the video element  
is today - fully scriptable, styled, usable through canvas, etc.  My  
test for this is "install a wordpress plugin and you can talk to me  
via that" instead of having to use gmail, skype or any of the other  
huge centralized systems.

So that's where I want to see us go and it's a multi-year kind of  
thing.  Part of it is the need to allow people like Michael and others  
to finish their editor projects, but I also want to see us get to the  
point where where changing the way that video on the web is consumed  
and produced that that free formats are at the center of that.

Licensing is only a small part of that but here's what I would suggest  
we start with:

1. Assume that code for the capture can be shared between gstreamer +  
Mozilla.  If we can use the v4l2src module as a base to start with and  
find everyone who has contributed to it and get it re-licensed that  
would be awesome - it's a good base to start working together.  But  
assume that we'll do it without glib and without the gstreamer bits so  
we'll need to make sure we're thinking about that.  We can make sure  
we're good citizens @ Mozilla about making sure that changes that we  
do are exposed, but it's up to the gstreamer people to make sure that  
the code that's in gstreamer is also tri-licensed and that  
contributions to that code are also tri-licensed so we can use them in  
Mozilla.  (Right now the code contributions would only flow one-way -  
something I would like to avoid.)  I would assume that Mozilla will  
invest here so you're likely to have access to some windows + mac  
capture code at some point.  If we plan to collaborate ahead of time  
we can set some expectations about what that sharing looks like and  
the licenses involved.

2. I talked with Christian about this at FOSDEM a little bit and it  
sounds like they might be willing to re-license some of the RTP stuff  
they have as well.  That's entirely up to them and it's a really long  
term project for us - and something that we're probably not willing to  
fund quite yet (although I think we should.)  I'm not sure what form  
that should take.  I think that trying to hit some kind of SIP- 
compatibility is the wrong answer, especially to start.  Huge set of  
constraints and sets us down the path to compatibility with existing  
systems instead of trying to do p2p video + audio chat like the web  
would do it instead of the way that telcos and businesses would do  
it.  So that's something that needs to be well-scoped and understood.   
Worth talking about at OVC anyway.

--Chris