doc/design/vob.tex

   1 \documentclass{article}
   2 \title{VOBs}
   3 \author{}
   4 \date{}
   5 \begin{document}
   6 \maketitle
   7
   8 VOB files are tricky.  They appear to be components of a complete
   9 media file which have been chopped up with no regard for packets.
  10 Therefore they must be interpreted as if they had been joined together
  11 with \texttt{cat}.
  12
  13 This is true, at least, with one test (``The Blues Brothers'' DVD)
  14 which has its first VOB-to-VOB transition when Elwood looks at the
  15 `Murph and the Magictones' business card.
  16
  17 Solutions:
  18 \begin{enumerate}
  19 \item Fiddle the decoders so that they pass on bits of packets
  20   to the next decoder in line; this appears to be difficult.
  21 \item Coalesce VOB files into one big `file' (or virtual file)
  22   for feeding to FFmpeg.
  23 \end{enumerate}
  24
  25 The second solution is easy enough to do, but the UI is tricky.  As
  26 far as I can see the user has explicitly to request this behaviour, as
  27 coalescing two normal video files will cause problems.  If they do
  28 request it, how should it be represented?
  29
  30 \begin{enumerate}
  31 \item In the UI?
  32 \begin{enumerate}
  33 \item Select VOBs and coalesce or
  34 \item Coalese all files by some switch?
  35 \end{enumerate}
  36 \item In the back-end?
  37 \begin{enumerate}
  38 \item A single \texttt{Content} has multiple files or
  39 \item A single \texttt{Decoder} has multiple \texttt{Content}s.
  40 \end{enumerate}
  41 \end{enumerate}
  42
  43 UI-wise, there will have to be some heuristic or nudging to get the
  44 user to do the right thing.  It probably does not matter.
  45
  46 The back-end is trickier.  There is currently a 1:1 map of back-end
  47 content to UI content.  To preserve that, we would have to:
  48
  49 \begin{enumerate}
  50 \item Have some hierarchy to enable grouped content (so that 1:1
  51   decoder--content is preserved).  This removes the 1:1 between
  52   content and file, which is nice for everything except this
  53   special (nasty) VOB case.
  54 \item Allow a single decoder to manage multiple pieces of content.
  55   The problem with this is that the \texttt{Player} has
  56   \texttt{Piece}s, which are 1:1 decoder--content maps.  1--many for
  57   decoder--content screws anything done with \texttt{Piece}s --- seek
  58   (at least).
  59 \end{enumerate}
  60
  61 Probably have to think about this from the UI point of view; first,
  62 the user adds 4 VOB files (1 by 1) which should eventually be
  63 coalesced.  Either:
  64
  65 \begin{enumerate}
  66 \item They are coalesced magically with a switch, or
  67 \item The user must specifically coalesce them, and then the result
  68   must be reflected in the UI.
  69 \end{enumerate}
  70
  71 The first option could be done in the \texttt{Player} if it created
  72 whatever it wanted in the back-end.  It would either coalesce content
  73 or make the decoder handle multiple content; the former would preserve
  74 the \texttt{Piece} stuff.
  75
  76
  77 \section{Attempt 1}
  78
  79 An alternative might be to change \texttt{Piece} so that it can
  80 represent multiple pieces of content, then give these to the decoder; i.e.
  81
  82 \begin{itemize}
  83 \item 1 \texttt{Content} $\to$ 1 file
  84 \item 1 \texttt{Piece} $\to$ 1 \texttt{Decoder} $\to$ many \texttt{Content}
  85 \end{itemize}
  86
  87 At first glance the disadvantage seems to be that where once we had a
  88 piece of content, we now have a list, and so there has to be
  89 non-trival extra work each time we look at that piece of content
  90 (effectively coalescing that content on the fly).  This suggests that
  91 the \texttt{Content} should take multiple files so that the management
  92 of that is done within \texttt{Content}
  93
  94
  95 \section{Attempt 2}
  96
  97 \begin{itemize}
  98 \item 1 \texttt{Content} $\to$ many files
  99 \item 1 \texttt{Piece} $\to$ 1 \texttt{Decoder} $\to$ 1 \texttt{Content}
 100 \end{itemize}
 101
 102 The immediate `shame' about this is that most content is happy being
 103 just one file.  Details of content path(s) are used for:
 104
 105 \begin{itemize}
 106 \item \emph{[UI]} Presentation to the user.
 107 \item \emph{[UI]} UI to `find' missing content.
 108 \item \emph{[Back-end]} Actually opening the files to decode / examine them.
 109 \end{itemize}
 110
 111 If we create the coalesced \texttt{Content} on building the pieces for
 112 the player, it will never appear in the user interface.  This means
 113 that it needs only the \emph{[back-end]} interfaces.
 114
 115 However, it seems silly to create a specialised different
 116 \texttt{FFmpegContent}-like type to express the tiny difference
 117 between single- and multi-file.
 118
 119 This suggests that the `shame' above is not a big deal.
 120
 121 \end{document}