oruebel
commented
1 year ago (which as I understand is more legal than technical)?
I think a lot comes down to tooling and (re)suablility of the data. You could write the video in compressed form as a binary blob to HDF5, but then it is up to the user to know how to decompress and read that data and existing video-players and tools won't know how to access the data from within an HDF5 file. I.e., I think putting compressed video inside an HDF5 file would limit the reuse of that data because many of the tools that exist around compressed video data won't work out of the box if the data is in HDF5.
I'm not sure about the legal aspects, but the effectiveness of these algorithms if integrated with HDF5 would heavily depend on how the data is chunked, since HDF5 does compression on a per-chunk basis, whereas video compressors usually rely on a temporal look-ahead and use of diffs.
In the same vein as PyNWB #1647, this question has occurred before (mostly within the team or with other dev teams such as SLEAP/DANDI) but always given as a verbal response.
Would it be possible to have a concise & precise FAQ description of why it is discouraged for users to write videos of natural behavior from lossy formats (mpg, mp4) to internal NWB Datasets?
And why we 'cannot simple integrate' the codecs directly into NWB (which as I understand is more legal than technical)?
@oruebel @bendichter
Came up in meeting with @rly today