[Icecast-dev] OPUS/FLAC Metadata

Fri Jun 16 13:47:31 UTC 2017

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>