Re: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1104 --- Ship it! Looks good. Nice job overall bringing the pieces together and excellent test plan. indra/newview/llvieweraudio.cpp <http://codereview.secondlife.com/r/520/#comment1077> Minor point - maybe a warning where you define the fade in/out times that they should not be zero, even for testing. - Callum Prentice On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > --- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > Description > --- > > Audio fading in has been added for when a music stream starts. Audio fading > out has been added for when there is a change in the music stream that is > playing. > > Two dead files have been eliminated. > > An existing bug in how music was not being paused correctly has been fixed. > > When you are teleporting you will hear the music stream from the place you > are leaving. This is a change in behavior; previously the music stream was > stopped when the teleport progress bar was being displayed. > > This code change affects several areas where music is started or stopped. > The new code has evolved significantly, so please look for things that might > not "make sense." > > > This addresses bug STORM-591. > http://jira.secondlife.com/browse/STORM-591 > > > Diffs > - > > doc/contributions.txt 8b455c1b7a5e > indra/newview/lloverlaybar.h 8b455c1b7a5e > indra/newview/lloverlaybar.cpp 8b455c1b7a5e > indra/newview/llpanelnearbymedia.h 8b455c1b7a5e > indra/newview/llpanelnearbymedia.cpp 8b455c1b7a5e > indra/newview/llvieweraudio.h 8b455c1b7a5e > indra/newview/llvieweraudio.cpp 8b455c1b7a5e > indra/newview/llviewermedia.cpp 8b455c1b7a5e > indra/newview/llviewerparcelmgr.cpp 8b455c1b7a5e > > Diff: http://codereview.secondlife.com/r/520/diff/diff > > > Testing > --- > > See the massive test plan in the jira. > > > Thanks, > > Jonathan Yap > > ___ 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] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1105 --- Ship it! Ship It! - Callum Prentice On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > --- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > Description > --- > > Audio fading in has been added for when a music stream starts. Audio fading > out has been added for when there is a change in the music stream that is > playing. > > Two dead files have been eliminated. > > An existing bug in how music was not being paused correctly has been fixed. > > When you are teleporting you will hear the music stream from the place you > are leaving. This is a change in behavior; previously the music stream was > stopped when the teleport progress bar was being displayed. > > This code change affects several areas where music is started or stopped. > The new code has evolved significantly, so please look for things that might > not "make sense." > > > This addresses bug STORM-591. > http://jira.secondlife.com/browse/STORM-591 > > > Diffs > - > > doc/contributions.txt 8b455c1b7a5e > indra/newview/lloverlaybar.h 8b455c1b7a5e > indra/newview/lloverlaybar.cpp 8b455c1b7a5e > indra/newview/llpanelnearbymedia.h 8b455c1b7a5e > indra/newview/llpanelnearbymedia.cpp 8b455c1b7a5e > indra/newview/llvieweraudio.h 8b455c1b7a5e > indra/newview/llvieweraudio.cpp 8b455c1b7a5e > indra/newview/llviewermedia.cpp 8b455c1b7a5e > indra/newview/llviewerparcelmgr.cpp 8b455c1b7a5e > > Diff: http://codereview.secondlife.com/r/520/diff/diff > > > Testing > --- > > See the massive test plan in the jira. > > > Thanks, > > Jonathan Yap > > ___ 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] Viewer Tools Upgrades - with a call for help
> > None of the "right click and run as administrator" is needed; when the > installer needs admin rights to install, it will prompt to do so. > In the past, I've noticed subtle differences in the behavior of packages when you don't explicitly run the installer as an administrator and when you do. Unless you have a strong objection, I'd like to leave those lines in there until we're sure. DX SDK 2010 is not used if you are using the windows 8 SDK or higher (DX > SDK is integrated into windows SDK 8.0 and higher); both VS community and > VS 2013 ultimate install Windows SDK 8.1 and therefore will use the DX there > Interesting - I do see DX headers and libs in the "C:\Program Files (x86)\Windows Kits\8.1" folders. Do you know for sure that builds complete without the separate SDK? If so, we should remove the reference to it - it's huge. > The linked update for Visual studio 2013 points to update 5 CTP; this is a > preview and should not be used for production environment. It should point > to: > http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#DownloadFamilies_5 > which will list the latest stable update. > Good point - noted. and I will change the wiki. A note to run Microsoft Update with the option of installing updates for > other Microsoft products should be included in the last step of installing > VS 2013. This will update all the installed applications from VS 2013 like > SQL server and VS itself. > Good idea. I'd like to document how to enable that - all I see in Windows Update -> Settings are options to change how and when they're updated. Do you know how to change what gets checked? > I will probably have other recommendations after trying the wiki out on a > fresh system that hasn't been tainted with the 2010 build process. > Great stuff. Thanks TankMaster. -- *Callum Prentice *| *Software Engineer* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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] Viewer Tools Upgrades - with a call for help
Did you add the C:\Python27\Scripts folder (or wherever you installed Python) to your path after you 'pip installed' autobuild? Sounds like you did but that's the only thing I can think of. On Wed, Jan 28, 2015 at 12:19 PM, Melissa Browne < moonbots...@centurylink.net> wrote: > Has anyone that has tried to build the viewer per the how to set up a > Windows development environment instructions ran into autobuild not being > recognized? Following the instructions line by line, everything before the > Autobuild Configure section checks out as set and installed correctly > including setting the path in the environment settings. Is there something > possibly missing in the instructions for us noobs? > > MB > > ___ > 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* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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] Viewer Tools Upgrades - with a call for help
Thank you Jonathan - you're right - there should be more notes on how to download and configure the Community version. For the Pro version we use here, I note in the doc that "Uncheck all the "Optional features to install:" - they are not required" - the same sort of thing along with notes on the local/downloader version would help - can you put something together? Perhaps you can clarify what needs to be improved in the Autobuild and Python sections? Reads okay to me but it's sometimes hard to see what's wrong when you're close to it. Looks like the Todo note about autobuild configure options for packages like FMod and Havok was removed when the doc was moved from our internal wiki - can you outline what you'd like to see there and I'll add it. On Wed, Jan 28, 2015 at 12:25 PM, Jonathan Welch wrote: > I've read over the instructions and have started the install process > on a fresh VM. Some notes: > > These instructions should be written assuming the person reading them > is not a developer...yet, but does know their way around when > installing software. > > The yellow info window talks about requirements for installing > windows. Let's drop that part and just list what windows version(s) > these instructions work on. > > The term Cygwin shell is not defined, nor how to access it. > > Let's only have one set of installation instructions, and that for a > package everyone can access: the Community version of the compiler. > If you own a better version of this compiler then you are probably > smart enough to figure out what different/additional steps to perform. > > No mention is made about the online vs offline versions of the > Community file you can download. I picked up the offline version, > which took over two hours to download. If I ever needed to reinstall > this software or if there was some hiccup in the installation process > I would not want to repeat that long download again using the online > method. > > Very important -- when installing the compiler do I need to also > install all those additional optional features that are automatically > checked and which take up precious space on my drive? > > As an addendum to pulling in the offline version, mention should be > made on where to pick up a free package that lets you mount this .ISO > file without first having to burn a disc. > > The instructions for setting up Autobuild and Python need some editing > for grammar, clarity, and consistency. > > NSIS should be under an Optional heading. > > No mention is made about FmodEX -- have these instructions been tested > outside of the lindenlab.com domain? I suspect an additional section > will be necessary for this package. > > Okay, more later, once I have made some additional progress. > > -jonathan > ___ > 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* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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] Viewer Tools Upgrades - with a call for help
Thanks for the clarification Darien - my working assumption TankMaster is that those libs/headers are pulled in via some CMake magic - I'll go check to see if that's the case. On Wed, Jan 28, 2015 at 1:25 PM, Tank Master wrote: > As far as I know, it is only used to detect the GPU name in windows. > Also, if the compile IS using the DX 2010 SDK, there is no documentation on > modifying VS2013 to point to it, which make me wonder if the build > environment is even using the files, let alone seeing them. > ~TM > -- > Date: Wed, 28 Jan 2015 13:22:33 -0800 > From: darien.caldw...@gmail.com > To: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Viewer Tools Upgrades - with a call for help > > Oh and DXERR is removed as well. > > On Wed, Jan 28, 2015 at 1:21 PM, Darien Caldwell < > darien.caldw...@gmail.com> wrote: > > The windows 8.1 version of the DirectX SDK removes the D3DX* library and > changes XNAMath to DirectXMath, so if you use either from those namespaces, > it's not going to work. I don't know exactly what the viewer is using > DirectX for, but as long as it's not using anything from the > removed/renamed libraries, it should be fine to change over. > > > > ___ 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* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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] Viewer Tools Upgrades - with a call for help
I can try it on an XP system tomorrow when I'm in the office and have access to the QA Lab. On Wed, Jan 28, 2015 at 3:11 PM, Jonathan Welch wrote: > From something Tank said at a meeting: will the resulting executable > run on an XP system? If not a note should be put in somewhere about > this restriction. > > On 1/28/15, Callum Prentice (Callum) wrote: > > Thanks for the clarification Darien - my working assumption TankMaster is > > that those libs/headers are pulled in via some CMake magic - I'll go > check > > to see if that's the case. > > > > On Wed, Jan 28, 2015 at 1:25 PM, Tank Master > > wrote: > > > >> As far as I know, it is only used to detect the GPU name in windows. > >> Also, if the compile IS using the DX 2010 SDK, there is no documentation > >> on > >> modifying VS2013 to point to it, which make me wonder if the build > >> environment is even using the files, let alone seeing them. > >> ~TM > >> -- > >> Date: Wed, 28 Jan 2015 13:22:33 -0800 > >> From: darien.caldw...@gmail.com > >> To: opensource-dev@lists.secondlife.com > >> Subject: Re: [opensource-dev] Viewer Tools Upgrades - with a call for > >> help > >> > >> Oh and DXERR is removed as well. > >> > >> On Wed, Jan 28, 2015 at 1:21 PM, Darien Caldwell < > >> darien.caldw...@gmail.com> wrote: > >> > >> The windows 8.1 version of the DirectX SDK removes the D3DX* library and > >> changes XNAMath to DirectXMath, so if you use either from those > >> namespaces, > >> it's not going to work. I don't know exactly what the viewer is using > >> DirectX for, but as long as it's not using anything from the > >> removed/renamed libraries, it should be fine to change over. > >> > >> > >> > >> ___ 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* > > *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum > Linden > > > > Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative > Spaces > > > > Check out what we're working on! <http://lindenlab.com/products> > > > -- *Callum Prentice *| *Software Engineer* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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] Viewer Tools Upgrades - with a call for help
Yep - we need to add the right set of parameters to 'autobuild' to set up FMod, Havok QuickTime etc. Can anyone tell me what they are or point me at the right doc before I start searching. On Thu, Jan 29, 2015 at 12:44 PM, Henri Beauchamp wrote: > On Thu, 29 Jan 2015 11:45:46 +0100, Henri Beauchamp wrote: > > > On Wed, 28 Jan 2015 10:53:11 -0500, Oz Linden (Scott Lawrence) wrote: > > > > > We've also put up a new page of instructions on how to set up a Windows > > > development environment > > > <https://wiki.secondlife.com/wiki/Visual_Studio_2013_Viewer_Builds>. > > > Suggestions for improvement are most welcome here and on the Talk > > > page... we're trying to keep it as simple as possible while being > > > sufficient to build a clean checkout of the viewer. > > > > Missing bits: > > > > - When using Windows 7, you must also update from IE8 to a newer version > > since else, you can't log in to register for a free license from within > > Visual Studio 2013 Community (the IE8 Javascript engine fails on two of > > the scripts used by VS2013). > > > > - To compile a viewer, you'll also need FMOD Ex installed. > > > > Henri. > > I also forgot: there's the Quicktime issue: TPVs need the QuickTime SDK > (v7.3) installed, since the pre-built library in autobuild.xml is on > a private (Linden-only) server... > > 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 > -- *Callum Prentice *| *Software Engineer* *Cell* 650 888 1697 | *Skype* CallumPrentice | *Second Life *Callum Linden Linden Lab <http://www.lindenlab.com/> | Makers of Shared Creative Spaces Check out what we're working on! <http://lindenlab.com/products> ___ 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
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 <https://bitbucket.org/callum_linden/viewer-release-vlc>. 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 <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
> > > > 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
> > > 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
> > 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
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 <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
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 <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
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 <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
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 > <https://bitbucket.org/callum_linden/viewer-release-vlc>. 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 <http://www.lindenlab.com/> > -- 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
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 <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] Firewall block of media files
> > > At one time we could play individual media files on both parcel media and > MOAP such as mov avi wmv that were stored on services such as Dropbox. > I noticed will testing viewer-release-vlc that it these are not allowed. > Can you elaborate what you mean by "not allowed" - they just don't play? If so, it might be that VLC doesn't support those media types. I've certainly been able to play MPEG4 files directly from Dropbox for example. ___ 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
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 <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 >> > > > ___ > 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
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 <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
> > > 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
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
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 <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 > -- 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
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 <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
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 > <https://bitbucket.org/callum_linden/viewer-release-vlc>. 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 t
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
> > > 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] 64 bit viewers build instructions
I'd like to fix that too. Is it just a question of add /LTCG to the jpeglib link command? I see that's done via an nmake makefile and then build via a .sln but I think I see where to add that command. On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian wrote: > Would this be a good time to fix this warning? > > jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL > found; restarting link with /LTCG; add /LTCG to the link command line to > improve linker performance > > Thanks > > On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed wrote: > >> On Nov 29, 2016 11:11 PM, "Nicky Perian" wrote: >> >> > I am unable to get a windows 64 bit build environment. A learning issue >> for me. >> > What commands do you use to switch to 64 bit? >> >> I use: >> >> autobuild build --address-size=64 >> >> :-) >> >> But I don't yet have a clean 64-bit build on any platform. >> > > > ___ > 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
[opensource-dev] Windows 64 bit build issue
I'm working with Nat Linden on the 64 bit viewer build and we've been encountering an odd error - A number of projects in 64 bit only configurations have an entry for "Force Includes" files set to XED:NO. Nothing on Google so we were stumped for a while but eventually tracked it down to a number of lines in CMakeLists.txt files of the form: *add_definitions(/FIXED:NO)*. Evidently, */FI* is the compiler command to include a forced header file - hence the *XED:NO* entry. You can see one here: https://bitbucket.org/lindenlab/viewer64/src/3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 The *FIXED* command is evidently for the linker and not the compiler but I'm not sure (a) if it's needed or (b) if it is, how to direct it at the right place. Has anyone else encountered this and already and figured it out? -- 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] Windows 64 bit build issue
Great. I had an idea that was the case. Thanks again Cinder. On Wed, Nov 30, 2016 at 6:30 PM, Cinder Roxley wrote: > We nuked that whole project and set volume directly on Windows using > waveOutSetVolume(HWAVEOUT, DWORD). > https://bitbucket.org/alchemyviewer/alchemy/commits/ > b3e54a075de4440390bb1be8c9f73bfd94053a01 > > The shim is only needed up to XP and is completely unnecessary with the > availability of WASAPI in Vista and above. > > -- > Cinder Roxley > Sent with Airmail > > On November 30, 2016 at 7:36:24 PM, Callum Linden (cal...@lindenlab.com) > wrote: > > Thanks so much for the speedy reply Cinder. I hoped that was the case and > the build seems okay without it. > > The other perplexing one is for the winmm_shim project. For 64 bit builds > it fails with a bunch of unresolved externals which look to be related to > MMX intrinsic maybe. Not at my computer right now and haven't really > started to investigate but if that rings s bell after your work, please do > let me know. > > Cheers! > > On Nov 30, 2016, at 5:16 PM, Cinder Roxley > wrote: > > It’s not needed. We dropped it in Alchemy when adding 64-bit support, and > it continues to run fine. /FIXED:NO just ensures that code can be position > independent. Maybe at some point this was needed a long time ago for apr > hijinks or Windows98 compatibility or something of that nature, but you can > safely remove it. > > -- > Cinder Roxley > Sent with Airmail > > On November 30, 2016 at 6:55:37 PM, Callum Prentice (Callum) ( > cal...@lindenlab.com) wrote: > > I'm working with Nat Linden on the 64 bit viewer build and we've been > encountering an odd error - A number of projects in 64 bit only > configurations have an entry for "Force Includes" files set to XED:NO. > Nothing on Google so we were stumped for a while but eventually tracked it > down to a number of lines in CMakeLists.txt files of the form: > *add_definitions(/FIXED:NO)*. Evidently, */FI* is the compiler command to > include a forced header file - hence the *XED:NO* entry. You can see one > here: https://bitbucket.org/lindenlab/viewer64/src/ > 3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/ > CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 > > The *FIXED* command is evidently for the linker and not the compiler but > I'm not sure (a) if it's needed or (b) if it is, how to direct it at the > right place. > > Has anyone else encountered this and already and figured it out? > > -- > > 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 > > -- 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] 64 bit viewers build instructions
Yep - we;re all following along similar tracks by the sound of it Nicky :) With my latest changes, if I unload the VLC plugin (as you say, that needs a little work) the build completes - only issue is that some script is trying to copy fmodex.dll to the right place and not (the correct) fmodex64.dll (I fixed the third party package). If I move that DLL manually, the viewer starts and seems to run, as first glance anyway, pretty normally. I'll attack the fmodex and vlc issues on Monday. On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed wrote: > On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: > > With: > (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 > configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE > -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE > -DFMODEX:BOOL=ON2>&1 | c:\cygwin64\bin\tee configRel.log > > I get many: > > No windows64 configuration found; inheriting windows > > But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64 > bit and it runs. > > > Yes: we've been discussing those messages internally. The viewer's CMake > logic runs autobuild install for each applicable package, and I think the > messages you're seeing are simply from autobuild waking up each time and > reading autobuild.xml. In other words, I believe the message is about the > package_description rather than any of the installables. > > We really want to avoid duplicating all of the windows section of > autobuild.xml for windows64, which is why we added $parameter support in > autobuild 1.1. So we don't plan to add a windows64 section to > package_description. > > vlc plugin had may unresolved externals so, commented it out in > media-plugins CMakeLists.txt in order to complete the build. > > This was with viewer64-callum changes merged in. > > > I'm pretty sure Callum disabled VLC too, though perhaps that's only local > so far. > > We're really at about the same point! Please bear with us. :-) > > ___ > 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] 64 bit viewers build instructions
woohoo - thanks nicky. On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian wrote: > *only issue is that some script is trying to copy fmodex.dll to the right > place and not (the correct) fmodex64.dll (I fixed the third party package).* > > It's fixed at: > https://bitbucket.org/kokua/viewer64/commits/ > ca4ffedff48cf4ae29622434567a59f6b010708b > > On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) < > cal...@lindenlab.com> wrote: > >> Yep - we;re all following along similar tracks by the sound of it Nicky >> :) >> >> With my latest changes, if I unload the VLC plugin (as you say, that >> needs a little work) the build completes - only issue is that some script >> is trying to copy fmodex.dll to the right place and not (the correct) >> fmodex64.dll (I fixed the third party package). >> >> If I move that DLL manually, the viewer starts and seems to run, as first >> glance anyway, pretty normally. >> >> I'll attack the fmodex and vlc issues on Monday. >> >> >> >> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed wrote: >> >>> On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: >>> >>> With: >>> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 >>> configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE >>> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE >>> -DFMODEX:BOOL=ON2>&1 | c:\cygwin64\bin\tee configRel.log >>> >>> I get many: >>> >>> No windows64 configuration found; inheriting windows >>> >>> But, build-vc120-64/packages has 64 bit libraries and the viewer builds >>> 64 bit and it runs. >>> >>> >>> Yes: we've been discussing those messages internally. The viewer's CMake >>> logic runs autobuild install for each applicable package, and I think the >>> messages you're seeing are simply from autobuild waking up each time and >>> reading autobuild.xml. In other words, I believe the message is about the >>> package_description rather than any of the installables. >>> >>> We really want to avoid duplicating all of the windows section of >>> autobuild.xml for windows64, which is why we added $parameter support in >>> autobuild 1.1. So we don't plan to add a windows64 section to >>> package_description. >>> >>> vlc plugin had may unresolved externals so, commented it out in >>> media-plugins CMakeLists.txt in order to complete the build. >>> >>> This was with viewer64-callum changes merged in. >>> >>> >>> I'm pretty sure Callum disabled VLC too, though perhaps that's only >>> local so far. >>> >>> We're really at about the same point! Please bear with us. :-) >>> >>> ___ >>> 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/> >> > > -- 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
[opensource-dev] Question about BUG-41029 and 64 bit usage
https://jira.secondlife.com/browse/BUG-41029 I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and whilst it seems straightforward, it seems to be unraveling into something that touches dozens of files and I wondered if someone had done this work already. There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined indirectly here: https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 that are used to count memory sizes/usage/difference etc. I think we can convert them to their U64 equivalents for all viewers. Nat points out, rewriting this code using size_t as a return type would make more sense but that seems like it would involve more invasive code changes including changes in fundamental LL headers. What does the collective wisdom say? -- 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] Question about BUG-41029 and 64 bit usage
Yep - I saw a lot of memory related texture references too - I don't know if cards these days have more than 4GB of video memory - definitely a possibility soon if not already. On Thu, Dec 15, 2016 at 5:01 PM, Niran wrote: > Funny, i just so happened to stumble across this a few days ago when i had > this mindblowing realization that this might be the cause for the Viewer > not properly reporting VRAM over 4gb but i don't happen to have a 4+gb VRAM > GPU so i wouldn't be able to test anything i do and ultimately dropped the > idea of touching it for now. > > 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) > : > >> https://jira.secondlife.com/browse/BUG-41029 >> >> I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and >> whilst it seems straightforward, it seems to be unraveling into something >> that touches dozens of files and I wondered if someone had done this work >> already. >> >> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >> defined indirectly here: >> >> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9 >> c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h? >> at=default&fileviewer=file-view-default#llunittype.h-824 >> >> that are used to count memory sizes/usage/difference etc. I think we >> can convert them to their U64 equivalents for all viewers. >> >> Nat points out, rewriting this code using size_t as a return type would >> make more sense but that seems like it would involve more invasive code >> changes including changes in fundamental LL headers. >> >> What does the collective wisdom say? >> >> -- >> >> 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 >> > > > ___ > 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] 64 bit viewers build instructions
KDU build here was indistinguishable from the 32bit viewer-release on first
inspection.
Tried both with full cache and cleaned one.
On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian
wrote:
> [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
> world. Terrain and most prim textures are grey. Full bright textures and
> my avatar appear normal. Is this the same with KDU? I haven't a KDU license
> or I would check myself.
>
> On Tue, Jan 10, 2017 at 12:30 PM, Nicky D.
> wrote:
>
>> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
>>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
>>> if ("$ENV{LL_BUILD}" STREQUAL "")
>>> message(FATAL_ERROR "Environment variable LL_BUILD must be set")
>>> endif ()
>>>
>>> Above allows configure to complete, but I would like a better place or
>>> better yet some autobuild involvement to set LL_BUILD based to the chosen
>>> Release, RelWithDebugInfo, Debug build.
>>>
>>>
>>>
>> Autobuild tries to do this by some machinery in source environment, but
>> it fails because you use ReleaseOS. I did encounter the same problem just a
>> few minutes ago
>> with ReleaseFS and had to edit the file variables in the build-variables
>> repository.
>> Once I added a variable for the configuration, LL_BUILD will be set as
>> desired.
>>
>> https://bitbucket.org/NickyD/viewer-build-variables/commits/
>> cfab877696c6a35af1d80e5d17ea7acfffa6c762
>>
>>
>
> ___
> 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
