Closed Bug 1511006 Opened 6 years ago Closed 5 years ago

MediaRecorder.onDataAvailable triggers erratic behaviours (mixed Blobs and Files)

Categories

(Core :: Audio/Video: Recording, defect)

63 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1513596

People

(Reporter: michael, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce:

I'm attaching a use case where you can play with different parameters of timesliceLength and totalRecording
_ Start recording using a timeslice of 2500ms or more and a length that allows for minimum 2/3 Blobs to be generated 
_ Fire onDataAvailable to get the Blobs
_ Create a Blob object on stop to review the video


Actual results:

In case of a timeslice of more than 3000, it seems like except for the first and last data generated by ondataavailable() that are Blob objects, the rest are File objects.

Between 2000 and 3000, it seems erratic, sometimes adding a File in the middle of the Blobs, sometimes working. (E.g. 2500 / 10000 worked a few times, not always, but 2500 / 12500 consistently generates 2 Files in the middle and at the end of the chunks array)

One very bizarre case is the combination 2500 / 7500, last chunk is an empty Blob, so I get only 5 seconds of video out of 7.5

In case of a timeslice <= 2000, it seems to work correctly and generates only Blobs.


Expected results:

Only Blobs should be generated, and it was the case before (can't tell exactly when, but I'm almost sure on 60 it was working properly and 62 it wasn't)

Hence can't review the final video, cause it is obviously corrupted with the mix of Blobs and Files.
As a side note, I can reproduce both on Windows 10 and on several versions of Mac OS X
Hi any update on this ?
I've investigated and attached a complete use case, so it shouldn't be too hard to confirm it or not :)

Thanks !
Chun-min, can you triage this?
Flags: needinfo?(cchang)
Hi michael,
Do you have any existing code that we could use it to check out the problem ? It would be really helpful.
Flags: needinfo?(cchang) → needinfo?(michael)
MediaRecorder will put blobs that exceed 1MB in file-backed blobs instead of memory-backed ones.

Not too long ago we had some fixes to the file-backed blob implementation in MediaRecorder, and it's possible this introduced a regression. The idea is that these file-backed blobs should look like Blobs and behave like Blobs, i.e., they should still be Blobs.

Andrea, does the reported behavior make sense to you?

Michael, you can verify this by changing the "media.recorder.max_memory" pref. It's default is 1024000 (bytes). If you set it smaller on about:config (you'll need to add it) you should get more files, and if you set it higher you should get more Blobs.
Flags: needinfo?(amarchesini)
See Also: → 1403706
Hi Chun-min,
I have attached a complete use case to reproduce the issue and detailed instructions, what more can I possibly do ? :)

@Andreas : thanks that makes sense I will test this and let you know the results as soon as done.
Flags: needinfo?(michael)
Hi Andreas, 

Didn't find such option on the prefs. I created a new one with this name setting a bigger value, but it didn't seem to have any effect (I'm using Firefox 64.0)

But from what I can tell, this is indeed the behaviour you reported : everytime the chunk is bigger than 1024000 bytes, it produces a File instead of a Blob.
All right, I've tested now. FWIW the pref works for me. It needs to be of integer type and gets read by the MediaRecorder session ctor (an internal object, but it's when a recorder starts recording basically. a single recorder can have many sessions).

The File objects are inheriting from Blob, and a Blob can be created from a mix of Blob and File objects.

However, we cannot play back a Blob consisting of a list of Blobs when one of those Blobs is a File.

I'm getting an error from the media element: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006)


This decoding issue is bigger than the File vs. Blob issue. It's already been filed as bug 1499560 so let's keep that for the decoding issue, and this for the File vs. Blob issue.
See Also: → 1499560
Ah I didn't pay attention and created it as a string and I'm now unable to delete it or edit its type...
Anyway, thanks for the detailed info and the investigation !
> This decoding issue is bigger than the File vs. Blob issue. It's already
> been filed as bug 1499560 so let's keep that for the decoding issue, and
> this for the File vs. Blob issue.

I haven't seen your comment in time... And I filed bug 1513596, with a patch included.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(amarchesini)
Resolution: --- → DUPLICATE
Depends on: 1499560
See Also: 1499560
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: