Daniel Oberhoff
Daniel Oberhoff
I used some other libs i think. I will try to remember to outline it on monday
Ok, so I ended up using `github.com/pion/webrtc/v3` for webrtc and also being h264 specific in adding start codes to the h264 nalus in the stream. so its a bit hacky...
open sourced it: https://github.com/pixelwise/rtsp_to_webrtc
It serms like the whole nat traversal doesn't fully work? I had to set up a turn server in my case, but still only could get my version to work
I use the webcodecs api to decode video frames and use those as textures in a three.js scene.
This would be extremely cumbersome tbh, we really want to just directly use the webcodec images
And these are effectively video textures, but with more control. If you block this you effectively make threejs incompatible with webcodecs (minus cumbersome workarounds). All this while the required change...
Ok, I just checked again, and there is a very significant performance boost in using images from the webcodecs api as texture with my patch, so it is extremely relevant...
ah, actually this would be for canvas texture I guess, because it always has this problem due to the bug.
ok, I added an example that showcases the performance. you can switch by setting isGpu to true/false. results depend on bowser. on my old machine there is maybe a 20%...