X-Git-Url: https://git.carlh.net/gitweb/?a=blobdiff_plain;f=doc%2Fdesign%2Fvob.tex;h=075c343187579764ab158ca75202ab374adb3874;hb=6d686ea45f5cd01a0d11f92a903ac77779ad8562;hp=08ef90af96f5deadb08121cc73c69d049511df82;hpb=34a5f6381d7eba172dbbca25c3263180bf9c152e;p=dcpomatic.git

diff --git a/doc/design/vob.tex b/doc/design/vob.tex
index 08ef90af9..075c34318 100644
--- a/doc/design/vob.tex
+++ b/doc/design/vob.tex
@@ -73,4 +73,49 @@ whatever it wanted in the back-end.  It would either coalesce content
 or make the decoder handle multiple content; the former would preserve
 the \texttt{Piece} stuff.
 
+
+\section{Attempt 1}
+
+An alternative might be to change \texttt{Piece} so that it can
+represent multiple pieces of content, then give these to the decoder; i.e.
+
+\begin{itemize}
+\item 1 \texttt{Content} $\to$ 1 file
+\item 1 \texttt{Piece} $\to$ 1 \texttt{Decoder} $\to$ many \texttt{Content}
+\end{itemize}
+
+At first glance the disadvantage seems to be that where once we had a
+piece of content, we now have a list, and so there has to be
+non-trival extra work each time we look at that piece of content
+(effectively coalescing that content on the fly).  This suggests that
+the \texttt{Content} should take multiple files so that the management
+of that is done within \texttt{Content}
+
+
+\section{Attempt 2}
+
+\begin{itemize}
+\item 1 \texttt{Content} $\to$ many files
+\item 1 \texttt{Piece} $\to$ 1 \texttt{Decoder} $\to$ 1 \texttt{Content}
+\end{itemize}
+
+The immediate `shame' about this is that most content is happy being
+just one file.  Details of content path(s) are used for:
+
+\begin{itemize}
+\item \emph{[UI]} Presentation to the user.
+\item \emph{[UI]} UI to `find' missing content.
+\item \emph{[Back-end]} Actually opening the files to decode / examine them.
+\end{itemize}
+
+If we create the coalesced \texttt{Content} on building the pieces for
+the player, it will never appear in the user interface.  This means
+that it needs only the \emph{[back-end]} interfaces.
+
+However, it seems silly to create a specialised different
+\texttt{FFmpegContent}-like type to express the tiny difference
+between single- and multi-file.
+
+This suggests that the `shame' above is not a big deal.
+
 \end{document}