Hello, Is there an overview - in plain English - summarizing the API changes? I realize that the github page linked below has the actual code changes, but I was hoping for a design overview. I do see comments and discussion, but did not readily find any overview. If I missed something, please help me find it.
Without diving in to the source changes, my first question is: Would it be possible to leave the existing API as it is, but only add new functions for continuous stream decoding? If only new function names are used, then existing code will not have to change or be recompiled. Of course, a deeper question is whether the existing API was already designed for continuous (chained) streaming, in which case the changes are more to fix bugs or design flaws in the original. I seem to recall that FLAC always intended to support continuous streams, but since I never worked with that feature I have no idea how well it was implemented, nor whether there were any bugs. Questions such as the above are why I was hoping for an overview. It would be nice to see a brief summary of what the original API was (probably) intended to support; whether we have changed our expectations or merely found flaws in the original design; and what sorts of changes were necessary, and why. It would be especially helpful if there was already discussion of the pros and cons of adding new functions for the new support, versus altering the API of existing functions to enhance existing support to broader use cases. As always, it's entirely possible that I'm missing something critical, so I offer the above as a way to start the conversation - at least for this mailing list. Admittedly, I've long been curious how metadata would be handled in a continuous stream, such as a 24/7 radio station, but have never looked into the details. Brian p.s. Are we talking about changes to the .flac file format in any way? ... or is this all about changing the streaming input (not file-based input) handling to support chained streams? On Sep 1, 2024, at 12:44 PM, Martijn van Beurden wrote: > Hi all, > > As some of you may know, the Ogg container is allowed to be 'chained', > meaning Ogg files or streams can simply be concatenated into a single > file or stream. This is something the vorbis and opus tools have > supported for some time, but FLAC hasn't. > > Anyway, there are a few internet radio stations using chained Ogg FLAC > streams, and I was for a few years getting requests (and some > rudimentary implementations) to get this implemented. I've taken this > up the past few weeks and the result is quite a large change to the > current code base and some API changes. > > Everything works, but as is with any change to the API, I don't know > whether it is convenient for API users other than the flac command > line tool. So, I'd like some feedback. > > Proposal is here: https://github.com/xiph/flac/pull/735 > > Kind regards, Martijn van Beurden _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
