DASH Low Latency setup

In DASH low latency, you must decide the duration of your segment (produced file) and the duration of your fragment or `CMAF chunk` (sub-part of the produced segment).
In GPAC, the dashing process only cares about segments and is unaware of the fragmentation of the segment, as this is a property of the underlying multiplexing format. For example, low latency DASH using MPEG-2 TS mux or raw elementary stream do not need to worry about fragment duration since packets of the mux are generated as soon as input packets are received.

For  ISOBMFF (fmp4), each segment can be divided in one or more fragments. This is described by the [cdur](mp4mx#cdur) option, which in case of DASH will be set by default to the segment duration (hence one fragment per DASH segment).

```
MP4Box -dash 10000 -frag 1000 -profile live -out DST_URL source1 ... source2
gpac -i source1 -i source2 -o DST_URL:segdur=10:cdur=1:profile=live
```

This will DASH your content trying to use 10s segments, each made of 10 fragments of 1s. 

__Note__   
_The fragments duration will vary depending on the duration of input frames, but in any case a new fragment will be created as soon as the current fragment duration is equal to or greater than the desired duration._


You can now do a live (dynamic) DASH session:

```
MP4Box -dash-live 10000 -subdur 10000 -frag 1000 -profile live -out DST_URL source1 ... source2
```

This will generate a live session, dashing 10s (`-subdur`) of content into 10s (`-dash-live`) segments, each containing 10 fragments of 1s (`-frag`). If your sources are live, you don't need to specify the `-subdur`option since real-time regulation of source is not needed. 

or

```
gpac -i source1 -i source2 -o DST_URL:segdur=10:cdur=1:profile=live:dmode=dynamic:sreg
```

This will generate a live session, dashing content into 10s (`segdur`) segments, each containing 10 fragments of 1s (`cdur`), performing real-time regulation after each segment generation (`sreg`). If your sources are live, you don't need to specify the `sreg`option since real-time regulation of source is not needed. 


The above commands do not perform fragment regulation, which means that the content of each segment will be written at once by the file multiplexer (if your sources are live, this will not be the case and you can skip this next step) :   

```
MP4Box -frag-rt -dash-live 10000 -frag 1000 -profile live -out res/live.mpd source1 source2
gpac -i source1 -i source2 reframer:rt=on -o res/live.mpd:segdur=10:cdur=1:profile=live:dmode=dynamic
```

The `-frag-rt` simply injects a [reframer](reframer) in the filter graph performing real-time regulation on media frames. This will ensure that both segments and fragments are written to disk in real-time.


If you dash a live TS source for example, the commands will be, without regulation:
```
MP4Box -dash-live 10000 -frag 1000 -profile live -out res/live.mpd udp://IP:PORT
gpac -i udp://IP:PORT -o res/live.mpd:segdur=10:cdur=1:profile=live:dmode=dynamic
```

You now have low-latency producing of your DASH session, however in terms of DASH you may want to indicate to the client that if it is low-latency enabled, it may fetch segments earlier than advertised in the manifest. This is indicated by the `availabilityStartOffset` attribute which gives the amount of seconds a request can be sent ahead of time:

```
MP4Box -ast-offset 9000 -dash-live 10000 -frag 1000 -profile live -out res/live.mpd udp://IP:PORT
gpac -i udp://IP:PORT -o res/live.mpd:segdur=10:cdur=1:profile=live:dmode=dynamic:asto=9
```

In the above example, we indicate the requests can be issued 9s (`asto` or `-ast-offset`) before the segment is fully produced. Your typical setup should have `cdur + asto = segdur`. 
If `asto` is greater than `segdur + cdur`, this will results in 404; if is is less, this will increase the client delay to the live edge.