flac dev - Sep 2024 - Feedback on implementation of decoding of chained streams

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

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