Video conversion guidance would be great

[ievi]

So my hard drive is getting filled with 1080p movies with over the top file sizes so I have decided to convert then all I'm gonna include my results and program I use, maybe there is better settings with faster results if you have better settings or advice it would be great as I have just started using this program.

Results are at bottom with stats

Program used: Handbrake 0.2.10.2.7286

Settings I use

Container: mp4

picture
- source: 1920x1080
- Anamorphic: Strict
- Cropping: Custom - top 0, left 0, bottom 0, right 0

Filters
- Detelecine: off
- Decomb: Decomb, off
- Denoise: off
- Deblock: off
- Grayscale: unchecked

Video
- Video Codec: H.264(x264)
- Framerate: same as source, Constant framerate

Quality
- Constant quality: 25

Optimise Video:
- x264 preset: very slow
- x264 tune: film
- h.264 profile: high
-h.264 level: 4.1

Audio
- codec: auto passthru


Here are some of my results

Original video
- container mp4, resolution 1920x1080, size 2.78GB, Length 31:37, data rate 11988kbps, total bitrate 12116kbps

Conversion video
- container mp4, resolution 1920x1080, size 867MB, Length 31:37, data rate 3700kbps, total bitrate 3828kbps

This is a really good result, and i saw 0 quality loss, downside it took two hours to convert

