No control over moof size while segmenting

[collin]

Currently, when segmenting a file, a large number of moof boxes are created.

For the files I've been looking at, this results in ~1MB overhead per track per minute (more or less depending on frame/samplerate).

That's probably not much of an issue when doing on-the-fly segmentation for playback, but isn't ideal when remuxing files for long term storage.

For the cases I'm thinking of there's a big advantage in being able to fragment/separate tracks on clients before uploading to servers. In particular, it would be useful to create moofs that contain an entire group of pictures.

If I were to create a patch that either:

• allows for controlling this in the current segmentation code path
• adds a new segmentation code path that creates larger moofs

Would that be likely to be accepted as a merge?

[DenizUgur]

Without seeing the actual implementation, it's hard to say if it can be merged or not. PRs are always welcome.

[collin]

I'm not quite sure I understand that.

Is it unclear what the feature would be? What kind of implementation issues are you anticipating?

[DenizUgur]

It's more or less clear, I was just saying that I can't say anything for sure if it can be merged or not.

If it's a good contribution and works well without breaking existing functionality then we can merge it.

[github-actions[bot]]

:tada: This issue has been resolved in version 1.3.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: