Closed yume-chan closed 1 year ago
First of all, note that WebM does not officially support H.264 as a codec, so I would not expect every media player to play it back correctly. That said, it's likely that many still support this codec despite it not being spec-compliant.
I do see a need for your usecase, however, of manually adding data into the muxer. I added two methods addVideoChunkRaw
and addAudioChunkRaw
(documented in the README), which should address this issue.
Thanks for the suggestion!
That said, it's likely that many still support this codec despite it not being spec-compliant.
Yes, even Chrome's MediaRecorder
implementation also supports WebM with H.264.
A more spec-compliant solution might be using MKV instead of WebM, but I can't find a MKV muxer as good as this one.
I mean, you could probably change the doctype in the muxer to mkv and just give your output file an .mkv extension, and it would be fine! Remember that webm is just a subset of Matroska.
I want to use this library to re-mux a raw H.264 stream into a WebM file (because WebM has better support among media players than raw H.264 stream).
Because I already have an encoded stream, I don't need (or want) WebCodecs API to be involved (browser compatibility is another concern).
But currently, this library does an
instanceof
test againstEncodedVideoChunk
here:https://github.com/Vanilagy/webm-muxer/blob/1e0d3200ebbab54f9500737aa68ee3bbd7a8a011/src/main.ts#L367
I know I can construct
EncodedVideoChunk
s with my encoded data, but ideally, I want to supply the buffer directly to this library, saving the extra memory allocation and copying.I tried to modify this library like this:
So I can give it plain objects. I haven't modified it to take buffers directly.
Here is my consuming code:
https://github.com/yume-chan/ya-webadb/blob/eaf3a7a3c829ebdbd4e1608c4cc0f3caf623f180/apps/demo/src/components/scrcpy/recorder.ts#L77-L100