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

[Nicky D.]

>
>
>
> I can confirm that it does build properly and results in a functional
> CEF3 plugin with MP4 & Co support (tested in a private build of the
> Cool VL Viewer, with the mime_types.xml file edited to replace all
> plugins with the CEF3 plugin): no more "You have requested a file
> download, which is not supported within the viewer." issue...
>
>
Same here. I can confirm the 2623 (Chromium 49) branch builds fine at least
with Ubuntu 14.04
as 32 and 64 bit. the 32 bit executable is Debian Wheezy compatible, the
x64 not.
i have to try to rebuild that on Wheezy x64 and then go for Windows.

Regarding VLC: Note that the project Viewer LL made already uses VLC for
Linux.
___
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

[Nicky Perian]

Should avi abd wmv files be moved from cef to vlc plugin.
Made a change locally and it worked.


Movie (Windows Media WMV)


movie


media_plugin_libvlc




Movie (AVI)


movie


media_plugin_libvlc





On Sat, Jun 4, 2016 at 9:20 AM, Henri Beauchamp  wrote:

> On Sat, 4 Jun 2016 06:52:58 -0500, Argent Stonecutter wrote:
>
> >
> > > • Ask for help from open source developer community to
> > create a version for Linux using LibVLC
> >
> > Since Linux currently doesn’t use Quicktime, why doe it need to be
> > converted?
>
> Quicktime media plays just fine under Linux, thank you !...
>
> It needs to be converted for the sake of having an uniform set of plugins
> with the same capabilities on all OSes...
> Also, the gstreamer plugin, while working just fine (again, for Quicktime
> media included), would need the viewer code to be changed (it's doable
> hoewever) if it would be kept along other plugins (the new CEF3 plugin,
> without media textures flipping, and now the VLC plugin), since media
> textures are flipped upside down when compared to the old way of
> rendering them (which matched the gstreamer, the Quicktime and the
> QtWebkit plugins).
>
> Henri.
> ___
> 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

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

[Henri Beauchamp]

On Sat, 4 Jun 2016 06:52:58 -0500, Argent Stonecutter wrote:

> 
> > • Ask for help from open source developer community to
> create a version for Linux using LibVLC
> 
> Since Linux currently doesn’t use Quicktime, why doe it need to be
> converted?

Quicktime media plays just fine under Linux, thank you !...

It needs to be converted for the sake of having an uniform set of plugins
with the same capabilities on all OSes...
Also, the gstreamer plugin, while working just fine (again, for Quicktime
media included), would need the viewer code to be changed (it's doable
hoewever) if it would be kept along other plugins (the new CEF3 plugin,
without media textures flipping, and now the VLC plugin), since media
textures are flipped upside down when compared to the old way of
rendering them (which matched the gstreamer, the Quicktime and the
QtWebkit plugins).

Henri.
___
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

[Argent Stonecutter]

>   • Ask for help from open source developer community to create a 
> version for Linux using LibVLC

Since Linux currently doesn’t use Quicktime, why doe it need to be converted?

___
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

[Anya Kanevsky]

And here's a project viewer:
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_VLC_Media_Plugin/4.0.6.316087

On Mon, May 23, 2016 at 11:42 AM, 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!​
>
>
>
> 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 depa

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

[Henri Beauchamp]

On Wed, 18 May 2016 13:49:26 +0200, Henri Beauchamp wrote:

> On Wed, 18 May 2016 12:16:27 +0200, Nicky D. wrote:
>
> > It is supposed to be "Just add proprietary_codecs:1 to cef.gypi'
> > That said there's probably the devil in the details, according to:
> > http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=10741 some
> > had problems, but there's also a newer thread at
> > http://magpcss.org/ceforum/viewtopic.php?f=6&t=13515
> > claiming success.
> 
> I'll have a look, time permitting; I'm also in the process of migrating
> my main system to a newer Linux distro and given the high level of
> customizations I use (which involves recompiling many packages with
> patches or different compile options), it will take time...

Well, I finally got my new main system up and working (almost) fully
the way I like, so I fired my CEF3 build VM (Debian 7.8 32 bits) and
let it recompile CEF3 with the proprietary CODECs last night.

I can confirm that it does build properly and results in a functional
CEF3 plugin with MP4 & Co support (tested in a private build of the
Cool VL Viewer, with the mime_types.xml file edited to replace all
plugins with the CEF3 plugin): no more "You have requested a file
download, which is not supported within the viewer." issue...

Note that the CODECs are statically linked inside libcef.so (no need
any more for a "ffmpegsumo" shared library).

The rebuilt CEF3 package (without tcmalloc statically linked to it,
and with the CODECs built-in) for 32 bits Linux is available here:
http://sldev.free.fr/libraries/sources/
and the updated llceflib-linux-20160601.tar.bz2 32 bits package from
here: http://sldev.free.fr/libraries/

The rebuild steps have been updated (basically, you need to install
the "chromium" package for the CODECs headers/libraries and to add
two variables to your .gyp/include.gypi file):
http://sldev.free.fr/libraries/sources/cef-rebuild-steps-2526.txt

I will also rebuild the 64 bits packages.

Henri.
___
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

[Geir Nøklebye]

Which is absolutely true but nobody suggested to use Carbon in the 64-bit 
continuation, but the relevant frameworks.  For all we know it may not even be 
possible to compile or run the viewer any more on OS X 10.12 or whatever they 
will call it (WWDC 2016 ) with the current codebase.   First step is to 
completely decarbonate the viewer, and to convert it to a full-blown Xcode 
project so we can use the tools in an efficient way. 

Cheers, 

> 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

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

