> Thanks for the good description! Of course I don't want you > to get the wrong idea from my post. I think the direction of > the middleware framework is the correct direction and it > seems to be coming along. As a grid operator I look at what > is used every day. We all know that video/audio conferencing > is THE major application that is being used. >From the grid > operator's perspective of trying to satisfy users with a > better system, the video and audio are THE most important > application. I understand completely that the audio and video > are not the thrust of the work being done, the middleware portion is.
No problem; just wanted to make sure we're on the same page :-) > Please correct me but it seems what you are saying in your > post is that the framework when completed should provide a > consistent interface where compatible video/audio > applications could be plugged in AND assuming everybody in a > particular meeting is using compatible software we would be > able to take advantage of the development that's being done > in video and audio. Right. The plan would be to enable this environment, then "let the market/users" push the platforms to provide interoperable data. The protocols are available and in use, but the choice of codecs (mostly because of patent/IP issues) is still quicksand. > I stand corrected on the open source issue. I thought VRVS > was open source (which means I suppose that vic and rat must > be under some sort of license that is similar to the BSD > license possibly?). Right, vic,vat,rat are BSD, from either Berkeley Lab, University College London or both. VRVS is closed and owned by Caltech. > It looks like we have some smart people in related projects > of lesser scope (VRVS, OpenMash, ect...) that are > concentrating on the particular application of video and > audio. It's seems to me to only make sense to work with those > folks in improving the video/audio aspect of the AG that is > not nessessarily being developed by the core AG team so that > we can use them with the middleware ( I don't want to > belittle ANYTHING that people like Bob Olson, yourself and > others have done to fix vic and rat and add features where > nessessary). :) We entirely agree here. I've been working with folks from UCL, LBL, OpenMash, I2, VRVS etc to try and converge on a set of tools. It seems like downward pressure from our middleware isn't sufficient motivation. I don't know what might be needed to encourage better convergence, but we'd be all for it :-) > I also don't want to imply that there isn't any talk between > AG and the other communities. It's just as a node operator I > don't see much movement with audio/video. It's been almost 3 > years since I set up our node and Vic and Rat work almost > exactly the same as it did back in 2001. There have been some > great fixes...many thanks for that (Really!) That code was *very* well written by the original authors. We've made very modest changes to it, and in fact we're working with UCL to "give back" our changes and use "standard distributions" of vic and rat. > What led me to ask the first question was how well the VRVS > version of Vic worked and the fact that they were working on > adding MPEG4 and HDTV. And of course the fact that InSors > also added support for H.264 (but only between InSors > clients). I'm sure we (the node community) would love to see > these improvements, but the question is how to get the > development process going so we can see the features > developed/deployed in a way that everybody can take advantage > of them. Especially in a way that can take advantage of the > AG 2.x framework in the way you've described. I haven't had time to grab the latest vrvs tools (3.x+) and look at what's been done; I would love to see them offer their modifications back to the "home" source maintainers (like we're planning on doing). The structure is in place for us all to improve the one code base and then all benefit from the new features and bug fixes. I think we're seeing enough activity to try and make that model work again. Pressure from your side (end-user and of course large important institution :-) on various projects to "give back" modifications might go a long way. > Do you think that once the middleware portion is complete and > robust that we will see the community dump vic and rat for > something better? (like some of the software you mentioned?) > Should the community talk about what we should move to when > the middleware is ready for it so there is some common video > denominator during meetings? I think a "common denominator" will always be an elusive target. Market forces cause the big two platforms to differentiate platforms by locking each other out of "high value" IP. Codecs are one space that happens a lot, software patents might make that worse, who knows. I think as time goes on we'll have a "majority denominator" and smart middleware that transcodes the "minority users" (who might be on via VoIP, or handheld, or something more interesting) streams into something they can handle. The transcoding will cost latency, but if it's designed correctly the users who require special services only pay the latency bill. This encourages them to join the majority :-). I'm not sure the collaboration community should really steer codec choices, since the scenarios are so wildly different for each possible use. I think keeping the situation in mind and taking every opportunity to encourage "consolidation of media tools work" is an excellent plan. --Ivan
smime.p7s
Description: S/MIME cryptographic signature
