Closed Bug 762730 Opened 12 years ago Closed 12 years ago

Show throbber in video app when remote content is buffering

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: onecyrenus, Assigned: sicking)

References

Details

Attachments

(1 file)

Media loading progress indicator
134.57 KB, image/png
Details 
Playing h.264 content it is difficult to understand what is happening, as it's not clear when you are buffering or if playing the video has failed. 

Need some visual cues when buffering, and how much has buffered.
Blocks: 748351
OS: Mac OS X → Gonk
Hardware: x86 → ARM
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
What i'd have expected to see was a spinning wheel on the video content, and the progress bar a visual indication of how much of the video has been downloaded.  Youtube does this by changing the background color to grey for the portion of the video that has been downloaded.
Is it specific to H.264, or does it occur on WebM too?
It occurs in webM as well. I am not sure how we want to provide this kind of overlay. 

But generally the user has no way of understanding there is buffering going on.
update
Update what?
Is this valid ? 
Is/Has this being addressed ?
Is this in the built in video application or is it in inline video playback in the browser?
Josh, is there anything in UX/VisD for media progress indicators?

Leaving nom'd until we figure out next steps if any.
Whiteboard: [blocked-on-input]
Are we talking about streamed content or local? If it's the later, do we need this? And if it's the former, the app was not designed for that use case (was not in our requirements). We can add it, but it we will need to define scope and determine if it's a v1 priority.
Let's show download progress right on the timeline bar like this (see blue area of the bar).
I am talking about streamed content, without buffering, you get this terrible jittery effect. Somehow we have to buffer the video content, and provide UI clues that this is happening.. 

The use case is in browser, on youtube.. etc...
If you are trying to stream video... I think there needs to be a buffering process, before you attempt to play the video, otherwise you end up with jitter. 

Now the point of this bug is to indicate that there needs to be a UI clue that this is happening. 

I don't know what the implementation would look like.  Whether it is done in gaia / gecko.  

Pretty sure brazil is on 3G / Edge networks.
I think fennec and b2g look different from desktop because they can't reuse the XUL? We could port the buffering indication from the desktop controls and already be very close to this mockup.
Ok, so as per Frank's mockup, we do have a buffering visual design solution in our back pocket. Let's go with that. We can also look at adding an activity indicator (eg: looping "loading" animation) if needed. 

> The use case is in browser, on youtube.. etc...

So as I mentioned, this is V1 scope creep. We did not design for video playback of anything but local files. YouTube, Browser etc are all new use cases for us. Buffering may be only one UX we need to deal with. If we're adding this to V1, we should be thorough and capture all use cases + requirements.

Chris, can you comment on what we need to do here?
I'm pretty sure this bug was raised for the in-browser video element with the 'controls' attribute set. Perhaps dclarke can expand with a test case demonstrating what the problem is.

If I'm the 'Chris' you're asking in comment 14, I'd suggest looking at the builtin controls on Android. They do buffering indication, download progress, etc.

For the in-browser video element case it should just be a matter of fixing whatever was broken when migrating the android controls over to b2g.
Sorry, I meant Chris Lee for V1 scope definition. Too many Chris's :)
Summary: Playing h264 content, no concept of spinning wheel while buffering → Playing video content, no concept of spinning wheel while buffering
cc'ing Larissa, who is handling Browser UX.
Whiteboard: [blocked-on-input] → [blocked-on-input Chris Lee]
Playing remote videos is a v1 feature according to Chris Lee.

We'd like to use the default HTML5 video player controls if possible.
blocking-basecamp: ? → +
Whiteboard: [blocked-on-input Chris Lee]
It's still a bit unclear what exactly is the problem here.

Is the problem here that the normal built-in controls for <video controls> doesn't show a spinner in B2G?

Or is the problem that one of the gaia apps uses custom video controls and those custom controls doesn't have a spinner?
I am unclear what UX is still needed for this bug. Can whoever is working on it please contact me if you are missing anything?

It seems that this use case is streaming video content from the web. In which case, the interaction flow is as follows:

1. The user taps on a video on the web
2. The video player opens
3. There is some period of time where we show an indeterminate loading indicator (a spinning wheel, etc. This should be a system UI component) while some portion of the video is buffering). During this period of time, if we can show the user some kind of clip, great. If not, it's just a dimmed screen.
4. Once some amount of video has loaded, it starts playing. In the meantime, it continues buffering, as per Frank's attached graphic.
5. If the video playback reaches the end of the buffer, go back to step #3.

