If there is a problem with running out of memory, decoding a file in whole will surely run into problems. I have FLAC files that are hours long, so mobile devices would surely run out of memory. In contrast, a streaming player would be able to play any size file.
You were also concerned about licensing restrictions, so it might be better to write your own streaming player. Of course, you'd still have the license restrictions of the libFLAC or libFLAC++, so that might not really help (I'm no expert on open source licenses). Then again, I understand that there's never enough time to do everything. I'm still hoping to find time to write a streaming plugin for iTunes that supports FLAC. Brian On Jan 20, 2015, at 12:12 PM, Rainer Rillke <ril...@wikipedia.de> wrote: > 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.) > > > From: Brian > > > > 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 > _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
