The mkv or Matroska format (https://en.wikipedia.org/wiki/Matroska) supports an unlimited number of tracks of a/v/s type streams. WebM, which is a subset of mkv, may also support this.
I haven’t yet found another format with this quality, but there could be one. Here are other things to consider in the video container choice: https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
I’m not sure if the python bindings support this, but ffmpeg does:
My hunch here is that for both the codec and BackingArray, this library can support fewer or more than 4 dimensions. It may complicate the ds.video API, however.
The implications of this excite me. For one, it means that we can store more kinds of scientific data, like bio, geo, or climate data is this souped up Zarr. Second, it proves the hunch that time is a preeminent dimension for data and compression, as much of the secrete sauce of video codecs has to do with encoding across time. So, maybe the constraint really is n > 2 dimensions.
The mkv or Matroska format (https://en.wikipedia.org/wiki/Matroska) supports an unlimited number of tracks of a/v/s type streams. WebM, which is a subset of mkv, may also support this.
I haven’t yet found another format with this quality, but there could be one. Here are other things to consider in the video container choice: https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
I’m not sure if the python bindings support this, but ffmpeg does:
My hunch here is that for both the codec and BackingArray, this library can support fewer or more than 4 dimensions. It may complicate the
ds.videoAPI, however.The implications of this excite me. For one, it means that we can store more kinds of scientific data, like bio, geo, or climate data is this souped up Zarr. Second, it proves the hunch that time is a preeminent dimension for data and compression, as much of the secrete sauce of video codecs has to do with encoding across time. So, maybe the constraint really is n > 2 dimensions.