fzwoch / obs-teleport

An OBS Studio plugin for an open NDI-like replacement. Pretty simple, straight forward. No NDI compatibility in any form.
GNU General Public License v2.0
438 stars 16 forks source link

[Feature Request] lossless mode with alpha, QOI format #27

Closed no-connections closed 1 year ago

no-connections commented 2 years ago

It looks almost too simple to be true. I think it's single threaded but that might not even be a problem if it's fast enough. "removal of the size header. This allows for a streaming encoder without having to jump back to set the size in the file header." This could allow for very low latency transfer as well. Depending on content lossless will quickly run out of bandwidth on 1G Ethernet but there is plenty of use cases that need alpha and compresses pretty well like text and graphics. Also 10G Ethernet exist.

It already have implementations on github for pretty much every programming language linked. https://phoboslab.org/log/2021/11/qoi-fast-lossless-image-compression https://phoboslab.org/log/2021/12/qoi-specification https://qoiformat.org/ https://github.com/phoboslab/qoi

fzwoch commented 2 years ago

Looks interesting. Is there a current use case where it is possible to use it? I mean, is there a source where it makes sense to use what does not require the effect filter functionality?

fzwoch commented 2 years ago

There is a qoi branch available.

The quickest Go implementation from that list claims a 1/2 half performance of the C reference implementation. It was easy to integrate, but performance does not feel great yet in that approach. Tested with 1080p60.

QOI qoi

JPEG jpeg

no-connections commented 2 years ago

"Is there a current use case where it is possible to use it?" One option is to render graphics overlay and send it over to another for stream. Another is keying a camera with a RTX card and sending it over to a non RTX PC. You could also send an already framed webcam (like talking head) already keyed. Or chat.

"is there a source where it makes sense to use what does not require the effect filter functionality?" I'm note sure what you mean by this, but if you mean chroma key it won't compare to alpha.

1080p60 might be optimistic in terms of bandwidth depending on what it contains but it's a start. Does load change with content? How does it compare with JPEG turned up to 100? I would not expect sending a game at that resolution and frame rate to work for example. Is there a way to limit frame rate? Maybe a setting to select what frame rate gets sent. The gui would need a checkbox to turn alpha on and off as well.

Another option is to have a setting to send video contend as JPEG and alpha channel as QOI. I guess JPEG with alpha can be sent as a separate gray scale image if QOI turns out to be impractical to use in practice.

fzwoch commented 2 years ago

The question was more, "can I try it"? I think image source and browser source for example are no async sources and I can't hook teleport in there.

Only using QOI for the alpha channel is an interesting idea. But personally, don't expect too much time spent here from my side in the next future.

no-connections commented 2 years ago

It would be very interesting to try out performance and utility with different content if you have it selectable in a future version. Source mirror in StreamFX would allow hooking to many things.

YorVeX commented 2 years ago

The base idea sounds great for my specific use case where I transmit data between OBS instances on the same PC - where bandwidth shouldn't be an issue. That's also why I tried to set Teleport quality to 100 for this transmission, assuming that this also would mean less compression = less CPU load. But yeah, I was totally wrong, CPU load increased instead and I had to go with lower quality 😛 See here for my test results.

So I started to read this thinking that this is the solution I was looking for with higher quality and smaller CPU load but once more I was wrong when I look at the tests that have been performed with the QOI branch 😆 I must be missing something here - when QOI is so much faster, shouldn't that "faster" come exactly from the CPU having less work to do? Or is the CPU load not actual load in the original computation sense but the CPU being so busy moving these vast amounts of data?

Oh well, still leaving this on sub now to see whether a solution turns up at some point.

fzwoch commented 1 year ago

Closing as I don't think this will ever happen. If there is a codec implementation that comes close to the libjpeg-turbo implementation one might reconsider.