Thread 106240096

So now that 4chan allows MP4 with H264 uploads, has anyone figured out how YIFY managed to cram 1080p movies into just 2Mbps with good quality? I found a 24Mbps (similar to a raw blu-ray) 1080p 30 fps test file with lots of detail and zooming which is difficult to compress.

https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_30MB.mp4

I made MP4 related with the following. The veryslow preset and 2 pass mode seem to be the bare minimum for a YIFY 1080p 2Mbps encode.

ffmpeg -i in.mp4 -c:v libx264 -b:v 2M -preset veryslow -pix_fmt yuv420p -an -y -pass 1 -f null -
ffmpeg -i in.mp4 -c:v libx264 -b:v 2M -preset veryslow -pix_fmt yuv420p -an -y -pass 2 out.mp4
ffmpeg -i out.mp4 -i in.mp4 -lavfi ssim=stats_file=ssim_logfile.txt -f null -

The important ssim score is the one that says ALL and I got this for MP4 related, which is pretty terrible. Meaning there must be something else YIFY is doing in addition to veryslow + 2-pass

SSIM 0.942575

Have you ever considered that yify looks like shit and they frontload their encode quality (commonly used tactic for public rippers), which gets progressively worse as the video goes on?

More on SSIM but tl;dr, good quality video = ~0.975


>Well, a colleague recently pointed me to an article entitled SSIM-based Video Admission Control and Resource Allocation Algorithms published by multiple researchers from the Department of Information Engineering, University of Padova, Italy. The article contains the table copied below, which maps SSIM scores to mean opinion scores, which are subjective ratings. These scores were established in yet another article, available here. As you can see, scores above 0.99 should look perfect, while scores in the 0.95 – 0.99 range would indicate the presence of “perceptible but not annoying” impairments. I have a project now that involves SSIM scoring, and these data points are definitely useful; I hope you find them useful, too.

https://streaminglearningcenter.com/learning/mapping-ssim-vmaf-scores-subjective-ratings.html

>>106240125
Yeah, there's some bad rips and it makes sense because they're limiting themselves to 2Mbps which may not be enough for some movies but most do achieve good quality. Not "pixel perfect, whoah I can't tell this video apart from the original at 400% zoom!" quality but just good quality in general. Which is pretty impressive considering H264 is a video codec from 2003 and a raw 1080p blu-ray uses 20+ Mbps which translates to more than 90% file size reduction for a small hit in quality. Obviously modern video codecs like AV1 are much much better but that's going on a tangent and not what this thread is about.

Anyway pretty cool that a 2003 video codec can allow you to store 100+ 1080p movies on a 256GB flash drive after 2 decades. I think.

2000 kbps for video + 192 kbps for audio = ~2,200 kbps / 8 = 275 KB per second
275 KB per second x 60 = 16500 KB per minute / 1024 = 16.1 MB per minute
16.1 MB per minute x 120 minutes or 2 hours = ~2000 MB or 2GB
2GB x 100 = 200 GB

>>106240263
At the end of the day bro wtf are you even talking about, and why are you giving a fuck about yify garbage, not proper x265 encodes of at least 8-12 mbit.

>>106240125
Yes, but I doubt it.

>>106240096 (OP)
Never got into H264, poked around for a while while AV1 was gaining traction.+
You're missing
>keyframe/gop sizes
>degraining, denoising
>picture entropy
The average is 2Mbps for 90 minutes runtime.
You're using a 30s detailed proof-of-concept-desgined clip for this, that's not the same benchmark as motion picture.
I mean, you're not even considering frame rates, 30 fps is already 125% more pictures uncompressed alone.
Films set in space or otherwise visually monotone settings (Star Wars V) will be more tighter compressed than highly entropic visual ones, like Ep. IV or VI.

It's an artform itself, encoding...

>>106240314
>30 fps is already 125% more pictures uncompressed alone
Eh, 25% more, it's 125% compared to the 24000/10001 = ca. 23.976 fps.

Nub :P