Another test same settings(Don't like the result for this one )

Original video
- container mp4, resolution 1920x1080, size 3.81GB, Length 01:19:03, data rate 6759kbps, total bitrate 6911kbps

Conversion video
- container mp4, resolution 1920x1080, size 2.19GB, Length 01:19:03, data rate 3808kbps, total bitrate 3960kbps

not sure why the file size was not a massive change like the first one but its still smaller with 0 quality loss and makes room on my drive. this conversion took about 3-4 hours maybe longer

[jagabo]

Different videos require different bitrates to maintain quality. That's all.

CRF 25 is pretty low quality. You are getting quality loss. Watch for posterization artifacts in smooth gradients, especially in dark areas. I'd leave the videos as they are and just get a larger hard drive.

[Baldrick]

You can adjust the x264 preset to ultra fast for faster encoding...but you will get much bigger output file size and I guess you don't want that.

But batch convert everything over some nights. Vidcoder might be easier if you have several files.

Or just invest in a new bigger HDD or external HDD. No quality loss!!!

[ievi]

You are getting quality loss. Watch for posterization artifacts in smooth gradients, especially in dark areas. I'd leave the videos as they are and just get a larger hard drive.

Can't really get bigger I already have 16TB, no more space in my case. Not saying you are wrong about quality loss, but I have compared both videos at exact time stamps in different sections of the video and I see 0 quality loss in comparison. If anything my conversion has less artifacts

But batch convert everything over some nights. Vidcoder might be easier if you have several files.

Or just invest in a new bigger HDD or external HDD. No quality loss!!!

I will test that program out, thanks

[jagabo]

Using the veryfast preset will give about the same file size but much faster encoding. Lower quality though.

[ievi]

Using the veryfast preset will give about the same file size but much faster encoding. Lower quality though.

Okay thanks I will test to see if quality is much different

[jagabo]

If you have a recent Intel CPU try the quick sync encoder. It's even faster. About the same quality as x264 at veryfast with the most recent CPUs.

[bulgom]

.
What's always, if not eternally, more or less difficult to set, or rather: decide, is the priority:

— results weight? (in MB, or GB, here)
— quality?
— processing speed?

I was never able to help anyone who wants, I mean simultaneously, "those three choices " at their "very best " (you bet);

"OK, OK... what's a good compromise, then? " being as difficult to answer.



Anyway, quality wise, instead of [ Constant quality ] = wrong / I meant (I confused) CBR: Constant BitRate compression, I would of course (recommend, and) test some Variable (VBR: Variable BitRate) and two-pass compression settings, in the first place:

at least, "2-pass VBR" * mode takes cares or TRIES to manage both weight and quality expectations.

Edit · Correction, above: sorry, my mistake: I did read too fast yesterday: "CBR", INSTEAD OF "CRF" (constant rate factor)! That's why I corrected: "CBR" (in dark red) — and knowing that the initial post never mentionned "CBR".

Now, instead of simply erasing, I leave in place, otherwise, Manono's sweet critic (below: post #10) would become less relevant...

I also know why I made that mistake:

(not only I hate "VFR", and "CFR" sounds close to "CRF", though it's got nothing to do here / but I happened to be struggling at the same time with "VFR" videos to convert to "CFR" – but: )

the initial post being aimed to processing speed (besides storage space), at least, I guess I understood right, reading (between the lines): 1-pass encoding.

Since I've been avoiding 1-pass for years (somewhat less now), I have a tendancy to relate it to "CBR" — and even to "CRF", by the way. In other words, although I need them sometimes, I kind of shove together (and away) most fast coding practices...

Of course, the whole debate, besides raising agressivity on several forums, is endless...

* not processing speed, though — and that, especially if you select TWO-PASS recoding... which is also highly recommended, since it's the best VBR option (quality wise);

Edit again... and that (above), I maintain, despite Manono's tag (below: post #10): "nonsense". Because, after testing AMOUNTS of settings and all kinds of advice for years, I'd be more than happy to see anyone / anything beat "2-pass VBR"! (as of november 4th, 2015 anyway; i.e.: two days or two months or years from now: I-don't-know!)

I mean, whith this goal in mind: both the best possible visual quality (I didn't say "the best quality period") AND a relatively lightweight result (in MB or GB, or MiB/GiB if you prefer ).

I don't understand all of the advanced "x264" settings, but: between "1-pass CRF" + other fast modes AND the old "2-pass VBR", even my little sister, who cares less about all that, pointed the graphical differences at once (sharp kids' eyes)...

Should I insist on one point? I guess I'd better: at the same weight in MB or GB (& on the same video), of course.

plus, undeniable 2-pass VBR advantage: it lets you predict the weight quite precisely, using a bitrate calculator, such as: http://www.dr-lex.be/info-stuff/videocalc.html

except that I usually set its "Overhead" value to "6", instead of "2", at least when I want to fit a video to a CD or a DVD (I'd rather end up with a bit too "light" a fileweight, than having to recode the whole thing because it exceeds the disc capacity ).

Now, for those who aim at processing speed above all, but equipped with very average and even old PCs, "x264" "veryfast" setting — quite lossy, take note —, still does MUCH better than the old "XviD / DivX" of the 2000 decade...

... and: a "little" question or problem just pops up spontaneously, here: why not, what about "x265" HEVC.265, then?

The point being: if I plan to recode tons of videos, that I'll keep, say... at least a few decades , knowing that "x265" yields the same quality as "x264" but between two thirds & half the weight, why not save even more storage space?..

Some answer: uncertain (future) compatibility with players, including the rather fussy standalone home + gadget devices.

OK, back to "x264": When "AviDemux" or "VirtualDub" is too slow — despite "x264" set to "veryfast" —, even a PC dated from 2006 ~ 2008 (old ~3 GHz "Pentium 4" CPU) CAN recode in real time (1 hour of video = 1 hour of processing):

using for instance the "PotPlayer" "Record video" (in fact "re-Record") tool ;

I often use it to recode (AVC to AVC), including resizing, HD & Full HD cell phone videos — that their owners or myself do NOT consider too important, of course.


The main reason why I mentionned that tool, and also two-pass VBR, is your "3700 kbs" bitrate. I suppose that, if you want both speed and quality, such a bitrate works well, even in "veryfast" or "fast" mode;

but what about your storage space requirement? Unless you recode football games on bright green lawn, with a lot of close ups + fast pans etc. (i.e. high contrast + color + fast & permanent movement),

even in Full HD, I find that bitrate quite high. I'd rather use a 2nd PC and let it grind overnight (I know, it means patience...), but: in two-pass recoding, "medium" or even "slow", and at a bitrate set between 2500 and 3000 kbs. Or even between 2000 and 2500 kbs, on standard HD + slow & dark movies.

[ My case: I often use "AviDemux" with a ".py" preset they call a "project script", quite optimized but that would still need to be improved:

extremely slow, but that lets me recode 25 FPS DVD sized movies between 876 (!) kbs and 1500 kbs only. I do NOT pretend to respect full / excellent quality: only to get relatively lightweight results, still watchable...

One exception: very high color saturation (red especially) + lots of fast movement, force me to raise the bitrate up to more or less 2000 kbs. ]

.

[KarMa]

You are getting quality loss. Watch for posterization artifacts in smooth gradients, especially in dark areas. I'd leave the videos as they are and just get a larger hard drive.

Can't really get bigger I already have 16TB, no more space in my case. Not saying you are wrong about quality loss, but I have compared both videos at exact time stamps in different sections of the video and I see 0 quality loss in comparison. If anything my conversion has less artifacts

A CRF of 25 is going to give a noticeable quality loss. I do CRFs of 26-27 for shows I record for archiving, shows that I want small and can accept quality loss. I also use one of the slow presets.

Different videos require different bitrates to maintain a given quality. If the source has low noise (film grain) and little movement, it will be small. If it's very noisy and/or action-packed it will be huge. The more random your video is, the bigger the file size will be.

The larger your video resolution the higher the CRF you can get away with. So for SD stuff I usually go below 20, and HD I usually go a bit over 20. Stuff that I want higher quality with. That's just me and everyone has an opinion.

[manono]

Anyway, quality wise, instead of Constant quality compression, I would of course (recommend, and) test some Variable (VBR: Variable BitRate) compression settings, in the first place

Constant Quality is VBR. which makes your whole post a useless waste of words.

...especially if you select TWO-PASS recoding... which is also highly recommended, since it's the best VBR option (quality wise)

Nonsense.

[KarMa]

I would only do 2-Pass anymore if I want to keep it below a certain point. Like I've made some long videos at 3.9 GiB with 2-Pass, just to keep the video below the 4GiB limit on FAT32 systems.

2-Pass makes the quality an unknown and also takes longer. While CRF makes the file size unknown but the quality is known and one less pass. I've gone back on some old posts on private torrenting sites that banned CRF because of how bad it was in the early days, but that has not been the case for awhile.

Should point out that CRF works by keeping the quality of the slow moving scenes while allowing quality loss on fast moving scenes. The idea being that it's happening so fast that you can't make out the loss. 2-Pass does this too but is more constrained when it comes to the quantizer range.

[PuzZLeR]

.
What's always, if not eternally, more or less difficult to set, or rather: decide, is the priority:

— results weight? (in MB, or GB, here)
— quality?
— processing speed?

I was never able to help anyone who wants, I mean simultaneously, "those three choices " at their "very best " (you bet);

"OK, OK... what's a good compromise, then? " being as difficult to answer.

Jagabo and I have had a debate like this in another thread.

In theory - and I'm talking in theory only, and likely at the PhD level - for a finite period of the maturity of a lossy format (like x264), you can only have two of those three choices. Only in an infinite amount of time in the format's life "cycle" can you have all three.

In practice though, today, x264 is indeed mature, and any development, or further development at this point, yeilds benefits in all three that are becoming increasingly less. This explanation is asymptotic in nature and inversely exponential.

So to answer your question, you may as well have all three today since any disadvantage of dropping one is very minor now. Or at least it certainly feels that way now.

Now my head is spinning again.

[PuzZLeR]

@ievi: Honestly, and I'm not trying to be mean. Is all this really worth it to save some HDD space? A general rule of good practice in this hobby is indeed to keep the Source while encoding with lossy methods.

Encoding is great and all, but it really should be only to satisfy a playback requirement IMO, especially more so with a lossy format. If it's to save space, fine, but not at the expense of deleting the Source - a loss of extra quality forever, and a loss you will likely regret one day.

Financially speaking, you can get an external HDD for dirt cheap today. Psychologically speaking, you can make a small corner of your back closet available to stash the Source if you find the extra HDD space unsightly.

[fritzi93]

Dunno what you're viewing these movies on but...

1) For each of the "original" videos, bitrate is already rather low for 1080p.
If they're commercial movies from Blu-Ray, they've already been compressed (re-encoded) aggressively.
And if they weren't professionally done in the first place, the low bitrate comment goes double.

2) It shouldn't take any training to see that you've degraded the quality by re-encoding so severely.
If they could be compared to the Blu-Ray originals, it should be very obvious indeed.
Which is why I wonder what is the display the before/after videos are being viewed on.

3) CRF 25? Not good enough for 1080p unless the display is quite small.
If you ever get a sizable, decent 1080p display, you'll regret re-encoding those movies.

Sorry, but that's how I see it. You'd be better off leaving well alone and getting more storage space.

[ievi]

Dunno what you're viewing these movies on but...

1) For each of the "original" videos, bitrate is already rather low for 1080p.
If they're commercial movies from Blu-Ray, they've already been compressed (re-encoded) aggressively.
And if they weren't professionally done in the first place, the low bitrate comment goes double.

I use a Asus VN247H 24" monitor to watch the movies on.
the movies i have only get released on dvd not blu-ray so i download them direct for 1080p.

2) It shouldn't take any training to see that you've degraded the quality by re-encoding so severely.
If they could be compared to the Blu-Ray originals, it should be very obvious indeed.
Which is why I wonder what is the display the before/after videos are being viewed on.

i actually see quality improvement after i compress if you want to see the before and after images i will inbox them to you, maybe its my eye site.

3) CRF 25? Not good enough for 1080p unless the display is quite small.
If you ever get a sizable, decent 1080p display, you'll regret re-encoding those movies.

maybe it will look bad on a decent sized tv, but i watch my movies on my 24" monitor

Sorry, but that's how I see it. You'd be better off leaving well alone and getting more storage space.

i have 5 hard drives all ready

[fritzi93]

the movies i have only get released on dvd not blu-ray so i download them direct for 1080p.

i have 5 hard drives all ready

Irrelevant and irrelevant. At least as it pertains to the conversion guidance you asked for.

Though it's looking like you're talking about warez.

[ievi]

the movies i have only get released on dvd not blu-ray so i download them direct for 1080p.

i have 5 hard drives all ready

Irrelevant and irrelevant. At least as it pertains to the conversion guidance you asked for.

