Foreword¶
In this howto, we will study complex use cases for DASH and HLS (and sometimes SmoothStreaming) powered by GPAC.
Please make sure you have read most if not all of the server-side and client-side DASH documentation of GPAC before going on.
Some of these examples may work with MP4Box, however MP4Box does not support session interruption which can be quite useful for these examples.
We therefore illustrate these with gpac, for which the session can be interrupted and flushed using ctrl+c
.
HAS reading¶
Quick record examples¶
Record the session in fragmented MP4
Note that we specify frag option for the generated MP4 so that:
- we don't have a long multiplexing process at the end
- if anything goes wrong (crash / battery dead / ...), we still have a file containing all media until the last written fragment.
Record the session, max quality with no adaptation in fragmented MP4 and TS
HAS to Multicast TS
Quality splitting¶
The DASH reader can be configured through -split_as to consider each quality in a HAS manifest to be an independent media rather than part of an adaptation bundle.
This can be used for example to grab all qualities of a HAS session. For live cases, you will need to have enough bandwidth or a quite large server timeshift buffer !
For single file recording of all qualities:
For one file per source media recording of all qualities, using filter chain templating:
We must use chain templating here since the MP4 multiplexer would accept any number of input PIDs.
If your sources were multiplexed AV and you want to store a multiplex, simply use the Representation
property instead of the PID
property, since AV streams were part of the same representation (mux):
File forward mode¶
The DASH reader can be configured through -forward=file to deliver multiplexed files instead of demultiplexed media frames into the pipeline - see here for more details.
This can be combined with the split_as
option to forward all files from the source.
The important thing to remember about this mode is that it changes the link capabilities of the dashin
filter and consequently the filter must be explicitly created.
Recording on disk:
Acting as an HTTP proxy:
In this mode, files grabbed are deleted according to the -max_cache_segs option.
ROUTE forwarding:
Segment forward mode¶
The DASH reader can be configured through -forward to insert segment boundaries in the media pipeline - see here for more details.
Two variants of this mode exist:
segb
: this enablessplit_as
, DASH cue insertion (segment start signal) and fragment bounds signallingmani
: same assegb
and also forward manifests (MPD, M3U8) as packet properties.
This mode is quite useful to do some media processing on a DASH session and output the same segment names/duration and fragment structure. Processing could mean transcoding, encrypting/decrypting and so on.
Take for example:
This will read the HAS session and invoke a dash segmenter which will operate with the default settings, i.e. 1s dash duration, ignoring completely the segmentation properties of the source.
When forcing segment boundaries signalling:
then the dasher will operate in cue-driven mode and will reproduce the same boundaries as the input, using the input default segment duration. It will also use the same file name for segments as the source ones.
By replacing the reframer with a media processor, for example an encrypter:
this creates a DASH/HLS encryption gateway. And, as usual, the output can be a ROUTE session, an HTTP server or an HTTP push sink.
In this mode, the dasher will however recreate its own manifest. If the source manifest had extensions or features not handled by GPAC, they will get lost in the process.
To avoid this, the mani
mode can then be used to tell the dasher to use the source manifest, patch it and republish it.
HAS writing¶
Explicit cue-driven segmentation¶
If you have already encoded your media in an optimized way, you will likely have variable segment durations not compatible with regular dashing.
You may also have IDR in the middle of your segments, but still do not want the dasher to cut there (for example because these in-between IDRs are not there for all qualities).
You can instruct the dasher to follow a list of cues telling it when to start a new segment. The following shows a cue file listing the segment boundaries by sample (frame) number:
?xml version="1.0" encoding="UTF-8"?>
<DASHCues xmlns="urn:gpac:dash:schema:cues:2018">
<Stream id="1">
<Cue sample="101"/>
<Cue sample="201"/>
<Cue sample="301"/>
<Cue sample="351"/>
<Cue sample="476"/>
<Cue sample="601"/>
</Stream>
</DASHCues>
The XML syntax for cue files is detailed here.
This is then used as follows:
gpac -i source.mp4:#DCue=cues.xml -o dash.mpd:profile=ondemand
gpac -i source.mp4:#DCue=cues.xml -o dash.mpd:profile=live:stl
gpac -i source.mp4:#DCue=cues.xml -o hls.m3u8
If using DASH but not an on-demand profile, you will need to use segment timeline stl option, since the segment durations will likely vary a lot.
Implicit cue-driven segmentation¶
We have covered in the previous section usage of cues with the segment forward mode of the HAS reader.
The flist
filter also offers the same possibility, by inserting cues at each new file. You should however make sure your files have the same codecs !
You can now dash in the same way:
gpac -i playlist.txt:sigcues -o dash.mpd:profile=ondemand
gpac -i playlist.txt:sigcues -o dash.mpd:profile=live:stl
You can prepare one playlist per quality, and then dash everything (here using a global filter option rather than repeating it):
Manifest-only generation¶
The dasher can operate in manifest-only generation, read pre-fragmented input files and output DASH or HLS manifest. Look here for more details about this mode.