4 ms·

Except buffering wasn't the problem, an OS-managed thread was.

PaulDavisThe1st 6y ago
It was the interaction between the expected amount of required buffering and the thread scheduling behavior that caused the problem. As typically happens when there's a video programmer around, the audio timing is considered less important, and there's a belief that "we can always get the audio we need for the video". Ergo, not much need for buffering. In this case, the odd/incorrect behavior of the thread scheduler exposed the optimistic assumption that you can rely on waking up every 15ms and handling the audio.
- marcan_42 6y ago
  And further, video latency is much less noticeable than audio latency. ~nobody will notice one dropped frame, but ~everyone will notice 16ms of audio missing, because you get a blatant click. Therefore, it is always important to prioritize audio buffering over video buffering.
  - gpderetta 6y ago
    oh, yes, I had to use some videoconferencing software recently that appears to drop audio before video. It was basically unusable.
wolrah 6y ago
The reason it caused a problem is because Netflix wasn't loading more than a frame worth of data at a time. That's a strategy that makes sense for a game streaming app like Stadia or Steam Link where every frame of latency matters, but for a movie/TV streaming app it really doesn't. The point is that there was never any good reason to make the Netflix app so timing-dependent. Had Netflix not done this they wouldn't have even noticed. --- That said, if a company was releasing an Android 5.0 powered device in late 2017 when Android 8.0 had already been released I can't help but say they brought this on themselves by being idiotically out of date. There's no excuse for launching a device with an OS three years and three versions out of date. Everybody in this story is doing really dumb things.
- tomnipotent 6y ago
  > wasn't loading more than a frame worth of data at a time So the real question should be, does Netflix have a valid reason for only delivering a single frame of video and audio at a time? Is it bad software design, or good software design for an unknown problem (to us)? I've seen plenty of things that looked stupid out of context, then made sense later on after understanding why the "stupid" things was done in the first place.
  - jfim 6y ago
    It's probably easier to keep the audio and video in sync with a simple implementation. They can't really drift out of sync if all that's being one is handling one frame at a time.
    - ghusbands 6y ago
      Though it sounds like they aren't even getting that advantage, because the audio thread is separate, and the described problem is starvation of the audio buffer alone.
  - Closi 6y ago
    It probably makes it easier to implement things like variable frame rates.
  - csharptwdec19 6y ago
    Stupid thought, especially thinking about Netflix's history as one of the earliest services that streamed licensed content, it would not surprise me if this was at some point a way to minimize how much unencrypted data was in memory or similar. Other thought would be, whether the architecture was somehow related to how one had to do things in Silverlight (any silverlight devs still remember how one would do this sort of thing? Any Silverlight devs still around?)
- andi999 6y ago
  "There's no excuse for launching a device with an OS three years and three versions out of date." Really? Why not? I mean if you only launch for the newest OS version, you cut out a lot of devices which were not or cannot be upgraded. Maybe in the US this is not a problem, but in Europe I wouldnt be surprised if this were actually a larger than 50% market share you cut out.

It was the interaction between the expected amount of required buffering and the thread scheduling behavior that caused the problem. As typically happens when there's a video programmer around, the audio timing is considered less important, and there's a belief that "we can always get the audio we need for the video". Ergo, not much need for buffering. In this case, the odd/incorrect behavior of the thread scheduler exposed the optimistic assumption that you can rely on waking up every 15ms and handling the audio.

marcan_42 6y ago
And further, video latency is much less noticeable than audio latency. ~nobody will notice one dropped frame, but ~everyone will notice 16ms of audio missing, because you get a blatant click. Therefore, it is always important to prioritize audio buffering over video buffering.
- gpderetta 6y ago
  oh, yes, I had to use some videoconferencing software recently that appears to drop audio before video. It was basically unusable.

wolrah 6y ago

The reason it caused a problem is because Netflix wasn't loading more than a frame worth of data at a time. That's a strategy that makes sense for a game streaming app like Stadia or Steam Link where every frame of latency matters, but for a movie/TV streaming app it really doesn't. The point is that there was never any good reason to make the Netflix app so timing-dependent. Had Netflix not done this they wouldn't have even noticed. --- That said, if a company was releasing an Android 5.0 powered device in late 2017 when Android 8.0 had already been released I can't help but say they brought this on themselves by being idiotically out of date. There's no excuse for launching a device with an OS three years and three versions out of date. Everybody in this story is doing really dumb things.

tomnipotent 6y ago
> wasn't loading more than a frame worth of data at a time So the real question should be, does Netflix have a valid reason for only delivering a single frame of video and audio at a time? Is it bad software design, or good software design for an unknown problem (to us)? I've seen plenty of things that looked stupid out of context, then made sense later on after understanding why the "stupid" things was done in the first place.
- jfim 6y ago
  It's probably easier to keep the audio and video in sync with a simple implementation. They can't really drift out of sync if all that's being one is handling one frame at a time.
  - ghusbands 6y ago
    Though it sounds like they aren't even getting that advantage, because the audio thread is separate, and the described problem is starvation of the audio buffer alone.
- Closi 6y ago
  It probably makes it easier to implement things like variable frame rates.
- csharptwdec19 6y ago
  Stupid thought, especially thinking about Netflix's history as one of the earliest services that streamed licensed content, it would not surprise me if this was at some point a way to minimize how much unencrypted data was in memory or similar. Other thought would be, whether the architecture was somehow related to how one had to do things in Silverlight (any silverlight devs still remember how one would do this sort of thing? Any Silverlight devs still around?)
andi999 6y ago
"There's no excuse for launching a device with an OS three years and three versions out of date." Really? Why not? I mean if you only launch for the newest OS version, you cut out a lot of devices which were not or cannot be upgraded. Maybe in the US this is not a problem, but in Europe I wouldnt be surprised if this were actually a larger than 50% market share you cut out.