[Icecast] dir.xiph.org : OPUS stream wrongly identified as Vorbis

[Hoggins!]

Hello,

Le 27/12/2016 à 16:09, Philipp Schafft a écrit :
> Good afternoon,
>
>
> On Tue, 2016-12-27 at 15:52 +0100, Hoggins! wrote:
>> Hello Philipp,
>>
>> Thank you for your answers !
>>
>> Le 27/12/2016 à 12:14, Philipp Schafft a écrit :
>>> Good morning,
>>>
>>> On Tue, 2016-12-27 at 11:46 +0100, Hoggins! wrote:
>>>> Hello,
>>>>
>>>> We started to publish an OPUS stream amongst others on our Icecast
>>>> streaming server. That's cool, we're muxing it in an Ogg container, it
>>>> works well !
>>>> So this is just a remark : as the Icecast shows its type as
>>>> "application/ogg", it may be the reason why the Icecast directory shows
>>>> this as an Ogg Vorbis stream although it's an Ogg OPUS one.
>>> Ogg/Opus streams are audio/ogg or application/ogg[0]. The codec is given
>>> in the codec parameter[0]. It should be listed as 'sub type' on the
>>> Icecast status page.
>> Sniffing what is being sent to the Directory (by using my own little
>> gateway and dumping the contents), I can see that :
>>     - for Vorbis streams :
>>         - "type" = "application/ogg"
>>         - "stype" = "Vorbis"
>>     - for OPUS streams :
>>         - "type" = "application/ogg"
>>         - "stype" = ""
>>
>> That would explain why the Directory assumes that it's also Vorbis.
> Yes, I talked with Thomas. He said that the yp uses the file extention
> to guess the subtype if stype is empty. If you rename your mount
> to .opus it should work.
>
> Also there seems there was a bug in Icecast to not set the subtype for
> Opus in Icecast2 2.4.x, I fixed it this morning (will be included in
> 2.4.4) (2.5.x will include full Ogg/Opus metadata support).
>
>
>>>> Any idea how to correct this ?
>>> Which (exact!) version of Icecast2 you run?
>> I'm running 2.4.0-kh3. I know it's not the official stream, but I was
>> guessing these basic functionalities were handled by the main branch. If
>> not, I'll ask somewhere else.
> -kh is not a branch but a private fork. The Foundation has no control
> over it nor do any updates on the official Icecast automatically go into
> that fork. (Also: the code is generally considered incompatible)
>
>
>>> What is the URL to your stream? (you can also answer directly to me (but
>>> keep general questions to the list) or ask me on IRC[1]) I would have a
>>> look at it and see if the stream is valid.
>> The URL is http://live.radiom.fr:80/live600.ogg
> Ok. that seems to be fine expect for the notes above and that it does
> not contain metadata.
>
>
>
>>>> Also, it's worth noting that Icecast refuses to dynamically update the
>>>> metadata update on such a mountpoint, responding "Mountpoint will not
>>>> accept this URL update" / Return Code: 1.
>>>> I know it's been quite difficult to allow dynamic updates for Ogg
>>>> Vorbis, but hey, it's working. Whereas it's not with Ogg Opus.
>>> This interface is only for ICY streams (MP3 and AAC). For all other
>>> streams the metadata is to be send along the data stream as per codec
>>> and mapping standard. The API only 'works'[2] for Ogg/Vorbis for
>>> historical reasons.
>> Yes, that's what I read somewhere else. No problem for that, I'll try to
>> have this updated by the app.
>> I'm using GStreamer, but I'm afraid the shout2send element I'm using
>> does not allow to set the currently played title.
> The metadata is not related to Icecast or libshout at all. They are part
> of the bitstream as generated by the encoder.
>
>
> Hope that helped you,
>
> with best regards,
>
>
>>> [0] https://wiki.xiph.org/MIMETypesCodecs
>>> [1] #icecast on irc.freenode.net
>>> [2] It breaks many things like exact timing or bitrate efficiency. Just
>>> don't use it.
>

Very helpful, thanks !

    Hoggins!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20161227/92683765/attachment.sig>