[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

[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

[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?
>
> 

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

[Darien Caldwell]

I have to agree. It's probably one case where removing an exception isn't
worth the effort. Neither would extending the exception into parcel media.
Since parcel media is all within the scope of 'browser accessed', it would
make sense to keep it within that scope.

On Thu, May 19, 2016 at 12:44 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> It would make sense to route MP3 media URLs to the same system that plays
> parcel media but given the complexity of those systems, it might be a lot
> of work.
>
>
___
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)]

It would make sense to route MP3 media URLs to the same system that plays
parcel media but given the complexity of those systems, it might be a lot
of work.

I experimented with playing MP3s in FMODEx directly and many https URLs
failed with a generic "HTTP error" - they all played in LibVLC.

On Thu, May 19, 2016 at 12:05 PM, Darien Caldwell  wrote:

> I just tried with this public radio stream:
> http://stream.nonstopplay.co.uk/nsp-64k-mp3
>
> for Prim media, I received the "You have requested a file download"
> message being discussed in the other thread. But the same URL as parcel
> stream works.
>
> On Thu, May 19, 2016 at 11:58 AM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
>> Parcel media streams might use FMODEx vs. media (I know, I know)..  Have
>> you tried putting an MP3 URL on a prim and seeing if it plays?
>>
>>
>>
>>
>>
>
> ___
> 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
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Darien Caldwell]

I just tried with this public radio stream:
http://stream.nonstopplay.co.uk/nsp-64k-mp3

for Prim media, I received the "You have requested a file download" message
being discussed in the other thread. But the same URL as parcel stream
works.

On Thu, May 19, 2016 at 11:58 AM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> Parcel media streams might use FMODEx vs. media (I know, I know)..  Have
> you tried putting an MP3 URL on a prim and seeing if it plays?
>
>
>
>
>
___
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)]

Parcel media streams might use FMODEx vs. media (I know, I know)..  Have
you tried putting an MP3 URL on a prim and seeing if it plays?

On Thu, May 19, 2016 at 11:53 AM, Darien Caldwell  wrote:

> I don't know, I only know when Windows 10 came out, I did a clean install
> of windows 10, and never installed Quicktime, as it at the time wasn't
> 'compatible' with windows 10. MP3 parcel streams always worked despite
> having no Quicktime on the system.  Maybe this is a fluke, or windows 10
> only situation. I still don't have Quicktime and I still have parcel stream
> support to this day.
>
> On Thu, May 19, 2016 at 10:02 AM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
>> My understanding was that QuickTime was used to play MP3 URLs on a prim
>> or parcel - QA reported that uninstalling QuickTime resulted in those files
>> not playing anymore and that assertion is backed up by what's in
>> mime_types.xml and it's friends.
>>
>> --
>>
>> CALLUM PRENTICE | Software Engineer
>>
>> LINDEN LAB | Create Virtual Experiences 
>>
>
>
> ___
> 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
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Darien Caldwell]

I don't know, I only know when Windows 10 came out, I did a clean install
of windows 10, and never installed Quicktime, as it at the time wasn't
'compatible' with windows 10. MP3 parcel streams always worked despite
having no Quicktime on the system.  Maybe this is a fluke, or windows 10
only situation. I still don't have Quicktime and I still have parcel stream
support to this day.

On Thu, May 19, 2016 at 10:02 AM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> My understanding was that QuickTime was used to play MP3 URLs on a prim or
> parcel - QA reported that uninstalling QuickTime resulted in those files
> not playing anymore and that assertion is backed up by what's in
> mime_types.xml and it's friends.
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>
___
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

[Dax Dupont]

CEF proprietary codecs will solved that issue. Whether or not it will be a
replacement for media is up in the air.
I think it might be good to have a trial version of all the three options
if possible and measure impact.

On May 19, 2016 19:13, "Callum Prentice (Callum)" 
wrote:

>

> >

> Thanks Whirly - I'll take a look and see what, if any, of the proposed
solutions allows those to work.
>
> On Thu, May 19, 2016 at 2:43 AM, Whirly Fizzle 
wrote:

>

> >>

>> The JIRA issues Nicky referenced are:
>>
>> https://jira.secondlife.com/browse/BUG-11008
<https://jira.secondlife.com/browse/BUG-11008> - [CEF] MPEG4 and AAC video
not working in TV object
>>
>> https://jira.secondlife.com/browse/BUG-11606
<https://jira.secondlife.com/browse/BUG-11606> - Missing proprietary codec
support
>>
>> 
>> Date: Thu, 19 May 2016 11:24:50 +0200
>> From: sl.nicky...@googlemail.com
>> To: cal...@lindenlab.com
>> CC: opensource-dev@lists.secondlife.com
>> Subject: Re: [opensource-dev] Replacement for QuickTime media plugin - a
straw man proposal
>>
>> Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF
just so they work in the browser.
>> I know there is demand for those, there is also two Jiras for that, so
TVs can use HTML5. I can dig those two Jira up (or ask Whirly)
>> if people are interested in the tickets.
>>
>>
>> ___ 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
>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
> <http://www.lindenlab.com/>
> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
<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

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

[Callum Prentice (Callum)]

Thanks Whirly - I'll take a look and see what, if any, of the proposed
solutions allows those to work.

On Thu, May 19, 2016 at 2:43 AM, Whirly Fizzle 
wrote:

> The JIRA issues Nicky referenced are:
>
> <https://jira.secondlife.com/browse/BUG-11008>
> https://jira.secondlife.com/browse/BUG-11008 - [CEF] MPEG4 and AAC video
> not working in TV object
>
> https://jira.secondlife.com/browse/BUG-11606 - Missing proprietary codec
> support
>
> --
> Date: Thu, 19 May 2016 11:24:50 +0200
> From: sl.nicky...@googlemail.com
> To: cal...@lindenlab.com
> CC: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Replacement for QuickTime media plugin - a
> straw man proposal
>
> Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF
> just so they work in the browser.
> I know there is demand for those, there is also two Jiras for that, so TVs
> can use HTML5. I can dig those two Jira up (or ask Whirly)
> if people are interested in the tickets.
>
>
> ___ 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
>



