Hello there, 

I encountered an issue while using the mp4dash tool. According to the **ISO/IEC 14496-12** standard, in section **8.8.10 Track Fragment Random Access Box**, it specifies that the maximum number to be represented in the 'time' and 'offset' fields when the version of the 'tfra' box is 0 should be a number represented by 32 bytes (2^32 -1).

The problem arises when adding encryption information to the other mp4 atoms in an input content where the version of the 'tfra' box is 0. If the offset of the output 'tfra' box becomes a number greater than 2^32, according to the standard, it should update the version of the 'tfra' box to version 1 in order to represent an integer up to 2^64.

The command: 
```bash
 mp4dash --mpd-name my_content.mpd --widevine-header provider:MyProvider#content_id:1 --encryption-key MY_HEX_KEY2 --playready-header=LA_URL:http://test.playready.microsoft.com/service/my_manager.asmx\
my_content_video_Avc_3500_1280x720.mp4\
my_content_video_Avc_1800_960x540.mp4\
my_content_video_Avc_800_640x360.mp4\ 
my_content_audio_aac_96_es.mp4\ 
my_content_audio_aac_96_eng.mp4\
-o /my_output_path/cipher/ --verbose --no-split
``` 

The issue occurs only in the highest layer (3.5mbps) mp4 file, whose original offset of the 'tfra' box is an integer value of 4292674329. When encryption information is added to the rest of the atoms, the value increases to 4301140778 (greater than 2^32), and thus, the number should not be encapsulated in a 'tfra' version 0. However, the software still does it, resulting in errors in some mp4 file reading and analysis programs. This could potentially cause playback issues in some media players.
mp4dash does not update version of 'tfra' atom when it should 
This is a GitHub Issue
repo:Bento4
owner:axiomatic-systems
Title : mp4dash does not update version of 'tfra' atom when it should 
Issue date:

--- start body ---
Hello there, 

I encountered an issue while using the mp4dash tool. According to the **ISO/IEC 14496-12** standard, in section **8.8.10 Track Fragment Random Access Box**, it specifies that the maximum number to be represented in the 'time' and 'offset' fields when the version of the 'tfra' box is 0 should be a number represented by 32 bytes (2^32 -1).

The problem arises when adding encryption information to the other mp4 atoms in an input content where the version of the 'tfra' box is 0. If the offset of the output 'tfra' box becomes a number greater than 2^32, according to the standard, it should update the version of the 'tfra' box to version 1 in order to represent an integer up to 2^64.

The command: 
```bash
 mp4dash --mpd-name my_content.mpd --widevine-header provider:MyProvider#content_id:1 --encryption-key MY_HEX_KEY2 --playready-header=LA_URL:http://test.playready.microsoft.com/service/my_manager.asmx\
my_content_video_Avc_3500_1280x720.mp4\
my_content_video_Avc_1800_960x540.mp4\
my_content_video_Avc_800_640x360.mp4\ 
my_content_audio_aac_96_es.mp4\ 
my_content_audio_aac_96_eng.mp4\
-o /my_output_path/cipher/ --verbose --no-split
``` 

The issue occurs only in the highest layer (3.5mbps) mp4 file, whose original offset of the 'tfra' box is an integer value of 4292674329. When encryption information is added to the rest of the atoms, the value increases to 4301140778 (greater than 2^32), and thus, the number should not be encapsulated in a 'tfra' version 0. However, the software still does it, resulting in errors in some mp4 file reading and analysis programs. This could potentially cause playback issues in some media players.
--- end body ---
