Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Callum Prentice (Callum)]

This is what I propose for moving forward with the "Remove QuickTime from
the viewer" work:

(TLDR;  Replace QuickTime plugin with one based on LibVLC and use it to
play MPEG-4 and MP3 media URLS plus anything else we get for free.
Additionally, turn on flags in
Chromium->CEF->CEF-bin->LLCEFLib->media_plugin_cef builds that enable
embedded media support.)

   - Remove QuickTime entirely from the viewer.
   - Replace it with a new plugin:
  - Version for Windows (32 bit) using LibVLC
  - Version for OS X (32 bit) using LibVLC
  - Ask for help from open source developer community to create a
  version for Linux using LibVLC
   - Update mime_types.xml (etc) to point old QuickTime handled media at
   new version (plus any others we think should not go to the default, CEF
   plugin)
   - Ask for help from the open source developer community to flip Linux
   GStreamer output since we flipped the prim media texture coordinates
  - I hope this is possible - reason it was done is that both CEF and
  LibVLC need to be flipped so it seems foolish to flip everything twice.
   - Inhibit the "This file needs to be downloaded" message in CEF for
   media types we are unable to handle - replace with Alert?

Then as a separate task maybe since it's more of a feature vs. a replace
QuickTime issue:

   - Assuming legal gives us the go ahead to turn on the CEF embedded media
   support, go ahead and update the Windows/OS X 32 bit CEF media plugins
   accordingly.

Then, once this is finished and we resume the 64 bit conversion work:

   - Create 64 bit versions of the LibVLC plugin for Windows and OS X
   - Create 64 bit versions of the media-enabled CEF plugin for Windows and
   OS X



​Unless ​
​anyone has any significant objections, I'll go ahead and clean up the
existing LibVLC plugin, get it working on OS X and make a version of the
CEF plugin with embedded media.

I have no ability to do anything for the Linux side of things so would
appreciate help from someone with a contributor agreement.

Cheers!​



On Mon, May 16, 2016 at 1:41 PM, Callum Prentice (Callum) <
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 LibVLC here
> . 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?
>
> 

[opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Geir Nøklebye]

For OS X save yourself all the trouble in the world by using the OS X media 
frameworks and QuickTime. 

To create a 32-bit OS plugin based on LibVLC just to covert it to 64-bit is 
asking for trouble and weeks of headaches when you already have everything your 
need both for 32 and 64 bit QuickTime available and virtually just need to set 
a flag in the compiler. 

If you are ever to be serious developing on OS X or iOS, snap out of it and 
start to use what is available, supported and tested through and trough. The 
time you free up can be used for the rest of your projects! ;-)

Cheers!

___
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

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Cinder Roxley]

On May 23, 2016 at 12:42:12 PM, Callum Prentice (Callum) (cal...@lindenlab.com 
 ) wrote:
 
This is what I propose for moving forward with the "Remove QuickTime from the 
viewer" work:

(TLDR;  Replace QuickTime plugin with one based on LibVLC and use it to play 
MPEG-4 and MP3 media URLS plus anything else we get for free. Additionally, 
turn on flags in Chromium->CEF->CEF-bin->LLCEFLib->media_plugin_cef builds that 
enable embedded media support.)
*   Remove QuickTime entirely from the viewer.
*   Replace it with a new plugin:
*   
*   Version for Windows (32 bit) using LibVLC  
*   Version for OS X (32 bit) using LibVLC
*   Ask for help from open source developer community to create a 
version for Linux using LibVLC
*   Update mime_types.xml (etc) to point old QuickTime handled media at new 
version (plus any others we think should not go to the default, CEF plugin)
*   Ask for help from the open source developer community to flip Linux 
GStreamer output since we flipped the prim media texture coordinates
*   
*   I hope this is possible - reason it was done is that both CEF 
and LibVLC need to be flipped so it seems foolish to flip everything twice.
*   Inhibit the "This file needs to be downloaded" message in CEF for media 
types we are unable to handle - replace with Alert?
Then as a separate task maybe since it's more of a feature vs. a replace 
QuickTime issue:
*   Assuming legal gives us the go ahead to turn on the CEF embedded media 
support, go ahead and update the Windows/OS X 32 bit CEF media plugins 
accordingly.
Then, once this is finished and we resume the 64 bit conversion work:
*   Create 64 bit versions of the LibVLC plugin for Windows and OS X
*   Create 64 bit versions of the media-enabled CEF plugin for Windows and 
OS X


​Unless ​ 
​anyone has any significant objections, I'll go ahead and clean up the existing 
LibVLC plugin, get it working on OS X and make a version of the CEF plugin with 
embedded media.

I have no ability to do anything for the Linux side of things so would 
appreciate help from someone with a contributor agreement.

Cheers!​
 

Sounds good to me. 

I wonder if doing vlc on darwin32 is worthwhile though. Quicktime for Mac is 
deprecated, but doesn’t exhibit the security holes Windows does. Once 64-bit is 
building, Quicktime has got to go as there is no 64-bit support anyway. Guess 
it depends on how soon darwin64 could be out the door.

-- 
Cinder Roxley
Sent with Airmail
___
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

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Cinder Roxley]

On May 23, 2016 at 1:13:54 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
 ) wrote:

 
For OS X save yourself all the trouble in the world by using the OS X media 
frameworks and QuickTime. 

To create a 32-bit OS plugin based on LibVLC just to covert it to 64-bit is 
asking for trouble and weeks of headaches when you already have everything your 
need both for 32 and 64 bit QuickTime available and virtually just need to set 
a flag in the compiler. 

If you are ever to be serious developing on OS X or iOS, snap out of it and 
start to use what is available, supported and tested through and trough. The 
time you free up can be used for the rest of your projects! ;-)

The QuickTime C APIs can’t be used directly for 64-bit applications…. See 
Apple’s 64-Bit Guide for Carbon Developers. 

-- 
Cinder Roxley
Sent with Airmail
___
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

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Callum Prentice (Callum)]

>
>
> I wonder if doing vlc on darwin32 is worthwhile though. Quicktime for Mac
> is deprecated, but doesn’t exhibit the security holes Windows does. Once
> 64-bit is building, Quicktime has got to go as there is no 64-bit support
> anyway. Guess it depends on how soon darwin64 could be out the door.
>

​That's a great point Cinder - thank you. I will get straight back to the
64 bit work once this project is complete.

Only concern I foresee is that it might end up with URLs rendering on one
platform and not the other.  I'll run it by product and see what they say.

Cheers.​
___
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