-- 

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

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

[Callum Prentice (Callum)]

>
> > Do people agree that this would be the best solution?
>
> Definitely NOT !
>

​Yep - that may have been hasty - a desire to have a single orthogonal
solution for everything.

 ​
___
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)]

Re: codecs for CEF - I've had *some* success with that.  Building the last
working 32bit build of the OS X version didn't build - lots of C++ errors.
Building the tip in (required) 64bit for OS X did work and I was also able
to build with the FFMPEG codecs turned on and it played pure media URLS in
the CEF test apps. Tried building the tip of Chromium/CEF  for Windows/32
bit so I could actually try it in LLCEFLib failed overnight - I think
because it now required the Windows 10 SDKs.  Building the same branch we
are currently using for Win32 now to see how it goes.

While that's building, I'll dig into those TV Jiras - I see Whirly posted
them later in the thread.

On Thu, May 19, 2016 at 2:24 AM, Nicky D. 
wrote:

> Yep, that's a concern - I believe we used QuickTime to play MP3s too so
>> that would be even more wasteful.
>>
>>
> The Quicktime plugin is used for a lot of content. And yes, you are
> correct it is used to MP3 when it is used as MOAP.
>
>
>
>> The answer might be to do this anyway so we enable videos embedded in web
>> content, play video URLs with the LibVLC plugin and come up with a
>> lightweight solution (FMODEx??) for MP3s.
>>
>
>
> I am in favor of enabling those codecs for CEF, for the sake of being able
> to play a lot more (HTML5) content inside CEF than we can do now.
> If resources for the whole media change so scarce that that the question
> would be CEF or mostly no MOAP at all, then CEF would
> be a solution. Mind you not the best one, but at least better than nothing.
> Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF
> just so they work in the browser.
> I know there is demand for those, there is also two Jiras for that, so TVs
> can use HTML5. I can dig those two Jira up (or ask Whirly)
> if people are interested in the tickets.
>
>


-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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)]

My understanding was that QuickTime was used to play MP3 URLs on a prim or
parcel - QA reported that uninstalling QuickTime resulted in those files
not playing anymore and that assertion is backed up by what's in
mime_types.xml and it's friends.



On Wed, May 18, 2016 at 9:49 PM, Darien Caldwell 
wrote:

> Using CEF for media is what I've been saying since CEF support was
> announced for the viewer. I think it would be a clean solution. The viewer
> already runs 3 instances of CEF at startup, using one of those for media
> wouldn't really add any additional load.
>
> The viewer is already using something else (FMODEX maybe) for MP3, as it
> works without Quicktime installed.
>
> On Wed, May 18, 2016 at 5:25 PM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
>> Yep, that's a concern - I believe we used QuickTime to play MP3s too so
>> that would be even more wasteful.
>>
>> The answer might be to do this anyway so we enable videos embedded in web
>> content, play video URLs with the LibVLC plugin and come up with a
>> lightweight solution (FMODEx??) for MP3s.
>>
>> On Wed, May 18, 2016 at 4:51 PM, Cinder Roxley 
>> wrote:
>>
>>> On May 18, 2016 at 5:40:18 PM, Callum Prentice (Callum) (
>>> cal...@lindenlab.com) wrote:
>>>
>>> Digesting all the suggestions here - thank you.
>>>
>>> Intrigued by Nicky's suggestion, I am currently trying to build CEF
>>> directly via Chromium - first attempt is without the extra flags
>>> (proprietary_codecs=1 ffmpeg_branding=Chrome).  Building the branch in use
>>> in the viewer failed with a bunch of errors - fixable but there were just
>>> too many. Still not sure *why* it fails - I would expect specifying a
>>> branch would chckout and build a tagged point in the repo that built.
>>> Maybe because I'm on a slightly older Xcode and on 10.10 vs 10.11?
>>>
>>> Now trying the tip for OS X /64bit (only have my OS X box with me today)
>>> - if this works (on 9856 of 15438 files) then I have high hopes we can
>>> build it with the flags switched on for the platforms and bit widths we
>>> care about.
>>>
>>> Do people agree that this would be the best solution?  It would, I think
>>> play media URLs directly in the CEF plugin like Chrome does and of course,
>>> allow us to support embedded media.
>>>
>>>
>>> I think it’s a little heavy to run a browser instance to play a video.
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>>
>> CALLUM PRENTICE | Software Engineer
>>
>> LINDEN LAB | Create Virtual Experiences 
>>
>> ___
>> 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
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Whirly Fizzle]

The JIRA issues Nicky referenced are:

https://jira.secondlife.com/browse/BUG-11008 - [CEF] MPEG4 and AAC video not 
working in TV object

https://jira.secondlife.com/browse/BUG-11606 - Missing proprietary codec support

Date: Thu, 19 May 2016 11:24:50 +0200
From: sl.nicky...@googlemail.com
To: cal...@lindenlab.com
CC: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Replacement for QuickTime media plugin - a straw 
man proposal
Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF just 
so they work in the browser.I know there is demand for those, there is also two 
Jiras for that, so TVs can use HTML5. I can dig those two Jira up (or ask 
Whirly)if people are interested in the tickets.


___
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

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

[Henri Beauchamp]

On Wed, 18 May 2016 16:40:14 -0700, Callum Prentice (Callum) wrote:

> Digesting all the suggestions here - thank you.
> 
> Intrigued by Nicky's suggestion, I am currently trying to build CEF
> directly via Chromium - first attempt is without the extra flags
> (proprietary_codecs=1 ffmpeg_branding=Chrome).  Building the branch in use
> in the viewer failed with a bunch of errors - fixable but there were just
> too many. Still not sure *why* it fails - I would expect specifying a
> branch would chckout and build a tagged point in the repo that built.

