492420 - streaming stops. need to restart via controls.

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Dietrich Ayala (:dietrich)]

when i watch air.mozilla, the stream freezes right after loading, and i have to kickstart it by hitting pause and then play.

Comment 1

[Justin Dolske [:Dolske]]

I know that originally <video autoplay> didn't buffer anything (?), leading folks to adopt the "load, pause, *wait*, play" trick to make the stream play smoothly. I thought this was addressed at some point. But I noticed today that after loading the page, the stream seems to render 1 non-key frame, does nothing for ~10 seconds, and then starts playing normally.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think I see it with this one:
http://air.mozilla.com/wp-content/uploads/2009/04/status-04-20.ogg

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually, I'm not seeing it.

air.mozilla.com isn't seekable and doesn't give us a duration, so we don't know the duration, and we can't estimate the overall playback data rate from that. Instead we try to estimate the playback data rate by looking at the frames of video we've decoded, but that's quite inaccurate. That may be related to what you're seeing, although with the current code we're conservative so if the playback rate is known to be unreliable we should only start autoplaying when we have all the data. I don't see how that could be causing your problem.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we had the ability to read timestamps from our buffered data (which we'd have if we implemented 'buffered'), then we could get much better playback rate estimates. But that's not for 1.9.1. I think this bug isn't going to be addressed in 1.9.1 unless we discover something causing it other than bad playback rate estimates.

Comment 5

[Justin Dolske [:Dolske]]

Attachment: Airmozilla videocontrols log

This is from my current trunk build. There are a few weird things about this...

It immediately fires |playing| and |canplaythrough| (which I guess is intended, since it's a stream of unknown duration. Might be nice to always try buffering up a little bit though).

It then shows a couple frames (timeupdate events), and fires playing/canplaythrough again. It then does nothing for many seconds, except for firing some progress events at the usual rate, increasing from 50K --> 600K.

There's no |waiting| event being fired. There should be, so the controls can know to put up the throbber because playback is stuck.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to comment #2)

> http://air.mozilla.com/wp-content/uploads/2009/04/status-04-20.ogg

That file works fine for me, it's only the live stream that seems to be a problem. Maybe asa can set up a test stream to experiment with.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, for live streaming we just go straight to HAVE_ENOUGH_DATA since there is nothing else we can do. I guess we could add some delay there, e.g., wait for N bytes of data to be loaded before we go to HAVE_ENOUGH_DATA ... I'll make a patch.

From your log, the failure to fire 'waiting' looks like a consequence of this code:
  if (aNextFrame != NEXT_FRAME_AVAILABLE &&
      !mDecoder->IsEnded() &&
      stats.mDownloadPosition < stats.mTotalBytes) {
mTotalBytes is -1 so the last condition will not be true. That's a bug, we shouldn't be comparing to -1, we should probably have stats.mTotalBytes < 0 || stats.mDownloadPosition < stats.mTotalBytes here.

The good news, however, is that that buggy code is removed by the patch in bug 493443 which I'm about to land! So that should fix this part of your bug.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This will delay HAVE_ENOUGH_DATA until mDownloadRateReliable is true, which in practice means about one second after we've started receiving the download. I hope that's enough time to get some data buffered.

Either the user's network is fast enough to play the stream live, or it isn't. If it isn't, we're going to buffer frequently anyway so it doesn't really matter what we do. If it is, then the main thing we're worried about is bursty stream bit rate and/or network, but hopefully one second of downloading will give us about one second of data which should be enough to get us through the less predictable start-up phase.

It would be great if someone can try this to see if it helps.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This patch doesn't make any difference to http://www.editingarchive.com:8000/eatv-public.ogg. The 'reliable' flag is pretty much always set because it takes about a second for us to get through the headers of the video.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v2

This makes the 'reliable' flag kick in after 3 seconds. Kind of a hack but it seems like a reasonable compromise. Any longer and you don't save much time over just buffering for 10 seconds. Any shorter and EATV at least will usually hit buffering anyway.

There's no perfect solution here, whatever value we choose, on some servers and some content you'll sometimes encounter buffering. At least now we get a visual indicator and things are likely to be better.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/d9d952a62260

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4105310225ef

Comment 13

[Tony Chung [:tchung]]

havent seen streaming issues happen since the fix on branch and trunk nightlies.  verifying.

Comment 14

[Dietrich Ayala (:dietrich)]

the monday project meeting on air.m.o are *unwatchable* for me because of the hangs and stuttering.

hang out in #staffmeeting and you'll see a lot of people complaining about the same thing.

i vote to re-open this.