open question: when the user is finished watching the video, how does he go back to the browser?
dclarke, can you provide an STR for this bug? Or confirm it's the following:

1) Start B2G browser
2) Enter http://cd.pn/b3 as the URL
3) Press Play button on the video that appears

Expected result:

4) Some indication that the video is buffering occurs until playback starts
   (Android uses a spinning throbber here)

Actual result:

4) What happens here?
4)
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #11)
> I am talking about streamed content, without buffering, you get this
> terrible jittery effect. Somehow we have to buffer the video content, and
> provide UI clues that this is happening.. 
> 
> The use case is in browser, on youtube.. etc...

Chris are you asking me to recheck this, or confirmation of what I had said above, or further quantification of the problem that i saw.
I want confirmation of what the issue is. See comment 19. I want an STR so I can follow the exact steps and get what you're getting so we all know we're working on the right thing.
doublec: here's some initial Visual design for the indicator, according to our building blocks: https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Progress_.26_Activity_Indicators

(I'm referring to the indeterminate ones, not the ones that show linear progress)
dclarke, can you provide an STR for this bug? Or confirm it's the following:

1) Start B2G browser
2) Enter http://www.webmfiles.org/demo-files/ as the URL
3) Press Play button on the video that appears

Expected result:

4) Some indication that the video is buffering occurs until playback starts
   (Android uses a spinning throbber here)

Actual result:

4) No playback, and then it would start playing but be entirely jittery, especially on a slower internet connection like 3g. The audio is unintelligible.  After it had fully downloaded, reload of the page content didn't play any faster. ( These results are fairly old) There could have been some improvements. I can retest tomorrow.
Actually just verified webm / mp4 playback in browser is currently not working on the b2g otoro device.
Do we want a throbber in the browser or in the video app?  Or both?
(In reply to Andrew Overholt [:overholt] from comment #27)
> Do we want a throbber in the browser or in the video app?  Or both?

The browser should immediately open the video player once the video is tapped. It makes the system feel more responsive and eliminates the need for two throbbers. The throbber should only appear in the video player while initial buffering is in progress.
Actually, I take that back :p The throbber should also appear any time a playing video has reached the end of the buffer and there's still content that needs to be loaded.
Thanks for the clarification!  I've tried to similarly clarify the summary based on my understanding.
Summary: Playing video content, no concept of spinning wheel while buffering → Show throbber in video app when remote content is buffering
(In reply to Andrew Overholt [:overholt] from comment #30)
> Thanks for the clarification!  I've tried to similarly clarify the summary
> based on my understanding.

Sorry if I'm over-clarifying  here :) I just want to make sure that we can still buffer in the background while video is playing (as per Frank's attached design in this bug). 

We should only resort to the throbber when we can't play any more video because the current buffer is empty and needs to be replenished.

(For more info, see comment #20)
Larissa: Are you saying we won't support playing <video> elements inside a website or app other than the video app at all?

Or are you just saying that when a video uses <video controls> then those controls will always cause the video to be opened in the video app as soon as the user clicks the <video controls> element?
Or, to put it another way, what do you expect to happen in the following cases. I.e. in which of the above cases should we start playing the video contents in the app and display a throbber as needed, and in which cases should we switch to the video player app?

* Webpage contains <video> and calls .play() on it.
* Webpage contains <video controls> and calls .play() on it.
* Webpage contains <video controls> and user clicks on it.
* Webapp contains <video> and calls .play() on it.
* Webapp contains <video controls> and calls .play() on it.
* Webapp contains <video controls> and user clicks on it.
(In reply to Larissa Co from comment #28)
> The browser should immediately open the video player once the video is
> tapped.

Hang on, I'm not clear on what you mean by this... 

Are you saying that when the B2G browser loads a page with a <video> in it and the user taps on the video, then the video should be loaded in the Gaia Video Player App rather than being played seamlessly in the page using the built in Gecko video controls? Or should Gecko's built in video controls make the video fullscreen?

There are two "video players" present on a B2G device, each of which have their own set of video controls; Gecko's built in <video> playing functionality, and the Gaia Video Player App's.

Gaia's Video Player App is just a web app using Gecko's <video> functionality but without using Gecko's video controls; the Gaia Video Player defines and uses its own JavaScript controls.

If you want Gecko to forward <video>s to the Gaia Video Player App for playback, then there's a bit of plumbing that we need to implement in Gecko to make this happen. Larissa, can you please confirm that you do or do not expect videos to be forwarded to the Gaia Video Player App for playback?

Whereas if you want Gecko's video controls to open the video in fullscreen on tap, then you need a bug filed in Core/Toolkit/Video controls to track making that change.

This bug is a mess, with people either not or mis-understanding and/or not communicating clearly what they want or need. I suggest we resolve this INVALID and refile bugs with clear scopes defining what needs to be done.

As far as I can tell the issues identified here that are bug-worthy are:
1. The gecko built in video controls should make the video fullscreen on tap.
2. The gecko built in video controls should display a throbber when there is no buffered video data to play.

I thought we used the android video controls on B2G, so I don't know why (2) isn't happening already.
1. The gecko built in video controls should make the video fullscreen on tap.
2. The gecko built in video controls should display a throbber when there is no buffered video data to play.

Agreed on this.  I think loading the video app would not be a good thing.
> This bug is a mess, with people either not or mis-understanding and/or not
> communicating clearly what they want or need. I suggest we resolve this
> INVALID and refile bugs with clear scopes defining what needs to be done.

Agreed. But lets get some clarity in what behavior we want before we do that.

> As far as I can tell the issues identified here that are bug-worthy are:
> 1. The gecko built in video controls should make the video fullscreen on tap.
> 2. The gecko built in video controls should display a throbber when there is
> no buffered video data to play.

I agree, that sounds good. Only question I have is, what should happen if there's a <video controls> element in a page, and the page calls .play() on it. Should that fullscreen the video?
fullscreen ability while playing video content has been reported
https://www.bugzilla.mozilla.org/show_bug.cgi?id=762739

Can we move the conversation to that bug, and maintain the conversation about the throbber here.
ur comment was:

    Sorry for contributing to the messiness :) I was under the impression that part of the reason this bug exists was that we didn't have the ability to play video right in the browser. This is why I was specing out a case in which we go to the video player.

    Here's what I think the "right" interaction design should be for the cases Jonas mentioned in comment 33-- let me know what we're capable of, and let's file those more specific bugs. (I'm also open to push back about this because I might not fully understand all the issues)

    * Webpage contains <video> and calls .play() on it.
    ** video should play in-page. It shouldn't play full-screen unless the app has specifically asked for it (can it do that?)

    * Webpage contains <video controls> and calls .play() on it.
    ** video should play in-page. It shouldn't play fullscreen unless the app has specifically asked for it.
    ** Do we have or need UI for embedded controls?
    ** (I hope I understand this case correctly to mean that there are controls, but the video is set to play at some point without the user clicking on any control). 

    * Webpage contains <video controls> and user clicks on it.
    ** I could be convinced otherwise, but I think this should open the video full-screen on the webpage. Do we have UI for such a player?

    I'm not sure if the risks or tradeoffs are different for Webapps, but I expect that the interaction should be the same as for Webpages, unless there's a good reason not to do it that way.

    In summary, if we have the ability to play video within the webpage/app I would much prefer that over opening the video player app. I also believe that we should only open the video fullscreen if the user taps on it. I.e. we shouldn't allow a video to hijack the screen when it plays automatically.

    Note that where the video plays is not quite the same as the buffering question.

    I still think that we should show a throbber while the video is buffering initially, and then continue buffering in the background when we have enough to start playing the video.
(In reply to Larissa Co from comment #38)
>     * Webpage contains <video> and calls .play() on it.
>     ** video should play in-page. It shouldn't play full-screen unless the
> app has specifically asked for it (can it do that?)

I believe we can do that yes.

>     * Webpage contains <video controls> and calls .play() on it.
>     ** video should play in-page. It shouldn't play fullscreen unless the
> app has specifically asked for it.
>     ** (I hope I understand this case correctly to mean that there are
> controls, but the video is set to play at some point without the user
> clicking on any control). 

You are understanding this correctly yes.

>     ** Do we have or need UI for embedded controls?

Good question. I don't know.

>     * Webpage contains <video controls> and user clicks on it.
>     ** I could be convinced otherwise, but I think this should open the
> video full-screen on the webpage. Do we have UI for such a player?

This sounds good to me.

>     I'm not sure if the risks or tradeoffs are different for Webapps, but I
> expect that the interaction should be the same as for Webpages, unless
> there's a good reason not to do it that way.

I agree.

>     In summary, if we have the ability to play video within the webpage/app
> I would much prefer that over opening the video player app. I also believe
> that we should only open the video fullscreen if the user taps on it. I.e.
> we shouldn't allow a video to hijack the screen when it plays automatically.

I agree.

>     Note that where the video plays is not quite the same as the buffering
> question.

Indeed. I wanted to get us aligned on the fundamental behavior before getting into exact UI.

>     I still think that we should show a throbber while the video is
> buffering initially, and then continue buffering in the background when we
> have enough to start playing the video.

I agree.


So it sounds like we're getting closer alignment between everyone here. Yay!

So based on that. Let me draft a proposal for how things should behave and then we can figure out what doesn't work so that we can file bugs on that:


In all cases we will buffer in the background while playing using the various heuristics that we already use on desktop (i.e. we honor various buffering-controlling attributes, and try to not buffer more than needed). 

In all cases, videos in apps behave like videos in webpages.


If a page contains <video> and the page calls .play() on it, we'll play the video in-page at exactly the size that the video had before it started playing. No controls are displayed, and if the user clicks the video nothing happens (though the page can detect the click and fullscreen the video if it so desires). If the video pauses due to buffering we *don't* display a throbber, that's the responsibility of the webpage (events are fired on the page to aid in this). This matches what we do on desktop.

If a page contains <video controls> and the page calls .play() on it, we'll play the video in-page at exactly the size that the video had before it started playing. Controls are displayed as needed. If the user clicks the video it fullscreens. If we have to pause the video due to buffering we display a throbber.

If a page contains <video controls> and the user clicks it we'll fullscreen the video and start playing it. Controls are displayed as needed. If we have to pause the video due to buffering we display a throbber.


Does this match people's expectations? dclarke, can you elaborate on which of the above parts do not work so that we can file bugs. STRs are always helpful in these cases.
(In reply to Jonas Sicking (:sicking) from comment #39)
> Does this match people's expectations?

Yup, sounds good.
(In reply to Jonas Sicking (:sicking) from comment #39)
> If a page contains <video controls> and the user clicks it we'll fullscreen
> the video and start playing it. Controls are displayed as needed. If we have
> to pause the video due to buffering we display a throbber.

With the exception of this, what you describe is how Android and desktop works. I think B2G should be the same. We shouldn't full screen on user click because this will break pages that have events on the video and change items on the page when those events occur, expecting the user to see those changes while it plays. For example, showing a slide deck next to the video as it plays with the deck changing at certain time points. Clicking the video should just play it inline. 

On Android you long press the video to go full screen - can we do this on B2G?
I'm a bit confused. Are you saying that Fennec *does* fullscreen on normal user click? Or that a long-click is required?

What do other mobile browsers do? I.e. Safari, Android browser, chrome-for-android?

I agree that it might very well be the wrong thing to do for many pages to go fullscreen. But it seems more common than not on small-screen devices that you want to go fullscreen, and the whole point of <video controls> is that the page shouldn't have to provide scripting to get a good player.

Would an option be to let the default action for the "click" event be to go fullscreen? That way pages can call .preventDefault() in order to "stay in the slide".
(In reply to Jonas Sicking (:sicking) from comment #42)
> I'm a bit confused. Are you saying that Fennec *does* fullscreen on normal
> user click? Or that a long-click is required?

Long click on the video in fennec and a menu appears. One of the options in the menu is "Full Screen".

> What do other mobile browsers do? I.e. Safari, Android browser,
> chrome-for-android?

Android browser plays inline when you click on the video. I don't know about the others.

> Would an option be to let the default action for the "click" event be to go
> fullscreen? That way pages can call .preventDefault() in order to "stay in
> the slide".

Won't this result in different behaviour to the desktop. Users would need -preventDefault() for mobile but not desktop.
(In reply to Chris Double (:doublec) from comment #43)
> > Would an option be to let the default action for the "click" event be to go
> > fullscreen? That way pages can call .preventDefault() in order to "stay in
> > the slide".
> 
> Won't this result in different behaviour to the desktop. Users would need
> -preventDefault() for mobile but not desktop.

If we have the following requirements:

* <video controls> should provide a "good" UI by default on all platforms.
* "good" UI on desktop is to not go fullscreen by default.
* "good" UI on mobile is to go fullscreen by default.

Then I see no way of exposing an API which is fully consistent on all platforms. The best thing I could think of would be to go fullscreen on mobile but in the controls show a button to go out of fullscreen. This obviously wouldn't solve all the problems, but I can't think of a solution that does.
dclarke, with regard to comment 26 (videos not playing at all on otoro) I raised bug 783172.
Yeah, I agree that the case doublec raised in comment 41 doesn't seem very common to me on a mobile platform. (Or rather, the page would probably be extremely difficult to view anyway on a small screen that missing some changes to the webpage while the video is playing is probably the least of our worries.)

On the stock browser on Android JB, the video plays inline on some pages, and opens a full screen player in some (it evens seems like it went to the video player app, but I can't be sure). On the Youtube site, the video plays inline, but turning the phone in landscape mode makes the video play full screen, which was a cool compromise. WP7 and iOS also open the video to full screen (WP7 in landscape mode and iOS in portrait).

Anyway, this is all to say that there isn't a consistent pattern here.

If I had to choose, I'd still say that the default should go to fullscreen when the user clicks play. The fullscreen mode should have a controller (similar to the video player app) that can be revealed on tap, and the user can exit the mode to return to the webpage.

It's true that this direction means we won't have an API that's fully consistent on all platforms (and at what screen size do we say "good" == play inline ?) but I believe it's more aligned with the user's intent (i.e. "I want to be able to view a video at a 'reasonable' size."-- it's possible that someone could make the video thumbnail so small that you can't really watch it at all).
I'll take this just to make sure that we file bugs on the appropriate issues and then close this one.
Assignee: nobody → jonas
(In reply to Larissa Co from comment #46)
> Yeah, I agree that the case doublec raised in comment 41 doesn't seem very
> common to me on a mobile platform. (Or rather, the page would probably be
> extremely difficult to view anyway on a small screen that missing some
> changes to the webpage while the video is playing is probably the least of
> our worries.)

I'm not sure I understand what you are saying here.

Are you saying that you don't think that it's a common problem that a automatic-fullscreen-video would cover up other changing parts of a page since those other parts would be very small anyway? (speaking only in the context of phone-sized devices which we're shipping for basecamp).

Or are you saying that you don't think it's common for videos to automatically fullscreen when clicked (again, only in the context of phone-sized devices)?

> If I had to choose, I'd still say that the default should go to fullscreen
> when the user clicks play. The fullscreen mode should have a controller
> (similar to the video player app) that can be revealed on tap, and the user
> can exit the mode to return to the webpage.
> 
> It's true that this direction means we won't have an API that's fully
> consistent on all platforms (and at what screen size do we say "good" ==
> play inline ?) but I believe it's more aligned with the user's intent (i.e.
> "I want to be able to view a video at a 'reasonable' size."-- it's possible
> that someone could make the video thumbnail so small that you can't really
> watch it at all).

I agree with this. So that leaves the question of who's call this is since as I understand it Chris feels otherwise.

I'd like to get to a desired behavior fairly soon so that we can figure out what pieces aren't working as they should and get bugs filed on them.
(In reply to Jonas Sicking (:sicking) from comment #48)
> I agree with this. So that leaves the question of who's call this is since
> as I understand it Chris feels otherwise.

While I personally feel otherwise I think we should go for the decision of the mobile/UX people since they have more experience in that area. We can always adjust the display size threshold of when fullscreen vs inline playback should occur at some later time.
Ok, so let me try to summarize.

For in-page (and in-app) <video>:
The user clicking on the video should do nothing. If the page calls video.play we should not show a throbber even when buffering, that is the webpage's responsibility. While the video is playing we show no UI, that too is the webpage's responsibility. The video isn't full-screened unless the page explicitly fullscreens the video element using normal DOM APIs for fullscreening and/or resizing elements.

For in-page (and in-app) <video controls>:
The user clicking on the video should fullscreen the video and start playing it. If we have to pause the video to buffer more data we should show a throbber. We show UI of some sort to allow controlling the video, including pausing/resuming/rewinding/fastforward. This UI will also include the ability to switch out of fullscreen mode, as well as swich back into fullscreen mode.

If the page calls video.play() on the video we do not fullscreen automatically, but otherwise the UI behaves the same.

I'll leave it up to the UX team to decide if this UI is only shown when the user clicks the screen or if it's shown at all times. This UI can in theory be different in fullscreen mode and non-fullscreen mode.

For the video player app:
At all times show the appropriate UI for controlling video playback. Again, up to UX to decide what that appropriate UI is. But we should always show a throbber if we have to pause a video due to buffering.


Does this sound correct to people? If so, can we get clarification on which parts do not currently work so that we can get bugs filed. Note that a throbber shouldn't be displayed in all situations when buffering since for some situations that is the responsibility of the web page/app.
Adding qawanted so that we can get answers about what exactly of the behavior in comment 50 that isn't working.

You should be able to try the behavior for <video> and <video controls> by simply loading webpages with those elements in the browser app.
Keywords: qawanted
@sicking, The UI you describe makes sense to me! I'll wait to see what QA finds before I go and design more UI. I think we have enough from the video player UI that we might not have more to design. Potentially, we just have to define what shows up in certain cases.
David: Did you have a chance to look at this?
Whiteboard: [blocked-on-input David Clarke]
blocking-basecamp: + → ?
(In reply to Jonas Sicking (:sicking) from comment #50)
> Ok, so let me try to summarize.
> 
> For in-page (and in-app) <video>:
> The user clicking on the video should do nothing. If the page calls
> video.play we should not show a throbber even when buffering, that is the
> webpage's responsibility. While the video is playing we show no UI, that too
> is the webpage's responsibility. The video isn't full-screened unless the
> page explicitly fullscreens the video element using normal DOM APIs for
> fullscreening and/or resizing elements.

This is how things work. 
 
> For in-page (and in-app) <video controls>:
> The user clicking on the video should fullscreen the video and start playing
> it. If we have to pause the video to buffer more data we should show a
> throbber. We show UI of some sort to allow controlling the video, including
> pausing/resuming/rewinding/fastforward. This UI will also include the
> ability to switch out of fullscreen mode, as well as swich back into
> fullscreen mode.
> 

My observations with 09/10 build: 
Video controls, I don't see a method to go full screen, and a tap does not bring up a full screen. I did not get the case to work where there is automatic fullscreening. 

The throbber, really doesn't give much indication that data is buffering, as in when paused you don't see data being added to the buffer. So it's a bit hard to tell what is going on. After a while you can press play, and then wait some period of time and the throbber will update with however much has been buffered. Basically the UI is inconsistent, and given that I have a constant rate of download I should visually see the buffering occurring. 

As I move back and forth in the video on the browser, I don't get a sense that we are using cached data.  

> If the page calls video.play() on the video we do not fullscreen
> automatically, but otherwise the UI behaves the same.

Calling video.play() on the video does cause there not to be a fullscreen. 

> I'll leave it up to the UX team to decide if this UI is only shown when the
> user clicks the screen or if it's shown at all times. This UI can in theory
> be different in fullscreen mode and non-fullscreen mode.
> 
> For the video player app:
> At all times show the appropriate UI for controlling video playback. Again,
> up to UX to decide what that appropriate UI is. But we should always show a
> throbber if we have to pause a video due to buffering.
> 
This sounds correct to me. 

> Does this sound correct to people? If so, can we get clarification on which
> parts do not currently work so that we can get bugs filed. Note that a
> throbber shouldn't be displayed in all situations when buffering since for
> some situations that is the responsibility of the web page/app.

I would say the throbber part is the UI design that needs the most work at this part. And the ability to go fullscreen from the video.
Keywords: qawanted
Whiteboard: [blocked-on-input David Clarke]
David: I think there might be some mismatched vocabulary.

The "throbber" is the spinny thing that should be displayed overlayed on the video if the video is paused due to not enough data.

The "buffering bar" (don't know if this has a more official name) is the thing that displays how much data has been downloaded and is immediately available to play.


I think the "throbber" is an important indicator to users why their video isn't playing like they expect. I.e. it helps the user understand that the phone/browser/website isn't broken, but rather that they just need to wait a bit for downloading.

So if the video is pausing due to more download needed, I think it's important that a throbber is displayed. It seems less important that the "buffering bar" is usable as an indicator that the network connection is working. Especially since we apply various complex policies for when we choose to buffer ahead of where the user is playing.
So then there is no throbber, and there is a buffering bar, but the buffering bar does not behave as I would have expected.
I filed bug 790126 and bug 790125.

Closing this one as INVALID since we now have bugs for the individual issues discussed here.

David, if you have any links that you have used to find this, it would be great if you could add it to the above two bugs.
Status: NEW → RESOLVED
blocking-basecamp: ? → ---
blocking-kilimanjaro: ? → ---
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: