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
|
% LICENSE: see LICENCE
\section{Data Features}
\subsection{Programme-Associated Data}
It is possible to encode Dynamic Label Segment and Slideshow using ODR-PadEnc,
and to inject the PAD data into the audio encoder.
ODR-AudioEnc and ODR-PadEnc need to be launched with the same PAD socket
identifier, and they will be able to communicate. The PAD length specifies the
amount of data that is taken away from audio and used for PAD. Valid values are
6, and the range 8 to 196. When not transmitting slides, small PAD lengths
are perfectly suitable. When using slides, it is better to use values around 30.
Higher lengths will of course accelerate the transmission of the slide at the
expense of reduced audio quality during the transmission time.
ODR-PadEnc will itself only take DLS and slides from files on the
system it runs on.
If your playout system is able to push updates using FTP, you will need to
configure and FTP server to present the right folder.
A more modern approach is offered by ODR-EncoderManager, which will not only
configure and run your encoders, but also present you an HTTP API to update DLS
and upload slides. More information is available in its README.
\subsection{FIG 1 Labels and FIG 2 Extended Labels}
The specification offers two ways to carry ensemble, service and component
labels: through FIG 1 and through FIG 2, specified in clauses 5.2.2.2 and 5.2.2.3
of ETSI EN 300 401~\cite{etsidab}.
Most receivers are only able to show FIG 1 Labels encoded in the Complete EBU
Latin character set (defined in ETSI TS 101 756 clause
5.2~\cite{etsidabtables}). Some are able to display Unicode FIG 1 Labels,
encoded either in UTF-8 or UCS-2, and, as of early 2019, receiver support for
FIG 2 Extended Labels is practically absent.
The main downside of carrying Unicode FIG 1 Labels is the length limitation: 16
bytes will only encode eight characters in alphabets that require two bytes per
character. FIG 2 supports up to 32 bytes labels to alleviate this.
The intention is that new ensembles in countries requiring labels in non-latin
alphabets transmit only FIG 2 Extended Labels, whereas currently operating
ensembles keep transmitting FIG 1 Labels. This entices receiver manufacturers to
support FIG 2 without impacting functionality of receivers currently in use.
Transmitting both FIG 1 and FIG 2 is discouraged by the specification.
The way FIG 2 is encoded has been redefined, which is why ODR-DabMux supports
two variants: FIG 2 with character flag being the old variant, and FIG 2 with
text control that will become the default variant.
\subsection{Announcements}
The ODR-DabMux multiplexer supports the insertion of FIG 0/18 and FIG 0/19 that
are used to define and trigger announcements according to ETSI TR 101 496-2
Clause 3.6.8~\cite{etsitr1014962}.
An example configuration is available in the ODR-DabMux repository, in
\texttt{doc/advanced.mux}.
The best known application for announcements is traffic information, but other
kinds of announcements can also be signalled. ODR-DabMux allows triggering the
announcements through the telnet and ZMQ remote control interfaces.
\subsection{Service Linking}
ODR-DabMux also supports the ability to inform receivers about other ways to
receive a given service, through the FIGs 0/6, 0/21 and 0/24. FIG 0/6
communicates the identifiers of services linked together, 0/21 informs the
receiver about other frequencies, and 0/24 includes information about other DAB
ensembles carrying the linked service.
Their interaction is outlined in ETSI TS 103 176~\cite{etsits103176}.
You will find an example configuration in the ODR-DabMux repository, in
\texttt{doc/servicelinking.mux}.
% vim: spl=en spell tw=80 et
|
