VideoHelp Forum




+ Reply to Thread
Page 2 of 3
FirstFirst 1 2 3 LastLast
Results 31 to 60 of 61
  1. 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.
    Last edited by _Al_; 2nd Oct 2015 at 15:56.
    Quote Quote  
  2. 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.".
    Quote Quote  

  3. 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.
    Quote Quote  
  4. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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.
    Quote Quote  
  5. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by THRobinson
    Anyone have that issue? Creating a file with CQ the same size as CBR file, some scenes are worse?
    Never.

    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.
    Quote Quote  
  6. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by _Al_ View Post
    Maybe it is difficult for whomever starts to encode to kind of take in that CQ really watches for quality, that could be counter intuitive, because how would some software be able to control quality of video, right, ..., but it does, it compares differences with original so to speak.
    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.
    Quote Quote  
  7. 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.org where 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.
    Quote Quote  
  8. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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.
    Quote Quote  
  9. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by LigH.de View Post
    Don't confuse "constant quantizer" with "constant rate factor" mode. CRF is probably obviously better than CQ...
    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.
    Quote Quote  
  10. Originally Posted by THRobinson View Post
    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.".
    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)
    (You'd have to change the source plugin if the source is not a DVD, there's a Script Creator module inside MeGUI which helps choosing the right parameters -- and of course the other settings applied specifically to this video, for the purpose of such a test you'd only need to load the video and to add the "SelectEveryRange" command.)

    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.
    Quote Quote  
  11. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    ^ 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.
    Quote Quote  
  12. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    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)
    Or just use 5% of the frames:

    Code:
    TDecimate(cycleR=19,cycle=20)
    You get the idea.

    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.
    Quote Quote  
  13. @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.)
    Quote Quote  
  14. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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.
    Quote Quote  
  15. Deleted. Lots of posts already covering the topic I didn't see.
    Quote Quote  
  16. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    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.
    Quote Quote  
  17. Originally Posted by PuzZLeR View Post
    Of course it's NOT the best method, only one of simplicity.
    But it's not even simpler than SelectRangeEvery(), the method has only downsides. Reduced accuracy, needs external plugin, probably slower. Better to just forget about it.
    Quote Quote  
  18. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by sneaker View Post
    Originally Posted by PuzZLeR View Post
    Of course it's NOT the best method, only one of simplicity.
    But it's not even simpler than SelectRangeEvery(), the method has only downsides. Reduced accuracy, needs external plugin, probably slower. Better to just forget about it.
    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.
    Quote Quote  
  19. 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.
    Quote Quote  
  20. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by _Al
    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 personally don't bother. Too much work for me.

    But yes, you can do it in HandBrake. Suppose you want:

    Code:
    --zones 100,200,crf=18/300,400,crf=19
    In HandBrake - in the Video tab, open up the Advanced Tab, and in that tab's "x264's Encoder Options" enter with the = sign, and also entering a ":" (no quotes) to separate multiple commands.

    For our example (Note the extra = sign.):

    Code:
    zones=100,200,crf=18/300,400,crf=19
    Example with multiple commands. (Again note the equal signs, and the the colons.):

    Code:
    level=4.1:bframes=3:ref=3:weightp=0:cabac:zones=100,200,crf=18/300,400,crf=19
    I think this is some classic Mencoder style, but I'm not sure. I'm using HandBrake version 0.9.9.5530, but it's always been like this.
    I hate VHS. I always did.
    Quote Quote  
  21. good new for those who use Handbrake or Vidcoder
    Quote Quote  
  22. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    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.
    Quote Quote  
  23. 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?
    Quote Quote  
  24. Member
    Join Date
    Jul 2013
    Location
    Montreal
    Search Comp PM
    Originally Posted by THRobinson View Post
    So, as I understand it, the x265 is the newer 'improved' codec. I looked online to see what the difference was but, was a lot of overly technical stuff for me. I'm just a basic user.

    So, I tried it... took an 18GB movie and re-encoded it down to 4000kbps for the video, AC3 5.1 640kbps, high profile, 2-pass, and a few other settings... saved profile I use for pretty much everything. Video comes out usually pretty good, can still see film grain, sometimes I bump up/down the bitrate but in general, I am happy with it. I use VidCoder which is basically Handbrake, but I like the GUI better.

    Anyways, ran the encoding for x264 and took maybe 2h. Using the same settings I ran using x265 and took about 8h, and came out to being the same file size...???

    I was expecting the compression to be better maybe, or encoding faster, or something... but nope. 4x longer and same size when done.

    So... what's the deal with x265 over x264?
    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.
    Quote Quote  
  25. Originally Posted by PuzZLeR View Post
    You very much sound like the me of yesteryear as I was first feeling out this hobby many years ago, and you bring me back to, not only the old DivX/Xvid vs x264 days, but to even DivX vs MPEG-1/2 days, and all that nit-picking we'd all do with bitrate, quality, speed enhancements, etc. Personally, I'm done with that, and I'm done with burning out processors, motherboards and fans.

    You don't have to understand all that tech stuff here, but you can still learn from us here, and our experience.

    1) Retain your Source. Whatever you do now will change again and again (and again), and restarts are always better from the Source than from a constantly re-encoded stream. Yes, it's more hard drive space, but it's just something many of us have accepted, and implemented into our lives.

    Having said that...

    2) Whatever you do now with x265 will not be relevant down the road. Keep in mind, x265, and even HEVC, is a developing science currently. You will want to re-encode everything again when new features are implemented/improved. And again. And again. This is why I still pretty much use x264/DivX/MPEG-2 today for serious stuff, just like I used DivX in the early days of x264 - because the encode times of a mature codec are fast, the settings are stable, the headaches are few, and the output will play anywhere, and its quality/bitrate is competitive (if not better in some cases) with that of a developing next-gen codec in its early development.

    If anything changes, fine. I still have the Source (which was #1).

    It's perfectly fine to play around with x265 and experiment, but that's the best thing you can do with x265 at the time of this post, and it will contribute to your encoding efforts of the future what you practice today. However, I do not advise a full-scale encoding project with x265 today.

    3) Yes, if you could squeeze a bit of bitrate savings out of x265, great. But at what cost? Longer encoding times, re-encodes, endless experimentation, etc, and, again, where will you play the content? Even the current playback/decoding options for x265 are, at best, annoying. Maybe they'll play fine in a few years, but it doesn't matter because you will be re-encoding again in the meantime (see #2).

    I know you mention HDD space is like money, but even the word "cost" can include many other things too.

    4) Using constant quality is a mindset, and a philosophy, and one that brings on maturity in this hobby. And it's much more efficient, not only timewise, but in quality.

    You talk about file size, and you are averse to the unpredictability of constant quality. Well, I guarantee you this - a good constant quality algorithm, such as that in x264, and in DivX/Xvid, will give you the smallest file size possible for a given quality. Traditional 2-pass methods won't - they will virtually always either give you too much bitrate for the quality you want, or too low a quality for the bitrate you want.

    And not only does constant quality save you tons of time using only one pass, it will save you tons of time in endless self-bickering. You will hate your life constantly testing, testing, testing and wondering which bitrate is best. I personally just run constant quality once and get what I get and move on.

    Two-pass methods are either a thing of the past, or if a "fit-it-on-a-certain-medium" is important, otherwise they are useless. Also, an encoder without constant quality is useless too IMO.

    It's your life, and do whatever you see fit, but hopefully we can save you many, many headaches down the road.

    EDIT: I was using the expression "Constant Quality" generically here, which could be similarly --crf (x264), CBR (CCE), target quantizer (DivX/Xvid), or CQ with HCenc.

    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.
    Quote Quote  
  26. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    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.
    Quote Quote  
  27. 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."
    Quote Quote  
  28. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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...
    Quote Quote  
  29. MKVToolNix reported this error Click image for larger version

Name:	error.png
Views:	292
Size:	88.6 KB
ID:	39386

    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"
    All the settings were default.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!