MP4 Progressive Download - Microsoft solution varies from specification
magaylor opened this issue · comments
The spec currently states in section 12.3.2.3:
Avoiding such a large C2PA Manifest Store for a large asset is achieved by using one or more Merkle trees.
• For a large non-fragmented asset that contains one or more 'mdat' boxes in a single large file, one Merkle tree is
used for each 'mdat' box.
• For a large fragmented asset that contains a set of 'mdat' boxes for a single track which may be spread across
multiple files, one Merkle tree is used for each track.
The Microsoft solution breaks the Merkle trees up by track_ids. The reason we do this is because we define fragments based off the samples attribute in the 'trun' box. Additionally, each track is required to have a unique track_id and at least one 'trun' box. @samuelwenker and I chose to go with this because we thought this was the best solution for consistency and ease of processing. I was unaware that it was uncompliant until @mauricefisher64 pointed it out. He liked our solution though so we thought we would create an issue to see what the TWG thought. I fear that we will run into compatibility issues with other implementations if there is a file with more than one 'mdat' files.
I have never seen a file like this before so I can't guarantee what our solution would do. I presume that it would be agnostic to the number of 'mdat' boxes. When it produces the fragment hashes, it just reads 'sample_size' bytes from 'sample offset' in the file (which points into an 'mdat') foreach sample in the 'trun' box.
Closing in favor of internal version