VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. I'm not not sure if this is the correct terminology for this topic but I haven't found anything that fits what I'm looking for.


    Problem:
    Is there a program/method that can take or analyze the source media's quality (bit rate) and adjust the converted file's quality accordingly, avoiding the need to experiment with "perceived" quality for MP4 files?


    Example:
    Windows Media Center can record the digital stream of TV shows. These streams can vary quite a lot in bit rates. The same show/episode recorded on different channels can have a different bit rate, in this case 12.66Mbps vs 4.92Mbps. If everything else appears equal (720p60 with 5.1 AAC and 43:36 length) then video quality would mainly be the only differential factor. Test conversions of these files using MCEBuddy with the HQ mp4 setting so far have resulted in near identical file sizes.


    This didn't surprise me, but using this same show example is it not reasonable to think that a video of a lower bit rate should also produce a lower quality converted file as well? After all I wouldn't want a high quality "crappy" video when a lower bit rate would look exactly the the same.

    This process may be a pipe dream as I'm trying to save myself a lot of work (and hard drive space) but any advice would be greatly appreciated. If anything I'm hoping someone may have a rule of thumb for settings to use.
    Quote Quote  
  2. The x264 encoder has a single pass, quality based encoding mode. That's what most of us use. The encode is roughly the same quality relative to the source each time (for a given CRF value and identical encoder settings) while the bitrate varies accordingly. It also has an average bitrate encoding mode which will output the same file size for a given duration each time, which is less efficient, but MCEBuddy could be using that. I don't use MCEBuddy although I'd forgotten about it so I'm going to download it for a look. If I can work out the settings it uses I'll report back, unless someone else knows.

    I had a quick scan through the documentation but I couldn't find any details regarding the encoder settings. If it's using the x264 encoder for h264 encoding, which it probably is, and the encoder is writing the settings to the video stream, you can see the details with MediaInfo (use the Text or HTML view). You can paste them here if they don't mean anything to you. They should look like this with MediaInfo displaying in HTML view.

    Click image for larger version

