Hello!

I've noticed that MP4Box is changing the values of my HDR10 mastering display characteristics (i.e. the SMTPTE ST.2086 metadata that x265 injects into the HEVC bitstream).

When I use mediainfo to inspect the original MP4 out of ffmpeg I see what I specified:
```
Mastering display color primaries        : BT.2020
MasteringDisplay_ColorPrimaries_Source   : Stream
Mastering display luminance              : min: 0.0050 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Source        : Stream
```

However, when I look at the remuxed MP4 that comes out of MP4Box now things are really weird:
```
Mastering display luminance              : min: 0.0768 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Source        : Container
MasteringDisplay_Luminance_Original      : min: 0.0050 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Original_Sour : Stream
Maximum Frame-Average Light Level        : 768 cd/m2
MaxFALL_Source                           : Container
```

Also, MP4Box seemingly made up a MaxFALL value as well!

Where did these values come from? I've used Vega stream analyzer and I see the SEI messages on the IDRs for both the content light level (0 for maxcll and maxfall) and mastering display (0.005 - 1000 nit BT. 2020 D65) signaled with no inconsistency. 

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Sample file:
https://www.mediafire.com/file/ncx3yd1qjb0ojnk/fake_hdr10.mp4/file

How to repro:

```
PS D:\TestClips\tears of steel> MP4Box -raw 1 fake_hdr10.mp4
Exporting HEVC Video - Size 1920x800

PS D:\TestClips\tears of steel> MP4Box -add fake_hdr10_track1.hvc:fps=24000/1001 remux_03.mp4
Track Importing HEVC - Width 1920 Height 800 FPS 24000/1001 SAR 1/1
HEVC Import results: 120 samples (253 NALUs) - Slices: 2 I 30 P 88 B - 6 SEI - 2 IDR - 0 CRA
HEVC Stream uses forward prediction - stream CTS offset: 3 frames
HEVC Max NALU size is 15170 - stream could be optimized by setting nal_length=2
0.500 secs Interleaving
```

I did notice that just remuxing directly instead of demuxing and then muxing that works around this for some reason. For example:
```
MP4Box -add fake_hdr10.mp4 new.mp4
```

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

MP4Box changing HDR10 SMPTE ST.2086 (mastering display characteristics) metadata?
This is a GitHub Issue
repo:gpac
owner:gpac
Title : MP4Box changing HDR10 SMPTE ST.2086 (mastering display characteristics) metadata?
Issue date:

--- start body ---
Hello!

I've noticed that MP4Box is changing the values of my HDR10 mastering display characteristics (i.e. the SMTPTE ST.2086 metadata that x265 injects into the HEVC bitstream).

When I use mediainfo to inspect the original MP4 out of ffmpeg I see what I specified:
```
Mastering display color primaries        : BT.2020
MasteringDisplay_ColorPrimaries_Source   : Stream
Mastering display luminance              : min: 0.0050 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Source        : Stream
```

However, when I look at the remuxed MP4 that comes out of MP4Box now things are really weird:
```
Mastering display luminance              : min: 0.0768 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Source        : Container
MasteringDisplay_Luminance_Original      : min: 0.0050 cd/m2, max: 1000 cd/m2
MasteringDisplay_Luminance_Original_Sour : Stream
Maximum Frame-Average Light Level        : 768 cd/m2
MaxFALL_Source                           : Container
```

Also, MP4Box seemingly made up a MaxFALL value as well!

Where did these values come from? I've used Vega stream analyzer and I see the SEI messages on the IDRs for both the content light level (0 for maxcll and maxfall) and mastering display (0.005 - 1000 nit BT. 2020 D65) signaled with no inconsistency. 

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Sample file:
https://www.mediafire.com/file/ncx3yd1qjb0ojnk/fake_hdr10.mp4/file

How to repro:

```
PS D:\TestClips\tears of steel> MP4Box -raw 1 fake_hdr10.mp4
Exporting HEVC Video - Size 1920x800

PS D:\TestClips\tears of steel> MP4Box -add fake_hdr10_track1.hvc:fps=24000/1001 remux_03.mp4
Track Importing HEVC - Width 1920 Height 800 FPS 24000/1001 SAR 1/1
HEVC Import results: 120 samples (253 NALUs) - Slices: 2 I 30 P 88 B - 6 SEI - 2 IDR - 0 CRA
HEVC Stream uses forward prediction - stream CTS offset: 3 frames
HEVC Max NALU size is 15170 - stream could be optimized by setting nal_length=2
0.500 secs Interleaving
```

I did notice that just remuxing directly instead of demuxing and then muxing that works around this for some reason. For example:
```
MP4Box -add fake_hdr10.mp4 new.mp4
```

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

--- end body ---
