obs-teleport icon indicating copy to clipboard operation
obs-teleport copied to clipboard

[Feature Request] lossless mode with alpha, QOI format

Open no-connections opened this issue 2 years ago • 6 comments

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

no-connections avatar Apr 09 '22 17:04 no-connections

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 avatar Apr 12 '22 12:04 fzwoch

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

fzwoch avatar Apr 16 '22 18:04 fzwoch

"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.

no-connections avatar Apr 19 '22 11:04 no-connections

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.

fzwoch avatar Apr 19 '22 15:04 fzwoch

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.

no-connections avatar Apr 21 '22 15:04 no-connections

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.

YorVeX avatar Jun 07 '22 23:06 YorVeX

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.

fzwoch avatar Jan 31 '23 12:01 fzwoch