Whats the issue with HEVC anyway?

How about the yuffypuff codec?

HuffYUV is still too uncompressed. Production wants a high quality intermediate wavelet semi-lossy based codec. Closest thing was Dirac, but development ceased and nobody used it.

Well now mate, it aint that easy to keep things going being a obs-dev that gets cash under the table to make HEVC appear but not permitted to work. Even with terminal wuju

Xaymar is actually legit not allowed to enable HEVC streaming in StreamFX.

He is literally waiting for GPUs to include AV1 hardware encoders.

It’s beyond me atm. Tired of the codec garbage going on, not even qcksync built in and so many other codecs. SSR with it’s GLinject is better than the obs frames that glow in the dark.

I’ve used ReplaySorcery myself. Uses Jpeg-Turbo as the codec. Saves all frames to memory then uses a h264 or whatever when all frames are already recorded to uncompress the output.

Oh, for screen capture just use ProRes on an external recorder.

Or try my super specific OBS version based DNxHD/DNxHR workflow which nobody is convinced is needed because they think the reverse engineered ProRes in FFmpeg is good enough:

1 Like

Sure for great capture external stuff is needed. Although the great part about jpeg-turbo and saving to memory (ram disc for example) is a super cheap way to record very high res at acceptable framerate, without having either external which is super expensive and lots muhhh cores. Which ain’t cheap aswell.

Jpeg-turbo works across systems low-to-high.

That’s actually similar to how my friend David Kronstein’s Chronos 1.4 and Chronos 2.1 work. You get more record time the more RAM you have.

Exactly and the speed of ram disc’s superseed anything else. Even pci based nvme. Check out the jpeg-turbo docs. Looks pretty neat to me.

A bit of both, why? And why are u having a stroke?

U want to join the topic? If so, dish it out. Otherwise, gtfo off the thread.

That seriously needs JPEG XS support. XS is even faster than standard JPEG and was originally gonna be a DP DSC 1.2 alternative:

That’s very nice. Should we build it from source? Or how can it be implemented and actually used?

Jpeg-turbo is made somewhat easy to use, with and without terminal. Even as a systemd-ctl service, or probably any other init aswell.

We can blabber on and on about codecs. Many are great if not even better, if they can be USED anyhow. Otherwise we’re just spewing spec sheets back’n forth, which doesn’t do much, as to an use-case?

JPEG XS needs to be optimized for said instruction sets and requires tons of under the hood optimizations, like how the SVT (Scalable Video Technology) does AVX-512 enhancements for their VP9, HEVC and AV1 encoders.

It’s not a simple integration. It requires instruction set optimization.

So hardware acceleration, from the cpu would be my guess. Something like qcksync, perhaps better even. Loads of work into that…

Either way, the codec thingie. Seems like working for obs would be the go to place for gazillion of dollars, sponsored by Intel to so it’s scalabe aswell there.

Experimental SVT-AV1 support was recently added to OBS. Unfortunately I still don’t trust it for realtime encoding as SVT-AV1 enforces and hard codes realtime CPU priority in the source. This can’t be easily changed.

Hehe it’s so far out that obs-devs make users require more and more cores. Doing it the hardest possible way in that regard. And the crazy fanboism from nvidia users that can’t output 8k30fps. Obs devs pointing to their cores, even though they have 32+ of them. ReplaySorcery could do the same job with 4 cores or less…loooool

Well, it’s the complexity of the codec for real time applications. JPEG XS is exactly what that jpeg-turbo project needs to have a fast encoding high quality intermediate in RAM rather than regular JPEG but heavily accelerated.

Amazin input right there, if they can be mixed or whatever would be pretty awesome. Idk about the actual implementation in code, although the results sounds like they would be pretty awesome.

The math behind those codecs look preeeeetty complex, so actual implementation versus more ideas could be pretty useful overall, unless HEVC is going new world order style hardware encoding :laughing: