Closed Bug 1424937 Opened 2 years ago Closed 2 years ago

Got demuxer error while playing video recorded by MediaRecorder.

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- fixed

People

(Reporter: mchiang, Assigned: jwwang)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached file MediaRecorderBug.html
Video element shows "Video can't be played because this file is corrupted".
media panel shows that there is a NS_ERROR_DOM_MEDIA_DUMUXER_ERR.

mozregression point to this commit.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0ff4a36cce94d0b9cb64c3ee7204e72749707e5c&tochange=fdb2a41005f2c8ae4d3528c893821f9eb06b3f0c
I believe this is not a serious bug, so temporarily set this bug as P3. Correct me if I am wrong.
Flags: needinfo?(jwwang)
Isn't this related to bug1424183 and bug1421176?

I was testing these when I found bug1424191, and didn't expect the resulting Blob to be valid.
This bug was found after fixing bug 1424191 (patch: bug 1424191 comment 6).
This blob (*.webm) can be downloaded and played well by opening this webm file directly with Firefox.
Since the blob (*.webm) is valid, it should not be related to bug 1424183 if I understand correctly.
Well bug1421176 doesn't prevent downloading the merged Blob, nor playing the downloaded File either, it's when displaying such merged Blobs that the problem occurs.
HTTP “Content-Type” of “application/x-unknown-content-type” is not supported. Load of media resource blob:https://bug1424937.bmoattachments.org/ca0f193d-f6e6-3f42-99cb-60cd4370396d failed. attachment.cgi

The load algorithm fails even before running any code of ChannelMediaResource. This can't be a regression from bug 1415090.
No longer blocks: 1415090
Flags: needinfo?(jwwang)
https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/dom/media/MediaCache.cpp#2691-2694

It looks like aborting Read() when download ends abnormally is too aggressive. We should read as many bytes as we can before giving up reading.

This bug is regressed by bug 1415090 P4.
Blocks: 1415090
Keywords: regression
Attachment #8936551 - Flags: review?(bechen)
Comment on attachment 8936551 [details]
Bug 1424937 - read as many bytes as possible before giving up reading due to download ends abnormally.

https://reviewboard.mozilla.org/r/207286/#review213138

::: dom/media/MediaCache.cpp:2736
(Diff revision 1)
>  
> +    if (mDidNotifyDataEnded && NS_FAILED(mNotifyDataEndedStatus)) {
> +      // Since download ends abnormally, there is no point in waiting for new
> +      // data to come. We will check the partial block to read as many bytes as
> +      // possible before exiting this function.
> +      bytes = ReadPartialBlock(lock, streamOffset, buffer);

I wonder to know what's the different between the "ReadPartialBlock" here and the "stream->ReadPartialBlock" at line 2720?
Attachment #8936551 - Flags: review?(bechen) → review+
Comment on attachment 8936551 [details]
Bug 1424937 - read as many bytes as possible before giving up reading due to download ends abnormally.

https://reviewboard.mozilla.org/r/207286/#review213138

> I wonder to know what's the different between the "ReadPartialBlock" here and the "stream->ReadPartialBlock" at line 2720?

The test at #2732 works for a live stream because |stream->mChannelOffset == stream->mStreamLength| is always false for a live stream whose mStreamLength is negative.
Attachment #8936551 - Flags: review?(gsquelart)
Assignee: nobody → jwwang
Comment on attachment 8936551 [details]
Bug 1424937 - read as many bytes as possible before giving up reading due to download ends abnormally.

https://reviewboard.mozilla.org/r/207286/#review213220
Attachment #8936551 - Flags: review?(gsquelart) → review+
I think we should have a mochitest for it.
@Munro: Could you file another bug and provide the blob? (I guess we can just add this blob to current tests such as testing playback)
Flags: needinfo?(mchiang)
You can use the attachment (MediaRecorderBug.html) to record one and download it : )
Flags: needinfo?(mchiang)
Just remember to apply the wip (bug 1424191 comment 6) first.
(In reply to Munro Mengjue Chiang [:mchiang] from comment #12)
> You can use the attachment (MediaRecorderBug.html) to record one and
> download it : )

I don't think it works. Once you download and save it as a file, it is no longer a blog, right? I think we need a way to generate a blog from a file.
Thanks for the reviews!
Pushed by jwwang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/358f1c414f3e
read as many bytes as possible before giving up reading due to download ends abnormally. r=bechen,gerald
Another way is use MediaRecorder to record a stream from canvas.
You can refer to dom/media/test/test_mediarecorder_record_downsize_resolution.html
Priority: -- → P3
I am not able to reproduce the issue from a canvas stream as proposed by :mchiang, but I can definitely reproduce from a gUM stream.

Attached a new version of the reproduction page, with a workaround for bug 1424191.

Note that it is possible to download, or even display the video in a new Tab pointing directly to the blobURL, but playing it as is in the main page throws the DEMUXER_ERR.


Ps: I don't think P3 is correct, I guess it's quite common to display what has just been recorded in the same page.
https://hg.mozilla.org/mozilla-central/rev/358f1c414f3e
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.