You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, TranscodingSteams (TS) is currently mostly used for de/compression codecs, which are quite CPU-intensive. In this case it would be beneficial to allow the de/compression to happen in a separate thread concurrently.
I think this can be solved by having an Async codec that wraps any TS, such that the underlying stream's transcoding happens in another thread. More specifically, Async could carry an internal buffer B along with its input (I) and output (O) buffers. When O runs dry, it will copy data from B to O, then schedule the transcoding from I to B.
I believe this codec should be in TS and not a separate package because:
It's near-universally useful for users of TS
The Async codec might have to reach into TS's internals for efficiency, to make sure the underlying TS really does run its transcoding in a different task.
The text was updated successfully, but these errors were encountered:
As far as I can tell, TranscodingSteams (TS) is currently mostly used for de/compression codecs, which are quite CPU-intensive. In this case it would be beneficial to allow the de/compression to happen in a separate thread concurrently.
I think this can be solved by having an
Async
codec that wraps any TS, such that the underlying stream's transcoding happens in another thread. More specifically,Async
could carry an internal bufferB
along with its input (I
) and output(O)
buffers. WhenO
runs dry, it will copy data fromB
toO
, then schedule the transcoding fromI
toB
.I believe this codec should be in TS and not a separate package because:
Async
codec might have to reach into TS's internals for efficiency, to make sure the underlying TS really does run its transcoding in a different task.The text was updated successfully, but these errors were encountered: