1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
\documentclass{article}
\title{VOBs}
\author{}
\date{}
\begin{document}
\maketitle
VOB files are tricky. They appear to be components of a complete
media file which have been chopped up with no regard for packets.
Therefore they must be interpreted as if they had been joined together
with \texttt{cat}.
This is true, at least, with one test (``The Blues Brothers'' DVD)
which has its first VOB-to-VOB transition when Elwood looks at the
`Murph and the Magictones' business card.
Solutions:
\begin{enumerate}
\item Fiddle the decoders so that they pass on bits of packets
to the next decoder in line; this appears to be difficult.
\item Coalesce VOB files into one big `file' (or virtual file)
for feeding to FFmpeg.
\end{enumerate}
The second solution is easy enough to do, but the UI is tricky. As
far as I can see the user has explicitly to request this behaviour, as
coalescing two normal video files will cause problems. If they do
request it, how should it be represented?
\begin{enumerate}
\item In the UI?
\begin{enumerate}
\item Select VOBs and coalesce or
\item Coalese all files by some switch?
\end{enumerate}
\item In the back-end?
\begin{enumerate}
\item A single \texttt{Content} has multiple files or
\item A single \texttt{Decoder} has multiple \texttt{Content}s.
\end{enumerate}
\end{enumerate}
UI-wise, there will have to be some heuristic or nudging to get the
user to do the right thing. It probably does not matter.
The back-end is trickier. There is currently a 1:1 map of back-end
content to UI content. To preserve that, we would have to:
\begin{enumerate}
\item Have some hierarchy to enable grouped content (so that 1:1
decoder--content is preserved). This removes the 1:1 between
content and file, which is nice for everything except this
special (nasty) VOB case.
\item Allow a single decoder to manage multiple pieces of content.
The problem with this is that the \texttt{Player} has
\texttt{Piece}s, which are 1:1 decoder--content maps. 1--many for
decoder--content screws anything done with \texttt{Piece}s --- seek
(at least).
\end{enumerate}
Probably have to think about this from the UI point of view; first,
the user adds 4 VOB files (1 by 1) which should eventually be
coalesced. Either:
\begin{enumerate}
\item They are coalesced magically with a switch, or
\item The user must specifically coalesce them, and then the result
must be reflected in the UI.
\end{enumerate}
The first option could be done in the \texttt{Player} if it created
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}
|