Welcome to the wonderful world of Chrome/CEF... It's indeed surprising to
see how badly they screwed up the build system and what totally insane
amounts of time (hours !) and efforts (manual patching) are required to
build their browser (when Firefox builds flawlessly in under 20 minutes)...

> Do people agree that this would be the best solution?

Definitely NOT !

Please, see my prevous messages in this list (the last posted a few
minutes ago).

Please, pretty please, don't do that !!!

Regards,

Henri.
___
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

[Nicky D.]

>
> Yep, that's a concern - I believe we used QuickTime to play MP3s too so
> that would be even more wasteful.
>
>
The Quicktime plugin is used for a lot of content. And yes, you are correct
it is used to MP3 when it is used as MOAP.



> The answer might be to do this anyway so we enable videos embedded in web
> content, play video URLs with the LibVLC plugin and come up with a
> lightweight solution (FMODEx??) for MP3s.
>


I am in favor of enabling those codecs for CEF, for the sake of being able
to play a lot more (HTML5) content inside CEF than we can do now.
If resources for the whole media change so scarce that that the question
would be CEF or mostly no MOAP at all, then CEF would
be a solution. Mind you not the best one, but at least better than nothing.
Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF
just so they work in the browser.
I know there is demand for those, there is also two Jiras for that, so TVs
can use HTML5. I can dig those two Jira up (or ask Whirly)
if people are interested in the tickets.
___
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

[Henri Beauchamp]

On Wed, 18 May 2016 21:49:46 -0700, Darien Caldwell wrote:

> Using CEF for media is what I've been saying since CEF support was
> announced for the viewer. I think it would be a clean solution.

That solution would be plain *dirty* and totally wasteful (about 80Mb
per new CEF plugin instance), it would also be a big issue for old
computers and 32 bits OSes (and yes, there are still people using
those, mind you !).

Like I wrote in this list in an earlier message, using the CEF plugin
to play streaming shared media is plain YUCK !

> The viewer already runs 3 instances of CEF at startup,

Speak for your viewer... The Cool VL Viewer doesn't have any CEF
(or QtWebkit, since it can also still use that one, for Windows XP
users, who can't have a working CEF: the Windows CEF pre-built
library is not compiled any more to support Windows XP...) plugin
running unless there is a web media/UI element open.

> using one of those for media wouldn't really add any additional load.

You would need *one instance per shared media face*, not just one for
all shared media around !

It would be tremendously wasteful of resources and would slow down
things (CEF needs to refresh its frames 60 times per second, and it's
not especially speedy when compared to a plain video stream played
via gstreamer or VLC, the latter two also be playing the stream only
at its native frame rate, never more).

> The viewer is already using something else (FMODEX maybe) for MP3, as
> it works without Quicktime installed.

Yes, using FMOD Ex for playing plain sound shared media is an option,
but since the latter are rather rare (audio streams in SL are usually
played via the parcel streaming music channel), it would be acceptable
to use gstreamer (which is not much more more wasteful than FMOD and is
also, by designed, adapated to plain sound stream playin) or vlc (there
would likeley be wome wastage here, since AFAIK vlc is primarily designed
to play video streams).

Henri.
___
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

[Darien Caldwell]

Using CEF for media is what I've been saying since CEF support was
announced for the viewer. I think it would be a clean solution. The viewer
already runs 3 instances of CEF at startup, using one of those for media
wouldn't really add any additional load.

The viewer is already using something else (FMODEX maybe) for MP3, as it
works without Quicktime installed.

On Wed, May 18, 2016 at 5:25 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> Yep, that's a concern - I believe we used QuickTime to play MP3s too so
> that would be even more wasteful.
>
> The answer might be to do this anyway so we enable videos embedded in web
> content, play video URLs with the LibVLC plugin and come up with a
> lightweight solution (FMODEx??) for MP3s.
>
> On Wed, May 18, 2016 at 4:51 PM, Cinder Roxley 
> wrote:
>
>> On May 18, 2016 at 5:40:18 PM, Callum Prentice (Callum) (
>> cal...@lindenlab.com) wrote:
>>
>> Digesting all the suggestions here - thank you.
>>
>> Intrigued by Nicky's suggestion, I am currently trying to build CEF
>> directly via Chromium - first attempt is without the extra flags
>> (proprietary_codecs=1 ffmpeg_branding=Chrome).  Building the branch in use
>> in the viewer failed with a bunch of errors - fixable but there were just
>> too many. Still not sure *why* it fails - I would expect specifying a
>> branch would chckout and build a tagged point in the repo that built.
>> Maybe because I'm on a slightly older Xcode and on 10.10 vs 10.11?
>>
>> Now trying the tip for OS X /64bit (only have my OS X box with me today)
>> - if this works (on 9856 of 15438 files) then I have high hopes we can
>> build it with the flags switched on for the platforms and bit widths we
>> care about.
>>
>> Do people agree that this would be the best solution?  It would, I think
>> play media URLs directly in the CEF plugin like Chrome does and of course,
>> allow us to support embedded media.
>>
>>
>> I think it’s a little heavy to run a browser instance to play a video.
>>
>> --
>> 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
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>
> ___
> 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

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

[Callum Prentice (Callum)]

Yep, that's a concern - I believe we used QuickTime to play MP3s too so
that would be even more wasteful.

The answer might be to do this anyway so we enable videos embedded in web
content, play video URLs with the LibVLC plugin and come up with a
lightweight solution (FMODEx??) for MP3s.

On Wed, May 18, 2016 at 4:51 PM, Cinder Roxley 
wrote:

