MR to MSE 'timecode before previous block' error -- cannot jump gap segment either in segments mode or sequence mode
Reported by
chris.ch...@gmail.com,
Nov 17
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 11021.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.76 Safari/537.36 Steps to reproduce the problem: 1. Load (one) attached test page, the javascript console, and also media-internals 2. Press start, and wait ten seconds for first segments to be dropped 3. After six more seconds, segments will no longer be dropped, and you should see the following in media-internals: CHUNK_DEMUXER_ERROR_APPEND_FAILED: Got a block with a timecode before the previous block." What is the expected behavior? The expected behavior is that the video should jump the gap and continue playing, which sometimes (rarely) happens. If so, just repeat the test again. What went wrong? If you modify the test code to set skipNums=[], then no segments are dropped and the video plays perfectly (usually). This is also the case with the original version of Cunningham's test at https://storage.googleapis.com/chcunningham-chrome-shared/mr_to_mse.html Did this work before? N/A Does this work in other browsers? N/A Chrome version: 70.0.3538.76 Channel: stable OS Version: 11021.56.0 Flash Version: In the real version of my code, which involves sending segments over the network, I have some clients (or browser tabs) that have received all the segments, and others which are sent just the first segment (to get the headers -- due to other problems I ran into) and the current segment (to catch up with everyone else). Since every client is Chrome, and the ones that received all the segments continue to play fine, I suspect something other than bad encoding of the inter-segment timestamps. Note if you are suggesting workarounds: I am severely constrained with what I can do because I want to avoid processing things on the server. Also, the built-in streaming functionality can't be used with the networking scheme I want to use, so if I switch to some kind of live streaming method, I'll actually have to capture the stream into file segments myself, transport them over the network, and then unpack them on the other side... and I haven't been having good luck with processing intensive work in the browser... just seems to bog. So, I could really use your help here with the segment mode.
,
Nov 17
The last sentence in the summary should clarify that segment mode is not a reference to the sourceBuffer modes, just a reference to the method of making segments via ondataavailable.
,
Nov 17
I installed Firefox from the Play Store onto my Chrome-OS laptop. The gap jumping works correctly there using either attached example file. It continues playing after the gap.
,
Nov 19
,
Nov 19
,
Nov 20
That mr_to_mse is getting a lot of mileage! I looked at the segments demo. You're seeing this error because the gaps you're creating are not allowed by media source. If you create a gap and start a new append at some point later in the timeline, the new append must begin a "media segment" (MSE spec [0]). In WebM, the a media segment maps to a Cluster [1][2]. To make this demo work, after you skip your first bytes you need to throw away all subsequent bytes until you're at the start of a Cluster. I'm not very familiar MediaRecorder, but I don't see anywhere in its spec where it makes promises about how data is chunked up to the OnDataAvailable callback. You probably need to parse its output to figure out when the next cluster starts. I didn't look at the sequence mode demo. Using audio+video in a single sequence mode SourceBuffer is a minefield. [0] https://www.w3.org/TR/media-source/#sourcebuffer-parsing-media-segment [1] https://www.w3.org/TR/mse-byte-stream-format-webm/#webm-media-segments [2] https://matroska.org/technical/diagram/index.html
,
Nov 21
So if I understand correctly, it would mean that MSE is compliant with the spec, and that MR is unable to guarantee that a compliant player/parser will be able to recover after a network drop of any (one) of the chunks. Should the MR implementation of a browser be more resilient than that to connectivity problems? Opinions?
,
Nov 27
+Miguel for MR expertise
,
Dec 3
mcasas@, friendly ping
,
Dec 3
BTW, I worked around it so everything is cool for me. Thanks for your time!
,
Dec 5
Sweet, glad it worked out |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by chris.ch...@gmail.com
, Nov 17