Media Source Extension incorrectly reports Infintite duration for ISOBMFF duration=0, and after endOfStream() with nothing buffered and ISOBMFF duration=(all 1's) unknown
Reported by
cool...@gmail.com,
Apr 18 2016
|
||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Example URL: Steps to reproduce the problem: 1. Call MSE.appendBuffer(InitializationSegment). Initialization segment have MovieHeaderBox::duration == 0xFFFFFFFF because this is live stream. Quotation from 14496-12:2012: "If the duration cannot be determined then duration is set to all 1s." 2. After appendBuffer(), videoTag.seeking == 0-47721.858833. Note: 0xFFFFFFFF / 90000 (timescale) = 47721.858833 3. Call MSE.endOfStream(). 4. After MSE.endOfStream(), videoTag.duration == 47721.858833. If, in step 1, MovieHeaderBox::duration == 0 then videoTag.duration == Infinity. Wrong too. What is the expected behavior? 2. After appendBuffer(), videoTag.seeking == empty. 4. After MSE.endOfStream(), videoTag.duration == 0. Firefox 45 do it right. What went wrong? videoTag.seeking and videoTag.duration values. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 49.0.2623.110 m (64-bit) Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 PS. I do not check TrackHeaderBox::duration and MediaHeaderBox::duration. Maybe they have bugs too?
,
Apr 22 2016
,
Apr 23 2016
please hide my email from comment #2 "repro" in attach.
,
Apr 23 2016
Thank you for providing more feedback. Adding requester "yiningc@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2016
coolcmd@, I unzipped your attached 604353.zip file, none of the 4 .mp4 files can be played. please provide detailed repro steps and expect/actual behavior
,
Apr 26 2016
,
May 5 2016
- run chrome --allow-file-access-from-files - drag&drop 604353-f.html - console output: HTMLMediaElement.seekable=TimeRanges instead of empty (length == 0) HTMLMediaElement.duration=47721.858833 instead of 0 - drag&drop 604353-0.html - console output: HTMLMediaElement.seekable=TimeRanges is OK HTMLMediaElement.duration=Infinity instead of 0
,
May 5 2016
Thank you for providing more feedback. Adding requester "yiningc@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 11 2016
by follow steps in #9, I am able to repro this issue. Matt, can you take a look?
,
Aug 18 2016
Matt, any update?
,
Nov 21 2016
7 months later... nothing.
,
Dec 1 2016
Actually, I believe I fixed a duplicate of the 1/3 of this issue in September (in current M55 beta) -- see issue 649882 . 604353-f.html in #5 is now demonstrating that seekable ranges has length 0 after that fix. For the other 2 parts of this issue: 1) If it's indeed incorrect for ISOBMFF duration == 0 to be determined as Unknown (and therefore the HTMLMediaElement and MSE-before-endOfStream()-is-called specs indicate the element's duration is to be +Infinity), then I'm less certain of the negative impact of +Infinity reflection in that case. Note that webm (matroska info.duration), if present, must be > 0, so I don't believe there's any ambiguity for similar scenario for Chrome MSE for webm. 2) Following endOfStream(), the element is indeed incorrectly reporting +Infinity duration in OnSourceEnded (604353-f.html from #5), when nothing was ever appended. It looks to me like the condition in https://cs.chromium.org/chromium/src/media/filters/chunk_demuxer.cc?rcl=1480594633&l=1248 is triggering early return without actually updating the duration, if the resulting duration is 0. This seems wrong to me. See also issue 639144. Updating title of this bug to reflect these remaining 2 cases.
,
Dec 1 2016
,
Aug 4 2017
For c#14-2) see also https://bugs.chromium.org/p/chromium/issues/detail?id=751823#c10 |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by dalecur...@chromium.org
, Apr 20 2016Components: -Internals>Media Internals>Media>Source