Though it's looking like you're talking about warez.

No need to be making assumptions, I pay for my content on a monthly subscription.

The source is just not good quality to begin with that is why my conversion looks better

[_Al_]

Anyway, quality wise, instead of Constant quality compression, I would of course (recommend, and) test some Variable (VBR: Variable BitRate)

You perhaps think about constant bitrate , because from result point of view, there is no difference between Constant Quality encoding and 2pass VBR encoding. Constant Quality watches for quality as suggested, 2pass VBR watches for bitrate keeping avegare bitrate as was suggested. But choosing certain Constant quality value and average bitrate you can get almost identical videos (using x264). Or you might do it on purpose by encoding original using CQ, then calculate average bitrate from that video and encode original 2pass VBR. Compare videos.

[bulgom]

You perhaps think about constant bitrate.

No "perhaps": exactly.

I made that mistake: confusing "CBR" and "CRF", yesterday (but I know the difference ), for one main reason, that I explained, editing my post. And I agree with all the rest of your answer

+ even made another mistake, forgetting to always add "2-pass", to my "VBR" mention.

Because and at least, here, I'm positive — after... zillions of tests: in "2-pass VBR mode", I systematically get a better visual result and at same fileweight, than with "CRF" (not even talking about "CBR"). Of course, it's more or less obvious, depending on the video (high saturation, contrast, movement, image size, FPS... or not).

Anyway, quality wise, instead of Constant quality compression, I would of course (recommend, and) test some Variable (VBR: Variable BitRate) compression settings, in the first place

Constant Quality is VBR. which makes your whole post a useless waste of words.

Why not the whole forum, and moreover, the whole WORLD, while we're at it?.. Because, if we count only one micro nth of the mistakes they (& everything) contain(s), according to you, they should be "qualified" of... "useless waste"...

Anyway, since you pointed a mistake & thanks to your nice remark, I added corrections (leaving my main mistake in place, for some reason).

...especially if you select TWO-PASS recoding... which is also highly recommended, since it's the best VBR option (quality wise)

Nonsense.

There, I just added "two-pass". The rest, I maintain (+ explained, editing my post). Unless concentrating on the "2-pass" mention, that what missing, I'm still wondering where is the "nonsense"...

· I summarize / shorten "a bit" · What's difficult to set / decide, is the priority: — results weight? (GB) — quality? — processing speed? Can't help anyone who wants, simultaneously, "those 3 choices " & at their "very best ". Even "OK, what's a good compromise, then? " is difficult to answer.

Jagabo and I have had a debate like this in another thread. In theory - and I'm talking in theory only, and likely at the PhD level - for a finite period of the maturity of a lossy format (like x264), you can only have two of those three choices.

I sure agree, having experienced that since my 1st attempt to recode. All I'm able to achieve (more or less of course) at once, is: acceptable quality + lightweight results, never the 3rd point at the same time: fast processing.

So to answer your question, you may as well have all three today since any disadvantage of dropping one is very minor now. Or at least it certainly feels that way now.

I only find it "minor" in comparison to "XviD / DivX" coding of the 2000 decade (or up to ~2008). Or again, we could consider "the 3" "possible: nowadays", but only: compared to ten years ago...

