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

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

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 T

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

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 (Call

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

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

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 situa

Re: [opensource-dev] Firewall block of media files

Which is expected behavior, respecting MIME types should stay. On May 19, 2016 20:34, "Whirly Fizzle" wrote: > That will not play in a web browser though, the file needs to be > downloaded to play it. > Being able to play dropbox links like that via MOAP never worked in any SL > viewer as far as

Re: [opensource-dev] Firewall block of media files

It may have been parcel media, but I remember them playing. On Thu, May 19, 2016 at 1:34 PM, Whirly Fizzle wrote: > That will not play in a web browser though, the file needs to be > downloaded to play it. > Being able to play dropbox links like that via MOAP never worked in any SL > viewer as f

Re: [opensource-dev] Firewall block of media files

That will not play in a web browser though, the file needs to be downloaded to play it. Being able to play dropbox links like that via MOAP never worked in any SL viewer as far as I'm aware. Date: Thu, 19 May 2016 13:23:32 -0500 From: nickyper...@gmail.com To: cal...@lindenlab.com CC: opensource

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

CEF proprietary codecs will solved that issue. Whether or not it will be a replacement for media is up in the air. I think it might be good to have a trial version of all the three options if possible and measure impact. On May 19, 2016 19:13, "Callum Prentice (Callum)" wrote: > > > > Thanks W

Re: [opensource-dev] Firewall block of media files

URL placed in MOAP Texture https://dl.dropboxusercontent.com/u/7833186/Horse.wmv This plays in windows media player and VLC installed on system. Debug Log 2016-05-19T17:45:41Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert: You have requested a file download, which is not supported within

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 -

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.

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. > > There is a notice that these files cannot be downloaded to SecondLife.

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

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

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

Re: [opensource-dev] Firewall block of media files

The issue there, I suspect, is that the files are served with the wrong MIME type, causing them to appear as generic files to be saved to disk, not played. The correct fix is to serve media files from a server that sets the correct MIME type. However, while correct, that might be a burden on some

[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. There is a notice that these files cannot be downloaded to SecondLife. How are

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

The JIRA issues Nicky referenced are: https://jira.secondlife.com/browse/BUG-11008 - [CEF] MPEG4 and AAC video not working in TV object https://jira.secondlife.com/browse/BUG-11606 - Missing proprietary codec support Date: Thu, 19 May 2016 11:24:50 +0200 From: sl.nicky...@googlemail.com To: cal

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

On Wed, 18 May 2016 16:40:14 -0700, Callum Prentice (Callum) wrote: > Digesting all the suggestions here - thank you. > > Intrigued by Nicky's suggestion, I am currently trying to build CEF > directly via Chromium - first attempt is without the extra flags > (proprietary_codecs=1 ffmpeg_branding=

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

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

On Wed, 18 May 2016 21:49:46 -0700, Darien Caldwell wrote: > Using CEF for media is what I've been saying since CEF support was > announced for the viewer. I think it would be a clean solution. That solution would be plain *dirty* and totally wasteful (about 80Mb per new CEF plugin instance), it