From andromedaquonset at gmail.com Tue Apr 19 15:40:02 2016 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Tue, 19 Apr 2016 18:40:02 -0400 Subject: [opensource-dev] Quicktime Message-ID: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> In the past, I have been setup for compiling the viewer under VS2005. I haven't done any viewer-compiling for several years. One thing I remember having to do to setup that compiling environment is install the QuicktimeSDK that I had to independently download from Apple, and it took a very long time to install. Now I am seeing a lot of messages urging all Windows users to uninstall Quicktime, that it will never be updated for Windows, and that it hasn't been updated for 10 years. So the first question is "does uninstalling Quicktime have an impact on Second Life? The second question might be 'do I still need the QuicktimeSDK for compiling viewers? Or is there some substitute by now? In trying to find out more info about Quicktime, I find leads that Homeland Security issued the warning. Then I find Homeland Security copied a noticed from CERT, who copied a notice from Comodo.....and then I start having a few doubts about the warning being quite as dire as I first read. From sldev at free.fr Wed Apr 20 00:39:04 2016 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 20 Apr 2016 09:39:04 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> Message-ID: <20160420093904.f6ca076b.sldev@free.fr> On Tue, 19 Apr 2016 18:40:02 -0400, Andromeda Quonset wrote: > Now I am seeing a lot of messages urging all Windows users to > uninstall Quicktime, that it will never be updated for Windows, and > that it hasn't been updated for 10 years. So the first question is > "does uninstalling Quicktime have an impact on Second Life? Yes, it prevents the viewer from reading media files, QuickTime's, but not only: all video and audio media files are read via the QuickTime plugin in the viewer: see the occurrences of "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml (for LL's viewer; some TPV moved this file where it truly belongs, in the app_settings/ sub-directory). > The second question might be 'do I still need the QuicktimeSDK for > compiling viewers? Yes and no. You can make it so that you compile a QuickTime-plugin-less viewer (this might require some changes to the cmake files for LL's viewer: some TPVs provide this choice as a build option, via a cmake define). Not sure if LL's viewer sources build "as is" without QuickTime. In any case, LL's latest viewers (late v3 and v4) require VS2012 to build, and VS2005/VS2010 QuickTime SDK is incompatible with VS2012 (the plugin will still build with the old SDK under VS2012, but the resulting binary will fail to launch). LL apparently got their hand on a VS2012-compatible QuickTime SDK (their VS2012-compiled viewer therefore got a functionnal QuikTime plugin, that you could reuse together with your QuickTime-less viewer builds). Alas, the corresponding pre-built library package is not available to the public (it is hosted on LL's private servers)... > Or is there some substitute by now? Not that I know of... I already pointed out (like years ago), in this very list that alternatives to the long deprecated QuickTime did exist and should be used by LL but, as usual, it felt into deaf ears (LL, once more: "I told you !"). Such an alternative could be the gstreamer SDK for Windows; after all, the gstreamer plugin already exists for Linux, so it should not be an impossible (or even difficult) task to extend its use to Windows builds of the viewer. The only "difficulty" is to create a proper pre-built library/headers package out of the SDK, which will include all the necessary dependencies to build and package the viewer. > In trying to find out more info about Quicktime, I find leads that > Homeland Security issued the warning. Then I find Homeland Security > copied a noticed from CERT, who copied a notice from Comodo.....and > then I start having a few doubts about the warning being quite as > dire as I first read. As usual, such flaws require a thoroughly "cooked up" setup for a (black hat) hacker to exploit it against you. Whether it is possible to exploit QuikTime flaws to gain access to your computer via the QuickTime plugin is, for now and AFAIK, a purely theoretical issue. However, it is unwise to run exploitable software, even if the possibility of a compromission is slim. Regards, Henri. From darien.caldwell at gmail.com Wed Apr 20 10:49:04 2016 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed, 20 Apr 2016 10:49:04 -0700 Subject: [opensource-dev] Quicktime In-Reply-To: <20160420093904.f6ca076b.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> Message-ID: On Wed, Apr 20, 2016 at 12:39 AM, Henri Beauchamp wrote: > On Tue, 19 Apr 2016 18:40:02 -0400, Andromeda Quonset wrote: > > > Now I am seeing a lot of messages urging all Windows users to > > uninstall Quicktime, that it will never be updated for Windows, and > > that it hasn't been updated for 10 years. So the first question is > > "does uninstalling Quicktime have an impact on Second Life? > > Yes, it prevents the viewer from reading media files, QuickTime's, > but not only: all video and audio media files are read via the > QuickTime plugin in the viewer: see the occurrences of > "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml > (for LL's viewer; some TPV moved this file where it truly belongs, > in the app_settings/ sub-directory). > > This is only true for old codebases. The modern viewer using Chromium Embedded Framework no longer requires Quicktime. Quicktime was only used to decode media streams. But the viewers now do this with the CEF codec. > > The second question might be 'do I still need the QuicktimeSDK for > > compiling viewers? > > Yes and no. You can make it so that you compile a QuickTime-plugin-less > viewer (this might require some changes to the cmake files for LL's > viewer: some TPVs provide this choice as a build option, via a cmake > define). Not sure if LL's viewer sources build "as is" without > QuickTime. In any case, LL's latest viewers (late v3 and v4) require > VS2012 to build, and VS2005/VS2010 QuickTime SDK is incompatible with > VS2012 (the plugin will still build with the old SDK under VS2012, but > the resulting binary will fail to launch). > > LL apparently got their hand on a VS2012-compatible QuickTime SDK > (their VS2012-compiled viewer therefore got a functionnal QuikTime > plugin, that you could reuse together with your QuickTime-less viewer > builds). Alas, the corresponding pre-built library package is not > available to the public (it is hosted on LL's private servers)... > LL and Firestorm viewers still compile a media plugin that uses Quicktime, but it's really questionable if it's necessary anymore, given they can do everything through CEF. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160420/eb79d347/attachment.htm From sldev at free.fr Wed Apr 20 11:53:21 2016 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 20 Apr 2016 20:53:21 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> Message-ID: <20160420205321.72f49cf1.sldev@free.fr> On Wed, 20 Apr 2016 10:49:04 -0700, Darien Caldwell wrote: > On Wed, Apr 20, 2016 at 12:39 AM, Henri Beauchamp wrote: > > > Yes, it prevents the viewer from reading media files, QuickTime's, > > but not only: all video and audio media files are read via the > > QuickTime plugin in the viewer: see the occurrences of > > "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml > > (for LL's viewer; some TPV moved this file where it truly belongs, > > in the app_settings/ sub-directory). > > > > > This is only true for old codebases. The modern viewer using Chromium > Embedded Framework no longer requires Quicktime. Quicktime was only used to > decode media streams. But the viewers now do this with the CEF codec. Nope !... Media URLs pointing to *.mp3/4g *.avi *.wav *.you_name_it_media_type *still* use the QuickTime (for Mac and Windows) or gstreamer (for Linux) plugin... There is confusion in many people mind's about media streams embedded inside a web page (which indeed are played via CEF now, provided the web page is using HTML5 or a proper CEF plugin exists for the embedded media stream) and raw media file URLs: the latter are *not* played via CEF. Just look at the code in llviewermedia.cpp... Henri. From darien.caldwell at gmail.com Wed Apr 20 17:06:28 2016 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed, 20 Apr 2016 17:06:28 -0700 Subject: [opensource-dev] Quicktime In-Reply-To: <20160420205321.72f49cf1.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: On Wed, Apr 20, 2016 at 11:53 AM, Henri Beauchamp wrote: > On Wed, 20 Apr 2016 10:49:04 -0700, Darien Caldwell wrote: > > > On Wed, Apr 20, 2016 at 12:39 AM, Henri Beauchamp wrote: > > > > > Yes, it prevents the viewer from reading media files, QuickTime's, > > > but not only: all video and audio media files are read via the > > > QuickTime plugin in the viewer: see the occurrences of > > > "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml > > > (for LL's viewer; some TPV moved this file where it truly belongs, > > > in the app_settings/ sub-directory). > > > > > > > > This is only true for old codebases. The modern viewer using Chromium > > Embedded Framework no longer requires Quicktime. Quicktime was only used > to > > decode media streams. But the viewers now do this with the CEF codec. > > Nope !... Media URLs pointing to *.mp3/4g *.avi *.wav > *.you_name_it_media_type > *still* use the QuickTime (for Mac and Windows) or gstreamer (for Linux) > plugin... > > There is confusion in many people mind's about media streams embedded > inside a web page (which indeed are played via CEF now, provided the > web page is using HTML5 or a proper CEF plugin exists for the embedded > media stream) and raw media file URLs: the latter are *not* played via > CEF. Just look at the code in llviewermedia.cpp... > > Well for some magical reason I have two PCs with no Quicktime installed on them, that have no problem playing parcel media streams. One is Windows 7 and one is Windows 10. Streaming works fine on both... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160420/315edd82/attachment.htm From darien.caldwell at gmail.com Wed Apr 20 17:20:53 2016 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed, 20 Apr 2016 17:20:53 -0700 Subject: [opensource-dev] Quicktime In-Reply-To: <20160420205321.72f49cf1.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: Also just now as an experiment, I removed "media_plugin_quicktime.dll" out of the llplugin directory, and parcel media stll functions. So I can't see how it can be using quicktime at all with A) the plugin removed, and B) no Quicktime installed on the system. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160420/ea3bcb09/attachment.htm From darien.caldwell at gmail.com Wed Apr 20 17:29:52 2016 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed, 20 Apr 2016 17:29:52 -0700 Subject: [opensource-dev] Quicktime In-Reply-To: <20160420205321.72f49cf1.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: Actually after more testing, I do see there's one last vestige Quicktime is required for, and that's MP4 video streams. Won't work without it. But MP3 audio streams don't require Quicktime anymore, which was what I was basing my observation on. So I guess we were both right to some extent. If you don't watch MP4 videos on your parcel, (I certainly don't), you don't need Quicktime installed on your PC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160420/06bbe21c/attachment.htm From kirstiemc555 at hotmail.co.uk Wed Apr 20 18:50:13 2016 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Thu, 21 Apr 2016 02:50:13 +0100 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com>, <20160420093904.f6ca076b.sldev@free.fr>, , <20160420205321.72f49cf1.sldev@free.fr>, Message-ID: Quite a few widely used SL TV sets still use quicktime media. Those TV sets no longer play the movies now I've uninstalled quicktime from my Windows box. It appears LL are removing quicktime support from their viewer https://bitbucket.org/callum_linden/viewer-release-noqt Date: Wed, 20 Apr 2016 17:29:52 -0700 From: darien.caldwell at gmail.com To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Quicktime Actually after more testing, I do see there's one last vestige Quicktime is required for, and that's MP4 video streams. Won't work without it. But MP3 audio streams don't require Quicktime anymore, which was what I was basing my observation on. So I guess we were both right to some extent. If you don't watch MP4 videos on your parcel, (I certainly don't), you don't need Quicktime installed on your PC. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160421/ac931b43/attachment.htm From andromedaquonset at gmail.com Wed Apr 20 19:08:18 2016 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Wed, 20 Apr 2016 22:08:18 -0400 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: <5718361c.6869c20a.f1789.16bb@mx.google.com> There is a comment that says it is a test to see what breaks when Quicktime support is removed. At 09:50 PM 4/20/2016, you wrote: >Quite a few widely used SL TV sets still use quicktime media. Those >TV sets no longer play the movies now I've uninstalled quicktime >from my Windows box. >It appears LL are removing quicktime support from their viewer >https://bitbucket.org/callum_linden/viewer-release-noqt > > >---------- >Date: Wed, 20 Apr 2016 17:29:52 -0700 >From: darien.caldwell at gmail.com >To: opensource-dev at lists.secondlife.com >Subject: Re: [opensource-dev] Quicktime > >Actually after more testing, I do see there's one last vestige >Quicktime is required for, and that's MP4 video streams. Won't work without it. > >But MP3 audio streams don't require Quicktime anymore, which was >what I was basing my observation on. So I guess we were both right >to some extent. If you don't watch MP4 videos on your parcel, (I >certainly don't), you don't need Quicktime installed on your PC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160420/5bba9c7b/attachment.htm From sldev at free.fr Thu Apr 21 04:45:38 2016 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Apr 2016 13:45:38 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: <20160421134538.daa2668e.sldev@free.fr> On Wed, 20 Apr 2016 17:29:52 -0700, Darien Caldwell wrote: > Actually after more testing, I do see there's one last vestige Quicktime is > required for, and that's MP4 video streams. Won't work without it. Simply look at the mime_types.xml file: any URL type that invokes media_plugin_quicktime will fail if the QuickTime plugin (and Windows CODEC, which may be any QuickTime-compatible CODES, and not just the Apple QuickTime one) is absent. Henri. From sldev at free.fr Thu Apr 21 06:02:33 2016 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Apr 2016 15:02:33 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: <20160421150233.6c7cb527.sldev@free.fr> On Thu, 21 Apr 2016 02:50:13 +0100, Whirly Fizzle wrote: > Quite a few widely used SL TV sets still use quicktime media. Those > TV sets no longer play the movies now I've uninstalled quicktime > from my Windows box. Yep. > It appears LL are removing quicktime support from their viewer > https://bitbucket.org/callum_linden/viewer-release-noqt I already tried (months ago, when I noticed that the VS2012 builds were not producing a valid QuickTime plugin with the old QuickTime SDK) the trick consisting in replacing all occurrences of media_plugin_quicktime with media_plugin_cef (or even media_plugin_webkit; Webkit too, could play media, mind you...) in the mime_types.xml file for Windows, but got faced with the same problem as the one described by Nicky in the last commit to that experimental viewer (https://bitbucket.org/callum_linden/viewer-release-noqt/commits/540b99f9160fa478cade308f388e9303ed98b232) Many media URLs are then considered as files for download by CEF, causing a rejection of the URL and a failure to play the media. Plus, frankly, is it reasonnable to launch a new instance of CEF (i.e. a *full* embedded web browser instance, using over 80Mb of memory while the QuickTime plugin uses 100 times less) for *each* playing media on surrounding prims ? That's a bit like using a hammer and an anvil to squash a bug, don't you think so ?... Quite inelegant ! YUCK !!! Like I already wrote earlier, the way to go is to use the gstreamer SDK for Windows and get a gstreamer plugin compiled for the latter. Henri. From cinder at alchemyviewer.org Thu Apr 21 06:18:37 2016 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 21 Apr 2016 13:18:37 +0000 Subject: [opensource-dev] Quicktime In-Reply-To: <20160421150233.6c7cb527.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> Message-ID: <0100015438f8e7a0-724c2d84-c1af-45d8-b762-84c903999e53-000000@email.amazonses.com> On April 21, 2016 at 7:02:37 AM, Henri Beauchamp (sldev at free.fr ) wrote: Plus, frankly, is it reasonnable to launch a new instance of CEF (i.e.? a *full* embedded web browser instance, using over 80Mb of memory while? the QuickTime plugin uses 100 times less) for *each* playing media on? surrounding prims ? That's a bit like using a hammer and an anvil to? squash a bug, don't you think so ?... Quite inelegant ! YUCK !!!? Agreed. Like I already wrote earlier, the way to go is to use the gstreamer SDK? for Windows and get a gstreamer plugin compiled for the latter.? With all due respect, gstreamer is a major pain to build on Windows and runs afoul of dozens of patents and licenses. It?s fine if you?re building from source for linux, but it?s a lawsuit waiting to happen for commercial software if you want to play any ?standard? media format like h264 or mp3. Something like libvlc might work if you want a cross platform library (but again, there are per-install royalties to use h264 so you?d still be screwed on mp4.) Platform-specific plugins could take advantage of the OS?s media playback capabilities, without license and patent headaches. --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160421/fb36f59b/attachment.htm From oz at lindenlab.com Thu Apr 21 06:23:25 2016 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 21 Apr 2016 09:23:25 -0400 Subject: [opensource-dev] Quicktime In-Reply-To: <20160420205321.72f49cf1.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <20160420093904.f6ca076b.sldev@free.fr> <20160420205321.72f49cf1.sldev@free.fr> Message-ID: <5718D44D.9090406@lindenlab.com> On 2016-04-20 14:53 , Henri Beauchamp wrote: >> >This is only true for old codebases. The modern viewer using Chromium >> >Embedded Framework no longer requires Quicktime. Quicktime was only used to >> >decode media streams. But the viewers now do this with the CEF codec. > Nope !... Media URLs pointing to *.mp3/4g *.avi *.wav *.you_name_it_media_type > *still* use the QuickTime (for Mac and Windows) or gstreamer (for Linux) > plugin... > > There is confusion in many people mind's about media streams embedded > inside a web page (which indeed are played via CEF now, provided the > web page is using HTML5 or a proper CEF plugin exists for the embedded > media stream) and raw media file URLs: the latter are*not* played via > CEF. Just look at the code in llviewermedia.cpp... > You're correct for all released viewers, Henri, but we are in the process of building and testing to see what works with no quicktime plugin at all. -- OZ LINDEN | Engineering Director, Second Life email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160421/e0c5bbd6/attachment.htm From sldev at free.fr Thu Apr 21 06:36:17 2016 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Apr 2016 15:36:17 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: <0100015438f8e7a0-724c2d84-c1af-45d8-b762-84c903999e53-000000@email.amazonses.com> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <0100015438f8e7a0-724c2d84-c1af-45d8-b762-84c903999e53-000000@email.amazonses.com> Message-ID: <20160421153617.33f93ede.sldev@free.fr> On Thu, 21 Apr 2016 13:18:37 +0000, Cinder Roxley wrote: >> Like I already wrote earlier, the way to go is to use the gstreamer SDK? >> for Windows and get a gstreamer plugin compiled for the latter.? > > With all due respect, gstreamer is a major pain to build on Windows It's a pain to build under Linux too :-D But CEF is even more painful to build, so... Plus that "pain" is to go through only once and for all, to build the pre-built package that will then be used to build all the viewers (painlessly). > and runs afoul of dozens of patents and licenses. It?s fine if you?re > building from source for linux, but it?s a lawsuit waiting to happen for > commercial software if you want to play any ?standard? media format like > h264 or mp3. Please, elaborate and give pointers. There are dozens (and probably closer to dozens of dozens) of Linux and *BSD distributions (i.e. binary, ready to run OS+software, commercial or not) providing and using gstreamer, and I never heard about any lawsuite related to this fact... > Something like libvlc might work if you want a cross platform library > (but again, there are per-install royalties to use h264 so you?d still > be screwed on mp4.) Software patents are a US thingy... I'm glad the UE rejected them. MP4, H264 and anything involving patented protocols and formats are free to play in the whole world, but in the US... *If* such patents prevent to provide a full set of CODECs, I guess LL would have to restrict their number in their pre-built library package (gstreamer is not monolithic, it is fully modular), but TPV developers outside the US won't have to bother with such restsictions... > Platform-specific plugins could take advantage of the OS?s media playback > capabilities, without license and patent headaches. Perhaps for Windows. But again, Linux don't have any patent for playing media and no lawsuite whatsoever prevent Linux distros to be distributed (including in the US)... I'm still extremely doubtful about such patent issues for software that are only meant to *play* *existing* media files (i.e. media files you acquired legally and already paid any patent for). Henri. From cinder at alchemyviewer.org Thu Apr 21 09:27:07 2016 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 21 Apr 2016 16:27:07 +0000 Subject: [opensource-dev] Quicktime In-Reply-To: <20160421153617.33f93ede.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> Message-ID: <0100015439a57eeb-a4ca830c-25b1-44f0-9d8f-b993d47f98a7-000000@email.amazonses.com> On April 21, 2016 at 9:39:31 AM, Henri Beauchamp (sldev at free.fr ) wrote: On Thu, 21 Apr 2016 13:18:37 +0000, Cinder Roxley wrote:? >> Like I already wrote earlier, the way to go is to use the gstreamer SDK?? >> for Windows and get a gstreamer plugin compiled for the latter.?? >? > With all due respect, gstreamer is a major pain to build on Windows? It's a pain to build under Linux too :-D But CEF is even more painful? to build, so...? Plus that "pain" is to go through only once and for all, to build the? pre-built package that will then be used to build all the viewers? (painlessly).? True. > and runs afoul of dozens of patents and licenses. It?s fine if you?re? > building from source for linux, but it?s a lawsuit waiting to happen for? > commercial software if you want to play any ?standard? media format like? > h264 or mp3.? Please, elaborate and give pointers. There are dozens (and probably closer? to dozens of dozens) of Linux and *BSD distributions (i.e. binary, ready? to run OS+software, commercial or not) providing and using gstreamer, and? I never heard about any lawsuite related to this fact...? These distributions either do not include the patented video formats or provide them in source form for building. This is addressed in gstreamer?s documentation: https://gstreamer.freedesktop.org/documentation/licensing.html?(Licenses of applications using gstreamer) > Something like libvlc might work if you want a cross platform library? > (but again, there are per-install royalties to use h264 so you?d still? > be screwed on mp4.)? Software patents are a US thingy... I'm glad the UE rejected them. MP4,? H264 and anything involving patented protocols and formats are free to? play in the whole world, but in the US... *If* such patents prevent to? provide a full set of CODECs, I guess LL would have to restrict their? number in their pre-built library package (gstreamer is not monolithic,? it is fully modular), but TPV developers outside the US won't have to? bother with such restsictions...? US and Australia, not to mention Canada, United Kingdom, Germany, Japan, and any other country whose legal codes frown upon violation of software patents. Distributing a viewer that decodes the patented video compression puts the end user in legal jeopardy. (Albeit, there is slim to no chance of anyone being prosecuted for decoding h264 in a viewer, but we can?t condone breaking any country?s law on an official Second Life communications channel.) > Platform-specific plugins could take advantage of the OS?s media playback? > capabilities, without license and patent headaches.? Perhaps for Windows. But again, Linux don't have any patent for playing? media and no lawsuite whatsoever prevent Linux distros to be distributed? (including in the US)... I'm still extremely doubtful about such patent? issues for software that are only meant to *play* *existing* media files? (i.e. media files you acquired legally and already paid any patent for).? Linux distributions, for example Ubuntu, don?t ship with proprietary codecs, you must install them after the fact. (You can buy legitimate gstreamer plugins from the Canonical store.) Even if you build the gstreamer-plugins-ugly package from their repo, you?re greeted with a popup the first time you try and play a video with it in the US that what you?re doing may be illegal. As far as patent infringement lawsuits, MPEG-LA, the patent holder, is one of the biggest patent trolls in the industry. Going even as far as billion dollar lawsuits against paid license holders like Microsoft. MPEG LA sues Audiovox?http://www.twice.com/article/257658-Audiovox_Disputes_MPEG_LA_Lawsuit.php MPEG LA sues Alcatel Lucent?http://www.businesswire.com/news/home/20100329006257/en/MPEG-LA-Lawsuit-Alcatel-Lucent-Settled MPEG LA sues Apex?https://www.allbusiness.com/legal/legal-services-litigation/5917877-1.html MPEG LA has sued Google over V8 (for being too similar to h264, MPEG LA lost.) --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160421/19b695ce/attachment-0001.htm From sldev at free.fr Thu Apr 21 10:29:35 2016 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Apr 2016 19:29:35 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: <0100015439a57eeb-a4ca830c-25b1-44f0-9d8f-b993d47f98a7-000000@email.amazonses.com> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <0100015439a57eeb-a4ca830c-25b1-44f0-9d8f-b993d47f98a7-000000@email.amazonses.com> Message-ID: <20160421192935.f06308de.sldev@free.fr> Not wanting to enter a sterile argument about borderline topics, but: On Thu, 21 Apr 2016 16:27:07 +0000, Cinder Roxley wrote: > These distributions either do not include the patented video formats or > provide them in source form for building. This is addressed in gstreamer?s* > documentation: > > https://gstreamer.freedesktop.org/documentation/licensing.html?(Licenses > of applications using gstreamer) This has nothing to do with any SL resident's legal right to play a "patented" media files on their computer using gstreamer (or any other software) CODECs, including in the US (unless the file was not legally acquired and the patent paid for it). As for LL and their viewer itself, like I explained: "*If* such patents prevent to?provide a full set of CODECs, I guess LL would have to restrict their?number in their pre-built library package (gstreamer is not monolithic,?it is fully modular)" So it's not an obstacle but merely a limitaion. Note also that the CEF plugin will be faced with the *exact same* patent issues if it is to be used in place of the QuickTime plugin to play video and audio media files (which, like I explained and what you agreed with, is just "YUCK !" :-D ). > US and Australia, not to mention Canada, United Kingdom, Germany, NOPE ! You can forget about Germany and UK (at least till the "Brexit" for the latter, if it happens), because both countries are part of the UE and the latter totally and definitely rejected software patents. \o/ Regards, Henri. From sl.nicky.ml at googlemail.com Thu Apr 21 10:45:29 2016 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 21 Apr 2016 19:45:29 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: <20160421192935.f06308de.sldev@free.fr> References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <0100015439a57eeb-a4ca830c-25b1-44f0-9d8f-b993d47f98a7-000000@email.amazonses.com> <20160421192935.f06308de.sldev@free.fr> Message-ID: > > So it's not an obstacle but merely a limitaion. Note also that the CEF > plugin will be faced with the *exact same* patent issues if it is to be > used in place of the QuickTime plugin to play video and audio media files > (which, like I explained and what you agreed with, is just "YUCK !" :-D ). > > This is correct and the reason why CEF when using the prebuild version does not include the proprietary codecs. But when we're already on the topic of codecs and licenses, I think fmodex might fall into the same category. It can decode MP3 and does not come with a license for it: http://www.fmod.org/mp3license/ Also if, and I am speaking purely hypothetical here, LL would ban Quicktime and with that MP4 from their viewer and not have a alternate solution, I guess the whole point is moot anyway. I suppose shipping those codecs and being able to play those streams would be a shared experience violation then. Cheers, Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20160421/2d27279b/attachment.htm From sldev at free.fr Thu Apr 21 11:39:59 2016 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Apr 2016 20:39:59 +0200 Subject: [opensource-dev] Quicktime In-Reply-To: References: <5716b3c6.43ecc20a.d275.ffffe0c9@mx.google.com> <0100015439a57eeb-a4ca830c-25b1-44f0-9d8f-b993d47f98a7-000000@email.amazonses.com> <20160421192935.f06308de.sldev@free.fr> Message-ID: <20160421203959.32f5e96d.sldev@free.fr> On Thu, 21 Apr 2016 19:45:29 +0200, Nicky D. wrote: > But when we're already on the topic of codecs and licenses, I think fmodex > might fall into the same category. It can decode MP3 and does not come > with a license for it: http://www.fmod.org/mp3license/ As I understand it, the phrases "Licensing FMOD products does not include a license to use mp3" and "Game developers using mp3 are eligible for the ?game? license which costs $2500 USD per title." just mean that *if* you are a game developer and are including MP3 encoded files in the game you sell, then (and only then), you might(*) have to pay a MP3 license to Thompson Multimedia and that *in no circumstance* does the FMOD license cover your MP3 usage. That's just a "disclaimer", not an interdiction to include FMOD in your product to play MP3 files... Since the SL viewer is not distributed with MP3 files (and only wav files are stored on LL's servers and served by LL to the viewers), this won't be a problem. Keep in mind that the shared/parcel media encountered in SL, are just URLs for files/streams stored anywhere on Internet but on LL's servers. (*) if you are a US/Canadian/Japan(?) citizen, *and* are distributing over 5000 copies of your game: this places me "out of the game" so to speak on both fronts (French citizen and probably less than 5000 users, not to mention I don't sell my viewer) ! :-P > Also if, and I am speaking purely hypothetical here, LL would ban Quicktime > and with that MP4 from their viewer and not have a alternate solution, I > guess the whole point is moot anyway. I suppose shipping those codecs and > being able to play those streams would be a shared experience violation then. Hehe, good one ! :-D Henri.