Now, what I simply observe almost everyday is: many people (newbies mostly) — OK, NOT equipped with ultra powerful machines... —, complaining either about lousy quality, either about the time it takes to process an hour of video...

No wonder, since so many videos are now HD & Full HD. Also: lots of "fun" debates in perspective, on UHD / HEVC coding...

I would only do 2-Pass anymore if I want to keep it below a certain point.

Well, to me at least, it "seemed" to be ONE main point, of the initial (& complex) question:

So my hard drive is getting filled with 1080p movies with over the top file sizes (...)

__________________

2-Pass makes the quality an unknown

Yes! I noticed that. Therefore, it HAS its disappointing sides ALSO. Nevertheless, when speed is not a priority — and as I insisted by editing my post —, so far, I haven't found better quality + lightweight than in "2-pass VBR".

The idea being that it's — artifacts — happening so fast that you can't make out the loss.

I sure wish the idea became a reality! Several of those losses happen fast enough, or on difficult to notice graphical elements, OK...

... while MANY others remain too visible. I'm not talking about me, sticking my nose to the screen and behind a magnifying glass, but about absolute average people, who have many times pointed out quality loss: in fast movement, and sometimes on dark zones (pixelated instead of as smooth as on the original DVD, for instance)...


.

[PuzZLeR]

You perhaps think about constant bitrate , because from result point of view, there is no difference between Constant Quality encoding and 2pass VBR encoding. Constant Quality watches for quality as suggested, 2pass VBR watches for bitrate keeping avegare bitrate as was suggested. But choosing certain Constant quality value and average bitrate you can get almost identical videos (using x264). Or you might do it on purpose by encoding original using CQ, then calculate average bitrate from that video and encode original 2pass VBR. Compare videos.

...after... zillions of tests: in "2-pass VBR mode", I systematically get a better visual result and at same fileweight, than with "CRF" (not even talking about "CBR"). Of course, it's more or less obvious, depending on the video (high saturation, contrast, movement, image size, FPS... or not).

Bulgom, I really would like to know how you're testing this. Are you using the same settings for each?

From my eyes, with x264, I don't see any, or any significant, difference between CRF and 2-pass VBR at the same bitrate. And this has been debated to death, even some 8 years ago, and there has been no proof, or any significant proof either way more than a percent or less, that given the same bitrate CRF and 2-pass VBR gives any better quality ceteris paribus.

Unless something's changed in recent years, I'd like to know.

· I summarize / shorten "a bit" · What's difficult to set / decide, is the priority: — results weight? (GB) — quality? — processing speed? Can't help anyone who wants, simultaneously, "those 3 choices " & at their "very best ". Even "OK, what's a good compromise, then? " is difficult to answer.

Jagabo and I have had a debate like this in another thread. In theory - and I'm talking in theory only, and likely at the PhD level - for a finite period of the maturity of a lossy format (like x264), you can only have two of those three choices.

I sure agree, having experienced that since my 1st attempt to recode. All I'm able to achieve (more or less of course) at once, is: acceptable quality + lightweight results, never the 3rd point at the same time: fast processing.

So to answer your question, you may as well have all three today since any disadvantage of dropping one is very minor now. Or at least it certainly feels that way now.

I only find it "minor" in comparison to "XviD / DivX" coding of the 2000 decade (or up to ~2008). Or again, we could consider "the 3" "possible: nowadays", but only: compared to ten years ago...

Even with the later start, the development of x264 has been longer than that of DivX/Xvid, and much further into its maturity since it seems that development of DivX/Xvid, or MPEG4-ASP in general, has stopped or seriously slowed down in recent years, which is why choosing 2 out of 3 choices with x264 is so much easier now - and even easier than it ever was with DivX/Xvid.

Personally, I just drop the speed option now with x264. Since the gap between using slower settings are not much slower than faster settings than they were a decade ago (remember "insanity" or "insane" mode years ago? - THAT was slooooooowwwww...), and since slower settings are not nearly as slow as even the fast ones were a decade ago, it really does feel like I have all three choices today.

Yes, this is all relatively speaking.

OK, there are ridiculously slow settings with x264, even today, if you want them. But, again, it doesn't feel like an option either since the resulting quality is also much more minor here than it ever was, probably less than 0.5% now, between slow and super-slow settings. Such super-slow settings seem to be there for some "classic" feel or "retro" mode now more than anything IMO.

