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.
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
Asynccodec that wraps any TS, such that the underlying stream's transcoding happens in another thread. More specifically,Asynccould carry an internal bufferBalong with its input (I) and output(O)buffers. WhenOruns dry, it will copy data fromBtoO, then schedule the transcoding fromItoB.I believe this codec should be in TS and not a separate package because:
Asynccodec 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.