No penalty, is kind of the deal there with HEVC.
Haha h264 and h265 is a JOKE. Basing all codec garbage on cpu usage alone. Even qcksync is way better. If that at least was open sourced properly. Fracking codec gadgets. If qcksync was royalty free we could talk proper cpu encoding.
Feel bad for your friend, cause h264 is pure garbage in comparison to proper hardware accelleration.
Well, itās using the hardware acceleration of the ARM chip heās using.
Hereās a EEVBlog teardown of his camera: (Warning, long video, no TLDR)
You must be confusing H264 and H265 with x264 and x265, the CPU only encoders. H264 and H265 are the codecs, x264 and x265 are the encoders.
I agree, x264 and x265 donāt do well for real time encoding. Theyāre brilliant though at slower presets if you can stomach the encode time for encoding a file rather than live encoding a game.
Well if itās on ARM then itās another thing of course. Nowhere near as bad, as it would be on x86 cpuās.
Would still not use any H264-265 encoders. Tbh, the cpu based encoders should be or get royalty free after some time. Making the microcode available as useable software. As in a useable codec for example, software based that then can use the cpu or gpu. Bet the quality of the microcode aināt bad code.
Even for the power that mainstream cpuās use. Those encoders are a total joke. Even with 4-12 cores the actual results in video per frame is above and beyond a joke. Cpuās that can turbo and whatnot. OCāed to 5+ghz, still deliver measly results in video.
Itās all because of the bad quality of codecs and encoding code quality.
If they were coded properly a cpu running at such high speeds even above 2ghz should be more than enough. Those encoders make, look and make feel stupid. Because of what, royalty fees? Itās age old tech, even on mediocre hardware would perform properly. Yet do not.
Itās bad in itās default presets. You need to use āveryslowā and be encoding files (not streaming games) to take advantage of x264 and x265.
Though there is a limit to how good it can get because of how the codec was built, and youāre right on that.
Also, H265 is the same as HEVC. Sorry to burst your bubble.
AV1 is where advances in better coding of the video can actually happen.
Haha donāt even get me started on PRESETS. What a joke they are. SUPER USEFUL, yet not even built in on the fracking gui. The presets ALONE are more useful than the fracking CODEC, sorry for the language. Better code quality in presets of the darn thing.
Idk if h265 is the same as HEVC. Doubt that, although possible i guess. The code quality donāt seem the damn same thatās for sure. Itās marketed as HEVC, so by saying itās the same is not entirely true. The CODE is NOT the same. End of bubble bursting story.,
AH, youāre using a GUI.
FFmpeg is what drives most of the GUIs, thatās what you should be using, a CLI.
Handbrake is bad. It also always turns files into variable frame rate no matter what the setting.
Find a better FFmpeg GUI or use the CLI is my advice.
Gotta admit CLI is annoyingly good., The results in gui are super garbage compared to the amazing CLiā¦ Very annoying guiās and interfaces stomping the experience of something like terminal usageā¦
This one is slowly getting better. Itās called Fastflix and it is literally driven by command line prompts in a GUI, rather than Handbrakeās garbage:
Upgrading terminals, would be cool though. As to look like more of an interface as opposed to looking like nano editing garbage. Almost makes u wanna snort something, knowing u have to press 30 keystrokes just to pick a damn option. Not saying guiās are better, then donāt even work properly.
Better terminals. Is what everyone really needs. Prefferably built in python and not C++ garbage.
Itās actually not even remotely the same. If u meant based on the same codec, sure whatever. So are others, that have gone proprietary for example. If u want to compare HEVC to something properly it would be FVENC, in terms of performance results. H265 ALLOWS graphics acceleration. H265 is not entirely gpu dependant, where HEVC IS or at could be modified so it would work as an FVENC alternative for non-nvidia users. Not only counting AMD.
If HEVC was modified properly, it could provide code quality that is on par with FVENC and similar. HEVC codec quality probably got even better with the crazy performance it delivers on m1 macs.
If anyone is going to fix something that insane its def jackman
Whatās very likeable about the x264 - x265 encoders are not as much the actual frames that are encoded, it is the frames that arenāt lost. Thatās where code quality comes in.
The encoding quality results of those encoders feels as if there is more quality in code of frame-losses than the results of encoded frames.
Although something like the jpeg-turbo codec or similar codecs seems to dump a LOT of frames and thatās the problem with such codecs that are mostly based on memory rather than a processor. So if such codecs can be tweaked enough, that frame losses arenāt as much of an issue, thatās would solve any if not all problems of recording and choosing codecs.
Not only that, even people with only mechanical harddrives would be able to record at the same level as people with much higher-end hardware. There is much more that needs to be put into making a codec like HEVC similar to FVENC, than tweaking the hell out of something like jpeg-turbo.
The main thing about codecs running on memory-chips instead of a processor is that it can utilize the disc to both encode on-the-fly which then after cpu codec can take over when the frames are compressed to do the processing part of the compression.
Perhaps JPEG XS, JPEG-TURBO and similar codecs could be of use if modified and tweaked enough using a ram-disc which is the most important part. The coding quality or even code would probably not be so easy, as in semi-batshit insane to code. From a non developer perspective. But hey, hard to disagree that it could do wonders in the field of codecs.
Idk much about the linearality of C++ my guess would be thatās itās super linear for practical reasons. If it was more flexible as other languages then it could be pretty awesome to use several codecs simultaneously. Idk if and how something like that would work, but u have to admit it would be pretty cool.
Using several codecs simultanously on the cpu, gpu, harddrive, memory either of them, splitting the task that way could perhaps result in better and easier results, requiring less computing overall.
ASICās would be a great choice for that even though they run on cpu tasks. Perhaps if the chips used could process as well as provide graphics acceleration, then the task could also be split that way.
Code quality would be of utmost importance and that would also make it possible to encode and process on much much lower end hardware. If the unit can do both, again the task would be lessened as it splits tasks over several units.
Iāve seen usb ASICās used in crypto mining for example. Those if tweaked enough should be able to do the trick, with chips getting small enough to the tasks of those kind of units. Also super handy, could also use thunderbolt although that part is less open than the protocol that usb uses.
Even though many codecs depend on either cpu or gpu accel. Would much rather see, proper codecs that use either ram or hdd for the encoding part, the processing can be done when the frames are compressed or even stored in raw, (if possible) the problem again is the massive amount of frames lost. Which leaves those kind of dependant codecs, for themselves a bit to much compared to other codecs.
If itās possible to tweak such a codec to an extent of actually being useful like some are and focusing on not losing as many frames as for example jpeg-turbo does. The amount of lost frames, are way to high on jpeg-turbo. Canāt remember the exact numbers, though if memory serves me correctly itās above actually above 50% which causes massive loss of frames and thatās even when set super low, to something like 30fps only. Idk how it performs in different resolutions, although the amount of frames lost, if it can be tweaked that would really really be something special in the area of codecs.
The important thing of the codec is not as much itās naming as what itās using. The enormous benefits it would lead to and the area it would or could cover, by specifically using ram or hdd would surpass any other codec. As itās availability and requirements are so low, that it would be like a jewel of a codec.
For lossless wavelet, FFV1 is alive and well and usable in lots of software: FFV1 - Wikipedia
For high quality lossy, just crank-up MPEG-2, x264, or anything else with a GOP-size of 1. Do fixed quantizer levels (or CRF) encoding instead of bitrate.