I found this in the ffmpeg wiki, so this must be a 3rd component of a good quality 1080p YIFY H264 rip.

>You can optionally use -tune to change settings based upon the specifics of your input. Current tunings include:
>film – use for high quality movie content; lowers deblocking
>animation – good for cartoons; uses higher deblocking and more reference frames
>grain – preserves the grain structure in old, grainy film material

>>106240308
Because optimizing an ancient video codec to compress 1080p movies to less than 10% of their original blu-ray file size with good quality is pretty cool man. I'm trying to focus on the technological aspect of all this.

>>106240314
Thank you, I always suspected this was never going to be a walk in the park and that most people were talking out of their ass when criticizing YIFY technologically-wise.

MP4 related used -tune film but obviously this didn't improve much so trying the animation one next.

SSIM 0.943876

Just say you're a Sri Lankan poorfag with nothing but a 12 year old laptop. I can't imagine any other kind of reason why someone would want to decipher h264 instead of moving on to x265 in this day and age.

>>106240371
>most people were talking out of their ass when criticizing YIFY technologically-wise
They are very good with x264.
They've been spotted with x265 encodes, mostly for 4K (fun-fact: That's also the specified codec for 4K Blurays, for 1080p it's H264), and the art-form is there a step higher, because you also have to transfer colorspaces.
If you watch H265 with that one new colorspace name that escapes my mind, it will look 'bleak.'
VLC on Windows did not have a default transfer function, meaning you got desaturated 4K if you just played the remux.

Video and codec technology is incredibly complex, retards are here arguing about mp4 vs. mkv, completely oblivious to the fact they're both containers, not codecs (which is worth debating in and by itself, but the tards are discussing which has 'better visual quality,' not understanding that that's the codec's credit).

It *is* a rabbit hole.
Have lots of time or be ready to let go and give up.

>>106240454
>12 year old laptop
probably older than that, I suspect, or he's looking to sell compressed movie packs on DVDs for some extra cash

>>106240314
>>106240329
Interesting, I didn't consider the fact that most films are shot in 24 FPS. I'll up my bitrate to 2500k to compensate then. This 10 second clip may not be what a whole movie might look like but it is especially difficult to compress so I still think it's relevant. Besides I'd have to leave my PC encoding overnight to encode a whole movie with the veryslow preset so this is much easier and more practical to test too.

At 2 Mbps the animation tune seemed to do much better, barely. But yeah 2500k bitrate is next to compensate for 25% more frames per second.

>>106240454
Good for you but that's not what this thread is about.

>>106240463
*gulp* I just opened up a wall of text with ffmpeg -h encoder=libx264

OH GOD that's a lot of fucking parameters...

>how is yify so good
It isn't and YIFY encodes have never been special
>remove grain
>fuck the colors
>destroy darks and dark contrast and constrast detail
This is a YIFY compared to a ~7Mbit x265, not even the 60gb source
YIFY has never been good because its impossible to get good quality from 2mbit

>>106240314
>Films set in space or otherwise visually monotone settings (Star Wars V) will be more tighter compressed than highly entropic visual ones, like Ep. IV or VI.
Every noob can understand this when a 4K completely black picture gets saved to a png that's less than 1K in size or something.

Video goes a step further: How many pixels change from picture to picture?
Boom, you should now understand what a 'keyframe' is.

If you have a video of some dude talking into a camera, without any scene changes, you can safely go for, I don't know, five times the usual keyframe setpoint.

Shit like that, like I said, it's an artform.

