Open
Bug 1276928
Opened 9 years ago
Updated 2 years ago
MediaRecorder: clarify what happens when recording a stream with multiple tracks with different audio sampling rates
Categories
(Core :: Audio/Video: Recording, defect, P4)
Core
Audio/Video: Recording
Tracking
()
NEW
backlog | webrtc/webaudio+ |
People
(Reporter: sole, Unassigned)
References
Details
(Keywords: DevAdvocacy)
What should happen? Should the output be encoded at the maximum sampling rate? Can various tracks with different sampling rates coexist? Will they be upsampled to all match the highest rate?
This isn't defined in the MediaRecorder spec either, but it's getting developers confused.
Linking to the bug that already exists, for tracking purposes.
Comment 1•9 years ago
|
||
Does this prioritization seem sane?
backlog: --- → webrtc/webaudio+
Rank: 35
Flags: needinfo?(padenot)
Priority: -- → P3
Comment 2•9 years ago
|
||
(In reply to Soledad Penades [:sole] [:spenades] from comment #0)
> What should happen? Should the output be encoded at the maximum sampling
> rate? Can various tracks with different sampling rates coexist? Will they be
> upsampled to all match the highest
What would be a setup where this happens ?
For now in Gecko (and I'm just talking about the current setup to give some sense of perspective), it's all resampled to the "native sample rate" of the device the audio is going to (usually, the default audio output of the system), even if no audio is going out of the speakers.
This is going to change, because we'll be able to specify the sample rate of AudioContexts, and then as you mention we'll really have to spec what should happen.
Flags: needinfo?(padenot)
Updated•8 years ago
|
Flags: platform-rel?
Updated•8 years ago
|
platform-rel: --- → ?
Updated•8 years ago
|
platform-rel: ? → ---
Comment 3•7 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•