Name:	MediaInfo.gif
Views:	121
Size:	24.7 KB
ID:	39558

    Keep in mind if you take a high quality source and encode it at 12.66Mbps (for example), then encode it again at 4.92Mbps, then re-encode each of those with a quality based encoding method, there's no guarantee the re-encode of the 4.92Mbps source will result in a lower bitrate than re-encoding the 12.66Mbps source. In fact if the 4.92Mbps source has more compression artefacts due to the lower bitrate, that can make it harder to re-compress and require a higher bitrate.
    The amount of motion, picture detail, noise, and grain etc all play a part in how hard a source is to re-compress. The source bitrate doesn't necessarily reflect those things. If the file size is already on the low side, it's possibly not worth re-encoding.
    Quote Quote  
  3. I had a bit of a look at MCEBuddy and it encoded with the x264 encoder via ffmpeg. I'm not completely sure what it's doing though. The HQ MP4 setting runs two passes, but according to the encoder settings written to the video stream, average bitrate encoding is used which is only a single pass method. The same applies to the medium preset although it only runs a single pass encoding. I'll have to look through some log files to understand it properly

    Someone who uses MCEBuddy will hopefully come along, but 2 pass encoding usually involves specifying a bitrate or file size and the first pass is for the encoder to work out how to distribute those bits while the second pass encodes it. I can't imagine that's what MCEBuddy is doing otherwise "2 pass" would be written to the video stream by the encoder. I think it's running the first pass to adjust it's settings but I haven't run enough encodes to work out if it's aiming for a specific bitrate (according to the resolution) or if it's aiming for a particular quality, but either way it's probably not giving you maximum compression due to the average bitrate encoding.

    You might want to try Vidcoder or Handbrake on some of your source files as a comparison. They don't remove ads, but you can use single pass quality based encoding. A quality setting of around CRF18 is considered to be roughly "transparent", or at least a high quality. The default for the x264 encoder is CRF23. The higher the CRF value the lower the quality and the smaller the file size. x264 also has speed presets of it's own. The default of "medium" is fine but a rule of thumb is to decide on a CRF value and then use the slowest speed preset you can stand. The bitrate can vary quite a bit so it'll probably take several encodes to settle on a CRF value that gives you the file size you prefer.... on average.... for a particular resolution/duration......and hopefully also a quality you're happy with.
    Quote Quote  
  4. Thanks hello_hello for looking into MCEBuddy conversions, I did see the 2-pass but not options to change settings in the GUI, so I appreciate you looking a little deeper what it was doing.


    To be honest I have a little understanding on how the two pass works but I've never grasped how constant quality worked other than it's a single pass where you pick a CQ setting that you perceive to look good. Though I usually do use Handbrake's constant quality for most of my conversions, MCEBuddy plays much nicer with Windows Media Center files (wtv) which is the library I want to convert. Additionally I liked the idea of hot folders and file naming. Also from what I can tell it looks like MCEBuddy is setup to use Handbrake in command line interface, but I'm not sure how yet.


    Per your suggestion I'm going to test the CQ setting in Handbrake. I've converted the files to a TS format which I know works in Handbrake and will use a single pass constant quality 20 (recommended range for HD). I'll update when they're finished.


    Regarding you're comments that a lower bit rate source may possibly have more artifacts which may increase the bit rate when re-encoded makes sense, but what I like about using these as test files is at least the "motion, picture detail, noise, and grain" shouldn't be a factor only the quality (and artifacts).
    Quote Quote  
  5. Some programs call CRF constant quality or CQ so it gets confusing.
    CQ really means "constant quantizer" as that's what the encoders use for constant quantizer mode. The quality it theoretically the same throughout.
    CRF = constant rate factor and unique to x264. Handbrake may refer to it as constant quality. It's goal is to achieve the same "perceived" quality as a CQ encode (I think CQ20 = CRF20 for "perceived" quality), by reducing the quality where you won't notice and increasing it where you will etc, but the end result should be a lower bitrate. It's the sort of thing 2 pass encoding often aims to achieve. While you could describe constant quantizer encoding as "quality based" encoding, it's a somewhat "dumb" method. Not as clever as CRF mode, which is what Handbrake would use. I don't think Handbrake gives the user access to x264's constant quantizer mode.

    Xvid only has a CQ mode for single pass encoding. It distributes the bits a little differently in 2 pass mode for the same "perceived quality" reason.

    x264 tries to simulate 2 passes with CRF encodin. I can't remember the details as to how it works, but it does a very good job of it. As a result, if you run a CRF encode, note the average bitrate when it's done, then use that bitrate for a 2 pass encode, the two encodes will be effectively identical. There's very minor differences, but nothing you'd see without bionic eyes and a good imagination. x264 works out how it thinks the bits need to be distributed during the first pass, then encodes it during the second pass, but if I remember correctly, as it runs the 2nd pass it checks to make sure the target bitrate will be achieved and adjusts the quality up or down a little as required. CRF encoding doesn't need to worry about that sort of thing, although any bitrate differences through the video are very small.
    Anyway.... the upshot of all that is, if you want a particular file size, select a bitrate and use 2 pass encoding and the quality will be unknown, or select the quality (CRF value) and wait to see what the bitrate will be.

    I haven't gone back to playing with MCEBuddy again yet. If I do it won't be for a few days. Average bitrate encoding achieves a target bitrate just as 2 pass encoding does, but without the benefit of a first pass, so the encoder is in "guess at it encodes" mode and will probably need to make regular and large adjustments to the quality. That's why it's less efficient than 2 pass or CRF. I assume MCEBuddy is using average bitrate encoding because it only requires one pass, and if the bitrate is high enough it won't reduce the quality compared to 2 passes, although it might waste bits for no increase in perceived quality.
    What MCEBuddy does with the 1st pass info when it runs 2 passes in HQ mode, I'm not sure. I assume it must use it to adjust settings or determine the bitrate. Back in the dark ages of Xvid and AVis, the norm was to run a "compression test" before encoding. You'd encode (for example) 1000 frames, skip a bunch of frames, encode another 1000 and so on... the GUI would sometimes do it for you so it always encoded the same percentage of the video. Maybe 10% to 20%. From the resulting bitrate you could work out the expected quality for a given file size, and some GUIs would automatically adjust the resolution and encoder settings etc to keep the quality to a certain level if possible. From there you'd run a 2 pass encode as usual. I imagine MCEBuddy wants to avoid a compression test as it'd take time to encode a small percentage of the video. For Xvid you'd encode in CQ mode using CQ2, which would would give you 100% (maximum) quality and from there a program would extrapolate what it needs to. I assume for x264 a compression test would work much the same way.

    Therese days, with CRF encoding being all the rage, and 2 passes only required for things like making sure all the bits will fit on a disc, compression tests aren't something encoder GUIs do. Except for Staxrip. Last time I looked it could still run a compression test and calculate the expected quality.

    Hell.... Time flies sitting at a PC and I appear to have written an essay. Hopefully it was informative.
    Last edited by hello_hello; 18th Nov 2016 at 18:17.
    Quote Quote  
  6. Again hello_hello your "essay" was very informative. I appreciate the explanation between CQ (Constant Quality), CQ (Constant Quantizer), and CRF (Constant Rate Factor) as well as the compression test history. It helps clear things up quite a lot and gives a fair amount of insight.


    On a side note one thing I'm just not a fan of is "perceived quality" since its subjective, and the scale confuses me as to why 18 is considered transparent (for 480p I guess) and like 20 for HD. This made me think the source mattered for transparency so a lower quality TV recording should have like a 16. Also if value of 18 is transparent why have the option to go all the way down to 1 (creating a very large file). Know-one has to respond to this part as I have a little better understanding of it now, just saying it can be confusing, and I'm sure there are reasons.


    As for results using Handbrake with a Constant Quality of 20, there was about a 22% difference in file size. This was more than I expected but less than I was hoping for. So the constant quality (CRF) in Handbrake did notice something different between the two files, Ill assume it was the bit rate (image quality) as the converted files correlate with the source file sizes (12.66Mbps for the larger mp4 and 4.92Mbps the smaller).


    hello_hello I don't want you to get too distracted with what MCEBuddy is doing with its HQ mp4 settings. Not that I don't find it intriguing, but you've successfully pointed out that its not the best setting for what I want which is something that takes into account the source quality. I'LL need to see if it has a setting that does work.


    So far using using CRF does appear to look at source quality, but I'm going to see if I have a few other files that I can also test. If successful, and no other options are presented, I'll investigate to see if I can then get MCEBuddy to use CRF in the Handbrake CLI or by some other means.
    Quote Quote  
  7. Member
    Join Date
    Jan 2007
    Location
    United States
    Search Comp PM
    you want to save drive space
    record the show from the tv channel with the lower bitrate small file
    and keep it in the recorded format do not convert to mp4
    just use a software player that will play that format
    VLC or mpc-ht will play TS mts etc.. no need to convert to mp4

    me i prefer the highest quality i can get, i record in hi-def and keep the source file
    Quote Quote  
  8. You are correct. Quality is in the eye of the beholder, but x264 is still pretty much the benchmark for quality..... at a particular bitrate. Any encoder can encode to a high quality if you give it enough bits, but if you encode a video at 1000kbps (for example) with x264, the question would be can you find another encoder to match the quality at 1000kbps. Many are faster, but x264's bitrate/quality ratio is the one to beat.

    The more you encode, the less transparent CRF18 becomes (you start to notice more imperfections) but CQ0 can be used for lossless encoding, CQ2 would be extremely high quality..... and the higher the quantizer the lower the quality. For x264, CRF18 is somewhere around the area where the quality is still very high while the bitrate is still reasonable (ie the ratio is good).
    The logic behind CRF18 for standard definition and CRF20 for high definition is we all watch video upscaled to at least 1080p these days, and as you no doubt know when you take a low bitrate 720x400 Xvid AVI and run it fullscreen on a large 1080p TV there's all sorts of horrors to be seen, so ideally when the resolution is lower you want to keep the quality a bit higher if possible. It's just a resolution thing.

    I hadn't used CRF values lower than CRF18 much until recently myself, but I find these days I am using CRF16/17 a fair bit more because I'm encoding less film with lots of grain and far more digital camera stuff that's nice and clean (although more likely to have colour banding problems). A CRF16 encode of digital camera footage might even result in a lower bitrate than CRF19 for a grainy old movie, because grain is hard to compress.

    You can try comparing CQ18 to CRF18 and see how similar/different the perceived quality is to you and how different the bitrates are, although you'd need another GUI for CQ mode if Handbrake doesn't have one. You can also try comparisons with and without any of x264's psychovisual trickery by adding --no-psy to the x264 command line. I don't know how you do that Handbrake with though.

    Part of the reason I don't get too carried away with bitrate is I often try to improve the quality before it gets to the encoder (quality again being in the eye of the beholder) mostly with noise filtering and some subtle sharpening or something similar, and I always add dithering to end of the filter chain as the biggest problem with 8 bit encoding is colour banding. While often it's only a problem in sections of a video (if at all), it can sometimes require stupidly high bitrates to prevent. https://en.wikipedia.org/wiki/Colour_banding
    In a perfect world I'd be compensating for any loss of quality due to the lossy encoding with filtering much of the time, although the world is rarely perfect and it doesn't always happen, but for that sort of fiddling you'd need to use something like Avisynth (for which there's a plethora of filters) and/or an Avisynth based GUI. Handbrake's geared toward ease of use while still outputting a decent quality, and it is good at it's job in that respect.

    A few screenshots from an old post that were easy to find. Even if it's only a subtle improvement, which it usually is at best, it's still better than a subtle loss of quality.
    Original DVD:
    https://forum.videohelp.com/attachment.php?attachmentid=30871&d=1427391802
    Encode:
    https://forum.videohelp.com/attachment.php?attachmentid=30872&d=1427391921

    Original 1080p:
    https://forum.videohelp.com/attachment.php?attachmentid=32838&d=1437985152
    Encode:
    https://forum.videohelp.com/attachment.php?attachmentid=32837&d=1437984916
    Last edited by hello_hello; 21st Nov 2016 at 18:59.
    Quote Quote  
  9. theewizard I also prefer to have the highest quality I can get for videos. I have all my DVD's as uncompressed ISO's and will keep all my source recordings as WTV files, but this is a lot of terabytes. I want MP4 versions for a more manageable and compatible media server (ie...external HD connected to a router), with the option to go back to source files when needed. With that said I'm trying to create MP4's that are as close to transparent as possible (for smaller files with relatively high quality). So recording shows on a lower bit rate channel isn't a preference, the issue is that some recordings have much lower bit rates as channels very in quality. So I want to see if I could get MP4 conversions to reflect that difference. Using the same exact show episode with different bit rates allows me to test that. I'd rather not add another layer of conversion, but I need to until I can upgrade my server and network.


    hello_hello I can't deny that x264 has better quality encoding, if only the quality didn't have such a range (lossless to transparent) because deep down I want to use a setting of 0 ("lossless" and "extremely high quality" are alluring), but reason and drive space won't let me. Plus "lossless" doesn't necessarily mean it will be much better than transparent for most videos, at least it shouldn't.


    The resolution explanation makes sense, but your comments on the CQ for your digital camera verses old movies goes back to my confusion on CQ. My prior research lead me to believe that you find a CQ setting you like and use it for everything (of course I just went with the suggested transparent as my default). Clean video usually makes a smaller file size than an old grainy one, but why increase the CQ, were you not content with quality of the video conversions? Sorry I'm not questioning your decision, just reiterating my lack grasping CQ and how it relates source files.


    I'm willing to try a CQ18 vs CRF18 test, but until recently when you explained the difference between the two I thought they were the same thing. I am comfortable using Handbrake, but I don't know if it can do both. Do you know a program that can do both to minimize inconsistencies (maybe the mentioned Avisynth).


    Regarding your quality enhancements, man that's just an evil temptation. Granted I've done the occasional detelecine and denoise but that's it. I have have a fair amount of DVD movies and its taken a quite some time to just rip and convert them. I never really thought about trying to enhance them as I thought they were about the best they could be. Thanks for pointed out the term color banding (I always called it gradient stepping) which I'm very familiar with seeing and didn't know it could even be minimized, very cool! Now I like the idea of making videos look better, but the amount of work scares me. This is going a little off topic, but what process do you use to recognize the need for these enhancements? Do you watch each movie first and make notes, or do you just scan through them maybe? Either way would seem to be very time consuming.


    Well my mind has been opened up a lot about this processes so thanks for all the responses thus far.
    Quote Quote  
  10. Originally Posted by inlist View Post
    hello_hello I can't deny that x264 has better quality encoding, if only the quality didn't have such a range (lossless to transparent) because deep down I want to use a setting of 0 ("lossless" and "extremely high quality" are alluring), but reason and drive space won't let me. Plus "lossless" doesn't necessarily mean it will be much better than transparent for most videos, at least it shouldn't.
    It's very rare I use a CRF value lower than CRF16 as that's pretty high quality, but a lossless output will invariably result in a file size way larger than the source video, so it'd be far more practical to use the source video and not re-encode at all.
    Unless you're re-encoding for the purpose of applying filtering the best you can hope for when re-encoding is an imperceivable quality loss, but given the point of re-encoding is often simply to reduce the file size you have to decide what you'll be content with in respect to a quality/bitrate ratio.
    It's not always possible to reduce the bitrate when re-encoding though, although given h264 compresses far more efficiently than mpeg2, you'd generally expect a fair bitrate reduction when re-encoding DVDs, but sometimes even then it can be so hard to compress the bitrate can't be reduced much without making a quality compromise. I've got DVDs of some old Laurel and Hardy films and while I can't remember specifics, I do remember some of my first encodes, which no doubt would have been CRF18, resulted in a larger file size than the original. The quality relative to the source would have been roughly the same as it always is for CRF18, but without any bitrate reduction. If memory serves I removed a fair bit of the noise and resized the PAL DVD from 720x576 to 640x480 for encoding and managed to reduce the bitrate by half that way while using CRF18.
    It wouldn't be terribly unusual to re-encode a highly compressed h264 video at around CRF18 and for the bitrate of the encoded version to be higher than the source, whereas re-encoding h264 video ripped from a Bluray disc will usually result on a considerable bitrate reduction because the bitrate of the source is so high it can be recompressed at a much lower bitrate without reducing the perceived quality by anywhere near the same amount, if at all.

    Originally Posted by inlist View Post
    The resolution explanation makes sense, but your comments on the CQ for your digital camera verses old movies goes back to my confusion on CQ. My prior research lead me to believe that you find a CQ setting you like and use it for everything (of course I just went with the suggested transparent as my default). Clean video usually makes a smaller file size than an old grainy one, but why increase the CQ, were you not content with quality of the video conversions? Sorry I'm not questioning your decision, just reiterating my lack grasping CQ and how it relates source files.
    I assume you're referring to my mentioning I've been tending to use lower CRF values for digital sources?
    It still comes down to the same file size vs quality compromise. I've been content with both the quality and the average file size, but I'd tend to care a little more about the former so as the average file size seemed to decrease for digital sources I opted to exchange some of the increase in file size contentment for a little extra quality contentment instead.

    Originally Posted by inlist View Post
    I'm willing to try a CQ18 vs CRF18 test, but until recently when you explained the difference between the two I thought they were the same thing. I am comfortable using Handbrake, but I don't know if it can do both. Do you know a program that can do both to minimize inconsistencies (maybe the mentioned Avisynth).
    If you're referring to constant quantizer encoder vs constant rate factor encoding there, in theory any encoder GUI capable of using x264 for encoding should be capable of both (even if it's not Avisynth based), and Handbrake not making CQ encoding available to the user is probably not typical. I use MeGUI and it'll do both, but it'll have more of a learning curve. Avidemux should let you choose CQ encoding. I don't use other GUIs much so other than those I'm not sure.

    Originally Posted by inlist View Post
    Regarding your quality enhancements, man that's just an evil temptation. Granted I've done the occasional detelecine and denoise but that's it. I have have a fair amount of DVD movies and its taken a quite some time to just rip and convert them. I never really thought about trying to enhance them as I thought they were about the best they could be. Thanks for pointed out the term color banding (I always called it gradient stepping) which I'm very familiar with seeing and didn't know it could even be minimized, very cool! Now I like the idea of making videos look better, but the amount of work scares me. This is going a little off topic, but what process do you use to recognize the need for these enhancements? Do you watch each movie first and make notes, or do you just scan through them maybe? Either way would seem to be very time consuming.
    As a general rule I don't get too carried away experimenting with filters these days as I've settled on a few scripts/filters as my "go to filters" and I mostly use those as required. Usually I'll skim though parts of the source video to decide what filtering it might need, but for DVD sources especially, more often than not I use the same filters, just adjusting a few parameters while previewing the Avisynth output on my TV with MPC-HC. Sometimes I've cared enough to be fussy and applied different filtering to different parts of the video and spent a lot of time playing around, and yes that can be time consuming.
    Quote Quote  
  11. I ran a couple of CRF vs CQ (constant quantiser) encodes for a comparison today and the differences weren't nearly as great as I'd expected, but then again I've never compared them before.
    The source was a 720x480 video, about 45 minutes in duration. Reasonably noisy as it turned out (I picked a random episode without looking at it) and encoded with the default x264 settings aside from "tune film" as I normally use it. No resizing or filtering, just a straight re-encode.

    CRF18 - 505.2 MB
    CQ18 - 508.9 MB

    CRF23 - 208.1 MB
    CQ23 - 218.4 MB

    I thought to compare them properly I might have to run the CQ encodes, note the bitrates and use them for some 2 pass encodes (which encodes the same way as CRF) because the only way to judge if an encoder or setting etc is better than another encoder or setting is to compare encodes at exactly the same bitrate, but given the bitrates for the CQ and CRF encodes were so similar I didn't bother with 2 pass encodes.

    At CRF18, for this particular source at least, I couldn't reliably say which looked better or even which method encoded more accurately compared to the source, and I was pausing each on identical frames for a good nitpick. CRF18 and CQ18 appeared to have encoded most frames just a little differently, but I gave up trying to decide if one method was better on average.

    At CRF23, which is lower quality than I'd normally use (I picked it as it's the default quality), I still thought much the same thing much of the time, although CRF did seem to be a little more accurate and retain a little more detail than CQ on average, but just as I was starting to wonder if there was all that much advantage to CRF encoding I found a few frames like this. I don't know how much different they'll look at their native resolution (and displaying on my CRT monitor they don't look much different at all) but upscaled to 1080p on the TV it's easy to see the CRF encode retained more detail.

    Source
    Image
    [Attachment 39743 - Click to enlarge]


    CQ23
    Image
    [Attachment 39744 - Click to enlarge]


    CRF23
    Image
    [Attachment 39745 - Click to enlarge]


    I went back and checked the same frames for the CQ/CRF18 encodes and although the difference between CRF and CQ was far less, CRF definitely kept a little more detail.
    Last edited by hello_hello; 30th Nov 2016 at 10:52.
    Quote Quote  
  12. Sorry for the delayed response...tis the season and all! I does gratefully appreciate all the responses!


    *note that I'm going to use RF for referencing the quality setting, in HB the setting is under "Constant Quality" but is labeled "RF".

    Originally Posted by hello_hello
    a lossless output will invariably result in a file size way larger than the source video, so it'd be far more practical to use the source video and not re-encode at all.

    I agree that for now keeping the source file is the best option for a reasonable "lossless" video file. My pipe dream (and I'm sure many others) is a visually "lossless" compression used to replace larger source files. And since I don't have the option to just use all the source files as is, I'm willing to settle for the suggested RF18 for transparency. At least until I have a lot more drive space. So size is my first priory for the moment (quality a very close second) and keeping SD movies under 2GB is ideal. RF18 seems to be working for average movie lengths. Though I did have to add Denoise to a few old movies (mine were Abbot and Castello) to reduce their size but that's all I needed to adjust.


    If there isn't one already, it would be nice to have like a two minute lossless video that could be used to test quality settings. It could contain looping samples of scenes that are most likely to be affected visually by compression, like fire, grain, and fast motion. Then pick your perfect sleep number...um I mean RF number. Plus it would save the time of scanning through videos to find those scenes. Its not perfect but could help.


    Originally Posted by hello_hello
    re-encoding h264 video ripped from a Bluray disc will usually result on a considerable bitrate reduction because the bitrate of the source is so high it can be recompressed at a much lower bitrate without reducing the perceived quality by anywhere near the same amount, if at all.

    I haven't tackled Blu-ray movies yet, though I'm glad to hear that they should have a considerable bit rate reduction "without reducing the perceived quality". I guess that matches the suggested CQ20 I saw somewhere.



    Originally Posted by hello_hello
    "I assume you're referring to my mentioning I've been tending to use lower CRF values for digital sources?
    It still comes down to the same file size vs quality compromise. I've been content with both the quality and the average file size, but I'd tend to care a little more about the former so as the average file size seemed to decrease for digital sources I opted to exchange some of the increase in file size contentment for a little extra quality contentment instead.

    Yeah that's kind of what I thought and it makes sense, but I was also thinking it sounds very similar to having a target size with a bit rate that fits it. Kinda like how mentioned with the 2-pass method except your choosing the quality to get to a particular file size.


    Originally Posted by hello_hello
    As a general rule I don't get too carried away experimenting with filters these days as I've settled on a few scripts/filters as my "go to filters" and I mostly use those as required. Usually I'll skim though parts of the source video to decide what filtering it might need, but for DVD sources especially, more often than not I use the same filters

    I really do like the idea of enhancing videos, especially color banding, but I'm glad to hear that you have a simplified process now that your content. I thought about it a little more and now that I know what can be tweaked, I'll flag movies as I watch them on my larger TV since its easier to see. This should help ease overloading myself with trying to perfect every video. As is I spend enough time skimming through videos to verify if they're interlaced or not.


    hello_hello, I can't tell you how much I appreciate you testing CQ vs CRF. Your methodology was very sound and the results were very interesting! Using the quality 18 was a good was to judge the visual quality difference but it was more impact-full to see the file size difference, which was marginal. And the quality 23 was able to show which was better at retaining detail with a lower bit rate. Looking at your frame samples I agree that the CRF version held better detail overall. That was a very good test.


    I may try additional tests with either Avisynth or MeGUI, but yours did seem to work very well. Plus its been many years since I tried MeGUI but yeah I recall the learning curve to be a little difficult. For now though I'm going to research MCEBuddy to see if I can get it to use CRF, as hello_hello noticed that the default was using a faux 2-pass encoding with its presets. So far using CRF appears to be the solution that I started this thread for.


    One other thing I'm having trouble clarifying is what exactly HB uses, CQ or CRF. I know it uses x264 for encoding, but it refers to the quality setting as Constant quality and yet uses a value of "RF" (Rate Factor maybe) for the variable. I think it's probably using CRF but I haven't been able to verify that yet.


    **Sorry for the weird quoting, I was trying to emulated hello_hello's responses but I don't have it quite figured out
    Quote Quote  
  13. Handbrake uses crf. You can use MediaInfo to examine a file with x264 and see all the settings that were used.

    The difference in size when using qp vs crf varies depending on the particular video.
    Quote Quote  
  14. Originally Posted by inlist View Post
    If there isn't one already, it would be nice to have like a two minute lossless video that could be used to test quality settings. It could contain looping samples of scenes that are most likely to be affected visually by compression, like fire, grain, and fast motion. Then pick your perfect sleep number...um I mean RF number. Plus it would save the time of scanning through videos to find those scenes. Its not perfect but could help.
    There's no perfect solution as even x264 has tuning presets for different sources, one being Tune Grain. I use Tune Film for just about everything as it retains a little more fine detail than no tuning, at the expense of an increase in bitrate (there's no free lunch), or Tune Animation for Simpsons type animation. If a source is really grainy I usually try to remove a fair bit and stick with Tune Film.

    Originally Posted by inlist View Post
    Yeah that's kind of what I thought and it makes sense, but I was also thinking it sounds very similar to having a target size with a bit rate that fits it. Kinda like how mentioned with the 2-pass method except your choosing the quality to get to a particular file size.
    I'm still choosing a quality for an average file size though. Individual encodes still vary all over the place in respect to bitrate.

    Originally Posted by inlist View Post
    I really do like the idea of enhancing videos, especially color banding, but I'm glad to hear that you have a simplified process now that your content. I thought about it a little more and now that I know what can be tweaked, I'll flag movies as I watch them on my larger TV since its easier to see. This should help ease overloading myself with trying to perfect every video. As is I spend enough time skimming through videos to verify if they're interlaced or not.
    For DVDs and HD sources that need cleaning up my go-to filtering would usually be (in an Avisynth script):

    TFM().TDecimate() # NTSC pulldown removal if required
    QTGMC(InputType=1, Preset="Medium", EzDenoise=1.5)
    Crop(0,0,0,0) # as required
    Resize8(960x540) # or appropriate resizing
    LSFMod(Strength=75) # only when required
    gradfun3()

    QTGMC is a de-interlacer. I often use in progressive mode (as above) to stabilise and denoise, and for interlaced sources obviously you'd use it in interlaced mode. The denoise option can be adjusted as required. There's lots of other settings to play with but I usually don't adjust much else. LSFMod does the sharpening and gradfun3 does the dithering (needs the Dither Package). I usually only sharpen if it's needed and it doesn't make any remaining noise or artefacts more obvious.

    Depending on the source I might replace QTGMC with SMDegrain or MCTemporalDenoise or TemporalDegrain.

    They're all scripts that Avisynth needs to load to use their functions, and each require additional plugins. It can be a bit of a hassle downloading all the required plugins and getting the scripts to work but once they work, they work, and adding them as filters to any scripts MeGUI creates is pretty easy. They're all quite slow.

    Originally Posted by inlist View Post
    One other thing I'm having trouble clarifying is what exactly HB uses, CQ or CRF. I know it uses x264 for encoding, but it refers to the quality setting as Constant quality and yet uses a value of "RF" (Rate Factor maybe) for the variable. I think it's probably using CRF but I haven't been able to verify that yet.
    It uses CRF. I don't know why they just don't call it that.
    Mind you MeGUI is worse in a way. When the encoder configuration is in simple mode you have to select "targeting quality" as the encoding method for CRF encoding. When you check the option to show advanced settings the name changes to "constant quality". I don't know why someone thought that was a clever idea.
    Quote Quote  



Similar Threads