Fast video start

Fast video start is a user interface design technique for apps
that reduces the amount of time apparent to the user that the video
stream buffers before actual playback begins.

All digital video requires some time after a video is selected to begin
playback, and video files streamed over HTTP add network transfer rates
to this buffering time. Typically, to play back a video, the content
meta-data for a video is set, and an roSpringboardScreen component (or
equivalent) is shown to the user with descriptive details about the
video. When the user actually selects the video for playback, calling
play() on the roVideoScreen or roVideoPlayer object shows a "loading"
screen before actual playback, while the video stream is buffering.
"Fast start" allows this video stream buffering to take place
before the user has actually selected a video for playback, by
initiating the buffering process while the user is deciding whether to
play a certain video.

To implement fast video start, you create a roVideoScreen or
roVideoPlayer component prior to showing a roSpringboardScreen (or
equivalent) for a video, and call Prebuffer(). The video stream will
buffer for as long as the user is reading the description of the video
on the screen. Then when the user actually selects the video for
playback, call play(). Depending on how much time the user spent reading
the video description, the video may begin actual playback immediately,
or with a much reduced amount of time that the "loading" screen is
shown.

Calling Prebuffer() starts buffering the video specified by a previous
SetContentList() (for roVideoPlayer) or SetContent() (for roVideoScreen)
call. If the video has not been specified in one of these ways, calling
Prebuffer() has no
effect.

SceneGraph apps use the Video node control field prebuffer option to implement Fast Video Start. See Fast start media playback for information on implementing Fast Video Start in a SceneGraph app.

roVideoPlayer use cases

Prebuffer before playback

The following code demonstrates this use case.

port = CreateObject( "roMessagePort" )

content = {
  Stream: { url : "http://play.this.url.com/video.m3u8" }
  StreamFormat: "hls"
}

' First   create the player and set content list
player = CreateObject( "roVideoPlayer" )
player.setMessagePort( port )
player.setContentList( content )
' Prebuffer the data
player.Prebuffer()

' Show the content springboard screen and wait for an event
' from user asking to playback the content
while true
  msg = wait( 0, port)
  ' break out if correct message is received
end while

' Start   playback now
player.play()

' Handle user requests here
while true
  msg = wait( 0, port )
  ' process msg here
end while

For this use case, the video player event handling has to occur in two
event loops, one while prebuffering from a content springboard screen, and one during playback. This is necessary since the
firmware may encounter errors during prebuffer that should be handled by
the app.

Playback canceled after/while prebuffering

If the app calls Stop() while prebuffering, prebuffered video data
is discarded. The app can subsequently call SetContentList(),
Prebuffer() and Play() to play back a new video.

Additional considerations

To make use of the "fast start" feature, when an app enters the
springboard (or movie details) screen, it must create a roVideoPlayer or
roVideoScreen, and prebuffer the video. There are a few things to
consider.

Prebuffer position

Apps may have multiple play options on the springboard screen,
including resuming playback and playback from start. A bookmarked
position may be set in content meta-data to indicate the playback start
position. Each play option will have a different play position
associated with it. The bookmark position will have to default to one of
the play positions and prebuffer the content from here. If the user
selects the other play option, the data must be buffered again.

Resuming playback

A user may exit playback to go back to the springboard screen, and then
resume playback of the same video. Since the roVideoPlayer will have
buffered the data, the app will ideally just resume playback. When
going back to the springboard screen, Roku recommends that playback
should be paused on roVideoPlayer. A user request to resume playback
will take effect instantaneously. If the user starts playback from the
beginning, then the roVideoPlayer must be stopped first, the
BOOKMARKPOSITION modified in content meta-data, and a new playback
session started.