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

2016-05-18 Thread 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

2016-05-18 Thread 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

2016-05-18 Thread 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

2016-05-18 Thread 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

2016-05-18 Thread 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

2016-05-18 Thread 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

2016-05-18 Thread 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