>>106240454
You have a point, x264 is nice for learning, but you may want to go straight for AV1, or I guess, VVC?
(just don't go all pixDAIZy on image formats, what the fuck was that, man)

>>106240463
>Avisynth
>QTGMC
Yes, I love slow ass encodes. No really, I've used QTGMC and it's the best, but painfully slow. MCTD should be on that iceberg as it'll cripple pretty much any CPU.

>>106240577
>Besides I'd have to leave my PC encoding overnight to encode a whole movie with the veryslow preset so this is much easier and more practical to test too.
Other way around, go for something that'll work fast to test your settings with a veryfast preset.
Note the changes, but keep in mind that these will not linearly translate to veryslow.
Once you got your general parameters down, then leave it running once overnight at the slow preset.

I had JSON files and Python scripts at the end, good luck, anon.

Okay here's the revised 2 pass with the increased 2.5 Mbps bitrate to compensate for 30>24 FPS and animation tune for this kind of content. It would still yield a still acceptable 2.4 GB file size if you come across 30 FPS movies. Only 90% smaller than the 24 Mbps but dam that's still pretty cool. Also figured out how to use code tags this time lol.

ffmpeg -i in.mp4 -c:v libx264 -tune animation -b:v 2500k -preset veryslow -pix_fmt yuv420p -an -y -pass 1 -f null -
ffmpeg -i in.mp4 -c:v libx264 -tune animation -b:v 2500k -preset veryslow -pix_fmt yuv420p -an -y -pass 2 out.mp4

ffmpeg -i out.mp4 -i in.mp4 -lavfi ssim=stats_file=ssim_logfile.txt -f null -

SSIM 0.955064

HOLY SHIT we have crossed into the good quality threshold. Still a long way to go for 0.975

>>106240591
Okay, but is that 4x the detail for 4x the size?
No, if you ask me.

>>106240454
>>106240610
>You have a point, x264 is nice for learning
Ah, wait, it's for posting here!
derp
>>106240659
Nice, that's some insane quality I'm getting here on 4chins, shit, nigga.

>>106240659
Oh yeah, you know about the intricacies of ffmpeg's parameters, i.e. order DOES matter, yes?
Might be good practice to prepend -an before -c:v, just to be safe... it might become relevant once you start using the -map parameter as well.

>>106240675
I picked a shot-on-film with real grain example for a reason.
Grain -is- part of critical detail for a film video. You can't just smooth-average it away.
I consider the example immeasurably higher quality than the yify.

>>106240814
Those are all valid and fair points.
I have an own set of movies, ehhh, pardonez-moi, monsieur, 'films'! where it could be considered a crime to view them in YIFY quality, yes.
Is... Dodgeball (2004) one of them?
Well, for me, probably not.

>>106240096 (OP)
>retards STILL Arguing over AVC like its the be and end all when VP9 exists and has for years
VP9 is for quality and longer content
mp4 is for replacing VP8(complete dog shit) as a fast encoding method, not for quality

>>106240463
regarding your image, I dove into that hole and watched a fuck ton of videos and then stumbled on a sony vhs/dvd recorder (and then stumbled on ANOTHER one, both working well) and was content. Cheap as hell too.

>>106240463
>yify
>x265
There's a YIFY for x265 as well (or already was, once YIFY started).

AV1 is still open, I think, but I haven't been keeping up the past two years.

>>106240982
Aren't you curious how YIFY made such an old video codec achieve relatively good compression efficiency for high resolution video? Also while modern video codecs do what they're supposed to do they require newer hardware which not everyone can afford .VP9 will probably become the new H264 around 2030 but until then let's keep beating the dead corpse of H264 a little while longer!

OP here: I'm giving up. I tried changing ref/bframe count and fucking with the psy/trellis stuff but none of that even made a dent. The veryslow preset also seems eek out the practical limits of H264 compression efficiency as using placebo improved my SSIM score very little and was like 10X slower.

SSIM 0.955608

There must be some hidden spooky esoteric -x264-params that YIFY might have used that we all don't know about but given what >>106240591 posted it does sound like they cheated by making 1080p video easier to encode with something like HQDN3D at the cost of destroying grain and fine detail.

>>106241451
key / reference / b frames are useful when not much is moving, like an actor speaking and standing in place during a static shot. Doesn't work for anything in motion. I know its more complicated than this, but basically a 2-frame "blend" at 24fps is 40+ millisecond of "hang time" which would create blurring and blocky transitions.