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
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:
Would that be likely to be accepted as a merge?