The playlist segment lengths were **6s** in playlists I generated in `1.6.0-638` after using the following 2 commands to fragment an mp4 and create the playlist

```
mp4fragment --fragment-duration 6000 input_file intermediate_file
mp4dash --hls --no-split --profile=on-demand -o output_folder -f intermediate_file
```

After running the same commands with the same `input_file` with `1.6.0-639` and `1.6.0-640` the fragment files themselves have been larger than in `1.6.0-638` and the playlists generated have **1s** segment lengths.


| file size | version |
| --- | --- |
| 33504396 | 638 |
| 33508684 | 639 |
| 33508684 | 640 |

I also tried mixing the output from `mp4fragment` to the opposite `mp4dash` command (ex 638 mp4fragment output to 640 mp4dash and vice-versa) and the result was that the fragmented file seems to determine if 1s or 6s playlist segments are generated. So it seems like something changed in the 639/640 version of `mp4fragment` that is causing the playlist segment generation to go from 6s to 1s.

For completeness, here is the source file I was using, and the ffmpeg command I'm using to generate the `input_file` used in the commands above:

Source video: [fire_45s.mp4](https://jgcvideo2020.files.wordpress.com/2023/07/fire_45s.mp4)

Command to generate `input_file`
`ffmpeg -i fire_45s.mp4 -y -timelimit 28800 -xerror -threads 2 -f mp4 -s 2048x1080 -acodec aac -ar 48000 -async 1 -ab 160000 -vcodec libx264 -preset slow -profile:v high -movflags faststart -protocol_whitelist file,-ALL -crf 21 -pix_fmt yuv420p -max_muxing_queue_size 1024 -r 24 -g 24 -sc_threshold 0 -force_key_frames 'expr:gte(t,n_forced*6)' -metadata:s:a:0 language=und -ac 2 -maxrate 8M -bufsize 16M fire_1080_pre_frag
`
mp4fragment + mp4dash creating incorrect segment lengths after upgrade to `-639` and `-640`
This is a GitHub Issue
repo:Bento4
owner:axiomatic-systems
Title : mp4fragment + mp4dash creating incorrect segment lengths after upgrade to `-639` and `-640`
Issue date:

--- start body ---
The playlist segment lengths were **6s** in playlists I generated in `1.6.0-638` after using the following 2 commands to fragment an mp4 and create the playlist

```
mp4fragment --fragment-duration 6000 input_file intermediate_file
mp4dash --hls --no-split --profile=on-demand -o output_folder -f intermediate_file
```

After running the same commands with the same `input_file` with `1.6.0-639` and `1.6.0-640` the fragment files themselves have been larger than in `1.6.0-638` and the playlists generated have **1s** segment lengths.


| file size | version |
| --- | --- |
| 33504396 | 638 |
| 33508684 | 639 |
| 33508684 | 640 |

I also tried mixing the output from `mp4fragment` to the opposite `mp4dash` command (ex 638 mp4fragment output to 640 mp4dash and vice-versa) and the result was that the fragmented file seems to determine if 1s or 6s playlist segments are generated. So it seems like something changed in the 639/640 version of `mp4fragment` that is causing the playlist segment generation to go from 6s to 1s.

For completeness, here is the source file I was using, and the ffmpeg command I'm using to generate the `input_file` used in the commands above:

Source video: [fire_45s.mp4](https://jgcvideo2020.files.wordpress.com/2023/07/fire_45s.mp4)

Command to generate `input_file`
`ffmpeg -i fire_45s.mp4 -y -timelimit 28800 -xerror -threads 2 -f mp4 -s 2048x1080 -acodec aac -ar 48000 -async 1 -ab 160000 -vcodec libx264 -preset slow -profile:v high -movflags faststart -protocol_whitelist file,-ALL -crf 21 -pix_fmt yuv420p -max_muxing_queue_size 1024 -r 24 -g 24 -sc_threshold 0 -force_key_frames 'expr:gte(t,n_forced*6)' -metadata:s:a:0 language=und -ac 2 -maxrate 8M -bufsize 16M fire_1080_pre_frag
`
--- end body ---
