On 16 Jun 2017, at 5:41, Rick Keniuk wrote:> Is this the HTTP call for injecting the “song” metadata? > This is a capture (using RawCap in conjunction with Wireshark) of my > AAC+ stream metadata input to IceCast that works fine. > > GET > /admin/metadata?mode=updinfo&mount=%2FFVHradio_AAC&song=Fox%20Valley%20Hit%20radio%20-%20Hits%20from%20the%20Valley > HTTP/1.0 > User-Agent: RadioBOSS > Authorization: Basic > > The same input to IceCast capture for OPUS that does not work. > > GET > /admin/metadata?mode=updinfo&mount=%2FFVHradio_OPUS&song=Mike%20%26%20The%20Mechanics%20-%20The%20Living%20Years > HTTP/1.0 > User-Agent: RadioBOSS > Authorization: Basic > > This it the output of my encoder which is DJsoft’s RadioCaster > v2.5.0.0 > > I think Marvin Scholz indicated that OPUS and FLAC do this differently > but that makes it confusing for the encoder people.This endpoint is for legacy streams like MP3 and AAC. While it might work with other formats, it should NOT be used. It does not matter if the source client or you use it through the web interface. Both you and the source client should not use this for anything else than MP3 and AAC or other unsupported formats. 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. Note that FLAC metadata support is right now not fully working, Icecast will not display them in the Web interface, afaik, but the metadata should appear fine on the listener clients if they support it.> > Sorry… I’m a noob at this so I may be explaining this > incorrectly. > > Rick > >> On Jun 15, 2017, at 10:51 AM, Romain Beauxis <toots at rastageeks.org> >> wrote: >> >> Hi all, >> >> 2017-06-13 9:33 GMT-05:00 Philipp Schafft >> <phschafft at de.loewenfelsen.net >> <mailto:phschafft at de.loewenfelsen.net>>: >>> >>> Good afternoon, >>> >>> >>> On Mon, 2017-06-12 at 13:20 -0500, Rick Keniuk wrote: >>>> Marvin, >>>> >>>> That is the current version being used and it still has no meta >>>> data. >>>> server_id Icecast 2.4.99.1 >>> >>> Icecast2 2.5 beta releases use 2.4.99.x as version number. So that >>> is >>> correct. >>> >>> >>>> Testing the metadata from the admin page “Update Metadata” >>>> results in the response: >>>> >>>> Message: Mountpoint will not accept URL updates >>>> Return Code: 1 >>>> >>>> So I would guess it isn’t functioning yet. >>> >>> The metadata update interface is only for MP3 and AAC as they do not >>> have native metadata support. Generally speaking the metadata is in >>> the >>> domain of the source client. So the source client needs to send >>> them. >> >> Not sure if that was an intended feature but I'm pretty sure that >> metadata update through HTTP calls also works for ogg/vorbis in >> icecast or at least did at some point. >> >> Romain > > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
Thanks Marvin, Let me see if I’ve got this sorted in my brain before I discuss this my source encoder's company. My source encoder, RadioCaster v2.5.0.0, is a reliable Windows OS broadcast encoder which streams many formats to several different types of servers as well as act as its own server for small numbers of clients. When the encoder is configured to “push” a data stream to IceCast2, RadioCaster injects the metadata into the stream in what is now considered the legacy formatting: GET/admin/metadata?mode=updinfo&mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black (from the IceCast 2.3.1 documentation) I can see this in my stream captures directed to IceCast2 on AAC, MP3, and OPUS (didn’t test FLAC). The problem with RadioCaster is that they need to do this only for AAC and MP3 streams. Correct? When I configure my source encoder to be a “pull” encoder (RadioCaster can be a direct server for small numbers of clients) it does not show metadata at the listening client for any of the formats. This may be because they are still injecting the metadata as above, incompatible with the listening client, or are not injecting the metadata at all. They may only encode the audio stream in this configuration. I would imagine that when this is injected into the stream correctly, the “pull” encoder configuration will have a valid stream with metadata that will be decoded by the listening client. This will then be the same for the “push” encoder configuration sending that identically formatted stream to the IceCast2 server and in-turn to the rest of the listening clients. New question… In IceCast2, can this new method of inserting the metadata directly into the stream be done the same for all the formats OPUS, FLAC as well as AAC and MP3? That might simplify the encoders code. Or, will AAC and MP3 remain as they are injected currently in IceCast2? So… I will need to find the specification for injecting the OPUS/FLAC metadata directly into the stream and provide it to them. While coaxing them to revise their application. :-| Or… Find another Windows OS encoder with this metadata already properly injected for IceCast2 servers. Rick> On Jun 16, 2017, at 6:18 AM, Marvin Scholz <epirat07 at gmail.com> wrote: > > > > On 16 Jun 2017, at 5:41, Rick Keniuk wrote: > >> Is this the HTTP call for injecting the “song” metadata? >> This is a capture (using RawCap in conjunction with Wireshark) of my AAC+ stream metadata input to IceCast that works fine. >> >> GET /admin/metadata?mode=updinfo&mount=%2FFVHradio_AAC&song=Fox%20Valley%20Hit%20radio%20-%20Hits%20from%20the%20Valley HTTP/1.0 >> User-Agent: RadioBOSS >> Authorization: Basic >> >> The same input to IceCast capture for OPUS that does not work. >> >> GET /admin/metadata?mode=updinfo&mount=%2FFVHradio_OPUS&song=Mike%20%26%20The%20Mechanics%20-%20The%20Living%20Years HTTP/1.0 >> User-Agent: RadioBOSS >> Authorization: Basic >> >> This it the output of my encoder which is DJsoft’s RadioCaster v2.5.0.0 >> >> I think Marvin Scholz indicated that OPUS and FLAC do this differently but that makes it confusing for the encoder people. > > This endpoint is for legacy streams like MP3 and AAC. > While it might work with other formats, it should NOT be used. It does not matter if the source client or you use it through > the web interface. Both you and the source client should not use this for anything else than MP3 and AAC or other unsupported > formats. > > 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. > > Note that FLAC metadata support is right now not fully working, Icecast will not display them in the Web interface, afaik, but the > metadata should appear fine on the listener clients if they support it. > >> >> Sorry… I’m a noob at this so I may be explaining this incorrectly. >> >> Rick >> >>> On Jun 15, 2017, at 10:51 AM, Romain Beauxis <toots at rastageeks.org <mailto:toots at rastageeks.org>> wrote: >>> >>> Hi all, >>> >>> 2017-06-13 9:33 GMT-05:00 Philipp Schafft <phschafft at de.loewenfelsen.net <mailto:phschafft at de.loewenfelsen.net> <mailto:phschafft at de.loewenfelsen.net <mailto:phschafft at de.loewenfelsen.net>>>: >>>> >>>> Good afternoon, >>>> >>>> >>>> On Mon, 2017-06-12 at 13:20 -0500, Rick Keniuk wrote: >>>>> Marvin, >>>>> >>>>> That is the current version being used and it still has no meta data. >>>>> server_id Icecast 2.4.99.1 >>>> >>>> Icecast2 2.5 beta releases use 2.4.99.x as version number. So that is >>>> correct. >>>> >>>> >>>>> Testing the metadata from the admin page “Update Metadata” results in the response: >>>>> >>>>> Message: Mountpoint will not accept URL updates >>>>> Return Code: 1 >>>>> >>>>> So I would guess it isn’t functioning yet. >>>> >>>> The metadata update interface is only for MP3 and AAC as they do not >>>> have native metadata support. Generally speaking the metadata is in the >>>> domain of the source client. So the source client needs to send them. >>> >>> Not sure if that was an intended feature but I'm pretty sure that >>> metadata update through HTTP calls also works for ogg/vorbis in >>> icecast or at least did at some point. >>> >>> Romain >> >> _______________________________________________ >> Icecast-dev mailing list >> Icecast-dev at xiph.org <mailto:Icecast-dev at xiph.org> >> http://lists.xiph.org/mailman/listinfo/icecast-dev <http://lists.xiph.org/mailman/listinfo/icecast-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20170616/52ae5b88/attachment.html>
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... -- 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/741e5a77/attachment-0001.sig>
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>