[PuzZLeR]

]i actually see quality improvement after i compress if you want to see the before and after images i will inbox them to you, maybe its my eye site.

You will never see a quality improvement with a lossy format after an encode - even if you multiply the bitrate a million times. The best you could hope for is something that looks as good, or almost as good, to the human eye - but there will be degradation.

Sure you can make it look better, such as with a filter, or with de-interlacing, etc, depending on Source, but again, there will be loss.

Or, as an example, maybe the blurring of some detail, or a softer look, can be appealing to some instead of a more grainier sharper source. This, again, is just taste, and doesn't detract from the fact that there is still loss.

[_Al_]

bulgom - CRF vs. 2pass VBR ,
try to test it this way -> encode test video using CRF, you get certain volume, then calculate average bitrate from that result. Then encode it again using 2pass VBR. Same settings must be kept. You better use command line, just to be sure. Different encoders using GUI, might set something differently behind your back.

same settings, same final volume, then compare those , this is the only way to test it

[PuzZLeR]

bulgom - CRF vs. 2pass VBR ,
try to test it this way -> encode test video using CRF, you get certain volume, then calculate average bitrate from that result. Then encode it again using 2pass VBR. Same settings must be kept. You better use command line, just to be sure. Different encoders using GUI, might set something differently behind your back.

same settings, same final volume, then compare those , this is the only way to test it

I've personally stopped using GUIs because of this very reason - it feels like something is going on under the hood in many cases. And it could be possible that a GUI could be doing something very different with a CRF encode that it does, or doesn't do, with VBR 2-pass. And I remember one particular GUI (won't say which, but it wasn't HandBrake) would give me fits with all its tabs, and when I'd change something on one tab, I wauld catch it changing something on another.

I use to love HandBrake though, and would still recommend it to the CLI-averse, but I'm very happy just using x264's straight-from-the-commandline method now, and I'll agree that this is the only lucid way to truly test CRF vs 2-pass VBR.

[bulgom]

.
@ PuzZLeR & _Al_

OK, took note, + will have to test again.

Yes, I amost always tested using GUIs — and did suspect also, like you do, more "stuff" to happen to my encodings than strictly what I wanted.

What GUIs, by the way? Several, if not many, including "XmediaRecode" ("in its time" / but too many problems...). Mainly: "VirtualDub" and "Avidemux".

