ISO-BMFF allows for multiple audio (or video, depending on handler type) sample description entries in MOOV, with the (1-based) index of a default entry for a track also contained in the MOOV's TREX box for the track.

Currently, our parser only emits config-cb (triggering init segment + possible config change) at MOOV parsing. However, with ISO-BMFF's allowance for each MOOF's TRAF's TFHD to contain a different index than the default from the MOOV's TREX for the track, there technically could be multiple codec reconfiguration points for a track within the same set of media segments with no intervening MOOV.

This bug tracks enabling codec reconfigurations when non-default sample description indices are used in TFHD's. Further work may be required in MSE spec to ensure this doesn't break current boundaries/semantics of INIT vs MEDIA segment processing.

(I'll update the existing TODO in MP$StreamParser (https://cs.chromium.org/chromium/src/media/formats/mp4/mp4_stream_parser.cc?rcl=19bf43a04f98bbf169a9d025aa7b29dfcf15ec53&l=243) in an upcoming CL to reference this crbug.)

Note, in common usage, dash or MSE-targeted muxers generally don't switch codec configurations within a track within a media segment; hence this bug hasn't previously become a priority at all.
 

ISO-BMFF allows for multiple audio (or video, depending on handler type) sample description entries in MOOV, with the (1-based) index of a default entry for a track also contained in the MOOV's TREX box for the track.

Currently, our parser only emits config-cb (triggering init segment + possible config change) at MOOV parsing. However, with ISO-BMFF's allowance for each MOOF's TRAF's TFHD to contain a different index than the default from the MOOV's TREX for the track, there technically could be multiple codec reconfiguration points for a track within the same set of media segments with no intervening MOOV.

This bug tracks enabling codec reconfigurations when non-default sample description indices are used in TFHD's. Further work may be required in MSE spec to ensure this doesn't break current boundaries/semantics of INIT vs MEDIA segment processing.

(I'll update the existing TODO in MP4StreamParser (https://cs.chromium.org/chromium/src/media/formats/mp4/mp4_stream_parser.cc?rcl=19bf43a04f98bbf169a9d025aa7b29dfcf15ec53&l=243) in an upcoming CL to reference this crbug.)

Note, in common usage, dash or MSE-targeted muxers generally don't switch codec configurations within a track within a media segment; hence this bug hasn't previously become a priority at all.