> On May 18, 2016 at 5:40:18 PM, Callum Prentice (Callum) (
> cal...@lindenlab.com) wrote:
>
> Digesting all the suggestions here - thank you.
>
> Intrigued by Nicky's suggestion, I am currently trying to build CEF
> directly via Chromium - first attempt is without the extra flags
> (proprietary_codecs=1 ffmpeg_branding=Chrome).  Building the branch in use
> in the viewer failed with a bunch of errors - fixable but there were just
> too many. Still not sure *why* it fails - I would expect specifying a
> branch would chckout and build a tagged point in the repo that built.
> Maybe because I'm on a slightly older Xcode and on 10.10 vs 10.11?
>
> Now trying the tip for OS X /64bit (only have my OS X box with me today) -
> if this works (on 9856 of 15438 files) then I have high hopes we can build
> it with the flags switched on for the platforms and bit widths we care
> about.
>
> Do people agree that this would be the best solution?  It would, I think
> play media URLs directly in the CEF plugin like Chrome does and of course,
> allow us to support embedded media.
>
>
> I think it’s a little heavy to run a browser instance to play a video.
>
> --
> 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
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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 18, 2016 at 5:40:18 PM, Callum Prentice (Callum) (cal...@lindenlab.com 
 ) wrote:
 
Digesting all the suggestions here - thank you.

Intrigued by Nicky's suggestion, I am currently trying to build CEF directly 
via Chromium - first attempt is without the extra flags (proprietary_codecs=1 
ffmpeg_branding=Chrome).  Building the branch in use in the viewer failed with 
a bunch of errors - fixable but there were just too many. Still not sure *why* 
it fails - I would expect specifying a branch would chckout and build a tagged 
point in the repo that built.  Maybe because I'm on a slightly older Xcode and 
on 10.10 vs 10.11? 

Now trying the tip for OS X /64bit (only have my OS X box with me today) - if 
this works (on 9856 of 15438 files) then I have high hopes we can build it with 
the flags switched on for the platforms and bit widths we care about.

Do people agree that this would be the best solution?  It would, I think play 
media URLs directly in the CEF plugin like Chrome does and of course, allow us 
to support embedded media.


I think it’s a little heavy to run a browser instance to play a video.

-- 
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)]

Digesting all the suggestions here - thank you.

Intrigued by Nicky's suggestion, I am currently trying to build CEF
directly via Chromium - first attempt is without the extra flags
(proprietary_codecs=1 ffmpeg_branding=Chrome).  Building the branch in use
in the viewer failed with a bunch of errors - fixable but there were just
too many. Still not sure *why* it fails - I would expect specifying a
branch would chckout and build a tagged point in the repo that built.
Maybe because I'm on a slightly older Xcode and on 10.10 vs 10.11?

Now trying the tip for OS X /64bit (only have my OS X box with me today) -
if this works (on 9856 of 15438 files) then I have high hopes we can build
it with the flags switched on for the platforms and bit widths we care
about.

Do people agree that this would be the best solution?  It would, I think
play media URLs directly in the CEF plugin like Chrome does and of course,
allow us to support embedded media.

--Cal

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?
>
> Many thanks in advance.
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Henri Beauchamp]

On Wed, 18 May 2016 12:16:27 +0200, Nicky D. wrote:

> Point 1, bundling a lot of additional libraries probably also holds true
> for libvlc.
> One way or the other all those needed plugins need to end on the users PC,
> no matter if it is gstreamer or vlc.

True... I admit I didn't have a look at the vlc bundle for Windows. Under
Linux, either won't be much of an issue, since all the necessary plugins/
CODECs packages will most likely already have been installed by default
during OS installation.

> ffmpegsumo might be another alternative, but this again needs building
> Chromium.

I was under the impression that ffmpegsumo got removed from recent CEF
releases... Also, ffmpeg is, in my opinion and experience, an horrible
pile of crapastic spaghetti... One version will more or less work with
some media, and the next will crash lamentably... For example, ffmpeg
v1.2 is much reliabler than (any, to date) v2 for *.ts (DVB-T streams)
videos conversions...

> I have a feeling at least for Linux gstreamer will be the easier one
> to bundle (just rely on the installed gstreamer 1.0 installation on
> the users machine).

Well, the current plugin relies on gstreamer v0.10 and, in some Linux
distros, v1.0 (when at all available) doesn't play well when installed
along 0.10 (mainly because of a bad packaging from the distro maker)...
That's in fact an argument against gstreamer, since most distros are
(or have been) transitionning to gstreamer v1.0 and transition periods
always lead to problems for the final user...

> It is supposed to be "Just add proprietary_codecs:1 to cef.gypi'
> That said there's probably the devil in the details, according to:
> http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=10741 some
> had problems, but there's also a newer thread at
> http://magpcss.org/ceforum/viewtopic.php?f=6&t=13515
> claiming success.

I'll have a look, time permitting; I'm also in the process of migrating
my main system to a newer Linux distro and given the high level of
customizations I use (which involves recompiling many packages with
patches or different compile options), it will take time...

> I'd be interested in the resulting binary, maybe the ffmpeg parts
> could really be reused for a media plugin without the need for either
> vlc or gstreamer.
> If you can share a Linux (x64 preferred) version, that would be most
> welcome.

I always make the Cool VL Viewer specific packages I use available on
my website ( http://sldev.free.fr/libraries/ ) and you can bet that if
I get CEF to compile with all plugins enabled, the resulting pre-built
libraries will indeed be used by my viewer ! ;-)

Henri.
___
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

[Nicky D.]

>
>
> Technical, maybe. As pointed out by Nicky, the main annoyances with
> gstreamer are: 1. the amount of additional libraries that would have
> to be bundled together with the viewer, and: 2. the runtime symbol
> resolution and DSO loading which complicates the plugin code, but
> since that plugin code exists already, point 2 is in fact already
> solved.
>
>
Point 1, bundling a lot of additional libraries probably also holds true
for libvlc.
One way or the other all those needed plugins need to end on the users PC,
no
matter if it is gstreamer or vlc.
ffmpegsumo might be another alternative, but this again needs building
Chromium.



>
> I think that Nicky is mistaken by thinking that, because the LGPLed
> plugin code would have to use a GPL CODEC, then that CODEC DSO/library
> won't be usable: what counts, regarding the viewer code license, is the
> actual code of the viewer, not the license of the libraries that it
> uses (else, a GPL software won't be able to use Windows DLLs, for
> example, i.e. it won't be possible to use any GPL software on a closed
> source operating system).
>
>
You are right on that one. I do not understand the legal implications, thus
what
I wanted to point out that there could be the possibility of a problem with
some codecs.
But I did not know if there is a problem or not.



>
> This said, I'm pretty neutral about the final, adopted solution
> (gstreamer or vlc); I initially pointed gstreamer as "the way to go"
> because the gstreamer plugin code already existed and was functional
> (and is still used) for Linux, and pre-built gstreamer libraries/SDK
> also existed for Windows.
>
>
I have a feeling at least for Linux gstreamer will be the easier one to
bundle
( just rely on the installed gstreamer 1.0 installation on the users
machine).
That said I have no strong opinion about one of the two either. As long as
it work
I am fine with both.


> I did build CEF under Linux (for both 32 and 64 bits) because of the
> tcmalloc issue with CEF prebuilt packages for this OS; clearly, it was
> a major PITA...
> I was however unaware of these particular flags: if anyone could give
> me pointers (i.e. what flags to enable and how), I could give it a try
> and report how easy (or rather, how painful) it would be to rebuild CEF
> with them, and could provide you with a "recipe", like that one:
> http://sldev.free.fr/libraries/sources/cef-rebuild-steps-2526.txt
>
>

It is supposed to be "Just add proprietary_codecs:1 to cef.gypi'
That said there's probably the devil in the details, according to:
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=10741 some
had problems, but there's also a newer thread at
http://magpcss.org/ceforum/viewtopic.php?f=6&t=13515
claiming success.

I'd be interested in the resulting binary, maybe the ffmpeg parts
could really be reused for a media plugin without the need for either
vlc or gstreamer.
If you can share a Linux (x64 preferred) version, that would be most
welcome.

Cheers,
   Nicky
___
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

[Henri Beauchamp]

On Tue, 17 May 2016 16:32:01 -0700, Callum Prentice (Callum) wrote:

> Understood Nicky - thanks for the insight.
> 
> Messages here as well as some digging I've done today suggest that
> trying to make GStreamer work on Windows is going to be fraught with
> technical and legal issues.

Technical, maybe. As pointed out by Nicky, the main annoyances with
gstreamer are: 1. the amount of additional libraries that would have
to be bundled together with the viewer, and: 2. the runtime symbol
resolution and DSO loading which complicates the plugin code, but
since that plugin code exists already, point 2 is in fact already
solved.

As for the legal side, I see no difference between all possible
solutions: should there be an issue with a particular CODEC because
of patents, then this issue would be the same with vlc, gstreamer,
quicktime, media player, CEF, etc, etc...

> I'll double check with the legal team but it seems like VLC might be
> a more viable option right now given our limited resources.

I think that Nicky is mistaken by thinking that, because the LGPLed
plugin code would have to use a GPL CODEC, then that CODEC DSO/library
won't be usable: what counts, regarding the viewer code license, is the
actual code of the viewer, not the license of the libraries that it
uses (else, a GPL software won't be able to use Windows DLLs, for
example, i.e. it won't be possible to use any GPL software on a closed
source operating system).

I do think your legal team provided you with the right answer: there
is no issue whatsoever, be it gstreamer, vlc (or any other (L)GPL
solution).


This said, I'm pretty neutral about the final, adopted solution
(gstreamer or vlc); I initially pointed gstreamer as "the way to go"
because the gstreamer plugin code already existed and was functional
(and is still used) for Linux, and pre-built gstreamer libraries/SDK
also existed for Windows.

My only wish is that the final solution will be adopted (and
implemented !) for all OSes (Linux included) so that we get an uniform
way to deal with media and avoid incompatibility issues (for example,
in your vlc-enabled test viewer, you added code to invert upside down
the media textures on shared media object faces, something that would
be incompatible with the current gstreamer plugin).

> Great idea re: CEF too - that'd be a huge win.  Building Chromium
> then CEF with the flags enabled seems pretty daunting though and I
> think requires some serious hardware/RAM - has anyone tried that ?

I did build CEF under Linux (for both 32 and 64 bits) because of the
tcmalloc issue with CEF prebuilt packages for this OS; clearly, it was
a major PITA...
I was however unaware of these particular flags: if anyone could give
me pointers (i.e. what flags to enable and how), I could give it a try
and report how easy (or rather, how painful) it would be to rebuild CEF
with them, and could provide you with a "recipe", like that one:
http://sldev.free.fr/libraries/sources/cef-rebuild-steps-2526.txt

Regards,

Henri.
___
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)]

Understood Nicky - thanks for the insight.

Messages here as well as some digging I've done today suggest that trying
to make GStreamer work on Windows is going to be fraught with technical and
legal issues.

I'll double check with the legal team but it seems like VLC might be a more
viable option right now given our limited resources.

Great idea re: CEF too - that'd be a huge win.  Building Chromium then CEF
with the flags enabled seems pretty daunting though and I think requires
some serious hardware/RAM - has anyone tried that ?



On Tue, May 17, 2016 at 3:22 PM, Nicky D. 
wrote:

