You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in the last call, in ISOBMFF, it is assumed that within a handler, decoders are interchangeable, i.e. they produce the same output. For example, for the handler vide, within a given implementation, it should not matter if the stream was encoded with avc1 or av01. After decoding, the results is the same: an uncompressed 2D image, corresponding to the general parameters given in the VisualSampleEntry class. Similarly, with soun, the output of any decoder is expected to be uncompressed audio, with the characteristics of the base AudioSampleEntry. In fact, theoretically, within a given track you could even mix different codecs (e.g. Opus and mp4a), even if in practice that is never used.
The benefit of using a new handler is that we wouldn't have to use an AudioSampleEntry and its fields which may not be appropriate.
The drawback is possibly that some implementations may be less robust to new handlers?
This is also related to #18. If multiple tracks are used, clearly each audio track would use soun and the metadata track (if it exists) would use meta.
E.g. there is a VideoAuxillaryTrack but no corresponding AudioAuxillaryTrack.
The text was updated successfully, but these errors were encountered: