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>
On 16 Jun 2017, at 18:30, Romain Beauxis wrote:> 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.This concatenation are valid streams, it's called chaining, afaik. So players not supporting them are broken and the authors should be notified about it, I think.> > Romain > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
On 16/06/17 18:47, Marvin Scholz wrote:> This concatenation are valid streams, it's called chaining, afaik. So > players not supporting them are broken and the authors should be > notified about it, I think.And my question is... Is THAT the way an OPUS source communicates new metadata to the icecast server?. That is the question I would like to know :-). -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20170616/fc1f31a0/attachment.sig>