Closed
Bug 1424937
Opened 7 years ago
Closed 7 years ago
Got demuxer error while playing video recorded by MediaRecorder.
Categories
(Core :: Audio/Video: Playback, defect, P3)
Core
Audio/Video: Playback
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)
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
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 3•7 years ago
|
||
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.
Assignee | ||
Comment 5•7 years ago
|
||
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)
Assignee | ||
Comment 6•7 years ago
|
||
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
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Attachment #8936551 -
Flags: review?(bechen)
Comment 8•7 years ago
|
||
mozreview-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
::: 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+
Assignee | ||
Comment 9•7 years ago
|
||
mozreview-review-reply |
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.
Assignee | ||
Updated•7 years ago
|
Attachment #8936551 -
Flags: review?(gsquelart)
Assignee: nobody → jwwang
Comment 10•7 years ago
|
||
mozreview-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/#review213220
Attachment #8936551 -
Flags: review?(gsquelart) → review+
Comment 11•7 years ago
|
||
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)
Reporter | ||
Comment 12•7 years ago
|
||
You can use the attachment (MediaRecorderBug.html) to record one and download it : )
Flags: needinfo?(mchiang)
Reporter | ||
Comment 13•7 years ago
|
||
Just remember to apply the wip (bug 1424191 comment 6) first.
Assignee | ||
Comment 14•7 years ago
|
||
(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.
Assignee | ||
Comment 15•7 years ago
|
||
Thanks for the reviews!
Comment 16•7 years ago
|
||
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
Reporter | ||
Comment 17•7 years ago
|
||
Another way is use MediaRecorder to record a stream from canvas.
You can refer to dom/media/test/test_mediarecorder_record_downsize_resolution.html
Updated•7 years ago
|
Priority: -- → P3
Comment 18•7 years ago
|
||
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.
Comment 19•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•7 years ago
|
status-firefox57:
--- → unaffected
status-firefox58:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•