Video controls for live feeds: instant replay for the web
July 27, 2009
Watching live video online is generally a great experience. It’s a way to watch important world events without a TV, a way to view with friends without syncing, and still the best way to see a shuttle launch naked.
But online live video could be improved. For instance, there’s usually no way to rewind video to see a clip again, nor a way to pause and watch video from where you left off. In fact, current implementations of live video have very few features – usually they are adaptations of regular video controls, but with non-interactive elements such as stationary or removed timelines.
We think users would benefit from the ability to pause and go back in live video by keeping some amount of the video buffered. However, this presents a few design challenges:
- How to visually represent when the user is “live” vs. viewing buffered video
- How to visually represent the amount of video in the buffer
- How to make it easy for the user to jump between live and buffered video
Limi and myself did some brainstorming to develop ways to present this functionality. Below is an idea we had that we’d love feedback on. It’s based on the idea of a “live mode,” which users can enter and exit via the video controls. By default, the user begins in live mode (the box on the right of the timeline). As the user watches the live video, the timeline to the left encompasses how much video has been buffered. So, after one minute the timeline represents one minute in length, and after two minutes it represents two minutes. To give an indication of how much time the bar represents, ticks marking minutes will scroll left as the video plays. Clicking the live mode button or moving the slider back to the live point puts the user back in live mode.
However, eventually the video will reach the maximum that can be buffered. For the purposes of these mockups, we’ll say that 10 minutes is the limit. After the video plays for 10 minutes, the beginning of the video is dropped and no longer accessible. The user sees this as the 0:00 mark disappearing from the timeline, and higher time markers continuing to scroll left.
If the user pauses the video, he exits live mode and the slider moves off of the live mode box. A visual indication will show that the video is no longer live – perhaps by fading the live mode and/or changing the shape and color of the slider. As the video is paused, new live video will be buffered and old video will continue to be dropped, moving the paused slider and the timeline left.
Once the slider has moved back 10 minutes, the new video is no longer buffered: only the ten minutes immediately after the pause is stored. This is so that when the user returns, the video will play from the point they left off and not the somewhat arbitrary 10 minutes before the live video. At this point, the buffered 10 minutes and the live point are no longer connected – a visual indication such as a break of the timeline will indicate this.
So, what do you think? Was this difficult to understand? It’s a bit of a shift from commonly understood video control interaction, but I think it may be intuitive once users play with it. I’ll be eager to find out.
You can read more about our progress in the wiki.
P.S. This is the first blog post I’ve made in awhile, but unfortunately for you I’m going to be posting a lot more frequently, starting now. Please don’t cry, they won’t all be this long.
Jennifer Morrow's Blog 
July 27, 2009 at 9:01 pm
Actually, it’s pretty interesting for us non-UI designers to see someone working through the details of how this stuff ought to behave. The “tl;dr” crowd should go refresh their Twitter feeds if it irritates them. 🙂
July 27, 2009 at 9:17 pm
I like.
How would the time counter above the “live” button operate when the stream is paused in non-live mode? ie, would it pause too, or still count up?
July 27, 2009 at 9:21 pm
@Blair: The counter above live would still count up, showing how long the live video has lasted, but the time on the slider would remain the same.
July 27, 2009 at 9:30 pm
[…] https://jboriss.wordpress.com/2009/07/27/video-controls-for-live-feeds-instant-replay-for-the-web/ […]
July 27, 2009 at 9:31 pm
Interesting, but users aren’t going to like if they pause a video for 10+ minutes (or any arbitrary buffer time), come back, and discover a large gap missing that they can no longer play.
IMO you should try to buffer as much as possible, perhaps by writing excess buffered video data to the disk cache in case the user wants to play it later, then deleting it if needed after the user leaves the page.
July 27, 2009 at 10:44 pm
TiVo and other DVR systems already have that sort of restriction; it’s a bit annoying, but I’m not sure it’s reasonable to continue writing to memory or disk indefinitely, especially if you visit a streaming video site and then navigate on to other webpages, forgetting about it entirely. Having a limit is reasonable, and not unprecedented.
Also: I really like this proposal – it’s very DVR-like, which is an interface that’s becoming more and more common and therefore familiar to our users.
July 27, 2009 at 11:34 pm
Reminds me of Real Player. Although most of their ethical decision where questionable, their core playback functionallty was reallly quite good and ahead of it’s time.
July 27, 2009 at 11:38 pm
If you come back to a ten minute section unconnected to the live stream, would it be useful to know when this was in relation to *NOW*?
Is what I’m about to watch form 11 minutes ago or two days ago?
If I was watching news I would probably find absolute times useful, whereas if I was watching a football match relative times would be most relevant. In fact with football matches it would be most useful to split time into tracks each with their own relative time stamps.
10 minutes of pre-game
45 minutes of first half
30 minutes of half time
45 minutes of second half (most usefully starting the times at 45 to match the game time)
10 minutes of post game.
Obviously the safest assumption is to go with the norm and display relative times, but should there be scope for other ways of displayign the time as appropriate?
July 28, 2009 at 12:06 pm
I like this concept a lot – as Joe points out it’s very DVR-like and seems fairly intuitive. I’m curious how this interface would work if the stream is temporarily interrupted or hangs, though. Would the “live” indicator pulsate or glow if the stream is working and grey out if the stream dies, for example?
July 28, 2009 at 12:15 pm
If you are watching a live stream AND you are under the (undesirable) constraint of having only 10 minutes of buffer time, you probably (in most circumstances) want the pause to lapse, and to just buffer the latest 10 minutes. In other words, once 10 minutes has been buffered, the video would automatically start playing again, but 10 minutes behind the live point.
Why? If catch-play is also an option, you’d probably want to catch-play just the last 10 minutes, after you’ve finished, for example, being distracted by some engrossing website, running down to the store to buy milk or, erm, going to the toilet.
If you want to pause because you think “This is going to be important!” you really want a record button…
Tricky one, this feature will be great whatever you choose to do.
July 28, 2009 at 12:20 pm
Obviously (hopefully?) the “10 minutes” is just so that the edge case (of running out of storage, etc) can be illustrated.
It’s not clear whether cutting off the beginning or the end of a stream is more desirable.
July 29, 2009 at 8:34 am
I like it. Clearly, deciding whether to drop the oldest or the newest content when you run out of buffer is a Scylla and Charybdis thing. Neither option is great. Even cooler would be dynamically degrading the quality of the buffered video to make more space! 😉
Gerv
August 3, 2009 at 10:28 pm
>However, eventually the video will reach the maximum that can >be buffered. For the purposes of these mockups, we’ll say >that 10 minutes is the limit
Is there anyway to remove this constraint? I’ve been in situations where I would like to load a live feed for the purpose of recording it and watching it later. Also, watching the buffer start to disappear seems like it is taking control away from the user, and creating a stressful experience.
August 5, 2009 at 4:54 am
I think TiVo is a good analogy to this. Just set the windows to like 30 minutes, and let the progressbar move along. When you get to within 10 minutes of the end, add another 30. The next 30 after that drop the first 30.
August 7, 2009 at 4:42 pm
[…] everyone for the feedback, which was all useful. I did want to draw attention to one point that James Heaver touched on: different uses of live video benefit from different ways of displaying the current […]
August 7, 2009 at 9:23 pm
This is a very interesting discussion, and one that is especially relevant now that Flash Media Server supports DVR functionality. The current FLVPlayback component in Flash CS4 supports pause and rewind of live streams, but does NOT have any sort of intuitive display such as you are developing here. If you develop this concept into a Flash component, I’m certain there would be a market for it!
One note; FMS does not limit the buffer to an arbitrary amount as you mention, so you could conceivably rewind to the beginning of an event.
August 18, 2009 at 7:15 am
Reminds me of Real Player. Although most of their ethical decision where questionable, their core playback functionallty was reallly quite good and ahead of it’s time.
——————————————————
tuyen dung | viec lam | tim viec
July 2, 2011 at 2:05 am
[..]However, eventually the video will reach the maximum that can be buffered. For the purposes of these mockups, we’ll say that 10 minutes is the limit. [..] I think TiVo is a good analogy to this. Just set the windows to like 30 minutes, and let the progress bar move along. Tim Viec Lam