gaspard7/wiki_gpac huggingface dataset:
Foreword

This feature is deprecated in MP4Box starting from GPAC 0.9.0. You can grab input streams using [gpac](gpac_general):
```
gpac -i udp://ip_adress:port -o dump.ts
```

```
gpac -i udp://ip_adress:port --ifce ip_address -o dump.ts
```


### Dump a broadcast TS in a file

MP4Box can manipulate MP4 files, but it has also capabilities regarding broadcast streams.

Command syntax:

```
MP4Box -grab-ts udp://ip_adress:port dump.ts
```

For example:

```
MP4Box -grab-ts udp://239.0.0.1:8000 dump.ts
```

### Dump from a specific network interface

MP4Box provides a '-ifce' option:

```
MP4Box -grab-ts udp://ip_adress:port -ifce ip_address dump.ts
```

Use 'ifconfig' (Unix) or 'ipconfig' (Windows) to retrieve your IP address on the interface of your choice. Example:

```
MP4Box -grab-ts udp://239.0.0.1:8000 -ifce 192.168.1.1 dump.ts
```

### Troubleshoot Windows: MP4Box (or any tool) cannot dump my multicast

1) Clicking the Start button and then click on Control Panel. In the search box, type firewall, and then click Windows Firewall.

2) On the left panel, click on "Allow a program or feature through the Windows Firewall".

3) Make sure all columns are checked for your MP4Box programs.
Multiplexing HEVC bitstreams into ISOBMF

All profiles should be supported, interlace is not supported yet. The support is based on the study text of HEVC file format.


### HEVC Import


```
MP4Box -add file.hvc -new file.mp4
```

Adds file.hvc (Annex B format) to the given file.

The default import format uses `hvc1` storage.

```
MP4Box -add file.bin:FMT=HEVC -new file.mp4
```

`FMT` is used to indicate the format is HEVC, and can be omitted if the file extension is `hvc`, `hevc` or `265`

```
MP4Box -add file.hvc:fps=50 -new file.mp4
```

`FPS` is by default `25`, and should be specified most of the time as VUI timing is not yet parsed.


### HEVC File inspection

```
MP4Box -info file.mp4MP4Box -info ID file.mp4
```

Gives info on the file or on the track.


### HEVC Export

```
MP4Box –raw <trackId> file.mp4
```

Exports an HEVC file to annex B format.
MPEG-2 TS support

All MPEG-2 TS operations from GPAC (client and MP42TS) are supported on HEVC. MP42TS can be used to generate TS files usable for DASH or for injection in modulation chains; it can also be used to send the TS over an UDP or RTP stream in unicast or multicast mode:

```
./mp42ts -prog=hevc.mp4 -dst-file=test.ts
```
Content Generation

If you generate your content with an third-party application such as ```ffmpeg```, make sure all your video qualities use closed GOP and have the same positions for their IDR frames.
When using GPAC, this is usually ensure by using the `fintra` option.

GPAC can be used to generate both static and live DASH/HLS content. For live cases, GPAC can expose the created files:

- directly through disk
- through its own HTTP server
- by pushing them to a remote HTTP server

We recommend reading the [HTTP server](httpout) filter help, and looking at the [DASH](LL-DASH) and [HLS](LL-HLS) low latency HowTos.
Content Playback

GPAC comes with a various set of adaptation algorithms:

- BBA0, BOLA, basic throughput (called `conventional` in the literature)
- Custom throughput-based (`gbuf`) and buffer-based (`grate`) algorithms

