1427527 - Playback stalls when new metadata appear in ogg stream

Status: REOPENED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Pyroman]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171227151400

Steps to reproduce:

Playback of ogg vorbis stream stops when new metadata appears in the stream. 

This is similar or the same bug https://bugzilla.mozilla.org/show_bug.cgi?id=455165 broken again in Firefox 57 at least Linux version.

Versions prior to 57 not affected.

Example streams: http://listen.42fm.ru/

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

I can't repro the issue on the site, http://listen.42fm.ru/.

Can you give a specific link to repro this issue? How long should I play before new metadata appears in the stream?

Comment 2

[Pyroman]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #1)
> I can't repro the issue on the site, http://listen.42fm.ru/.
> 
> Can you give a specific link to repro this issue?

I can reproduce with any ogg vorbis stream. Also I've asked some Linux users of Firefox 57 and they could reproduce too.

Here are some direct links to the vorbis streams:
http://www.metalvoice.net:8000/listenVorbis
http://stream.keygen-fm.ru:8042/live.ogg
http://listen.42fm.ru/stealkill-3.0.ogg

> How long should I play before new metadata appears in the stream?

Average song lengths are 3-5-7 minutes. Some songs may last more.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

The stuttering is because download is not fast enough for the player to consume without underflow. Chrome also exhibits this issue. I guess the site is overloaded and can't handle too many connections.

Comment 4

[Pyroman]

> The stuttering is because download is not fast enough for the player to consume without underflow.

It's not a stuttering. Playback just stops at the end of every song. But server stats showing that browser continues getting data from the server. To continue playback I have to restart it manually. 

> Chrome also exhibits this issue.

I have Chromium browser too and playback of same streams work well there.

> I guess the site is overloaded and can't handle too many connections.

It's neither overloaded server problem nor network problem. I have more than enough network speed.

Also I have set up Icecast server at local machine and tested on it, the problem occurs with it too. 

Stalled playback screenshot: https://i.imgur.com/vSaEN5E.png (notice speaker icon disappeared on the tab.

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

https://searchfox.org/mozilla-central/rev/652fbd6270de0d3ec424d2b88f8375ff546f949f/dom/media/ogg/OggCodecState.cpp#240

sample->mOffset is not set by the ogg decoder and remains zero. mOffset is important for MediaCache to evaluate the playback position in bytes in order to suspend/resume HTTP download correctly.

In this case, sample->mOffset==0 will mislead MediaCache to think playback rate is very low and not download enough bytes ahead of the current decode position. This will then cause buffer underflow and slow decoding.

Hi jya,
Do you known how to give a good value to sample->mOffset?

Comment 6

[Jean-Yves Avenard [:jya]]

do we still need this bug?

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

After fixing bug 1428682, I am still able to repro the issue as described in comment 3. I am quite sure it is a problem of the network as I can repro the issue on Chrome as well.

Comment 8

[Pyroman]

(In reply to Jean-Yves Avenard [:jya] from comment #6)
> do we still need this bug?

I've tested in Nightly 59a1 and above streams all play well there. Debug messages from sterr:

    [DEBUG SHUTDOWN] ShutdownDecoder: decoder: 'vorbis audio decoder' (0x7f046fdc9bc0) flush:1
    [DEBUG SHUTDOWN] operator(): pool=0x7f0470bd3d90 shutdown=false count=0

Comment 9

[Matthias C. Hormann]

I have an Ogg Opus stream with metadata, and I observe with Firefox 127.0.1 (Linux), that the first song plays, then when it ends and metadata appears, Firefox keeps on reading the stream (HTML player shows pause symbol, not Play) but never resumes playing the next song. This happens when the stream link is directly opened from the address bar (player page appears), and when using the <audio> HMTL element.

I tried the same streams in Chromium, and they play fine. Same with VLC. mpv and other ffmpeg-based players expose ffmpeg’s "accumulating metadata" bug, but apart from that also play a continuous stream.

Here are two Ogg Opus streams for testing, both using Icecast as stream server:

• https://radio.niteradio.net/listen/niteradio/radio.opus (minimal metadata: artist, title, album)
• http://zeremy.serv00.net:8200/opus (more metadata fields)

You have to wait for a song ending before the issue occurs.

We can’t use a continuous stream because we need the metadata in players and for the MediaSession metadata. Opus has become an important codec due to its superior quality and low bandwidth. We shouldn’t neglect it, I’m sure its market share will increase.

Thanks in advance for checking and hopefully fixing!

Comment 10

[Matthias C. Hormann]

I did some more testing, and

• Chrome
• Chromium
• Opera
• MS Edge

all played the "chained" Ogg Opus streams just fine, without interruptions or stalling after the first metadata change.

Comment 11

[Matthias C. Hormann]

Sorry, had to replace the https://radio.niteradio.net/listen/niteradio/radio.opus stream with something that works, using a different encoder (ffmpeg).

Let me know if you still need a test stream.