[Icecast-dev] OPUS/FLAC Metadata

[Romain Beauxis]

2017-06-16 10:28 GMT-05:00 Jesus Cea <jcea at jcea.es>:
> On 16/06/17 13:18, Marvin Scholz wrote:
>> The source client is supposed to encode the metadata into the stream,
>> not use any endpoint whatsoever to send them, for Ogg and
>> other supported formats. There is nothing confusing about this. The
>> reason this is different for MP3 and AAC is, that it is simply
>> impossible to do that for these formats, which is why the endpoint you
>> mentioned exists. Kind of a hack to workaround the limitations
>> of the formats.
>
> Reading OPUS OGG fileformat, the metadata is limited to the second
> "page". In a live-stream, you could not send a new metadata
> information... unless you send a logical "End of Stream" to the icecast
> server followed by a new "Start of Stream" followed by new metadata. I
> wonder if that is transparent to the client, because the client I use
> stops reproducing when finding the EOS mark.
>
> So, how OPUS metadata updates works?
>
> I am deploying a new radio streaming service and I would love to use
> OPUS streaming, but I don't understand how to send metadata updates to
> icecast, how it send them to the clients and, moreover, current Debian
> supported version is 2.4.0 (I could override that, of course).
>
> That is, saying that OPUS metadata is embedded in the stream is
> insufficient, because OPUS OGG specification clearly indicates that
> metadata is ONLY legal at the very beginning of the file.
>
> Please, provide more details.
>
> * How source EXACTLY communicates metadata updates to the server? "Embed
> it in the stream" is not enough information.
>
> * How are those updates send to the clients?. Using legacy ICY?, OGG
> embedding?. How it works in that case, because OGG only supports
> metadata at the beginning of the stream, and stream concatenation (an
> EOS followed with a Start Of Stream) is not supported by many clients...

As far as I know, EOS followed by a new stream is the only way to pass
metadata in ogg-embedded streams. Clients didn't support that very well
back some years ago but I would hope that this is better now.. Only other
alternative to avoid stream concatenation is to remove all subsequent
metadata, I'm afraid.

Romain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20170616/43312fbc/attachment.html>