Of course 1!, comparing encoding modes (or trying ), I always used the same settings: I mean: as much as I could (and should I insist?.. the same video, length, GUI, etc.; i.e: though being a lamer, I'm not totally crazy *)

[ * yet... ]

Of course 2: I totally agree with the fact that: there will BE quality loss. Although your insisting warning concerns Ievi and not me, I found the arguments (or "sub"arguments) interesting (such as blurring a little might "feel" better on grainy video, etc.). And don't misunderstand me, here: I really think that insisting — in that case — is essential.



.

[PuzZLeR]

.
@ PuzZLeR & _Al_

OK, took note, + will have to test again.

Yes, I amost always tested using GUIs — and did suspect also, like you do, more "stuff" to happen to my encodings than strictly what I wanted.

What GUIs, by the way? Several, if not many, including "XmediaRecode" ("in its time" / but too many problems...). Mainly: "VirtualDub" and "Avidemux".

I don't want to point out a GUI in particular, even the one that gave me fits with all its tabs since I do like the author - and he himself admitted it.

The differences you're experiencing is actually more rule than exception IMO with GUIs. Not that they're not built well, but they seem to go on auto-pilot too much to simplify and optimize the process. The purists will notice the differences.

Right now I just run it through the commandline and don't bother with a front-end. This way I know for sure what's going on. And, as ironic as it may sound, it's actually easier. Once you set up a couple of batch files for your purposes it's so simple, and even faster.

Try a CRF vs 2-pass VBR, with the same bitrate, straight from the commandline, with minimal settings. I doubt you'll find much of a difference in the results.

Of course 1!, comparing encoding modes (or trying ), I always used the same settings: I mean: as much as I could (and should I insist?.. the same video, length, GUI, etc.; i.e: though being a lamer, I'm not totally crazy *)

[ * yet... ]

Yes, you may be going crazy. A couple of GUIs actually made me feel that way, so I wouldn't say it's your fault.

It's so funny that, over the many years, we always go back to the commandline to retain our sanity...

Of course 2: I totally agree with the fact that: there will BE quality loss. Although your insisting warning concerns Ievi and not me, I found the arguments (or "sub"arguments) interesting (such as blurring a little might "feel" better on grainy video, etc.). And don't misunderstand me, here: I really think that insisting — in that case — is essential.



.

I pointed this out because many (mostly bad) encoders sell this to you in that way - the results are "nice and clean". That's like washing your carpet so well that you actually remove the imprint on it. Yes, "nice and clean".

[bulgom]

.
Hi

Please find attached
"x264__VBR-2-pass_vs_CRF_simple-test.7z":

recoded in command line mode exclusively. The command lines are enclosed, and as basic as can be, like you suggested — "except", may be, the "veryslow" option,

as I consider that, if it's going to be slow, it might as well be REAL slow! Otherwise, I'd use CRF, systematically (since WAY! faster).


Besides an obvious visual quality loss due to "CRF" in comparison to "VBR 2-pass veryslow", the """conclusion""" is simple:

"CRF" does AS GOOD as "VBR 2-pass veryslow" on... what's EASY to recode! No doubt! So you are... half right,

but: NOT on difficult zones.

Enclosed: the original DV sample (interlaced...), + the recodes, + the batches and even "x264" codec (so you'll know precisely what I used);

plus a short side by side (at 6000 kbs, that one) / please set your player to "loop" and watch the grey pavement, at bottom... which happens, in THIS video AND movement anyway, to be tough to grind!

When I give THAT sample to any codec and/or UI, I know at once if it's worth keeping or what. Even a dead mole would...

______________________

If you wonder about my lousy bitrates choices ("CRF 27"...) or why I did not try to respect the original:

the reference I used here is: 90 mn of DVD sized video to fit on a single 700 MB CD. And those are the necessary bitrates, in order to add ~128 to 160 kbs AAC audio (though I try to stick to 192 - 256, rather & for two-channel audio).

+ "x264", and even "Xvid", SEEM to do a better job on longer videos than on one-minute tests.


Please note also:

— instead of strictly the same bitrate for each test, and although they are almost identical, I aimed at: the same fileweight in the end;

— and that I'm... a sport , since "MediaInfo" reports 879 kbs on "your" "CRF", while it reports 848 and 851 kbs only on "my" "VBR 2-pass"!

Had I applied an identical bitrate, like you suggested, the "VBR 2-pass" result would be even better, by a tiny bit.

What "MediaInfo" also reports, interestingly, is the maximum bitrate: much higher in the case of "VBR 2-past than with "CRF". No surprise. It proves that "x264" was smart enough, while 1st passing, to detect the trap of the gray pavement vertical pan, and to allocate more bitrate to that tough moment (otherwise, I'd wonder why I'm in favor of two-pass mode )...

.

[sneaker]

- You compared CRF preset medium against 2pass preset veryslow. When people say CRF is at least as good as 2pass they are of course talking about otherwise identical settings and bitrate.
- On short samples 2pass bitrate distribution may be sub-optimal. This means some frames get much more bitrate than in CRF, others much less. If you look at the frames that got more bitrate it may give the false impression of 2pass being better overall (or it may coincidentally actually be better on some samples). This can be different on other samples where CRF will have the advantage and does not matter for movie or TV episode lengths. It is not an indication of 2pass superiority. They are based on the same algos as has been stated by the author of the respective x264 code multiple times. According to him CRF should actually have the slight upper hand because it does not have to constantly adjust the bitrate to hit the target.

[_Al_]

There is no --preset veryslow in CRF command line. Settings must be the same.
Default setting is --preset medium, which in the end having same filesize causes video to be a bit less perfect.

Also you should include --bff in all command lines.
Also you should set buffers in real world like --vbv-bufsize 15000 --vbv-maxrate 15000 or something, but for test purposes I guess it does not matter

[bulgom]

.

bulgom - CRF vs. 2pass VBR ,
try to test it this way -> encode test video using CRF, you get certain volume, then calculate average bitrate from that result. Then encode it again using 2pass VBR. Same settings must be kept. (...) same settings, same final volume, then compare those , this is the only way to test it

There is no --preset veryslow in CRF command line. Settings must be the same. Default setting is --preset medium, which in the end having same filesize causes video to be a bit less perfect.

- You compared CRF preset medium against 2pass preset veryslow. When people say CRF is at least as good as 2pass they are of course talking about otherwise identical settings and bitrate.

"People"? Which people? Advanced, if not experts, you mean... Meanwhile, I'm obviously aimed at average users — who, btw, don't mention bitrate often, but: fileweight; that, yes!

Plus, both modes don't accept identical settings anyway...

Bulgom, I really would like to know how you're testing this. Are you using the same settings for each?

I'm not using the same speed settings — and that, not by mistake, but on the precise purpose of... what? As realistic as possible an answer to ordinary users (like myself; with the only difference: I'm able to wait).

Hi

So — and above all — why should one use the same speed settings? It's only relevant to specialists, not to average users.

This forum is open to anybody; therefore, rather than a lab or purist's approach, why not see from the average user's point of view (?)...

i.e.: simply use each mode at its — very own — most interesting setting(s).

Otherwise, I find any test quite unfair. Although 2-pass VBR can be set to speedy, it's "somewhat" contradictory, since its necessary 1st pass requires... a good dose of patience anyway.

"Plus", from average users' point of view again, 2-pass VBR being handicaped, why add the "--preset medium" extra and obvious handicap on visual quality?..

For a same resulting fileweight, I'm only or simply talking about improving visual quality — i.e. avoiding certain artifacts:


Now, whatever the tool, and that is of course: regardless of its settings other than the fileweight we get, there IS (or happens to be) ONE tool (mode), which proves its ability to avoid certain artifacts, or at least do better, on those problems.

If the conditions were drastic, OK: one test would be enough to forget it all, & no debate, period. But, if we take the case of users:

— gifted with some patience ("waddya mean 'barely-.001%-of-the-population-nowadays?'" ),

— who care, about some of their videos anyway, for the best possible H.264 * quality,

— plus who own a 2014 ~ 2015 average "i3 or i5" (not even an "i7"),

well, a solution exists.
And only for the sake of one particular trend — generalized impatience —, we should bash it?..

* One may argue — and personally, I do — : "Best quality & real light weight? HEVC!" (since it applies to std defs. as well)...

But, in 2015, that's precisely drastic, not far from a typical lab situation. Assuming slowness as acceptable, the lack of compatiblity with a wide range of players is not acceptable anyway. Same (& main) problem with "VP9 / webm"...

But... "OK" & clear, you all (all?..) have a tooth against 2-pass VBR, it's a fact;

only, if anyone's able to avoid the killer artifact of my little test (post #26 attachment, if you can spare 10 seconds) using any other + faster x264 mode than 2-pass VBR — plus end up with the same fileweight ** of course — please believe me, I do subscript... I mean: at once!

** May I insist on this?: the least to say about the fileweight criterion, is that it's NOT a "lab's or purist's" one! Among countless requests, including Ievi's initial post, here's a brand new one (Nov. 8th, 2015 = today):

New here... howdy, folks! (...) I've collected a massive library of video (~6TB). I'm tired of buying new hard drives (...)

I'm "afraid" it's, not in all — but in many cases... as simple as this:

Should point out that CRF works by keeping the quality of the slow moving scenes while allowing quality loss on fast moving scenes.

On processing duration:

Such super-slow settings seem to be there for some "classic" feel or "retro" mode now more than anything IMO.

"Well"... although far from being even good, the sample I posted — veryslow vs. medium — denotes clearly way less visible "artifact-ory". Not much subjectivity, there! And note: "slower = better", just like "reknown brand name & logo on central units = more reliable", among other fantasies, no, I don't buy.

Personally, I just drop the speed option now with x264. Since the gap between using slower settings are not much slower than faster settings than they were a decade ago (remember "insanity" or "insane" mode years ago? - THAT was slooooooowwwww...), and since slower settings are not nearly as slow as even the fast ones were a decade ago, it really does feel like I have all three choices today. Yes, this is all relatively speaking.

Yes, QUITE relative! On one side we have the above opinion, that I easily agree with: today, slow is way faster than slow ten years ago (yep, I remember "DivX insane" setting). Contradiction goes on, though... or more probably, today's average users never experienced the 2000 decade slowness; and that's the other side: the trendier than ever expectation: "zero waiting" becoming a real (if not wild) obsession.

bulgom,
king of AVERAGE users & even lamers', kingdom (at your service (if I could))

.

[sneaker]

Otherwise, I find any test quite unfair. Although 2-pass VBR can be set to speedy, it's "somewhat" contradictory, since its necessary 1st pass requires... a good dose of patience anyway.

Then set CRF to --preset veryslow as well...