> 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.
>>
>>
> The complexity IMO comes from two sources:
> A) The original author did opt do resolve all the gstreamer functions via
> dso loading and getting the needed symbols out of the dll/so/dylib at
> runtime. This adds a lot of boilerplate code.
> B) Implementing a gstreamer video plugin. I am not sure why this was done.
> You should be able to get the same result with an appsink and probably a
> videoscale filter.
>
> Getting rid of B makes porting to gstreamer 1.0 almost trivial. I played
> with that a good while ago, but I did not bother to add the videoscale
> filter, so the result was not correct.
>
> Taking it to Windows from there should be mostly trivial, but the devil
> might be in the details there.
>
> Regarding VLC, afaik some parts (some plugins for example) are still GPL?
> I am not sure about the implications of that.
>
> If the lawyers are okay with libvlc / gstreamer, what about enabling
> proprietary in CEF in addition. Not to use CEF as the media plugin, but to
> allowed it to play embedded media.
>
>


-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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)]

It would be a lot of work to come up with a per-platform decoder for say,
MPEG4 files. I'm not aware of a way to decode media into a buffer on
Windows for example that works across all versions - as far as I remember,
you have to set up Windows Media player before it'll do anything.

On Tue, May 17, 2016 at 12:28 PM, Geir Nøklebye 
wrote:

> Use the capabilities of the native operating systems.
>
> There is no reason at all why for OS X you should not use the system
> frameworks for media and audio. They are battle tested on virtually over a
> billion devices daily. They are also licensed to use for anyone with an
> Apple Developer ID.
>
> Equivalent is probably the case for Windows, while for Linux there
> landscape is much more complex.
>
> Geir Nøklebye
> ___
> 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
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Nicky D.]

>
> 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.
>
>
The complexity IMO comes from two sources:
A) The original author did opt do resolve all the gstreamer functions via
dso loading and getting the needed symbols out of the dll/so/dylib at
runtime. This adds a lot of boilerplate code.
B) Implementing a gstreamer video plugin. I am not sure why this was done.
You should be able to get the same result with an appsink and probably a
videoscale filter.

Getting rid of B makes porting to gstreamer 1.0 almost trivial. I played
with that a good while ago, but I did not bother to add the videoscale
filter, so the result was not correct.

Taking it to Windows from there should be mostly trivial, but the devil
might be in the details there.

Regarding VLC, afaik some parts (some plugins for example) are still GPL? I
am not sure about the implications of that.

If the lawyers are okay with libvlc / gstreamer, what about enabling
proprietary in CEF in addition. Not to use CEF as the media plugin, but to
allowed it to play embedded media.
___
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

[Geir Nøklebye]

Use the capabilities of the native operating systems.

There is no reason at all why for OS X you should not use the system frameworks 
for media and audio. They are battle tested on virtually over a billion devices 
daily. They are also licensed to use for anyone with an Apple Developer ID. 

Equivalent is probably the case for Windows, while for Linux there landscape is 
much more complex.

Geir Nøklebye
___
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)]

Thanks Nicky - lots of info there for me to look at.

On Mon, May 16, 2016 at 4:39 PM, Nicky Perian  wrote:

> https://jira.secondlife.com/browse/OPEN-151
> Dated from when fmod went to fmodex
> Kokua used gstreamer for streaming for windows, but went to fmodex because
> of code being out of date with plugins.
> Specfic to this was not playing some stream rates.
>
> I could set Kokua back to gstreamer but would need to autobuild1.0 the
> archives.
>
> There is an overhead of the gstreamer plugins dll's. iirc it was about 25
> MB.
>
> Kokua still uses gstreamer for linux as a lot of the linux users want as
> much opensource as possible.
>
> Linux version relies on distro packages for the plugins.
>
>
> On Mon, May 16, 2016 at 5:09 PM, Cinder Roxley 
> wrote:
>
>> On May 16, 2016 at 4:03:29 PM, Callum Prentice (Callum) (
>> cal...@lindenlab.com) wrote:
>>
>>   Do you know if anyone has made a Windows or OS X version of it ?
>>> ​
>>>
>>>
>>> I made an attempt three years ago, got it working on OS X. Got
>>> frustrated with mingw and moved on to something else. I know the Imprudence
>>> team had some success with replacing both FMOD and Quicktime with gstreamer
>>> earlier than that, but this issue from their tracker shows that they then
>>> debated moving to FFMpeg or libvlc instead:
>>> https://sourceforge.net/p/team-purple/imprudence/tickets/340/
>>> ​
>>>
>>
>> Good info - I'll go take a look - thanks Cinder.​
>>  ​
>>
>> Looks like this is the last efforts on gstreamer for the viewer from
>> Inworldz. Autobuild 3p for building gstreamer 1.0 win32:
>> https://bitbucket.org/mccabe/3p-gstreamer-sdk-x86-iw
>> --
>> 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
>>
>
>


-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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

[Nicky Perian]

https://jira.secondlife.com/browse/OPEN-151
Dated from when fmod went to fmodex
Kokua used gstreamer for streaming for windows, but went to fmodex because
of code being out of date with plugins.
Specfic to this was not playing some stream rates.

I could set Kokua back to gstreamer but would need to autobuild1.0 the
archives.

There is an overhead of the gstreamer plugins dll's. iirc it was about 25
MB.

Kokua still uses gstreamer for linux as a lot of the linux users want as
much opensource as possible.

Linux version relies on distro packages for the plugins.


On Mon, May 16, 2016 at 5:09 PM, Cinder Roxley 
wrote:

