Gstreamer is probably your best bet just based on the friendliness of the developer community when asking questions and gstreamer being somewhat more focused on being an intuitive framework to integrate into an application. However, libvlc has a much simpler api which makes it faster to integrate, and you don’t need to worry about plugins as much, as only the codecs are modular (which has benefits and drawbacks, of course.) As Henri pointed out though, getting a functional framework to link against is a job that only happens once (or once every library update anyway.)
If licensing isn’t an issue, I’d go with gstreamer. -- Cinder Roxley Sent with Airmail On May 16, 2016 at 2:41:20 PM, Callum Prentice (Callum) (cal...@lindenlab.com <mailto:cal...@lindenlab.com> ) wrote: As many of you know, support for playing media in Second Life using QuickTime is being removed after Apple announced in April 2016 that they have no further plans to provide security updates for QuickTime for Windows. This email is intended to be a solicitation for feedback and review of a proposed replacement and hopefully some discussion around its' merits, inadequacies and possible alternatives. A replacement media plugin for QuickTime needs to be created based on an existing media playback SDK and mime_types.xml (etc.) updated to direct appropriate media types (MPEG-4, MPG, MP3) at this new plugin. The two technologies that seemed like they might work were identified as GStreamer and LibVLC. The former was an attractive option since that was already used in the Linux viewer. The existing GStreamer media plugin code was somewhat complex and unknown to me whereas playback of a stream in LibVLC seemed very straightforward and I had toyed with it in the past. In order to get something working and provide something to base discussion on, I forked viewer-release and made a new viewer that had QuickTime removed and a new media plugin based on LibVLChere. Only the Win32 implementation is filled out currently until we can collectively decide if this is the right approach. I made a Linden autobuild VLC binary package that the new media code (media_plugin_libvlc.cpp) consumes - currently using the latest version (2.2.3). The limitations with this solution are: * I don't know how to resize the playback buffer once a stream starts playing so if a media plugin resize message come in, I restart the stream from the beginning. It is regrettable but not as big a concern as it would be for say, web media where resizing is much more common. * It doesn't appear to play back the QuickTime MOV files I have tried. I'm still investigating whether that is expected behavior or not. * If you click on a (say) link to an MPEG-4 movie from a web page that is rendered using the CEF plugin, the media system is (currently) not able to switch out the plugin implementation and play it - at the moment I think the CEF plugin reports that this type of file must be downloaded. As far as I know, this wasn't possible before though (clicking on link to QuickTime movie would play in same media instance). Our legal department have given us clearance to use either GStreamer or LibVLC as we see fit so that is not a concern. So what do we all think? Given the limited resources we have to throw at this, is this approach good enough? If not, what are are the alternatives, what are their advantages versus this one and how complex will they be to implement? Many thanks in advance. -- CALLUM PRENTICE | Software Engineer LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/> _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
