If your test gives you distinguished result for almost same average at the end, your setting was not the same or you might judge scenes because you do not trust CQ and your brain computes it in that way, that's normal
Also, you insist to get 4GB, so use 2pass, end of story, I tried (or others) to sway you towards quality encoding, which seems only logical, kind of,
basically you do not care about result, not caring if movie has grain or not, if it is action or not, you simply want to encode to 4GB. No sense whatsoever in it. Using about CRF 25 and having prelonged discussion about quality, I cannot understand that. CRF 25 gives you bad results, dark scenes , gradients would not look much good, so why this elaborate testing in the first place.
You should resize to 1280x720, use CRF 18 at least, perhaps even 17, keep grains in it, and you come up with movie about 4GB on average.
You can use this statistic outcome for CRF25 if you insist without resizing, just encode 10 movies and see the average volume for your movies. You know make it more like a logical factory, not some press factory that presses whatever content into the same box.
+ Reply to Thread
Results 31 to 60 of 61
-
Last edited by _Al_; 2nd Oct 2015 at 15:56.
-
Well, people said run tests and see for myself... I'm just reporting the results. CQ at 4GB didn't look as good as CBR at 4GB. Only setting I changed, was to click CQ and moved the slider to 25... nothing else changed.
I have better than 20/20 vision, I have a diploma in art, and a second in design, and I'm a photographer... so when it comes to picking out quality differences, I trust my eyes.
As for not caring about end results... where'd that come from? If I didn't care, I wouldn't have started the thread, nor would I be be mentioning film grain, I'd simply type in 4GB and hit encode.
Basically... I know CQ is supposed to be better, and I know why... but, I don't see it. I ran another encode at CRF22... which takes as long as 2-Pass CFR essentially, and the video looks just as good as my 4000kbps preset... but, now bloated up to 6.36GB.
You said so yourself... "CRF 25 gives you bad results"... but the file size was the same as my preset, which gave good results... and again, all I did was take my preset, and switch from "Avg Bitrate" to "Constant Quality" set at 25.
I'll probably play with a bit more, I have 2 other source files on my system right now... but, as another user on here said, "If you are still of the user category that has substantial size constraints, you are better off using 1 or 2pass VBR. Hands down.". -
I'm trying to pass on this:, you really are not scientific at all, trying to put ANY video into same space, you can test days, weeks, and still not be consistent at all, I am not sure if you understand, you do some test, but with different movie, different scene, you get something else ... and nobody knows what you encode while talking about this, this is worse than academic, it is unscientifically academic so to speak
, not sure what is the polite correct for this one ...
i think CBR can look better as oppose to CQ in some scenes getting same volume, it kinds of reminds me internet stream encoding, comparing lows and peaks, where that CRF was saving some (valuable) bandwith (ask anyone who streams from server they have data on, but you try to do the same basically) , those low bitrate scenes encoding video where there is not enough bitrate, because CRF distribute even less bitrate for low light, gradients etc., but it might happen where there is not enough bitrate selected in the first place
Yes, if there is limit for the size, use 2pass VBR. No way of persuading you to not do that.Not sure if you understand that you can get 4GB per movie using CRF where statistically you can get average close to 4GB, but not to encode strictly to 4GB every movie.
-
I would agree to _Al_ that there may be differences in constraints between 1-pass CRF (less restricted) and 2-pass VBR (possibly more restricted by VBV limits).
Please note also (because you mentioned photography): There are differences in perceiving still pictures on one hand, and moving pictures on the other. Rating quality of moving pictures should not be done by looking at magnified stills; video codecs often use psychovisual features which may let few parts of single frames look worse, but you won't notice that a lot while the movie plays with normal speed, so the movie in general may look better despite few areas worsen quality metrics for stills. -
Originally Posted by THRobinson
This is actually a debate that died already almost a decade ago with x264. (More like maybe 8 years.)
Many ran tests over the years, and no one has proven that 2-pass had any improvement over CQ given the same bitrate, ceteris paribus. I can't remember what tests were done (PSNR/SSIM/ or just plain frame-by-frame comparisons - you can search for yourself). All tests showed - at best - maybe less than a quarter of a percent of quality in favor of 2-pass, while others showed an advantage for CQ.
Some, including developers from HandBrake, tried to develop an algorithm that would quickly determine a result from CQ, and input that bitrate into 2-pass, but all that was scrapped when it proved rather unnecessary.
And speaking of ceteris paribus, I would bet, as others mentioned, that you're not using the same settings with CQ as you did with 2-pass, which appears as if CQ is lower in quality at the same bitrate.
EDIT: I was using the expression "Constant Quality" or "CQ" generically here, which is similarly --crf with x264.Last edited by PuzZLeR; 7th Oct 2015 at 10:38. Reason: Explanation for CQ or Constant Quality.
I hate VHS. I always did. -
Yes indeed. It's a concept that is hard to understand among those starting out. "You mean it controls quality?" "How the heck does it do that?"
I was a Mod in the old DivX forums (good times), and every week or so we'd be re-explaining this concept to a new member who couldn't fathom it, and almost always assumed, at least initially, that CQ would bloat the bitrate when only the opposite was true.
But it's all physics really how CQ, and even video compression, works (ex: signal processing).
EDIT: I was using the expression "Constant Quality" and "CQ" generically here, which could be similarly --crf (x264), CBR (CCE), target quantizer (DivX/Xvid), or CQ with HCenc.Last edited by PuzZLeR; 7th Oct 2015 at 10:39. Reason: Explanation for CQ or Constant Quality.
I hate VHS. I always did. -
Everyone knows that DVD's or BD's could be encoded scene by the scene, at least it should be, ..., so then we proceed to encode our videos or movies thinking: "I'm not sure, but there is a setting somewhere on the web, for x264 or 2265 that takes care of this and that video". There is , but for a scene, type of video, cartoon etc., it should be approached individually. Cartoon have similar going so perhaps one can decide what to do with it, and some go to the extremes with ref frames etc to compress it to the limit of that encoder, despite they limit devices that can play it.
As for videographers or home users, ..., take a wedding video for example, video is encoded nicely and then low light dancing scenes look like a crap, so it is proceed to encode again because it supposedly was not right setting, but it was, just those low light scenes, graphical designs, need different settings. Some proceed to encode CBR 25Mbit and they are done for, just to be sure and be covered.
So why not to approach it in the same way, using CRF and zones, first pass some CRF 18 (or whatever you know that for regular daylight scene, your camera is just fine) , look at the scenes in living room (you should watch it like that anyway, there is always a bad cut or whatever, before final delivery) , and then run it again with cranking up bitrate just for particular zones, all you got then, is two passes, - VBR 2pass does just that anyway. This approach makes sense, every scene has bitrate that is needed, no magic wand needed, no guessing etc.
About encoding a movie, well, again everyone looks for miraculous setting. But again, you can do a hell of a job, even choosing about right CRF, but result could be garbage in some scenes. Take ExMachina for example. You encode it right, but those scenes with power down look just pitiful. Full of banding. So you'd need to encode it again using zones. That takes time. No wander people download movies like that because they encode it always better if that approach was used. There should be some www.encodemoviewithzones.orgwhere some zones should be published so we can back up a movies and do it just right first time. You know like subtitle servers, so the same for actual video, to help it encode. With all that fluff, stars, likes etc.
So someone does not have to visit sites with those illegal downloads where mediainfo for those encodes are published and fish it out of there.
Hopefully with x265 and 10 bit or higher this is going to be a much less or no problem ...Last edited by _Al_; 6th Oct 2015 at 16:24.
-
Don't confuse "constant quantizer" with "constant rate factor" mode. CRF is probably obviously better than CQ because scenes with little detail and motion can reach the rate factor threshold already with a slightly worse quantizer, without harming the visual impression too much. (One example: Why waste QF ~20 on a completely black "cliffhanger" pause when QF >40 would be sufficient?)
I remember that the 2-pass mode is designed so that the statistics from the 1st pass help calculating just the CRF value which will create the desired target size as close as possible; the 2nd pass is in fact a CRF encode with auto-calculated threshold. Therefore 1-pass CRF and 2-pass VBR can't differ remarkably. At most in details when the encoder makes use e.g. of the MBTree cache or the stats file as a guide of the bitrate limits. -
Just as a note, with "CQ", I was referring to "Constant Quality" generically in my posts, not particularly "Constant Quantizer", which would be at the encoder level. I did apply an EDIT below each of them. I was discussing a quality centered approach in comparison to a bitrate centered approach.
And "constant quality" could be quite different regarding encoder and settings, such as --crf (x264), CBR (CCE), target quantizer (DivX/Xvid), or CQ(Constant Quantizer)/AQ with HCenc, and with zones and max bitrates, buffers, etc. maybe to serve a standard, such as DvD, or game system, mobile, etc. This is a very broad topic actually.
But my point is still that without any form of constant quality mode, an encoder is useless IMO.Last edited by PuzZLeR; 8th Oct 2015 at 10:42.
I hate VHS. I always did. -
To the OP : one method I used a few months ago when I had size constraints for a long video which I wanted to share on DVD-R (cf. this thread) was to use the Avisynth command "SelectRangeEvery". For instance :
SelectRangeEvery(7500,250)
will select a range of 250 frames every 7500 frames (that's 10 seconds every 5 minutes for a 25FPS movie). You can adjust that to get a more refined result according to the actual content of the video to be encoded. So with MeGUI (more complex than Handbrake / Vidcoder but it's worth it if you're willing to optimize the result -- more control over settings, access to advanced Avisynth filters, plus you can use the best available AAC encoders, Apple QAAC & Fraunhofer FDK-AAC, whereas the aforementioned tools are limited to poorly rated ones, FAAC & Libav AAC), I used an Avisynth script like this
Code:LoadPlugin("C:\Program Files\MeGUI_2507_x86\tools\dgindex\dgdecode.dll") LoadPlugin("C:\Program Files\MeGUI_2507_x86\tools\avisynth_plugin\NicAudio.dll") LoadPlugin("C:\Program Files\MeGUI_2507_x86\tools\avisynth_plugin\TIVTC.dll") global MeGUI_darx = 16 global MeGUI_dary = 9 Vid = MPEG2Source("E:\FullDisc\DES FLEURS POUR ALGERNON\VIDEO_TS\VTS_01_1.d2v") Aud = NicAC3Source("E:\FullDisc\DES FLEURS POUR ALGERNON\VIDEO_TS\VTS_01_1 T80 2_0ch 384Kbps DELAY 0ms.ac3") VidFM = Vid.tfm(order=-1) VidCleaned = VidFM.QTGMC(InputType=1) Mix = AudioDub(VidCleaned, Aud).SelectRangeEvery(10000,100) Return(Mix)
Then I made a few test encodes with different CRF values, all else being equal, which gave me a rough estimate of the average bitrate, and hence the final file size, for each CRF value. Then I selected a CRF value (23), removed the "SelectRange" command and ran the full encode, the video ended up in the right ballpark. -
^ This kind of "spot sample test" was already used in GordianKnot (during times of DivX 3) as "Compressibility test", and is still used in some current converters.
-
If you really need to do a pre-test with constant quality, one method is to use TDecimate(cycleR=M,cycle=N) to pull out M out of N frames, and check the resulting bitrate of a reduced version of the clip.
For example, you can run an encode with 10% of the frames by pulling 9 of 10 frames:
Code:TDecimate(cycleR=9,cycle=10)
Code:TDecimate(cycleR=19,cycle=20)
Of course, the lower the percentage or resulting total frame count, the quicker your encode, but at the cost of higher probability of less accuracy in inference to the global picture. It's a balance.
But my "balance" in recent years has been to pull out 0 frames, get 100% accuracy, and just do the encode with constant quality and move on.
But still mention this if anyone is interested.I hate VHS. I always did. -
@Puzzler : But with this method, won't it affect the average bitrate estimation's accuracy (i.e. generate a significantly higher bitrate than the full encode) even more than the one I suggested, since every selected frame is totally different from the surrounding ones, thus preventing the encoder from finding redundancies ? (This criticism was already formulated when I exposed the "SelectRange" method in the aforementioned thread, but at least that way a few seconds worth of contiguous frames are encoded, thus the encoder can work almost as efficiently as with the whole video.)
-
Bad idea, PuzZLeR; abolibibelot understood the issue.
Taking only each 10th or 20th single frame is less useful than using SelectRangeEvery, because the former would create a time lapse which will change the motion flow and decrease compressibility by increasing motion, while the latter samples scenes of a specific duration which may still contain easily compressible near-still scenes. -
Hey, I fully agree.
Of course it's NOT the best method, only one of simplicity. And although it's capable of scanning an entire movie, which would be more useful if the movie has many different types of scenes, it does not take into consideration the neighboring frames, etc, and more could be done with it to minimize an accuracy error that I did imply.
In the older days of trying to find a bitrate for 2-pass from constant quality, this method was used to establish a benchmark of sorts, but yes, it certainly wasn't conclusive in any way.
But I did mention "one method". You can call it a "crappy" method, but I can arguably say it's a "quick and dirty" one.I hate VHS. I always did. -
-
I see what you mean.
Yes, it would be simple to pull out, for example, ~90% of the frames with SelectRangeEvery(100,10) to get an inference. Acheiving this with TDecimate() can be done IIRC, but it wouldn't be as easy as TDecimate(cycleR=90,cycle=100). It would involve modes, and framerates, overrides, etc, of which would remove the simplicity out of it.
But the real point I was trying to make is that there is no real need for it anyway, at least not with x264 (which may explain why I was haphazard in my approach here). Like I said, it's been years since I've even looked at this estimating stuff, and have forgotten it all because I totally moved on to constant quality since and never looked back - as I encourage others.
We did do something like this in the old DivX Community Forums - trying to take a bitrate from an abbreviated constant quality encode - but those Forums have been closed for 5-6 years now, and I have nowhere to link. Maybe we did indeed use SelectRangeEvery()? Don't remember (and don't really care).
If anyone is interested, citing what I mentioned earlier in this thread, here's some discussion about it in the HandBrake Forums some 8 years ago, and any other links stating how useless something like this would be. "Palmrest" was an attempt by the HandBrake Devs to more-or-less apply some optimal bitrate for 2-pass.
https://forum.handbrake.fr/viewtopic.php?t=2348
You can find more on Palmrest with another search. However, you will also find that Palmrest was scrapped down the road when there was no significant evidence that the actual bitrate of --crf would improve quality if input into 2-pass.I hate VHS. I always did. -
Using avisynth and trim (start_frame, end_frame) for particular interested scene is more usable than random scene selection, because that could be way off, wrong and not consistent, something like that 2pass VBR testing. Handbrake has also frame range, so I'd use that, not random selection. r just once when one starts to use CRF so he gets some ideas about size. Those who tend to overshoot bitrate will be in shock that CRF gives nice video but with lower bitrates, those who tend to undershoot bitrates will tell you that CRF get too much volume, not good
. Both cannot accept easily that they both are in the same Universe with the same rules, and problems are in our head.
Can handbrake use zones? I would like to express once more, to encode it properly and most effectively, regarding space or for web downloads, one just have to do that that way, no way around it.
I always thought that most important is to get that one CRF value that is just enough, "if it is just a bit worse I am not happy with its quality" - it is most important to find correct CRF, not size. BUT.
The problem with 8bit encodings is, that the quality is ok but just couple of scenes are not right, low light, gradients, one shot of person walking through smoke etc., even nicely lit scenes but one corner for some reason with gradients, that look terrible. So those scenes has to be encoded again with zones. If you encode it correctly for all scenes with one setting , you wasted bitrate somewhere, a lots of bitrate actually, tons of it. So it makes little sense to elaborate under microscope and comparing 2pass VBR, CRF etc., if all one creates is some waste anyway.
Again, I'm looking forward for 10bit HEVC encoding next year or so, how it is going to work, it is going to be perhaps much more straight forward and one CRF value would be more acceptable across larger scene selection spectrum.Last edited by _Al_; 10th Oct 2015 at 18:06.
-
Originally Posted by _Al
But yes, you can do it in HandBrake. Suppose you want:
Code:--zones 100,200,crf=18/300,400,crf=19
For our example (Note the extra = sign.):
Code:zones=100,200,crf=18/300,400,crf=19
Code:level=4.1:bframes=3:ref=3:weightp=0:cabac:zones=100,200,crf=18/300,400,crf=19
I hate VHS. I always did. -
HandBrake faced much criticism for being overly simplistic, as if it was some toy. (Guess which arrogant, ignorant and biased forum did most of that chirping?)
But that's the point, and not true anyway.
HandBrake is indeed simplistic, which makes it very appealing. And if you need the finer features of x264, HandBrake still has, and always had, a "backdoor" for this.
(Although there are some ways around it, still hoping HandBrake will accept scripts and output raw streams.)Last edited by PuzZLeR; 12th Oct 2015 at 10:44. Reason: Grammar.
I hate VHS. I always did. -
I'm sure it is a great software, no doubt about it, Vidcoder using batch modes moves it even further. Dealing automatically with NTSC DVD's it suppose to recognize it and inverse telecine or just deintelarce. Also it deals very well with aspect ratio , gui shows input and output, nicely, in different color, depending what you set.
For someone advanced and using avisynth, that is kind of bummer though Handbrake cannot load it. Also that VFR was scary to read about. Not sure where it stands now. Heck it is most easy to implement Handbrak command line into batch and encode backed up DVD's, all at once, incredibly easy. But I was using DGindex, ffmpeg,avisynth, x264 to be sure it is nicely flagged as CFR. Is it still an issue? -
This is an old thread, but … just to point out that x.265's strength is its ability to squeeze the same quality as x.264 into a file size about half as big. If you encode using x.265 but specify the same bit rate as for x.264, you'll get the same file size (and it'll take much longer to transcode on top of it). But try specifying about half the bit rate you would use for x.264 when doing x.265 — in your case this would mean about 2,000 kbps — and compare the final product to x.264 at 4,000 kbps. In principle they should be comparable : this is x.265's strength. If the x.264 version still looks a bit better then bump the x.265 bit rate up a bit, say by 20%, so 2,400 kbps in your case. That should definitely do the trick. If someone has a 2.0 TB HDD full of H.264/MPEG-4 AVC video and took the time to transcode all of it to x.265, the 2.0 TB would size down to 1.0 – 1.2 TB, and their "new" 2.0 TB "x.265" hard drive would in a sense be comparable to a 3.5–4.0 TB "x.264" hard drive if you get my meaning.
-
Hey, I wanted to ask you if I should go for x264 8bit, x264 10bit or x265 10bit? I mean if you say x265 hasn't matured yet, then I should go for x264. But should I go for 8bit or 10bit considering I'm not at all concerned about compatibility. I will play them on my PC which can play pretty much everything. I'm only going to use Constant quality mode.Last edited by knightplex; 8th Nov 2016 at 14:52.
-
x264 10-bit would be the best quality/efficiency wise, even for 8-bit content, if you are not concerned about the slower encoding speed and low compatibility. CRF (Constant quality mode) is fine.
-
I just encoded x264 10bit and can't solve an error. This is the file I used for encoding http://komisar.gin.by/old/2721/x264.2721.10bit.x86_64.exe
I don't know if kMod is better! Is it? http://komisar.gin.by/
Anyway, the file was encoded successfully and this was the error I got -
"This AVC/h.264 track's timing information indicates that it uses a variable frame rate. However, no default duration nor an external timecode file has been provided for it, nor does the source container provide timecodes. The resulting timecodes may not be useful." -
The different modified x264 builds differ only slightly, merely regarding extra modules for input and output, but not regarding the x264 core encoder.
The error message you quoted is probably not exactly an "error" (in this case, the conversion would have been interrupted), just a "warning" (the conversion finished, but the result may not be what you expected). It means that it has detected that the playback speed is not constant, but there are scenes which play faster and other scenes which play slower. But it misses a reliable and explicit table of frame rates which could be used to reproduce the changing speed in the resulting file. I don't have experience with such a case; one possible consequence may be that you need a tool which can extract such a list from your source, the other may be that these differences are so tiny that you may not notice it, just even at the limit of numerical precision.
Which tool reports this error? And how did you use your x264 encoder, did you try to load a source file directly with the help of libavcodec input modules in this modified x264 build, not through an AviSynth script? Details, details, details... -
MKVToolNix reported this error
I used this build - http://komisar.gin.by/old/2721/x264.2721.10bit.x86_64.exe
and this is the command line I used
Code:x264 --vf crop:0,138,0,138 -o "output.264" "input.mkv"
-
Oh, you posted twice. I answered in the other thread:
https://forum.videohelp.com/threads/381218-x264-10bit-timecode-error
Similar Threads
-
H.264 vs x264 and H.265 vs x265
By LeoKac in forum Video ConversionReplies: 27Last Post: 18th Jan 2017, 07:59 -
Is x265 ready for Primetime.. Migrating From x264 to x265..
By RazorBurn in forum Video ConversionReplies: 83Last Post: 31st Jan 2016, 07:14 -
x265 vs x264
By deadrats in forum Video ConversionReplies: 71Last Post: 10th Jan 2016, 06:14 -
X264 vs x265 at sane values
By Valnar in forum Video ConversionReplies: 12Last Post: 15th Oct 2014, 11:56 -
x264 vs x265??
By xenotox in forum Video ConversionReplies: 167Last Post: 12th Jul 2014, 11:16