> On May 16, 2016 at 4:03:29 PM, Callum Prentice (Callum) (
> cal...@lindenlab.com) wrote:
>
>   Do you know if anyone has made a Windows or OS X version of it ?
>> ​
>>
>>
>> I made an attempt three years ago, got it working on OS X. Got frustrated
>> with mingw and moved on to something else. I know the Imprudence team had
>> some success with replacing both FMOD and Quicktime with gstreamer earlier
>> than that, but this issue from their tracker shows that they then debated
>> moving to FFMpeg or libvlc instead:
>> https://sourceforge.net/p/team-purple/imprudence/tickets/340/
>> ​
>>
>
> Good info - I'll go take a look - thanks Cinder.​
>  ​
>
> Looks like this is the last efforts on gstreamer for the viewer from
> Inworldz. Autobuild 3p for building gstreamer 1.0 win32:
> https://bitbucket.org/mccabe/3p-gstreamer-sdk-x86-iw
> --
> 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
>
___
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 16, 2016 at 4:03:29 PM, Callum Prentice (Callum) (cal...@lindenlab.com 
 ) wrote:
 
  Do you know if anyone has made a Windows or OS X version of it ?
​
   I made an attempt three years ago, got it working on OS X. Got frustrated 
with mingw and moved on to something else. I know the Imprudence team had some 
success with replacing both FMOD and Quicktime with gstreamer earlier than 
that, but this issue from their tracker shows that they then debated moving to 
FFMpeg or libvlc instead: 
https://sourceforge.net/p/team-purple/imprudence/tickets/340/

​

Good info - I'll go take a look - thanks Cinder.​
 ​
Looks like this is the last efforts on gstreamer for the viewer from Inworldz. 
Autobuild 3p for building gstreamer 1.0 win32: 
https://bitbucket.org/mccabe/3p-gstreamer-sdk-x86-iw

-- 
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)]

>
>   Do you know if anyone has made a Windows or OS X version of it ?
> ​
>
>
> I made an attempt three years ago, got it working on OS X. Got frustrated
> with mingw and moved on to something else. I know the Imprudence team had
> some success with replacing both FMOD and Quicktime with gstreamer earlier
> than that, but this issue from their tracker shows that they then debated
> moving to FFMpeg or libvlc instead:
> https://sourceforge.net/p/team-purple/imprudence/tickets/340/
> ​
>
>
Good info - I'll go take a look - thanks Cinder.​
​
___
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 16, 2016 at 3:41:47 PM, Callum Prentice (Callum) (cal...@lindenlab.com 
 ) wrote:
 

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.)

​Understood and thanks for the insight.  Does the GStreamer plugin in the LL 
viewer-release branch still build?
I’m not sure. You’d definitely want to update to gstreamer 1.x though and 
probably ditch the old repo and build with Cerbero.

  Do you know if anyone has made a Windows or OS X version of it ?
​
  I made an attempt three years ago, got it working on OS X. Got frustrated 
with mingw and moved on to something else. I know the Imprudence team had some 
success with replacing both FMOD and Quicktime with gstreamer earlier than 
that, but this issue from their tracker shows that they then debated moving to 
FFMpeg or libvlc instead: 
https://sourceforge.net/p/team-purple/imprudence/tickets/340/

-- 
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 16, 2016 at 3:39:53 PM, Callum Prentice (Callum) (cal...@lindenlab.com 
 ) wrote:
 

​​

 My knowledge about libVLC is rather outdated I would say, however it should be 
able to play quicktime/MOV files so I'm pretty sure it's a bug somewhere.

​
 ​Investigating now - the source of test material when I wrote the original 
QuickTime plugin was the Apple movie trailers site but they all seem to be in 
Apple's own m4v​ format which doesn't play in SL on my system with the latest 
version of QuickTime for windows installed.
M4v is like the video container version of mp4. Here are the official quicktime 
sample files:

https://support.apple.com/en-gw/HT201549

​
  No experience with gstreamer but if i remember when we were arguing for 
replacements a while back that there was a concern about licensing codecs wise. 
If legal cleared it then it should in theory be fine though. Building it for 
windows might be atrocious though.
 ​
 ​That was my experience a long time ago when we briefly discussed using 
GStreamer everywhere. However, I see now there is a page ​- 
 https://gstreamer.freedesktop.org/download/​ - with binary downloads for all 
platforms.
 ​
  Windows building support has come a long way as long as you’re using 
gstreamer 1.x (no more nasty mingw/msys) They claim that it builds with 
Microsoft compilers now.


-- 
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)]

>
>
> 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.)
>

​Understood and thanks for the insight.  Does the GStreamer plugin in the
LL viewer-release branch still build?  Do you know if anyone has made a
Windows or OS X version of it ?
​
___
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)]

>
>
> ​​
> My knowledge about libVLC is rather outdated I would say, however it
> should be able to play quicktime/MOV files so I'm pretty sure it's a bug
> somewhere.
>

​
​Investigating now - the source of test material when I wrote the original
QuickTime plugin was the Apple movie trailers site but they all seem to be
in Apple's own m4v​ format which doesn't play in SL on my system with the
latest version of QuickTime for windows installed.
​


> No experience with gstreamer but if i remember when we were arguing for
> replacements a while back that there was a concern about licensing codecs
> wise. If legal cleared it then it should in theory be fine though. Building
> it for windows might be atrocious though.
>

​
​That was my experience a long time ago when we briefly discussed using
GStreamer everywhere. However, I see now there is a page ​-
https://gstreamer.freedesktop.org/download/​ - with binary downloads for
all platforms.
​
___
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]

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 
 ) 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  


___
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

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

[Dax Dupont]

​Hello,
My knowledge about libVLC is rather outdated I would say, however it should
be able to play quicktime/MOV files so I'm pretty sure it's a bug somewhere.
No experience with gstreamer but if i remember when we were arguing for
replacements a while back that there was a concern about licensing codecs
wise. If legal cleared it then it should in theory be fine though. Building
it for windows might be atrocious though.

-- 
*Have a safe and productive day​,*
*Dax Dupont/Ghost Menjou​*
___
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

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

[Callum Prentice (Callum)]

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?

Many thanks in advance.

-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
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