Rainer Rillke
2015-Jan-20 18:14 UTC
[flac-dev] FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
Hi List! On flac--l I was advised to cross-post to this list. So here is an extended version: After compiling opusenc.js to JavaScript [1], now the flac tool is also available [2][3], too. s/Check out/Clone/ https://github.com/Rillke/flac.js ! I am slightly nervous about its license, the GPL and what CloudFlare is doing: It's melting a lot of content together into one file (but not the flac tool's code which is loaded separately) and adding JavaScript that doesn't appear to be GPL or compatibly licensed -- by any chance, is there a possibility to get an exception (e.g. LGPL license) for JavaScript versions? It's also an issue to what happens in proprietary browsers, or more specifically in browsers with proprietary JavaScript VM, when they optimize code and insert custom assets. In theory, users of them can't abide with the licensing terms and use the tool online[5]. Advice welcome. Another thing is the flac website[4] being GPL licensed, too. Of course one may quote from it; however things would be easier if it would be dual licensed, with something, say cc-by-sa 3.0 in addition. Another issue that literally kills browsers is the static union of buffers in flac's src/flac/decode.c which is commented with "WATCHOUT: can be up to 2 megs" and this ends up as zero byte characters in a "memory initialization file" Emscripten creates[6]. This file is then, together with something else huge from analyze.c (I guess a variable of type "subframe_stats_t"), around 2.8 MiB. This is not a big deal for desktop browsers. GZIP compressed and quickly transmitted -- all no problem. But on mobile browsers, this causes them to run out of memory and they simply crash. Any idea how I could avoid that? Yeah, obviously I could drop decoding and analysing support (is there a command line switch for making the flac tool w/o decoding support btw?) ... looking for something that does not contain "drop support for" :) Finally, thanks for the great free tools, Xiph. -- Rillke [1] http://lists.xiph.org/pipermail/opus/2014-December/002824.html [2] https://github.com/Rillke/flac.js [3] https://blog.rillke.com/flac.js/ [4] https://xiph.org/flac/index.html [5] http://stackoverflow.com/a/1239727/2683737 [6] http://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html#very-large-projects -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150120/9b4524ba/attachment.htm
Brian Willoughby
2015-Jan-20 18:25 UTC
[flac-dev] FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
I'm not sure that I understand your goal. In a browser setting, I would think that you want to decode a stream, not a file, because streaming should have less of a memory impact. The reference decoder is a file decoder, so you probably don't want to port that. I don't think that there is a reference streaming decoder, so you'd need to write your own using the libFLAC or libFLAC++ routines. Brian On Jan 20, 2015, at 10:14 AM, Rainer Rillke <rillke at wikipedia.de> wrote:> > After compiling opusenc.js to JavaScript [1], now the flac tool is also available [2][3], too. > > s/Check out/Clone/ https://github.com/Rillke/flac.js ! > > I am slightly nervous about its license, the GPL and what CloudFlare is doing: It's melting a lot of content together into one file (but not the flac tool's code which is loaded separately) and adding JavaScript that doesn't appear to be GPL or compatibly licensed -- by any chance, is there a possibility to get an exception (e.g. LGPL license) for JavaScript versions? It's also an issue to what happens in proprietary browsers, or more specifically in browsers with proprietary JavaScript VM, when they optimize code and insert custom assets. In theory, users of them can't abide with the licensing terms and use the tool online[5]. Advice welcome. > > Another thing is the flac website[4] being GPL licensed, too. Of course one may quote from it; however things would be easier if it would be dual licensed, with something, say cc-by-sa 3.0 in addition. > > Another issue that literally kills browsers is the static union of buffers in flac's src/flac/decode.c which is commented with "WATCHOUT: can be up to 2 megs" and this ends up as zero byte characters in a "memory initialization file" Emscripten creates[6]. This file is then, together with something else huge from analyze.c (I guess a variable of type "subframe_stats_t"), around 2.8 MiB. This is not a big deal for desktop browsers. GZIP compressed and quickly transmitted -- all no problem. But on mobile browsers, this causes them to run out of memory and they simply crash. Any idea how I could avoid that? Yeah, obviously I could drop decoding and analysing support (is there a command line switch for making the flac tool w/o decoding support btw?) ... looking for something that does not contain "drop support for" :) > > Finally, thanks for the great free tools, Xiph. > > -- Rillke >
Rainer Rillke
2015-Jan-20 20:12 UTC
[flac-dev] FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
Yeah, de-/encoding a stream would have a lot of advantages but there is no streaming en-/ decoder I would be aware of and for the application I'd intend to use it for, it might be sufficient to de-/ encode a file in whole. Dependent of the time and efforts for creation and maintenance of a stream encoder, it might not fit into the time budget. (Apart from that, as of now, it gives a nice demo application that just runs quickly in every browser, independently from any platform and has nearly zero maintenance cost.) -- Rillke> Subject: Re: [flac-dev] FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript? > From: brianw at audiobanshee.com > Date: Tue, 20 Jan 2015 10:25:31 -0800 > CC: flac-dev at xiph.org > To: rillke at wikipedia.de > > I'm not sure that I understand your goal. In a browser setting, I would think that you want to decode a stream, not a file, because streaming should have less of a memory impact. The reference decoder is a file decoder, so you probably don't want to port that. I don't think that there is a reference streaming decoder, so you'd need to write your own using the libFLAC or libFLAC++ routines. > > Brian > > On Jan 20, 2015, at 10:14 AM, Rainer Rillke <rillke at wikipedia.de> wrote: >>...-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150120/3c2c1bbe/attachment.htm
Apparently Analagous Threads
- FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
- flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
- flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
- FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript
- port Opus to Javascript using Emscripten