Comments (5)
Both seem useful. Big apps ported from native or advanced users probably want a synchronous API and use their own threading synchronized via shared memory to keep caches hotter when doing something with the output afterwards. Other users probably want something a bit more ergonomic.
Parallelism inside Web Codec constructs will be some sort of fork-and-join, but that's useful for intra-frame parallelism, for encoding video.
from webcodecs.
I'm not sure it makes sense to expose the WebCodecs API to the main thread at all. Shouldn't it always be in a worklet or worker? Is there a compelling use case that requires the main thread?
from webcodecs.
The spec's processing model now makes the threading behavior explicit
https://wicg.github.io/web-codecs/#codec-processing-model
Control thread: where you make the encoder/decoder (be it in a window or worker)
Codec thread: where actual encoding/decoding is to occur. May actually be N threads, but may not be the control thread.
I'm not sure it makes sense to expose the WebCodecs API to the main thread at all. Shouldn't it always be in a worklet or worker? Is there a compelling use case that requires the main thread?
This question probably goes away with my comment above. Apps with lots of main thread activity and/or heavy UI (e.g. video conferencing) should still use WebCodecs in a worker to avoid contention with controlling the codec and painting their UI. But for other apps, Window is fine.
from webcodecs.
Some questions were raised about WebCodecs support for threading here.
from webcodecs.
Chromium's WebCodecs implementation will offload decoding to a separate thread. We probably want to specify this behavior.
This is now spelled out in the spec. https://w3c.github.io/webcodecs/#control-thread-and-codec-thread
Big apps ported from native or advanced users probably want a synchronous API...
We discussed this in the call w/ audio epxerts. It is true that many are coming from a synchronous API, but they concluded that this was not a requirement for them. We also discussed how our API's under the hood are often async and they stated that they did not desire for us to hide that from them at the JS layer. Please open a new issue for this if I've overlooked anything.
I'm not sure it makes sense to expose the WebCodecs API to the main thread at all.
This same question is under more active discussion in #211.
from webcodecs.
Related Issues (20)
- Explicit frame drop signal from VideoEncoder HOT 3
- Long term reference support for AVC/HEVC HOT 6
- isConfigSupported: definition of "invalid" HOT 4
- webcodecs encode h264/h265 Capability set HOT 1
- Support for AV1 switch frames HOT 5
- Fatal encoding/decoding error on Windows 10/11 HOT 2
- Why is isTypeSupported() promise-based? HOT 8
- Receiving Uncompressed Webcam Data without Browser Compression HOT 5
- After how many decode should the codec process the frames? HOT 10
- Clarify `reset()` behaviour when multiple things are being output HOT 3
- key-frame request handling when scalability mode is not L1T1 for encoder HOT 6
- Clarify the `Clone configuration` algorithm HOT 4
- Figure out what should happen to the unused bits in 10-bits and 12-bits pixel formats
- Rephrase non-normative uses of RFC2119 keywords HOT 1
- Web Audio API compatibility HOT 1
- Assign VideoFrame resource to [[resource reference]] in BufferSource constructor HOT 4
- VideoFrameBufferInit metadata field missing
- sourceWidthBytes from sampleWidth, not sampleHeight
- Vekil
- Sporadic build failures HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webcodecs.