Looking forward to the next construction can be added to implement

[whxuezhe]

WebCodecs integration test WebCodecs_AudioEncoding_AAC_LC fails
xHE-AAC support
Strengthen Webcodecs API audio and video processing capabilities.

[gz83]

WebCodecs integration test WebCodecs_AudioEncoding_AAC_LC fails xHE-AAC support Strengthen Webcodecs API audio and video processing capabilities.

@whxuezhe what do you want to say?

[whxuezhe]

@gz83 Overview is as follows:In order to solve this problem, many audio and video editors used Webassembly to bring audio and video codecs to the browser, but there is a problem that many browsers have supported audio and video codecs at the bottom, and many hardware accelerate has been performed. The tuning, if we use Webassembly to re -pack these capabilities, it seems to waste human and computer resources.
Therefore, webcodecs API was born, exposed media APIs to use some capabilities that already have the browser, such as:

Video and audio decoding
Video and audio coding
Original video frame
Image decoder
Frames is the core of video processing, so most of WebCodecs either consumes Frames or produces Frames. Video Encoders converts Fedes to Encoded Chunks, and Video Decoders converts Encoded Chunks into Frames. All this is treated with non -main threads, so the main thread speed can be guaranteed.
Currently, in WebcodeCs, the only way to display Frame on the page is to convert it to ImageBitmap and draw a bitmap on Canvas or convert it to WebglTexture
One is to create Frame through ImageBitMap
The second is to handle the Frame generated by the VideoTrackReader setting method to handle from [MediaStreamTrack] (https://developer.mozilla.org/en-s/web/api/medreamtrack). At that time, this API is very useful

[gz83]

@gz83 Overview is as follows:In order to solve this problem, many audio and video editors used Webassembly to bring audio and video codecs to the browser, but there is a problem that many browsers have supported audio and video codecs at the bottom, and many hardware accelerate has been performed. The tuning, if we use Webassembly to re -pack these capabilities, it seems to waste human and computer resources. Therefore, webcodecs API was born, exposed media APIs to use some capabilities that already have the browser, such as:

Video and audio decoding Video and audio coding Original video frame Image decoder Frames is the core of video processing, so most of WebCodecs either consumes Frames or produces Frames. Video Encoders converts Fedes to Encoded Chunks, and Video Decoders converts Encoded Chunks into Frames. All this is treated with non -main threads, so the main thread speed can be guaranteed. Currently, in WebcodeCs, the only way to display Frame on the page is to convert it to ImageBitmap and draw a bitmap on Canvas or convert it to WebglTexture One is to create Frame through ImageBitMap The second is to handle the Frame generated by the VideoTrackReader setting method to handle from [MediaStreamTrack] (https://developer.mozilla.org/en-s/web/api/medreamtrack). At that time, this API is very useful

@whxuezhe This technique seems to come from Firefox?

[whxuezhe]

@gz83 Yes, it was first introduced by the Firefox browser, but the recently compiled three -party compilation version of the CHROMIUM core OPERA Dev Channel 96.0 and 97.0 was constructed, and I also saw it; therefore, it was proposed.

[gz83]

@gz83 Yes, it was first introduced by the Firefox browser, but the recently compiled three -party compilation version of the CHROMIUM core OPERA Dev Channel 96.0 and 97.0 was constructed, and I also saw it; therefore, it was proposed.

@whxuezhe
Here is the information you want to know

https://developer.chrome.com/en/articles/webcodecs/

https://chromestatus.com/feature/5669293909868544

https://www.chromium.org/audio-video/