The metadata in media on this bug results in bogus. It results in multiple samples having the same presentation timestamp. This causes the mp4 metadata parser to assign some samples the same start and end composition time (because if there are two samples at the same time, one must be displayed for 0 time). This results in 0 duration being calculated for some samples further down the pipeline (duration = end - start), which then causes issues in the Window's decoder if we pass those durations (it appears to try and infer a sane duration, but does not in this case). If we never pass durations to the Window's decoder (as in the fix above), it will also perfrom inference of durations, which appears to work for this file, but does not in the general case per bug 1576990. I will continue discussion in bug 1576990 -- there is hopefully a solution to this that providers broader support for different media.
Bug 1560440 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The metadata in media on this bug is bogus. It results in multiple samples having the same presentation timestamp. This causes the mp4 metadata parser to assign some samples the same start and end composition time (because if there are two samples at the same time, one must be displayed for 0 time). This results in 0 duration being calculated for some samples further down the pipeline (duration = end - start), which then causes issues in the Window's decoder if we pass those durations (it appears to try and infer a sane duration, but does not in this case). If we never pass durations to the Window's decoder (as in the fix above), it will also perfrom inference of durations, which appears to work for this file, but does not in the general case per bug 1576990. I will continue discussion in bug 1576990 -- there is hopefully a solution to this that providers broader support for different media.