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

Nicky D. sl.nicky.ml at googlemail.com
Wed May 18 03:16:27 PDT 2016


>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160518/5e06cd6d/attachment.htm 


More information about the opensource-dev mailing list