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 <ril...@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 > _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