The algorithm can be replaced by your own algo in [JS](/jsdash) or [Python](python#custom-gpac-callbacks).
 
[Low-Latency DASH](LL-DASH) streaming is supported, and [HLS](LL-HLS) is supported starting from GPAC 2.0. 

As usual in GPAC, accessing a DASH/HLS session is not reserved for playback, it can be used to feed a media pipeline for other tasks such as transcoding, encryption, recording, etc... See [this howto](HAS-advanced) for more information.
Tile-based adaptation using independent video encoded in H264

In this demo, a 4K tears of steel is split in 9 tiles, each of them encoded in various bitrates and resolutions. The resulting composition of tiles is played in GPAC with frame-level accuracy to rebuild the complete video. Of course, all of this is 100% DASH compliant and produced with MP4Box. MP4Box has the ability to add any MPD descriptor at period, adaptation set or representation level. For SRD, we use adaptation set descriptors as specified in MPEG DASH; for example:

`MP4Box -dash 1000 [other dash params]  source.mp4:desc_as=<SupplementalProperty schemeIdUri=\"urn:mpeg:dash:srd:2014\" value=\"0,0,1,1,1,2,2\"/>`

indicates that `source.mp4` is placed at X=0, Y=1 with width 1 and height 1 on a tiling grid of size 2x2. This information needs to be manually specified at command line for independent videos, but  is automatically inserted if the source file contains an HEVC tile track (see second demo).

The full content of the demo can be [browsed here](http://download.tsi.telecom-paristech.fr/gpac/SRD/tears_of_steal/), and you can have fun with the [HD version](http://download.tsi.telecom-paristech.fr/gpac/SRD/tears_of_steal/tos_srd_hd.mpd) or the [4K version](http://download.tsi.telecom-paristech.fr/gpac/SRD/tears_of_steal/tos_srd_all.mpd) of the DASH session.

You can use GPAC player with gui to watch the different tiles quality and stats:

[![ToS_Tile_Screenshot](https://gpac.io/files/2016/05/ToS_Tile_Screenshot-300x180.png)](https://gpac.io/files/2016/05/ToS_Tile_Screenshot.png)
HEVC Motion-constrained Tile-based adaptation

In this demo, we use HEVC tiling tools with constrained motion to allow replacing a tile of an HEVC bitstream with a tile from another HEVC bitstream with same configuration but different quality. In this use case the different HEVC bitstream represent the same content in order to perform bitrate adaptation at the tile level. The nice thing about this is that the reconstructed bitstream is HEVC compliant and requires only a single decoder for the playback!

The full content of the demo can be [browsed here](http://download.tsi.telecom-paristech.fr/gpac/SRD/srd_hevc/multi_rate_p60/), and you can have fun with the [HD version](http://download.tsi.telecom-paristech.fr/gpac/SRD/srd_hevc/multi_rate_p60/hevc_srd.mpd) of the DASH session.

You can use GPAC player with gui to watch the different tiles quality and stats:

[![gpac_dash_hevc_tile](https://gpac.io/files/2016/05/gpac_dash_hevc_tile-300x188.png)](https://gpac.io/files/2016/05/gpac_dash_hevc_tile.png)

A complete tutorial for HEVC and tiling is available [[here|HEVC Tile-based adaptation guide]].
HLS Low Latency setup

The same setup for configuring segments and CMAF chunks is used as the [DASH low latency](LL-DASH#dash-low-latency-setup) setup.

When you have low-latency producing of your HLS media segments, you need to indicate to the client how to access LL-HLS `parts` (CMAF chunks) while they are produced. LL-HLS offers two possibilities to describe these parts in the manifest:

- file mode: advertise the chunks as dedicated files, i.e. each chunk will create its own file. This requires double storage for segments close to the live edge, increases disk IOs and might not be very practical if you setup a PUSH origin (twice the bandwidth is required)
- byte range mode: advertise the chunks as byte range of a media file. If that media file is the full segment being produced (usually the case), this does not induce bandwidth increase or extra disk IOs.
  
GPAC can work in both modes, and always use byte-range in the segment being produced for the second mode.
The mode is selected using the [llhls](dasher#llhls) option of the dasher.

In either mode, each variant playlist will be modified at each new LLHLS part ready.

In file mode, each part file is the full segment name appended with `.N`, with `N` the 1-based number of the part being generated, e.g. `file_1.mp4.1`,  `file_1.mp4.2`,  `file_1.mp4.3` ...  
  
```
MP4Box -frag-rt -dash-live 10000 -frag 1000 -profile live -out res/live.m3u8:llhls=br source1 source2
gpac -i source1 -i source2 reframer:rt=on -o res/live.m3u8:segdur=10:cdur=1:profile=live:dmode=dynamic:llhls=br
```

In the above example, we indicate the LLHLS parts are byte-ranges in the segment being produced. 

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

In the above example, we indicate the LLHLS parts are independent files.
LLHLS Origin Server setup

The same setup for configuring the server is used as the [DASH low latency](LL-DASH#dash-origin-server-setup) setup.

The server will need a local directory where files are stored.


```
MP4Box -frag-rt -dash-live 10000 -frag 1000 -profile live 
	-out http://localhost:8080/live.mpd:gpac:rdirs=outdir:llhls=br source1 source2


gpac -i source1 -i source2 reframer:rt=on
	-o http://localhost:8080/live.mpd:gpac:segdur=10:cdur=1:profile=live:dmode=dynamic:rdirs=outdir:llhls=br
```

Note that since this example only uses a single DASH session, all options specified for the dasher can be set globally:
```
MP4Box -frag-rt -dash-live 10000 -frag 1000 -profile live
	-out http://localhost:8080/live.mpd --rdirs=outdir --llhls=br source1 source2

gpac -i source1 -i source2 reframer:rt=on -o http://localhost:8080/live.mpd
	--segdur=10 --cdur=1 --profile=live --dmode=dynamic --rdirs=outdir --llhls=br
```
LLHLS Origin PUSH setup

You may want to use a regular HTTP server as your origin server, and have GPAC push segments to that server while they are being produced. Again, please read the documentation of the [HTTP Server](httpout).

In this case, the httpout filter does not work as a server but as an HTTP client issuing PUT or POST requests, and does not need any local directory.


```
MP4Box -frag-rt -dash-live 10000 -frag 1000 -profile live
	-out http://ORIG_SERVER_IP_PORT/live.mpd:gpac:hmode=push:llhls=br source1 source2

gpac -i source1 -i source2 reframer:rt=on
	-o http://ORIG_SERVER_IP_PORT/live.mpd:gpac:segdur=10:cdur=1:profile=live:dmode=dynamic:hmode=push:llhls=br
```
Dual DASH and HLS Low Latency

You can generate at the same time DASH-LL and LL-HLS, by simply setting up both `availabilityStartOffset` and LL-HLS modes. 

It is recommended to only use byte-range mode for LL-HLS in that case for bandwidth efficiency reasons, but file mode is also working.


```
MP4Box -ast-offset 9000 -frag-rt -dash-live 10000 -frag 1000 -profile live
	-out http://ORIG_SERVER_IP_PORT/live.mpd:gpac:dual:llhls=br:rdirs=outdir source1 source2

gpac -i source1 -i source2 reframer:rt=on
	-o http://ORIG_SERVER_IP_PORT/live.mpd:gpac:dual:segdur=10:cdur=1:profile=live:dmode=dynamic:hmode=push:llhls=br:asto=9:rdirs=outdir
```
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](gpac_general), for which the session can be interrupted and flushed using `ctrl+c`.
Quick record examples

Record the session in fragmented MP4
```
gpac -i $HAS_URL -o grab/record.mp4:frag
```
Note that we specify [frag](mp4mx#store) 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
```
gpac -i $HAS_URL --algo=none --start_with=max_q -o grab/record.mp4:frag -o record.ts
```

HAS to Multicast TS
```
gpac -i $HAS_URL --algo=none --start_with=max_q -o udp://224.0.0.1:1234/:ext=ts
```
Quality splitting

The [DASH reader](dashin) can be configured through [-split_as](dashin#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:
```
gpac -i $HAS_URL:split_as -o grab/record.mp4:frag
```

For one file per source media recording of all qualities, using [filter chain templating](filters_general#templating-filter-chains):
```
gpac -i $HAS_URL:split_as -o grab/record_$PID$.mp4:frag:SID=#PID=
```
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):
```
gpac -i $HAS_URL:split_as -o grab/record_$PID$.mp4:SID=#Representation=
```
File forward mode

The [DASH reader](dashin) can be configured through [-forward=file](dashin#forward)  to deliver multiplexed files instead of demultiplexed media frames into the pipeline - see [here](dashin#file-mode) 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:
```
gpac -i $HAS_URL dashin:forward=file -o grab/record_$File$:dynext
```

Acting as an HTTP proxy:
```
gpac -i $HAS_URL dashin:forward=file -o http://localhost:8080/:gpac:rdirs=output_dir
```

In this mode, files grabbed are deleted according to the [-max_cache_segs](httpout#max_cache_segs) option.


[ROUTE](route) forwarding:
```
gpac -i $HAS_URL dashin:forward=file -o route://225.1.1.0:6000
```
Segment forward mode

The [DASH reader](dashin) can be configured through [-forward](dashin#forward)  to insert segment boundaries in the media pipeline - see [here](dashin#segment-bound-modes) for more details.
 Two variants of this mode exist:

- `segb`: this enables `split_as`, DASH cue insertion (segment start signal) and fragment bounds signalling
- `mani`: same as `segb` 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:

```
gpac -i $HAS_URL reframer -o re_has.mpd
```
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:
```
gpac -i $HAS_URL --forward:segb reframer -o re_has.mpd
```

then the dasher will operate in [cue-driven mode](dasher#cue-driven-segmentation) 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:

```
gpac -i $HAS_URL --forward:segb cecrypt:cfile=DRM.xml -o encrypted_has.mpd
```

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.
 
```
gpac -i $DASH_URL --forward:mani cecrypt:cfile=DRM.xml -o encrypted_dash.mpd
```
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](dasher#cue-driven-segmentation).

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](dasher#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 !

 
```
#first segment, not fragmented
intro.mp4
#second segment, not fragmented
chap1.mp4
#and so on
```

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):
```
gpac --sigcues -i pl_low.txt -i pl_mid.txt -i pl_high.txt -o dash.mpd:profile=ondemand
```
Foreword

In this howto, we will study various setups for DASH transcoding. 

Please make sure you are familiar with [DASH terminology](DASH-basics) before reading. 

It is likely that your source media is not properly encoded for DASH or HLS delivery, most likely because:

- openGOPs are used 
- key-frame position do not match between your different qualities
- key-frame intervals are not constant

__Note__
Non-constant key frame interval is not problematic for on demand use cases, as most profiles can deal with it. 

You can use GPAC to transcode your content, and inject the result in a GPAC filter session. 

We assume GPAC 2.0 or above for command line syntax.

As usual in GPAC, the concepts presented here can be reused with different filter chains, for example input being a live source or output being a non-dash file.
Single Quality Transcoding

To transcode a source to DASH using 2s segments to AVC|H264 single quality 1 Mbps and not modifying the audio:

```
gpac -i source_av.mp4 c=avc:b=1m -o dash/live.mpd:segdur=2
```

The segment duration will be passed to the encoder to force key frame insertion. If gpac still complains about open-gop present at segment boundaries, force encoder reset:

```
gpac -i source_av.mp4 c=avc:b=1m:rc -o dash/live.mpd:segdur=2
```

You can force an intra refresh frequency lower than the segment duration, for example 2s I-frames for 4s segments:

```
gpac -i source_av.mp4 c=avc:b=1m:fintra=2 -o dash/live.mpd:segdur=4
```
 

You can also transcode to HLS:

```
gpac -i source_av.mp4 c=avc:b=1m -o dash/live.m3u8:segdur=2
```

or to both HLS and DASH:

```
gpac -i source_av.mp4 c=avc:b=1m -o dash/live.m3u8:dual:segdur=2
```


You may also transcode the audio:

```
gpac -i source_av.mp4 c=avc:b=1m c=aac:b=64k -o dash/live.mpd:segdur=2
```

To transcode only non-aac tracks, you must use explicit PID linking (you may need to single-quot the link string to escape '!'):

```
gpac -i source_av.mp4 c=avc:b=1m @1#CodecID=!aac c=aac:b=64k -o dash/live.mpd:segdur=2
```

If no non-AAC audio tracks are present, you will get a warning indicating the AAC encoder was not used:
```
Filters not connected:
ffenc (c=aac:b=64k)
```
Same resolution

To transcode in two bitrates your video, you must add explicit links between your encoders and the source (or desired filter in the source chain).

For example, to transcode video source to 1 mbps and 200 kbps streams:

```
gpac -i source_av.mp4 @ c=avc:b=1m @@ c=avc:b=200k @ @1 -o dash/live.mpd:segdur=2
```

We use here the `@@` link shortcut to get the first filter declared. This is equivalent to:

```
gpac -i source_av.mp4 @ c=avc:b=1m @1 c=avc:b=200k @ @1 -o dash/live.mpd:segdur=2
gpac -i source_av.mp4:FID=S c=avc:b=1m:SID=S:FID=V1 c=avc:b=200k:SID=S:FID=V2 -o dash/live.mpd:segdur=2:SID=V1,V2
```


If you need audio passthrough:
```
gpac -i source_av.mp4 @ c=avc:b=1m @@ c=avc:b=200k @ @1 @@#audio -o dash/live.mpd:segdur=2
```

The same command using explicit filter IDs:
```
gpac -i source_av.mp4:FID=S c=avc:b=1m:SID=S:FID=V1 c=avc:b=200k:SID=S:FID=V2 -o dash/live.mpd:segdur=2:SID=V1,V2,S#audio
```


If you need audio encoding:
```
gpac -i source_av.mp4 @ c=avc:b=1m @@ c=avc:b=200k @@ c=aac:b=64k @ @1 @2 -o dash/live.mpd:segdur=2
```

The same command using explicit filter IDs:
```
gpac -i source_av.mp4:FID=S c=avc:b=1m:SID=S:FID=V1 c=avc:b=200k:SID=S:FID=V2 c=aac:b=64k:SID=S:FID=A1 -o dash/live.mpd:segdur=2:SID=V1,V2,A1
```
Multiple resolutions

To transcode in multiple resolutions your video, we will need the [rescaler](ffsws) filter.


```
gpac -i source_1080p.mp4 ffsws:osize=1280x720 @ c=avc:b=1m @@ c=avc:b=2m @ @1 -o dash/live.mpd:segdur=2
```

Obviously you can combine with the above approach to provide multiple bitrates for each resolution:

```
gpac -i source_1080p.mp4 @ ffsws:osize=1280x720 @ c=avc:b=1m @1 c=avc:b=500k @@ c=avc:b=4m @@ c=avc:b=2m @ @1 @2 @3 -o dash/live.mpd:segdur=2
```

If you specify the rescaler after the HD encoders:
```
gpac -i source_1080p.mp4 @ c=avc:b=4m @@ c=avc:b=2m @@ ffsws:osize=1280x720 @ c=avc:b=1m @1 c=avc:b=500k @ @1 @3 @4 -o dash/live.mpd:segdur=2
```

If you add more encoders, it may be simpler to understand the command line using explicit IDs:
```
gpac -i source_1080p.mp4:FID=S c=avc:b=4m:SID=S:FID=V1 c=avc:b=2m:SID=S:FID=V2 ffsws:osize=1280x720:SID=RZ c=avc:b=1m:SID=RZ:FID=V3 c=avc:b=500k:SID=RZ:FID=V4 -o dash/live.mpd:segdur=2:SID=V1,V2,V3,V4
```
Live Transcoding

The concepts are the same, except that you may need to add a real-time reframer after your input if it is not realtime


```
gpac -i source_1080p.mp4 reframer:rt=on ffsws:osize=1280x720 @ c=avc:b=1m @2 c=avc:b=2m @ @1 -o dash/live.mpd:segdur=2:dmode=dynamic
```

Using explicit IDs

```
gpac -i source_1080p.mp4:FID=S reframer:rt=on:SID=S:FID=RT ffsws:osize=1280x720:SID=RT:FID=RZ c=avc:b=1m:SID=RZ:FID=V1 c=avc:b=2m:SID=RT:FID=V2 -o dash/live.mpd:segdur=2:SID=V1,V2:dmode=dynamic
```
How to generate tiled streamable video content

The open-source "Kvazaar encoder":https://github.com/ultravideo/kvazaar allows encoding HEVC with motion constrained tiling. To instruct the encoder to encapsulate each tile in a separate slice, the `--slices` option is used with the value `tiles`. Motion vectors are then constrained within in each tile using `--mv-constraint`.

```bash
kvazaar -i input.yuv --input-res 3840x2160 -o output.hvc --tiles 3x3 --slices tiles --mv-constraint frametilemargin --bitrate 128000 --period 30 --input-fps 30
```

We can also set the target bitrate by `--bitrate` in bps instead of setting QP. It will turn the rate controller on. If you plan on merging tiles with different quality, keep the same QP settings and adjust the bitrate (changing QP would generate incompatible bitstreams). The output of the encoder is a raw bitstream and should be packaged within a container. To do so, MP4Box from GPAC can be used as follows, where the set value for `-fps` should match that of the encoded video.

```bash
MP4Box -add video_tiled.hvc:split_tiles -fps 30 -new video_tiled.mp4
```

The generated MP4 file includes one base track containing parameter sets and/or SEI messages plus one track for each tile. Now you can generate DASH segments and descriptor for the packaged video as follows.

```bash
MP4Box -dash 1000 -rap -frag-rap -profile live -out dash_tiled.mpd video_tiled.mp4
```

MP4Box can also generate an MPD with multiple representations by adding more input files.

```bash
MP4Box -dash 1000 -rap -frag-rap -profile live -out dash_tiled.mpd video_tiled_rep1.mp4 video_tiled_rep2.mp4
```

For more information, please refer [this article](https://gpac.io/2017/02/01/hevc-tile-based-adaptation-guide/).