`encodeAudioData` on AudioContext about web-audio-api-v2 HOT 9 CLOSED

@padenot This certainly overlaps with the WebCodec work. Not sure if this is the right place for this...

from web-audio-api-v2.

We've decided to leave encoding and decoding out of v2, and to rely on web codecs instead. The Web Audio API is just about processing and audio output.

from web-audio-api-v2.

@padenot

We've decided to leave encoding and decoding out of v2, and to rely on web codecs instead. The Web Audio API is just about processing and audio output.

To avoid confusion and for clarity (WebAudio/web-audio-api#1850 (comment)) can you post that exactly language on the landing page of this repository https://github.com/WebAudio/web-audio-api-v2?

from web-audio-api-v2.

I think @padenot meant we're not going to add new encoding and decoding features. decodeAudioData will probably not be removed in v2; there's just too many uses of it.

from web-audio-api-v2.

This could be handled by libraries, but having this built into the spec would avoid having to download large libraries/WASM blobs, and would open the door to more performant implementations.

AudioBuffer to WAV without using nodejs or WASM https://github.com/mattdiamond/Recorderjs.

If "large libraries" were required to specifically convert audio from one codec or container to another then those libraries would need to be included in the source code of browsers. Some browsers are already shipped with their own version of ffmpeg in which case the only action necessary by browsers is to expose that executable to the front-end.

One option available right now outside the purview of Web Audio API would be to utilize Native Messaging to execute native binaries that transcode the media, which can be retrieved using either File API or where available Native File System. Using that approach it is not necessary to wait for a specification to write an algorithm or an implementation to adopt that specification.

from web-audio-api-v2.

Virtual F2F:

• This and a lot of other things are worked on in web-codecs

from web-audio-api-v2.

Have not seen evidence that WebCodecs is anywhere close to being specified and shipped. If that evaluation is incorrect, kindly post evidence to the contrary here and at #61. This code converts input to a WAV file https://github.com/guest271314/audioInputToWav. This code can be adapted to record any input and convert to any container or codec supported by native applications already installed on the OS https://github.com/guest271314/captureSystemAudio which can then be saved, exported, etc.

from web-audio-api-v2.

I'd like to add a +1 for a future implementation of a simple audiobuffer -> encoded & wrapped audio. Brief reading of Webcodecs indicates that it would not handle wrappers? The browsers obviously already implement all of the features required for a few chosen formats (e.g. using MediaRecorder to gather a webm containing Opus audio) for both encoding the media and wrapping. The advantage of having a simple function to do this would be that it would avoid proliferation of buggy encoding and buggy muxing.
My specific use case is I record using chrome's PCM implementation (thankyou chrome) to see & send real samples in low latency and create a wav file for saving uncompressed, but at completion would like to save an Opus 128 in chrome's native webm container for distribution to other 'clients' at a smaller size.
Since I can't find any projects that go direct from AudioBuffer -> webm-opus, maybe I am just unique (there are a few live audio->opus/ogg).

from web-audio-api-v2.

Since I can't find any projects that go direct from AudioBuffer -> webm-opus

You can record an AudioBuffer with MediaRecorder to produce an Opus encoded track in a WebM container.

from web-audio-api-v2.