Some WebM files don't provide sample durations, so we need to provide a safe default in order for them to be playable.
Created attachment 350203 [details] Patch
This is necessary to pass MSE YouTube tests 21. StartPlayWithoutData, 22. EventTimestamp... and any testcase that uses WebM files without frame durations.
Comment on attachment 350203 [details] Patch Clearing flags on attachment: 350203 Committed r236264: <https://trac.webkit.org/changeset/236264>
All reviewed patches have been landed. Closing bug.
Comment on attachment 350203 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=350203&action=review > Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:59 > + m_duration = createMediaTime(16666667); // 1/60 seconds You should be used MediaTime(1, 60) then.
Comment on attachment 350203 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=350203&action=review >> Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:59 >> + m_duration = createMediaTime(16666667); // 1/60 seconds > > You should be used MediaTime(1, 60) then. I thought about that, but decided purposely not to. Using a different timescale here would require the timescales would have to be recomputed as soon as an addition is made (and additions will be made plenty with this). Furthermore, the least common multiple of 1e9 and 60 is 3e9, which is greater than MediaTime::MaximumTimeScale (~2.147e9). In consequence, MaximumTimeScale would lossly be chosen instead, which is not a power of ten, but 0x7fffffff. This is a lot of complexity, wasted computation and more worringly, risk: because 1e9 and MaximumTimeScale don't play nicely, `pts + dur - dur` would not be equal to `pts`, and converting them to GStreamer time would return different values. In this case I'm just choosing an arbitrary duration (16000000 ns, or 16031415 ns would have worked as well), so I don't mind if 1/60 is not represented exactly.