Lossless video format

>>57592478
>Trouble is I can't find one that isn't both larger AND slower than H.264.
Welcome to lossless video formats.

>>57592478
huffyuv failed you? How about iz?

>>57592478
>lossless
>video
kys 2bh stupid ass nigga

Pied Piper

File: auroras.jpg (77KB, 920x501px) Image search: [Google]

77KB, 920x501px

>>57592627
you're the only one who doesnt seem to be trolling but what is iz?

>>57592478
>Wanting lossless to be small and fast than H.264
You are crazy

File: nature.jpg (123KB, 576x768px) Image search: [Google]

123KB, 576x768px

>>57592594
isnt the point of lossless encoding to have great speed at the cost of great file size?

>>57592771
thats not what i said. i want it to be faster than h.264 yet larger.

Lossy compression usually yields higher compression ratios by nature of the idea. E.g. at the most extreme end you could compress a frame down to a single color. Because of this, lossless compression is usually slower because there isn't as much work put into it.

File: moon and earth.png (3MB, 2048x2048px) Image search: [Google]

3MB, 2048x2048px

>>57592812
>lossless compression is usually slower because there isn't as much work put into it
did you type that wrong or are you saying less work equals slower?

>>57592793
No, the point of lossless compression is to archive media in its original state without having to store raw video sizes. That way you can always re-encode or modify it later.

YUV444

File: matrix.jpg (211KB, 1024x768px) Image search: [Google]

211KB, 1024x768px

>>57592841
yeah and that. im tired, sorry. i meant when it comes to live streaming and such.

regardless, still looking for a good lossless codec that can beat the speed of lossless h.264

>>57592839
What I was saying is that there is less R&D in lossless formats because there isn't as much of a point for commercial interests.

File: the mask.jpg (36KB, 291x350px) Image search: [Google]

36KB, 291x350px

>>57592850
ffmpeg says: Unknown encoder 'YUV444'

>>57592866
>R&D
"research and demand"? im not english speaking so i don't really know all abbreviations

>>57592902
Research and development. Lossless isn't slower by nature, but it's slower because h.264 and other lossy compression algorithms are the ones that get all the funding. They get the funding because lossy algorithms will pretty much always yield higher compression ratios. So h.264 is fast because there is a small army of developers getting paid to make it fast.

>>57592902
H264 with YUV444 profile

File: paperman.jpg (51KB, 450x358px) Image search: [Google]

51KB, 450x358px

>>57592945
i see, thanks. thats probably true

im having some success with "ffvhuff", which is a "Huffyuv FFmpeg variant". ill do some tests with it

File: krang.jpg (66KB, 600x744px) Image search: [Google]

66KB, 600x744px

>>57592972
you don't happen to have a command line in memory for that?

im currently using "-pix_fmt yuv420p" because that seems to have best compability

while im here i might as well ask if anybody think using that pixel format is good?

>>57592793
>great speed at the cost of great file size?
Not really.
The algorithms are still complex and the huge amount of data involved requires a lot of processing.

Just look at FLAC vs MP3. FLAC isn't faster or less resource consuming to process than MP3.

>>57592945
Na, that's full shit right there.
Lossless encoding is slower because the algorithms for compressing the data losslessly are more complex than lossy algorithms.
They're still converting all the data into another format, a completely different format to the original RAW data, but it still needs to return to the original RAW data.

File: road sign cat mouse.jpg (121KB, 800x600px) Image search: [Google]

121KB, 800x600px

>>57593202
>process
you're talking about encoding right?

i'd figure it should always take longer to encode with lossy format since the computer then have to figure out how to best compress it (figure out what to remove)

for example it's faster to convert an ogg audio file to wav than to mp3. as long as the HDD/SSD can keep up it should be the same with video codecs

>>57593264
sounds about right

>>57593022
it's the 'standard' input for most compression shit

see why: https://en.wikipedia.org/wiki/YUV

basically we're more sensitive to brightness so using a format that separates brightness and colour information allows some neat tricks like reducing the amount of colour data you store (yuv420 is only 1.5 bytes per pixel, for example)

it's not lossless (only yuv444 is) but you won't notice the difference, especially in video where each frame is only shown for a few milliseconds

if you're not just being autistic, use h264 with bitrate cranked way up and a low keyframe interval and it'll look mint

File: mask.jpg (83KB, 500x608px) Image search: [Google]

83KB, 500x608px

>>57593350
>if you're not just being autistic
here's the thing, im making a program that will offer two ways of encoding losslessly. one that makes large files but goes fast. the other that makes small files but goes slow.

im very surprised to find however that going faster than my slow option is very hard...

>>57593318
>i'd figure it should always take longer to encode with lossy format since the computer then have to figure out how to best compress it
That's backwards.
It is easier to encode a lossy format because the codec has a pretty good idea what to throw away.
Lossless codecs have a harder time because they have to compress everything perfectly so that it can return to it's original state. Lossy doesn't give a shit, so long as the differences are small enough it's fine.

>>57593398
converting RGB to YUV420 is trivial and pretty efficient on cpu (but also easy to do on gpu if you're not afraid of that stuff, just not really worth it because cpu can do it so fast)

problem for you is that there's not really a container format made for it or anything that knows what to do with it if you stuff it into avi or other common containers

File: happy can.jpg (22KB, 499x320px) Image search: [Google]

22KB, 499x320px

>>57593462
i see your reasoning. though i know for example h.264 looks ahead several frames in order to determine which parts of the video won't change much over the next couple of seconds/milliseconds and then figures out what to remove from that. you'd think that all that comparing and figuring would be more demanding than what the lossless have to do: ok we have these bytes, lets stick them after each other and zip them. done! show's what i know...

>>57593474
so THAT'S why you can't play back so many codecs, it's the container format's fault

>>57592478

Lossless video doesn't exist in a digital format yet. As of today, you can only have lossless video in an analogical medium such as film.

File: Auto Wreck in Washington DC, 1921.jpg (361KB, 1200x950px) Image search: [Google]

361KB, 1200x950px

>>57593689
woah.. though what about father time, won't he cause some loss?

File: legrunners.jpg (131KB, 1280x1024px) Image search: [Google]

131KB, 1280x1024px

BY THE WAY fellas, while we're here

What's the best lossless audio codec? As in fastest.

Is it FLAC?

>>57593747

You can't have everything kike.

>>57593462
It is easier to encode a lossy format because the codec has a pretty good idea what to throw away.

I don't know which is faster because I don't have any use for lossless, but that logic is broken. If calculating what to throw away is the major bottleneck of encoding, then lossless comes out faster because lossless always knows what to throw away.

>>57593747
/fa/ asf

>>57592478
>lossless video encoding

File: stairway.jpg (207KB, 1024x680px) Image search: [Google]

207KB, 1024x680px

alright im leaving the thread now, OP out. thanks for the input

sage just in case

>>57592478
You do know that x264 and x265 support lossless encoding yeah?

https://x265.readthedocs.io/en/default/lossless.html
https://trac.ffmpeg.org/wiki/Encode/H.264#LosslessH.264