\fresh{}

\section{Video\label{sote:vide}}

\subsection{DASH\@: the standard for video streaming\label{sote:dash}}

\copied{}
Dynamic Adaptive Streaming over HTTP (DASH), or MPEG-DASH (\citet{dash-std,dash-std-2}), is now a widely deployed
standard for streaming adaptive video content on the Web (\citet{dash-std-full}), made to be simple and scalable.
\fresh{}
DASH is based on a clever way of structuring the content that allows a great adaptability during the streaming without requiring any server side computation.

\subsubsection{DASH structure}

All the content structure is described in a Media Presentation Description (MPD) file, written in the XML format.
This file has 4 layers: the periods, the adaptation sets, the representations and the segments.
A MPD has a tree-structure, meaning that it has many periods, each period can have many adaptation sets, each adaptation set can have many representation, and each representation can have many segments.

\paragraph{Periods.}
Periods are used to delimit content depending on time.
It can be used to delimit chapters, or to add advertisements that occur at the beginning, during or at the end of a video.

\paragraph{Adaptation sets.}
Adaptation sets are used to delimit content depending on format.
Each adaptation set has a mime-type, and all the representations and segments that it contains share this mime-type.
In videos, most of the time, each period has at least one adaptation set containing the images, and one adaptation set containing the sound.
It may also have an adaptation set for subtitles.

\paragraph{Representations.}
The representation level is the level DASH uses to offer the same content at different levels of resolution.
For example, an adaptation set containing images has a representation for each available resolution (it might be 480p, 720p, 1080p, etc.).
This allows a user to choose its representation and change it during the video, but most importantly, since the software is able to estimate its downloading speed based on the time it took to download data in the past, it is able to find the optimal resolution, being the highest resolution that the client can request without stalling.

\paragraph{Segments.}
Until this level in the MPD, content has been divided but it is still far from being sufficiently divided to be streamed efficiently.
In fact, a representation of the images of a chapter of a movie is still a long video, and keeping such a big file is not possible  since heavy files prevent the dynamic of streaming: if the user requests to change the level of resolution of a video, the system would either have to wait until the file is totally downloaded, or cancel the request, making all the progress done unusable.

Segments are used to prevent this issue.
They typically encode files that contain approximately one second of video, and give the software a great ability to dynamically adapt to the system.
If a user wants to seek somewhere else in the video, only one second of data can be lost, and only one second of data has to be downloaded for the playback to resume.

\subsubsection{Client side computation}

Once a video is encoded in DASH format, all the files have been structured and the MPD has been generated, all this data can simply be hosted on a static HTTP server that does no computation other than serving files when it receives requests.
All the intelligence and the decision making is moved to the client side.
A client typically starts by downloading the MPD file, and then proceeds on downloading segments of the different adaptation sets that he needs, estimating itself its downloading speed and choosing itself whether it needs to change representation or not.
This is one of the strengths of DASH\@: no powerful server is required, and since static HTTP server are studied since the beginning of the internet, they are optimized well and all DASH clients can benefit from it.

\subsection{DASH-SRD}

DASH-SRD (Spatial Relationship Description,~\cite{dash-srd}) is a feature that extends the DASH standard to allow streaming only a spatial subpart of a video to a device.
It works by encoding a video at multiple resolutions, and tiling the highest resolutions as shown in Figure~\ref{sota:srd-png}.
That way, a client can choose to download either the low resolution of the whole video or higher resolutions of a subpart of the video.

\begin{figure}[th]
    \centering
    \includegraphics[width=0.6\textwidth]{assets/state-of-the-art/video/srd.png}
    \caption{DASH-SRD~\cite{dash-srd}\label{sota:srd-png}}
\end{figure}

For each tile of the video, an adaptation set is declared in the MPD, and a supplemental property is defined in order to give the client information about the tile.
This supplemental property contains many elements, but the most important ones are the position ($x$ and $y$) and the size (width and height) of the tile describing the position of the tile in relation to the full video.
An example of such a property is given in Listing~\ref{sota:srd-xml}.

\begin{figure}[th]
\lstinputlisting[%
        language=XML,
        caption={MPD of a video encoded using DASH-SRD},
        label=sota:srd-xml,
        emph={%
            MPD,
            Period,
            AdaptationSet,
            Representation,
            BaseURL,
            SegmentBase,
            Initialization,
            Role,
            SupplementalProperty,
            SegmentList,
            SegmentURL,
            Viewpoint
        }
    ]{assets/state-of-the-art/video/srd.xml}
\end{figure}

Essentially, this feature is a way of achieving view-dependent streaming, since the client only displays a part of the video and can avoid downloading content that will not be displayed.
This is especially interesting in the context of 3D streaming since we have this same pattern of a user viewing only a part of a content.

\subsection{Prefetching in video steaming}
\copied{}

We briefly survey other research on prefetching that focuses on non-continuous interaction in other types of media.

In the context of navigating in a video, a recent work by~\cite{video-bookmarks} prefetches video chunks located after bookmarks along the video timeline.
Their work, however, focuses on changing the user behavior to improve the prefetching hit rate, by depicting the state of the prefetched buffer to the user.
Carlier et al.\ also consider prefetching in the context of zoomable videos in an earlier work~\cite{zoomable-video}, and showed that predicting which region of videos the user will zoom into or pan to by analyzing interaction traces from users is difficult.

Prefetching for navigation through a sequence of short online videos is considered by khemmarat et al in~\cite{user-generated-videos}.
Each switch from the current video to the next can be treated as a non-continuous interaction.
The authors proposed recommendation-aware prefetching --- to prefetch the prefix of videos from the search result list and related video list, as these videos are likely to be of interest to the user and other users from the same community.

\cite{video-navigation-mpd} consider the problem of prefetching in the context of a hypervideo; non-continuous interaction happens when users click on a hyperlink in the video.
They propose a formal framework that captures the click probability, the bandwidth, and the bit rate of videos as a markov decision problem, and derive an optimal prefetching policy.

\cite{joserlin} propose Joserlin, a generic framework for prefetching that applies to any non-continuous media, but focuses on peer-to-peer streaming applications.
They do not predict which item to prefetch, but rather focus on how to schedule the prefetch request and response.

There is a huge body of work on prefetching web objects in the context of the world wide web. Interested readers can refer to numerous surveys written on this topic (e.g.,~\cite{survey-caching-prefetching}).

