Closed Bug 492420 Opened 13 years ago Closed 13 years ago

streaming stops. need to restart via controls.

Categories

(Core :: Audio/Video, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: dietrich, Assigned: roc)

References

()

Details

(Keywords: verified1.9.1)

Attachments

(2 files, 1 obsolete file)

when i watch air.mozilla, the stream freezes right after loading, and i have to kickstart it by hitting pause and then play.
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.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+
Assignee: nobody → roc
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.
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.
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.
(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.
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.
Attached patch fix (obsolete) — Splinter Review
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.
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.
Attached patch fix v2Splinter Review
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.
Attachment #378145 - Attachment is obsolete: true
Attachment #378252 - Flags: review?(chris.double)
Whiteboard: [needs review]
Attachment #378252 - Flags: review?(chris.double) → review+
http://hg.mozilla.org/mozilla-central/rev/d9d952a62260
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs review] → [needs 191 landing]
havent seen streaming issues happen since the fix on branch and trunk nightlies.  verifying.
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.