Icecast - Dec 2016 - dir.xiph.org : OPUS stream wrongly identified as Vorbis

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.
>
>
>> 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.
> 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
>
>
>> 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.
>
>
> Have a nice day. Looking forward to your reply,
>
> 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.
>
>
>
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/d3c417b0/attachment.sig>

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.
-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20161227/f619ee54/attachment.sig>

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>

Yes,

Le 27/12/2016 à 16:09, Philipp Schafft a écrit :
> -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)
I'm only using the -kh fork because it supports the X-Forwarded-For header.

    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/7d22ccca/attachment.sig>