View Profile
View Forum Posts
Private Message
When upscaling is enabled, and you choose a resizing that's greater than the original (after cropping is taken into account) the resize values in MeGUI's Script Creator turn red. So if you have "upsizing" enabled, then for a 16:9 NTSC DVD (for example) when you enable resizing MeGUI will probably default to something like 720x400 (assuming there's no cropping). If you leave the "suggest resolution" option checked, MeGUI will adjust the height resizing as you adjust the width. What I do is increase the width until the value for the height turns red. When it does, you've gone a little past the maximum resizing without resizing the height. From there I disable "suggest resolution" and reduce the height so it's not red, then I fiddle with the resizing and/or cropping to reduce the aspect ratio distortion as much as possible.
Often, I'll let the resizing be whatever it needs to be after cropping, but sometimes I do it the other way around. I decide in advance the resizing I want to use and set that resizing first. I disable "suggest resolution" and then leave the resizing set while fiddling with the cropping to reduce the aspect ratio distortion. Sometimes that also involves cropping a little picture as well as black bars etc, but sometimes if yu want a particular resizing/aspect ratio that's what you need to do.
I'd mainly resize first if the source video is close to 4:3 or 16:9 to begin with and I want an exact 4:3 or 16:9 square pixels output. Or if I'm doing a bunch of episodes from a TV show etc. I'd use that method to resize each episode to the same dimensions.
For source video with square pixels (ie Bluray video), there's no reason to resize at all unless you want to. You can simply crop and encode what's left "as-is" without enabling resizing. In fact if you enable resizing but don't resize, MeGUI won't add any resizing to the script it creates. For example if you crop a Bluray video to 1920x800 and enable resizing and the resizing is set to 1920x800, you won't see any resizing under the script tab in the Script Creator.
Tip: After cropping, if you disable resizing, MeGUI resets the resize dimensions to the same as those of the original video. So if you crop 2 pixels from the top of an NTSC DVD and 2 pixels from one side, after resizing is disabled the values should reset to 718x478.
Normally, you'd only use anamorphic encoding for an anamorphic source and even then, only if your player will obey the set aspect ratio anyway. When you resize to square pixels, or if the source already consists of square pixels, there's no point to enabling anamorphic encoding or setting an aspect ratio in the script. Your player will apparently ignore it anyway, so forget anamorphic encoding completely, resizing to square pixels if need be and adjust the cropping and/or resizing as required to keep the aspect ratio distortion as close to zero as you can.
On the subject of aspect ratio calculations, different calculators use different pixel aspect ratios to calculate it. There's a list here:
https://www.doom9.org/showthread.php?p=1058927#post1058927
The "Exact PAR according to ITU-R BT.601" aren't used by any encoder GUI's I'm aware of, but I could be wrong.
MeGUI uses the second lot for ITU aspect ratios for it's calculations. The "Almost exact and commonly used ITU-PAR".
It's actually the least accurate of the aspect ratios but MeGUI still uses it because much of MeGUI is left over from the dark ages. I suggested changing that not so long ago but the idea didn't seem to go over well. Not that being the "least accurate" means all that much. The resizing difference is very small. Just a pixel or two.
The "MPEG-4 PAR taken directly from the MPEG-4 standard documents" are the pixels aspect ratios used by many encoder GUI's these days when an ITU aspect ratio is specified. It's almost the same and the numbers are easier to manage. I'm pretty ruse StaxRip and Handbrake use the mpeg4 PARs for ITU aspect ratios. MeGUI is maintained by a couple of volunteers so sometimes changes take a long time. It wasn't all that long ago MeGUI could only resize to mod16 and couldn't "upscale" at all.
The "Generic PAR" are the pixels aspect ratios used by all GUI's when a non-ITU input aspect ratio is specified.
(MeGUI was originally created by doom9, owner of the doom9 forum, but he doesn't have anything to do with it these days. The name, MeGUI, was due to it being a MEncoder based GUI. Obviously, that's no longer the case. Maybe one day it'll get a name change.....)
MeGUI uses the DAR at the top of the script and the script output resolution to calculate the correct pixel aspect ratio when anamorphic encoding is used. If you're just resizing to square pixels then all you need to worry about it minimising the aspect ratio distortion when you resize. Leave anamorphic encoding disabled.
Storage Aspect Ratio (resolution) x Pixel Aspect Ratio = Display Aspect Ratio
Tip. The aspect ratio distortion may not always be zero when anamorphic encoding is enabled because there's a setting that allows MeGUI to fudge the aspect ratio a little. It's probably set to 1% by default. The idea is to let MeGUI output exact 4:3 or 16:9 aspect ratios more easily (without needing to get the cropping exact). The option is under the Config button next to the AVS profile dropdown box. If you change it to 0% the aspect ratio distortion displayed by MeGUI should always be 0% when anamorphic encoding is enabled. The "fudging" setting only applies to anamorphic encoding.
For 4:3 video I'd probably set the resizing to 4:3 dimensions myself (ie 640x480), disable "suggest resolution" and adjust the cropping to reduce the aspect ratio distortion as much as possible. Sometimes that means also cropping a bit of picture from the sides or top and bottom to take the aspect ratio back to 4:3 (minimum aspect ratio distortion).
In some (less common) cases there's very little crud to crop from the sides of a 4:3 DVD. In that case I'd set the resizing to 656x480 and adjust the cropping to minimise the aspect ratio distortion as 656x480 is very close to 1.367. Sometimes that way you can get away with cropping a little less of the actual picture and the output aspect ratio will be a little wider than 4:3.
Whatever dimensions though, that's the way I do it for episodic DVDs. I pick the most appropriate resizing in advance and crop each episode differently if need be to resize to those dimensions with minimum aspect ratio distortion (quite often they require slightly different cropping anyway). That way, the output video is all the same size. That's just me though...... keeping my OCD tendencies under control. How you do it is up to you.
All of the above is me using the AVS script creator. I don't us the OneClick encoder. I just realised you do.
Normally you'd use the OneClick encoder by specifying the width and letting MeGUI apply auto-cropping and resizing. You'd simply enable anamorphic encoding in the OneClick setup, or leave it disabled, and MeGUI will take care of everything else. You can't actually specify a height using the OneClick encoder configuration....... unless you create an AVS template/profile for OneClick to use that includes resizing (or even an aspect ratio) but as each input video will be different, make sure you really know what you're doing before creating AVS templates for OneClick to use. Make sure you're not running before you can walk, so to speak. If you need to create individual AVS templates for each OneClick encode in order to get the output as you want it, I'm not sure what the point of using the OneClick encoder would be in the first place.
As I don't use the OneClick encoder myself, most of the info in this post applies to me creating individual scripts with the Script Creator......... which you can use as AVS templates in the OneClick encoder, if you really know what you're doing......
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 60 of 112
Thread
-
Last edited by hello_hello; 7th Apr 2015 at 22:12.
-
The exact pixel aspect ratios don't really matter because you have to have integer frame sizes. And with 4:2:0 chroma subsampling you have to have mod 2 frame sizes (integer multiples of 2), even mod 4 if you are encoding nterlaced. So the commonly used 10:11 and 40:33 are close enough. And as I've mentioned before you can't see a 2 percent error, much less fractions of a percent.
-
I agree it doesn't matter but there is a slight difference and it'd be mostly why aspect ratio/resize calculators don't always exactly agree on the amount aspect ratio distortion.Originally Posted by jagabo
For a PAL 16: 9 DVD translated to square pixel dimensions......
Exact ITU aspect ratio = 1048.4 x 576
Almost exact and commonly used ITU-PAR = 1050.2 x 576
MPEG-4 PAR = 1047.2 x 576
Generic (non-ITU) PAR = 1024x576
I was really just explaining why sometimes resize calculators disagree by a pixel or so when it comes to ITU resizing, or a percentage of a percent, but nothing to worry about.
I wonder if manofsteel31 has discovered the ability to use the reizers to crop an odd number of pixels yet (progressive video)? Being able to crop an odd number of pixels keeps my aspect ratio resizing at maximum OCD levels and helps make the difference in pixel aspect ratios appear more..... different.
http://avisynth.nl/index.php/Resize
For manofsteel31's benefit: ie to crop 11 pixels from the left and resize to 640x480
Crop(10, 0 0, 0)
Spline36Resize(640,480,1,0,0,0)
The Yoda Resize Calculator will calculate resizing while cropping in increments of single pixels
Although I've never quite worked out what ITU pixel aspect ratios it uses. They're just a tiny, tiny bit different to the standard ITU PARs. Nothing to worry about though...... -
Wow hello_hello, that was quite a detailed post. Thanks for sharing how you personally come up with the video size. While I understand your reasoning being the "extra cropping" in order to fix the aspect ratio, I dont really like the idea of losing any of the actual picture. I know its just a small amount and there will usually be nothing of importance that close to the edge of the video but it just feels wrong to intentionally cut out part of the image. I have no problem removing the black bars or the "crud" from the edges because I dont feel like it should be there in the first place and is only there because the original author of the dvd was too lazy to remove it themselves. But its just hard for me to rationalize cropping part of the actual picture.
If the original aspect ratio of the video is supposed to be 1.33, but its actually 1.367377 on the DVD, then the "Aspect Ratio Error" is going to aim you towards the 1.367377 value. However the fact that we are taking the extra steps to resize the video to 640x480 which is 1.33, should be still be aiming to comply with the 1.367377 AR?
As for why I use the One Click Encoder as apposed to the Script Creator, I think it was rather intimidating to me when I started encoding a year and a half ago. I also did not like the fact that audio always defaulted to "false" in the script and had to be encoded separately and then manually muxed back into the video afterwards.
Also, even if you use the Script Creator you still seem to need to pick an AviSynth Profile. Unless you are creating your own, they pre-made ones that come with MeGUI all specify a Resize value. I just did a quick test with the script creator. I selected a Profile with a 720x480 resize and then manually checked the resize box in the script creator and made it 620x480. Then I went to the "Script" tab and it clearly showed the settings from the 720x480 Profile I selected as apposed to the resize value I entered into script creator. So why would it ignore my options in the script creator and only accept the resize from the Profile instead?
Perhaps that is just another reason I use the One Click encoder instead. I typically chose one of the pre-made Profiles that is closest to the resize value I want (and that already specifies the correct DAR), and then modify the actual resize value to exactly what I want (which then changes the profile to "Scratchpad" unless I chose to save the changes as a new profile). For example, the 2.35:1 Bluray Movie that is cropped to 1920x816, I would chose the pre-made "16:9 1920x1080" Profile that comes with MeGUI and then edit it to "16:9 1920x816" and use that to encode with. I essentially custom an existing profile for each individual video so it meets the exact dimensions of the video itself. This is actually a BIG Improvement over what I used to do which was to encode every bluray movie to 1920x800 because I never paid attention to aspect ratio's and used to think that all black bars were 140 pixels each meaning that every 1080p movie was exactly 1920x800. Thank god I fixed that mistake, lol.
The only DVD's I plan to encode is simply OLD content that is NOT yet available on Bluray. That usually means just old 4:3 TV Shows. So hopefully your method will apply to all of them. Also, I know this is more of a Personal Preference for some people, but you mentioned that when you encode a full TV Show Season for example, that you would want to keep all episodes the same size and perhaps even cropped the same. I used to think that was the best way to do it too because the consistency looks good when the entire season is the same size. However I now think that it is best to treat each episode as a unique individual and crop and size it according to the specific needs of that video as apposed to being focused on them all being the same. I realize again that this is probably just the preference of the encoder but I would think the latter would produce the best results.
Not that it has anything to do with what we are talking about, but I just feel like mentioning that I encode using the "Constant Quality" Encoding Mode and adjust the "crf" value until I get a specific video bitrate of 2,200-2,399Kbps which I find to be Ideal picture quality while still at a managable size. It is NOT the most efficient way of encoding because it usually takes me a few tries to get the bitrate I want, but after trying all the different methods I am most happy with the results I get this way. I am sure that selecting one of the other Encoding Modes and specifying an actual bitrate within the range that I want (for example 2,300Kbps) would be much more efficient, but I just feel like I get the best results using "Constant Quality". Again, this doesnt really have anything to do with what we are talking about, but for some reason I felt compelled to mention it considering the fact that I know how inefficent it is since I always have to encode the same video multiple times using different crf values to get the bitrate I am aiming for. I am sure someone here can tell me how to achieve the same "Constant Quality" results I am getting know in a more efficient way. -
Academy ratio is roughly 1.37:1. If that's what you have, is there anything wrong with 656x480? Is there something magical about 640x480 or 1.33:1?Originally Posted by manofsteel31
You do know that makes no sense at all, don't you? You're contradicting yourself. Adjusting the CRF values varies the picture quality. If you want to encode to a specific quality pick a CRF and make all your encodes for that and don't worry about the final size. Almost by definition encoding to bitrates of 2200-2399 might give you wildly varying qualities. But, if you want specific bitrates then run two passes for your 2300 to begin with....but I just feel like mentioning that I encode using the "Constant Quality" Encoding Mode and adjust the "crf" value until I get a specific video bitrate of 2,200-2,399Kbps which I find to be Ideal picture quality -
While blu-ray movies can have different aspect ratios like 2.40:1, 1.78:1, 1.85:1, etc, all the 4:3 DVD's claim the aspect ratio is 1.33. So shouldnt I be focused on aiming towards the original AR just like i would for a bluray movie?Originally Posted by manono
Academy ratio is roughly 1.37:1. If that's what you have, is there anything wrong with 656x480? Is there something magical about 640x480 or 1.33:1?Originally Posted by manofsteel31
You do know that makes no sense at all, don't you? You're contradicting yourself. Adjusting the CRF values varies the picture quality. If you want to encode to a specific quality pick a CRF and make all your encodes for that and don't worry about the final size. Almost by definition encoding to bitrates of 2200-2399 might give you wildly varying qualities. But, if you want specific bitrates then run two passes for your 2300 to begin with....but I just feel like mentioning that I encode using the "Constant Quality" Encoding Mode and adjust the "crf" value until I get a specific video bitrate of 2,200-2,399Kbps which I find to be Ideal picture quality
When I first started encoding I spent months trying every encoding option in Handbrake and later MeGUI trying to find a picture quality I was consistantly happy with and was still small enough to be a reasonable size. Some of the encoding methods claimed that when they encoded a video that might use a different bitrate on different frames of the movie depending on if it needed more or less than others. I did not like that idea, and was led to believe that the "Constant Quality" would (as the name implied) Consistantly use the same bitrate on all frames throughout the movie so that every frame was encoding using the same bitrate as the last. That idea sounded ideal to me. While trying out every crf value between 15-27 on several small videos, I found that I was consistantly finding that my favorite encodes all had a video bitrate between 2,200-2,399Kbps. I have gotten much better at guessing the correct values now for that bitrate range. 1080p Blu-rays are typically between 23-26 and 480p DVD's are often 16-19.
I continue to use that method because there are so many 2pass, 3pass, ABR, quantizer, automated, etc options and I did not feel like they encoded my videos the way I wanted them to. Again, just people one frame on the movie is a night scene and full of deep black color, I dont want it to receive less of a bitrate then another. I want the quality to be constant throughout the entire video. I know I waste a LOT of time re-encoding the same videos until I am happy with the final result, but I dont know of another way that gives me the constant quality I am looking for. -
No, they don't. The video aspect ratio can also be 2.40:1, 1.78:1, 1.85:1, etc. And a 4:3 DVD can also be 1.37:1:Originally Posted by manofsteel31
http://en.wikipedia.org/wiki/Academy_ratio
Didn't you say somewhere in this increasingly long thread that you often work with classic films? If so, I expect you have quite a few 4:3 DVDs where the aspect ratio of the film on the DVD is Academy Ratio.
I doubt you were led to believe that, and probably misunderstood what you were told....and was led to believe that the "Constant Quality" would (as the name implied) Consistantly use the same bitrate on all frames throughout the movie so that every frame was encoding using the same bitrate as the last.
Most of what you think you know is just plain wrong. Not a little bit wrong, not difference-of-opinion wrong, but laughably wrong.Again, just people one frame on the movie is a night scene and full of deep black color, I dont want it to receive less of a bitrate then another.
CRF 18. Don't overthink this....but I dont know of another way that gives me the constant quality I am looking for. -
Doesnt Academy Ratio typically apply to Movies as apposed to TV Shows? My only interest in DVD's at all is when they contain content that is NOT available yet on a Blu-ray. That leads most of my interest in DVDs to old TV Shows which most likely originally aired on analog TV sets at 1.33 AR. So shouldnt they be encoded based on that original AR?Originally Posted by manono
No, they don't. The video aspect ratio can also be 2.40:1, 1.78:1, 1.85:1, etc. And a 4:3 DVD can also be 1.37:1:Originally Posted by manofsteel31
http://en.wikipedia.org/wiki/Academy_ratio
Didn't you say somewhere in this increasingly long thread that you often work with classic films? If so, I expect you have quite a few 4:3 DVDs where the aspect ratio of the film on the DVD is Academy Ratio.
I doubt you were led to believe that, and probably misunderstood what you were told....and was led to believe that the "Constant Quality" would (as the name implied) Consistantly use the same bitrate on all frames throughout the movie so that every frame was encoding using the same bitrate as the last.
Most of what you think you know is just plain wrong. Not a little bit wrong, not difference-of-opinion wrong, but laughably wrong.Again, just people one frame on the movie is a night scene and full of deep black color, I dont want it to receive less of a bitrate then another.
CRF 18. Don't overthink this....but I dont know of another way that gives me the constant quality I am looking for.
If my information is so wrong, then feel free to correct me, and advise me on how to do it better.
LOL .... using CFR 18 for every encode is crazy. If i am encoding an old cartoon tv show thats 30 min long and 720x480 then it might be ok, but if I used that to encode a 2 hour Live Action Bluray movie off a disc with a original bitrate of 39Mbps, then it would create an insanely large file size and a very high bitrate which would be a waste. Since my focus is on small sizes as well as good quality, you need to treat each video as an individual as apposed to picking the same CFR value for every video. So to use your own words against you, your statement is "laughably wrong".
The whole reason i started encoding in the first place is because I wanted my movies / TV Shows to be Small in size, yet I was NOT happy with encoders like "Yify" because their quality was not good enough for me. So I essentially doubled the bitrate he uses, vastly improved the audio from terrible quality AAC to excellent AC3, and still end up with fairly small size mkv's. The settings I use, along with my target bitrate, provides Amazing results to the point where nobody elses encodes are even acceptable to me anymore. So I have no plans on changing the quality I output ...... its just the process I use that I know needs improvement. -
I know, the price of bytes has been going through the roof lately.Originally Posted by manofsteel31
-
Yes, that's correct. The old television shows would be 1.33:1.Originally Posted by manofsteel31
I do it that way - encode a 1.33:1 video as 640x480, usually. But the other way is to crop away the black and then set an aspect ratio flag in the video which tells the player how to resize it. That would be similar to the 4:3 DAR of your television DVDs which are 720x480 on the DVD but which get resized to some 1.33:1 ratio like 640x480 during playback. I think a lot of the earlier discussion (didn't read much of it as there have been a whole lot of words exchanged) was about how to do that correctly. Since I don't usually do it that way myself, I didn't much care about that discussion.So shouldnt they be encoded based on that original AR?
Not if, as you claim, your interest is in having all your videos at the same quality. You sure as heck won't get that quality by doing it your way. However, many do suggest using a higher CRF for hi-def sources. I see 20 or 21 mentioned a lot. There are a lot of factors that go into how much a video will compress from its Blu-Ray or DVD source when doing them for the same CRF. If they're noisy or have a lot of film grain then they may not compress worth a damn. And if so, better than using a higher CRF to get the file size down and degrading the video quality more than you might like might be to make it more compressible by using a good denoiser.LOL .... using CFR 18 for every encode is crazy.
Okay, but don't delude yourself into thinking that your convoluted method produces anything even remotely resembling even quality among the different DVDs and Blu-Rays with which you work. Of course, you can do it however you like and if the results please you that's all that matters. Often times a lot of grain and noise can hide the imperfections in the results and some say you can get away with a lower quality when that's the case.Since my focus is on small sizes as well as good quality, you need to treat each video as an individual as apposed to picking the same CFR value for every video. -
crf encoding is variable bitrate just like 2-pass VBR. Open one of your crf encodes with bitrate viewer and you'll see. When the bitrate of a crf encode matches the bitrate of a 2-pass VBR encode the quality is essentially the same. If you look at the bitrate distribution of the two videos you'll see they are the same too.Originally Posted by manofsteel31
What you described is constant bitrate encoding which isn't even supported by x264. CBR is the worst mode of encoding.
The majority of compression in high compression codecs comes from not repeating parts of the frame that don't change from frame to frame. Why should 30 totally black frames in a video consume the same bitrate as 30 frames in a high action shot? With the all black frames the encoder can simply say "this frame is all black. Repeat. Repeat. Repeat...). That consumes almost no bitrate.
Look at the videos in this post:
https://forum.videohelp.com/threads/295672-A-problem-for-video-experts?p=1811057&viewfu...=1#post1811057
The codec is Xvid but the issue is the same. The addition of noise caused the video to use 20 times more bitrate than the clean static video. Trying to encode the noisy video with the same bitrate as the noiseless video returned a very poor picture. Encoding the noiseless video with the same bitrate as the noisy video would have wasted bitrate.Last edited by jagabo; 8th Apr 2015 at 07:52.
-
When a 4:3 DVD is displayed on a CRT TV (and even a modern 16:9 TV when it's in 4 :3 mode) the TV "overscans". That's why you don't see the crud down the sides when watching a DVD under "normal" circumstances (with a DVD player and TV) because it's off the edges of the screen (or hidden behind the pillarboxing when a 16:9 TV is in 4:3 mode). So too, is a bit of the picture. You see that crud when watching the DVD on a computer monitor as it doesn't over-scan like a TV. If you need to crop a little of the picture as well as the crud to achieve a 4:3 aspect ratio, chances are it's picture you normally wouldn't have seen due to over-scanning anyway.Originally Posted by manofsteel31
Generally it doesn't require much cropping of the picture, but the narrower the aspect ratio, the wider the black pillars will be down the sides when displaying the video on a 16:9 TV. So myself..... I tend to stick to a minimum aspect ratio of 4:3. If the picture's a little narrower after cropping just the crud, I crop a bit top and bottom to make it 4:3. That's just me though. You can of course do it however you like.
The 4:3 aspect ratio on a DVD consists of 704x480 of the resolution or picture area. That's why the whole 720x480 DVD is resized to a little wider than 1.3333 when resizing the whole thing without cropping and you get 1.367. It's nothing to do with the creator of the DVD being too lazy to remove the crud, technically that's how they're allowed to be. 704x480 should be picture, and the extra 8 pixels each side don't count, so the 8 pixels of crud own each side don't count as part of the 4:3 aspect ratio either. In a perfect world, you'd crop 8 pixels each side and resize the remaining 704x480 resolution to exactly 4:3 (or set the aspect ratio to 4:3 for anamorphic encoding). In the real world though, it's never that "neat". Sometimes there's more crud down one side than the other, sometimes there's a little top and bottom too. So I just fiddle with the cropping until the output aspect ratio is 4:3.Originally Posted by manofsteel31
Very occasionally you'd find a 4:3 DVD with no crud down the sides and so if you're not cropping anything you could resize the whole 720x480 to 1.367 (ie 656x480) but the reality is the amount of cropping varies a lot, so me...... I usually crop until the output is 4:3 even if it means cropping a little picture.
That's the difference between choosing "ITU 4:3" and just "4:3" for the input DAR in the Script Creator. For "ITU 4:3" the assumption is 704x480 = 1.333 so MeGUI resizes 720x480 to 1.367. If you select "4:3" it assumes 720x480 = 4:3.
Pretty much all 4:3 DVDs are "ITU 4:3" (in my opinion). Depending on which Input DAR you use, MeGUI adjusts it's aspect ratio error calculations accordingly, but hopefully that helps explain why you're often using a 1.367 Input DAR and aiming for a 1.333 Output DAR.
MeGUI's aspect ratio error calculation doesn't aim for any particular aspect ratio. It just indicates the amount of picture distortion. If you cropped half the width of a 4:3 DVD and resized to 320x480 the aspect error should be the same as resizing the whole thing to 640x480.
That's what the "AutoEncode" button is for. If you index a video properly the audio should be extracted (for DVD video and MKVs) and loaded into the audio section ready to encode. AutoEncode lets you add both video and audio jobs to the queue together and MeGUI will output a finished file for you. If you index another file type for which MeGUI can't extract the audio itself (ie AVI, MP4) MeGUI should create a second script for encoding the audio and automatically load it into the audio section for you.Originally Posted by manofsteel31
AutoEncode can also over-ride the x264 encoder configuration. For example if you leave the x264 configured for CRF (quality) encoding when you use AutoEncode it lets you specify a file size or bitrate. If you do (even though I'd recommend CRF encoding instead) MeGUI will automatically switch to 2 pass encoding for you and output the requested file size/bitrate so you don't need to keep changing the x264 encoder configuration.
If you specify a file size (ie 350MB) that's what you'll get, including any audio (give or take a few MB for margin of error). AutoEncode also lets you add the extracted audio to the encoding job if you want to keep the original audio rather than re-encode it (which I mostly do). If you prefer to do that, click the "X" box in the audio section to clear it before using AutoEncode.
I don't know what profiles you're referring to. I don't know where they came from. Open the script creator, click the "Config" button next to the profiles drop down box, click the "Load Defaults" button and then select the Extra Setup tab. In there, change whatever you like. Enable upsizing, change the default resizer to your preferred one, change the default mod etc, then click "Okay". That'll "reset" the script creator and it should do whatever resizing you tell it to etc. I don't know where the profile with a 720x480 resize came from.Originally Posted by manofsteel31
I have never seen the profiles to which you refer. Either they're very old, or they're very new, or they're not default MeGUI profiles (which is far more likely) but I've never seen them and have no idea where they came from. MeGUI doesn't have any pre-configured Script Creator profiles I've ever seen.Originally Posted by manofsteel31
I prefer to keep all related episodes the same resolution (not the same size in respect to bitrate) so I pick a resolution to use in advance and adjust the cropping for each episode as required to output that resolution with minimum aspect ratio distortion, but that's just me. I couldn't care less if episode one is 274MB and episode two is 453MB because they were both encoding using the same CRF value but one was harder to compress than the other, because I prefer them to be the same quality, but I do also prefer them to all have the same resolution, but that's just where my personal OCD tendency kicks in. Especially if the video is close to 16:9. Then I'd pick a 16:9 resolution and crop each episode accordingly so when they're done each one fills the entire 16:9 screen without any crud, even if sometimes that means cropping a little picture too, but that's just me.Originally Posted by manofsteel31
I mainly use my PC as a media player with overscanning disabled in the TV's settings.
For Samsung, the "16:9" picture size option (under Screen Adjustment) is the option with over-scanning enabled. "Screen Fit" is 16:9 without over-scanning. Unless the TV is in PC mode, in which case the 16:9 option is 16:9 without over-scanning and "screen fit" is greyed out. Go figure.......
When playing video via the TV's USB player the whole Screen Adjustment option is greyed out. I'm pretty sure over-scanning is disabled but I'd have to check.
I think the other guys have already covered most of that. Two pass and constant quality at the same bitrate produce identical results (any difference is so small they're effectively the same). I've tested it many times myself. If you want to pick a bitrate, just pick a bitrate to begin with, but honestly, if the choice is "same bitrate" for each episode, or "same quality", I'd go with the latter every time. You would have seen 350MB Xvid AVI encodes where one episode looks fine while the next is pretty crappy etc, and the same applies to x264 encoding. Some video is harder to compress than others so for the same quality you need different bitrates. The quality differences for a given bitrate mightn't be as noticeable with x264 as they often were for Xvid, but still, you're ultimately going to be watching the video when it's encoded, not the bitrate.Originally Posted by manofsteel31
I use virtually nothing but CRF encoding. CRF16 for stuff I'm really, really fussed about, CRF18 for most other video up to 720p, and CRF19 or CRF20 for anything over 720p (higher resolutions can usually get away with slightly higher CRF values for the same perceived quality). But that's just me......
Last edited by hello_hello; 8th Apr 2015 at 11:52.
-
While there are several things I would like to respond to, I am going to focus on the comments towards my own encoding style first.
It seems like, if I want to continue encoding my videos based on the video bitrate, then you are recommending that I switch from "Constant Quality" to "2 Pass" encoding. I can understand they theory behind that, but I have a few questions regarding it.
First, which "2 pass" option should I be using? There are several Encoding modes listed in MeGUI. I am going to assume I should pick "Automated 2 Pass" and then just enter a value within the range I normally aim for (2,200-2,399Kbps) so lets just say "2,300Kbps" since its close to the middle. There are other options that say "2 Pass - 1st Pass" and "2 Pass - 2nd Pass" and a few others. So which should i be using?
Secondly, I guess the idea is if I were to encode a video with Constant Quality and a crf value of 18, and it resulted in an encoded with with 2,314Kbps video bitrate, then encoding that the same video using 2-Pass and specifying the same 2,314Kbps would result in the EXACT SAME result. Is that really true? I understand that the end results might both display the same exact video bitrate, but how do I know that the bitrate was distributed throughout the videos frames in the same way as it would have been using Constant Quality? There is not really any real way to be sure. I mean, with the single pass Constant Quality encode, the encoder is not worried about being restrained by a pre-determined amount of pixels and gives each frame as many as it thinks it needs. Perhaps during 2-pass encoding, it is so focused about on staying within the pre-determined bitrate limit that is distributes the bitrate differently. You can only assume that the video is being analyzed the same way by the same software and is "probably" distributing them the same way. Maybe this is an OCD way of thinking, but I have been doing it the other way for so long now that I really want to know how how "exact" it really is.
Oh, and I went back into the Script Creator and I found something kind of strange. When I first load the video, it immediately tells me that there is an "Aspect Ratio Error" of "9.69907%" Before I even touch Any settings or make any changes. So how can the aspect ratio be off if nothing has been changed yet? Nothing cropped, nothing resized ..... it doesnt make any sense. It should be "0.00000%" until I start changing things. It looks like if I resize the video to "656x480" then it gets CLOSE to 0% (exactly 0.05195%) but of course it changes again as soon as I try cropping it.
Oh, hello_hello, as for the "Profiles", I have been using them since ever since I started using MeGUI. I guess I thought they came with the software but I looked into it after you said you were not familiar with them. Apparently I downloaded a pack of Profiles at the same time as MeGUI and added them into the software under someone else's recommendation. They are all very similar to the examples I posted before, just various profiles with common resizes and aspect ratio's pre-filled for easy selection. I either just pick one or modify one to make it adhear to the specific size I am looking for. So I guess when you encode you always just use a default "*scratchpad*" like this:
and then let the actual changes come from the options you pick in the Script Creator. Interesting. I always thought I needed to pick one of the profiles that were already made for me (from the pack I downloaded and added), like:Code:<input> <deinterlace> <crop> <resize> <denoise>
ORCode:global MeGUI_darx = 4 global MeGUI_dary = 3 <input> <deinterlace> <crop> Spline36Resize(720,480) # Spline36 (Neutral) <denoise>
Code:global MeGUI_darx = 16 global MeGUI_dary = 9 <input> <deinterlace> <crop> Spline36Resize(1920,800) # Spline36 (Neutral) mod8, mod16 h=1088 <denoise>
Going back to the resizing of the 720x480 4:3 DVD video, considering that I never watch my videos on a computer, and I only watch then on my Samsung TV (via a USB Flash Drive), and that said TV apparently ignores Aspect Ratio and just displays the video in the actual dimensions of the video, I am wondering if I should bother resizing to 4:3 square pixels (like 640x480) or not. I mean, if I simply rip the 720x480 .VOB file off the DVD and at the very least MUX it into an MKV without encoding it at all, then it is still going to play on my TV at 720x480 whereas I assume if I actually played the DVD itself on a dvd player on the same TV it might resize itself to 620x480 (Unconfirmed). So I am just wondering if I should be going out of my way to resize something simply because the TV ignores the Aspect Ratio, or if I should leave the image size as close to its original size off the DVD (720x480) in order to preserve as much of the original picture quality as I can.
Since I might one say save my encoded videos to my iPad (if I wanted to watch them while traveling or something), I found 3 apps that actually play x264 MKV videos with AC3 audio (it was very difficult finding apps that would decode AC3 audio, but there are a few). So I tested out out a few different sizes of encodes to see if any of them looked abnormal on the iPad. Just like "mode 2" on my Samsung TV, the apps defaulted to filling the screen with the 720x480, 710x480 and 656x480 encodes. Although the apps filled the screen horizontally and left some black bars at the top and bottom, as if it were a 16:9 video. Just like my TV though, I really didnt mind it. I realize the apps, just like the TV, have to be stretching the image in order to do that, but it still looks "normal" to me unless I am comparing it side by side with the original aspect ratio. Maybe thats just me ..... but then again if those are the DEFAULT settings for these apps, then it must be common enough that other people dont mind it either.
Sites like iTunes seem to release their 4:3 480p content at 640x480 and I am wondering if the studio's are giving them their content in that original (direct from the film cells) type of way, or if someone along the way is also converting mpeg-2 DVD 720x480 content down to 640x480. I have a feeling they are getting a more unadultered version from the 35mm film cells right to mpeg-4 square pixeled 640x480 encodes. The only reason I even bring it up is because if someone along the way really is encoding their content from mpeg-2 720x480 down to mpeg-4 640x480 then there must be a "compatability" type of reason they would do that, which in tern would make me believe that its truely mandatory for me to be doing so as well. -
Yes, you should, because if you don't the video will be displayed stretched.Originally Posted by manofsteel31
Yes, playing the DVD on a DVD-Player would display on your TV at 4:3 (or rather very close at 1.36:1, depends).Originally Posted by manofsteel31
You don't have to resize down to 640x480, you can also upsize the height only and leave the width at 704 (after cropping) if you use 704x528. You can basically use any 4:3 square pixel dimension. 640x480 is just a common one. Actually, it doesn't even have to be 4:3 – you can also crop to 710 width and then resize the height to 528. This will be slightly wider than 4:3 but still perfectly correct.Originally Posted by manofsteel31
Most likely, someone is converting 720x480 to 640x480 (in whatever manner we don't know) sourced from Digital Betacam (or similar).Originally Posted by manofsteel31
Last edited by Skiller; 10th Apr 2015 at 07:30.
-
2-pass encoding requires two passes. In the first pass the encoder examines the video to see how much bitrate each frame needs. It does this by performing a crf encode. During the second pass it uses that information to allocate bitrate to each frame so that the final average bitrate is obtained. Since your encoder supports automated 2-pass encoding you should use that. There are times when you want to separate the two passes. For example, if you want to try several different bitrates you can run the first pass once, then run the second pass multiple times, each time with a different bitrate.Originally Posted by manofsteel31
They won't be exactly the same. If you view enlarged still frames you'll see minor differences here and there. But for every frame where one looks better there will be another frame where the other looks better. Overall, watching the two videos at normal playback speed, you won't be be able to see any significant difference.Originally Posted by manofsteel31
-
Just stick with automated 2 pass. 1st Pass and 2nd pass configuration would normally be the same anyway.Originally Posted by manofsteel31
Or leave the x264 encoder in CRF mode and use AutoEncode instead, and specify a bitrate in the AutoEncode window. If you do, MeGUI will automatically switch to "automated 2 pass" for you.
The upshot of it is, if you encode a video using a specific CRF value, take note of the average bitrate, then encode it again using 2 pass encoding while specifying the same average bitrate, the two encodes will be virtually identical.Originally Posted by manofsteel31
The topic has been discussed many times, but I've literally tried the above, and played the two encodes side by side with ffdshow decoding, and ffdshow's on screen display showing the bitrate as it goes. The two pass encode will consistently be a few kb/s higher than the CRF encode for a little bit, then it'll be a few kb/s lower for a bit, then higher again, so the 2 pass encode does need to make adjustments but the difference is so small it has no effect on the visual quality compared to CRF. One of the more recent discussions on the topic where I learned a bit more about how it all works. The post is me reading the info here and translating it into something that made sense to my brain as I typed. It's actually part of a long discussion/argument, and some of my comments are replies to another poster, but if you read through the second part of the post I linked to it explains the three steps used by each encoding method and how the differ, or don't, although admittedly I'm still not sure if I understand it all completely myself yet.
In the words of one of the x264 developers.
Given the same amount of encoding time, CRF is superior to 2-pass at the same bitrate. Given the same settings rather than the same time, they're effectively identical within margin of error. My recent tests show that CRF generally has a very slight edge, albeit the difference is so small that you'd have to have OCD to care.
Translated it means 2 pass encoding takes longer because it requires a first pass. If you use slower settings so CRF encoding takes the same amount of time as 2 pass, the CRF encode will be better quality at the same bitrate. If all settings are equal (meaning 2 pass will be a bit slower due to requiring a first pass), CRF will have a slight edge at the same bitrate, but it's not enough to care.
I mainly use CRF encoding but on the odd occasion I require a specific file size for some reason, I just use 2 pass without thinking twice about it.
It makes sense if the source video is anamorphic (ie DVD video). If you've not yet enabled anamorphic encoding, MeGUI won't be setting the correct aspect ratio, or if you've not enabled resizing it won't be resizing to appropriate square pixel dimensions, so yes, until you do one or the other the aspect ratio won't be correct and there'll be an aspect error.Originally Posted by manofsteel31
If the source video is square pixels, there shouldn't be any aspect error to begin with.
I meant to mention...... have you discovered the script creator video preview doesn't display the correct aspect ratio for anamorphic encoding? Nothing to worry about. The encoded version will be correct if anamorphic encoding is enabled and if you use the preview button with resizing enabled rather than anamorphic encoding it'll resize correctly. Just thought I'd mention it......
Sounds like those profiles should be deleted as they've been confusing the issue.Originally Posted by manofsteel31
If you re-encode, you're going to have to resize to square pixels or the aspect ratio will be wrong. No way around it. The TV's media player (if it's the same as mine) assumes all video has square pixels. So it must be properly resized to square pixel dimensions to display correctly.Originally Posted by manofsteel31
I'm pretty sure even if you take the original video and stick it in an MKV the TV (assuming it'll even play it as I don't think mine supports mpeg2 video in MKVs) will probably still ignore the aspect ratio.
The TV has a 4:3 mode, but not when using the built in USB player. If you played the encoded video via a Bluray player and the Bluray player also ignored the aspect ratio, you could still put the TV in 4:3 mode and it'd over-scan and resize to 4:3 correctly with black bars down the sides (when I say "correctly" I'm pretty sure it resizes to 4:3 and not "ITU 4:3") and you can do the same for 16:9 video, but it only applies to HDMI inputs and you only have a choice between 16:9 and 4:3 so you'd need to stick to those aspect ratios. Or use an external player that's not aspect ratio ignorant like the Samsung USB media players (my Samsung Bluray player ignores aspect ratios when playing video via USB but the Sony Bluray player in this house resizes anamorphic video correctly).
I don't own an ianything but I use MXPlayer on Android and it supports anamorphic video even if the hardware decoder in the device in question does not. It also has the ability to zoom to fill the screen rather than stretch. None of the ipad players have anamorphic options? That'd be a bit icrap.Originally Posted by manofsteel31
Most of the itunes stuff is square pixels for frame rates up to 24fps. For higher frame rates, 720p is usually anamorphic. ie 25fps 720p itunes video is actually 960x720 with a 16:9 aspect ratio. My understanding is that's because older AppleTV devices max out at 1280x720/24fps, so higher frame rates require lower resolutions and anamorphic is the workaround. That'd lead me to conclude the itunes player should support anamorphic video but I don't own an ianything or have itunes installed so I don't really know.Originally Posted by manofsteel31
Would 1280x720 look better than 960x720 at 16:9? Well all else being equal it should (in theory) because the resolution is higher, but the 960x720 anamorphic stuff I've seen still looks pretty good.
I used anamorphic encoding for quite a while. When I bought the Samsung player and TV I switched to square pixels. I actually bought a Sony Bluray player for my mother even though I really didn't need a second player because it displays anamorphic video correctly and while she owns the same Samsung TV as I do and watches most encoded video via it's USB player, the Sony player is there for her to watch older anamorphic encodes (I use my PC as a media player). But I switched to square pixel encoding for pretty much the same reason I always encode subtitles for non-English parts into the video rather than keep them as a separate subtitle stream. It's just one thing less to worry about, playback wise. When someone else in the family is playing my encodes it eliminates the "why does the video look funny" and "how do I see the subtitles" questions that usually kill off another little piece of my soul. Square pixels and hard coded subtitles will always display as intended.Last edited by hello_hello; 10th Apr 2015 at 21:24.
-
OK, so I have used the last few days to do some research and test encodes in order to truly understand some of this.
To begin with, I am not sure why but every encode I do using the Script Creator comes out a little Jittery or Shakey in the beginning of my video. I have tried it repeatedly and each time I have the same problem. All I am doing is loading the video, changing the Input DAR from 4:3 ITU to 4:3 non-ITU (I will talk about that later), using a blank scratchpad profile with default settings (but selecting upsizing allowed with mod2, mpeg2 deblocking, minimal noice filter, and spline36 resize filter in the Extra Setup tab), cropping the video, resizing it, and then going to the script tab and changing "Audio=false" to "Audio=True". Nothing else. However when I use the "OneClickEncoder" (which I typically use) there is no problem.
Moving on, let me comment on the use of "4:3 NON-ITU 1.33" vs "4:3 ITU 1.367". From my research (which might be Completely Wrong for all I know), the "ITU" corresponds to "Anamorphic Encoding" which is a way for company to compress a MOVIE that was made for a widescreen display in a Movie Theater down to a smaller side to fit on a DVD Disc. It apparently squeezes the movie horizontaly. Then the DAR value is supposed to tell the Decoder how to resize the picture for proper viewing. While it was mentioned that all DVD's used ITU until around the year 2006, It seems like that should mostly apply to MOVIES and not 80's and 90's TV Shows that were made for 4:3 TV Screens. So since the content I have been trying to encode was an 80's TV Show, I am led to believe that I should base my encoding of this video on an input DAR of 4:3 1.33:1 instead. Is this wrong?
If it is wrong, then a lot of my progress from this point on might end up being worthless since all my Information is Based on encoding a 720x480 4:3 Non-ITU 1.33 FULLSCREEN DVD Full of TV Show Episodes, so hopefully that is not the case.
So in terms of cropping, am I supposed to keep cropping and resizing until the "Aspect Ratio Error" is exactly "0.00000%" or is a small error amount ok? If so, then how small is acceptable? Anything less than 1.00000%? Less than 0.09000%? Less than 0.00900%? While I should be aiming for 0.00000%, if that is not realistic without completely destroying the original video, what is considered acceptable?
If only 0.00000% is acceptable then there are not many cropping options available with the aim of keeping the encoded video close to the original. I found that there are three combinations that seem the most common ......
cropping 6pixels from the Width + 4 pixels from the height
copping 12 width + 8 height
cropping 18 width + 12 height
All three combinations with get you a perfect 0.00000% Error when resizing to the following:
640x480 (mod16)
704x528 (mod16)
720x540 (mod4)
I actually took the time to come up with every possible combination consisting of a cropped with of 10-14 and a cropped height of 0-8 (which I thought might be the most common. Most of the combinations were impossible to achieve a 0.00000% error level on the higher mods and many even impossible on the lower.
I dont really understand what "mod16, mod8, mod4, and mod2" mean, but its easier to find perfect error levels on mod2. From what I have researched, these levels have to do with the levels of compression used in the encoded video which can effect how the video is later decoded when played on a device. Apparently Older devices were unable to decode a video unless it was encoded with mod16. I dont think that inability had anything to do with the device (hardware) itself, but rather the fact that it came with an older version of the H264 codec use to decode the video, and there is noway to UPDATE the codec in the Older device. Is that true?
If so, then since all newer versions of the h264 codec can decode all mod values down to mod2, then then as long as all the devices i plan to play my videos on have an updated codec then I should never run into any problems ..... right?
Assuming this assumption was correct, I encoded a video to mod2 and then played it on every device I own that is capable of playing an mkv video (My TV, my Tablet, My Phone and even my iPod touch) and the video played on all devices. So I would assume that means there is no reason I should stick to encoding at mod16 and instead I should use mod2 instead ........... is that also right?
Anyway, moving on. Since I could not figure out why my videos encoded using the meGUI Script Creator were shaking at some parts, I went back to encoding using the same method I have been using for over a year now, which is the "OneClickEncoder". First I open the video in the Script Creator, let it "AutoCrop", and then see what the recommeded resize value is based on mod2. For example, with the video I started this thread talking about, AutoCrop removed 10pixels from the Left Side which essentially changes the 720x480 video to 710x480 which everyone here has told me is NOT an acceptable size because it does not match the original aspect ratio. So the recommended resize value is "710x540" (with upscaling enabled) and that gives me a perfect 0.00000% Error based on a 4:3 1.33 NON-ITU input. So I close the Script Creator and go back to the OneClickEncoder and use the new resize value (along with autocrop) that I just determined.
I tested this with many videos now, and as long as the only cropping needed is on the sides of the video, I dont seem to have a problem reaching 0.00000% on mod2, however when a video also needs cropping down on the top or bottom I have a hard time getting 0.00000%. I assume that is when I would need to add additional cropping to reach 0.00000% OR figure out what an acceptable Error value would be.
Finally, I would like to change the topic to my encoding style ..... I am being told that encoding based on bitrate as apposed to CRF value is NOT providing consistant quality to all my videos, although I have found all of my encoded videos over the past year to be VERY good quality. Even though the source video varies from blu-ray disc, to previously encoded video that I am re-encoding, and from HD and SD quality. Perhaps it has to do with the specific bitrate I have chosen. 2,200Kbps-2,399Kbps seems to provide me with very good results. Encoders like "Yify" aim for very small size encodes and often a bitrate of around "900Kbps" and I think his quality is OK for newer HD videos and rather Terrible for older SD sources. So maybe I just found the "sweetspot" lol, i dont know.
Then again, most 16:9 HD videos have aspect ratio's that are much smaller like 2.40:1 for example, so all that bitrate can be focused on the narrower picture itself. I have only encoded one (1) video that actually filled the entire 1920x1080 screen with a 16:9 aspect ratio. It turned out fine because it was a newer movie and the quality was already exceptional. However, just a few days ago I came across my 2nd, 3rd and 4th videos that were exactly 1920x1080 in size with no cropping needed. They were OLD animated cartoons that were professionally remastered with ab outrageously high bitrate, and when I tried to encode them down to my standard 2,200-2,399Kbps, then did not turn out all that great. This is actually the first time I have come across this problem so it is making my re-think me encoding style. I dont really want to start basing all my encodes on a single common CRF value (like was recommended to me) because a lot of videos dont need all extra bitrate they will end up with and that will just result in videos that are much bigger in file size then they need to be (which is just a waste of space). At the same time, I like to have consistency ....... not necessarily in my video output quality, but rather in my encoding style, so I dont really want to have to setup different rules from different videos. So I find myself at a crossroad while I try and figure this out. Opinions are welcome. -
Jittery or shaky at the beginning could be a few things. Do you let MeGUI analyse it to see if it needs de-interlecing or IVTC etc? It might pay to upload a sample of the original video otherwise it's impossible to do anything but guess.Originally Posted by manofsteel31
I don't use mpeg2 deblocking myself unless there's noticeable blocking as any deblocking will also blur a little. Same with noise removal, although the minimal noise filter is very light weight and probably won't make much visual difference, but it might make the video a tad easier to compress. Of course you can enable/disable them for each script you create with the script creator anyway.
I have no idea why you're changing Audio=True, but the fact there's an audio option to change is a pretty good indication you're not opening the video the best way. It seems like you're using DirectShowSource. Open the first vob file in the set (assuming you're ripping that way) or ripped MKV via the File/Open menu, let MeGUI open it with the File Indexer, add the indexing and audio extraction job to the queue and run it. When it's done, the script creator will open.
Yes, it's wrong. Or at least your interpretation of it is.Originally Posted by manofsteel31
All DVDs are anamorphic in that none use square pixels. In order to distinguish between 4:3 and 16:9 DVDs, where the pixels are a different shape (much wider), the movie industry elected to label 16:9 DVDs as anamorphic (you'll see lots of 16:9 DVDs labelled that way on the back cover). 4:3 DVDs are labelled fullscreen. Technically though, they're still also anamorphic but they're labelled fullscreen instead, because back in the early days of DVDs we all had 4:3 TVs and 4:3 was fullscreen. When discussing encoding DVDs though, they're all anamorphic whether they're 16:9 or 4:3.
Most early DVDs probably were ITU. I posted the rule of thumb I go by in one of my earlier posts in this thread. Pretty much all 4:3 DVDs are ITU (in my opinion).
ITU and fullscreen/anamorphic are two different things. ITU means 704x480 = 4:3 or 704x480 = 16:9. Non-ITU means 720x480 = 4:3 or 720x480 = 16:9.
I try to keep it at around 0.1% or less if I can, but you'd need to have a much larger aspect error for it to be noticeable. And remember, different calculators use slightly different pixel aspect ratios so they differ by around 0.1% anyway. Also remember, the difference between using an ITU input aspect ratio and a non-ITU input aspect ratio is about 2.5% in respect to how you'd resize to square pixels (ITU would be 2.5% wider) and that's still not easy to see, hence it often being hard to tell if ITU or non-ITU is correct just by looking at the video.Originally Posted by manofsteel31
Mod16 means the width or height is evenly divisible by 16. Mod8 means the width or height is evenly divisible by 8 etc.Originally Posted by manofsteel31
In the early days (mpeg2, Xvid etc) mod16 was kind of mandatory. These days for x264 encoding, it doesn't matter. Use mod2 if you like. Often though, you'll probably find you use a higher mod just because that's how the resizing works out (if you aim for a particular aspect ratio)...... 640x480 has a mod16 width and height and it's also 4:3. I use 960x540 mostly for PAL 16:9 DVDs as it's exactly 16:9 and it has a mod16 width and a mod4 height.
The only time I've ever had a mod2 playback problem is when playing mod2 video via Windows and DirectShow. That's a Microsoft API limitation. A lot of the itunes video I've seen is mod4 or mod2. It often comes in resolutions such as 1276x718, for reasons I don't understand.
Yes, it means you can use mod2.Originally Posted by manofsteel31
I don't think you've got it right just yet.Originally Posted by manofsteel31
If you take a 720x480 anamorphic video and crop ten pixels from the side and use anamorphic encoding to encode it at 710x480 the display aspect ratio will be correct. It'll be different to the original display aspect ratio because it has to be. You removed some of the "picture" (even if it was just crud). The shape of the remaining pixels doesn't change though. Look at it this way:
If 720x480 = 4:3 and you crop half the width, what's left is 360x480 and the output aspect ratio is 2:3. The remaining picture won't be distorted at all. Zero% aspect error, but there'll only be half of it assuming you're using anamorphic encoding. Nothing wrong with that, as such.
If you're resizing to square pixels (no anamorphic encoding) you'd resize the above to (for example) 640x480 before cropping and 320x480 after cropping for zero aspect error.
Mostly if you want to output 4:3 you're going to have to crop some of the picture that you normally wouldn't see due to over-scanning anyway.
Wait till you come across a DVD which requires drastically different cropping throughout a single episode. You might find it'll require 12 pixels left, 10 pixels right, except for that scene in the middle where it's 14 pixels left and 28 right, and I've seen plenty of them. Normally it's not that drastic, so I scan through the video, find the section that requires the most cropping, and then crop the whole thing that way, even if it's a bit of picture a lot of the time. At least the whole thing ends up 4:3 and cleanly cropped throughout, but that's just me. I've also cropped many DVDs differently throughout because when the cropping difference is large for just a small section, I haven't wanted to crop away a heap of picture for the rest. So I'd use Trim() to do it like this, as an example. Different cropping for frames 3000 to 4000.
Trim(0, 2999).Crop(12, 2, -10, -2).Spline36Resize(640, 480)\
++Trim(3000, 4000).Crop(14, 10, -30, -12).Spline36Resize(640, 480)\
++Trim(4001, 0).Crop(12, 2, -10, -2).Spline36Resize(640,480)
Here's an example for you. Two screen shots from the original PAL DVD (resized to 656x480). Both pics are from the same episode. The cropping I used wouldn't have been far off the above.
How I encoded it. As you can see, I had to crop more picture to make the second pic 4:3 and remove all the crud (there's nothing forcing you to crop the same amount top and bottom, although I did in this case). Do I miss the cropped part of the picture? Nope. I'd rather have no crud. That's just how I'd do it though.......
If you use the same bitrate all the time and it's high enough, all encodes will probably look fine. One might be encoded using just enough bits to look good, while the next uses way more bits than necessary, but also looks good.Originally Posted by manofsteel31
It's not logical. If you use the same CRF value each time the encodes should have around the same quality, relative to the original, each time. If sometimes the file sizes are much bigger, how can they be bigger than they need to be for that particular quality?Originally Posted by manofsteel31
Your encoding method is probably wasting space, if you use (for example) 2000kbps all the time and video "A" requires 2000kbps for a particular quality but video "B" only needed 1500kbps for the same quality, you've just wasted 500kbps that could have been used on video "C" which really needed 2500kbps for the same quality.
After you've been using CRF encoding for a bit you'll settle on a CRF value that gives you the file size you want, on average, but the quality will always be the same relative to the source for the same CRF value.
For the above series there were 38 episodes. All between 25 and 30 minutes, 640x480 and CRF18. File sizes ranged from 236MB to 457MB and bitrates from 1169kbps to 2272kbps. If I'd encoded them all at the same bitrate or made them all the same size, how would that have been better? The only way it could be is if I took the maximum bitrate for an episode and used it for all of them, but that'd be pretty wasteful. Yes, you'll re-encode a standard definition AVI encode of a movie and it'll come at out at 900MB and using the same CRF value for a 720p movie it might come out at 3.9GB, but that seems more logical than using the same bitrate for both to me.Last edited by hello_hello; 14th Apr 2015 at 10:01.
-
Yes I was using "DirectShowSource" because I thought that was the only way to use the Script Creator. I was not familiar with the "File Indexer" at all. However I tried it as you directed and it seemed to work better than the "DirectShowSource" did.
I have noticed that MeGUI does not handle .vob files very well. When i open one with "DirectShowSource" I just get a black screen in the preview window and when i tried to open one in the "File Indexer" is gave me another strange error saying it could not find the .vob file, but after closer examination it was changing the name of the .vob file and therefore looking for a file name that did not even exist. The file name was "VTS_03_1.vob" then presented me with an error saying it couldnt find "VTS_03_1_240.vob". Not sure where the "_240" came from, but whatever. I simply mux my .vob files into a .mkv and MeGUI seems to handle that much better.
I only selected "mpeg2 deblocking" and "minimal noise filter" because i noticed they were apart of the pre-made Profiles I told you about that i have been using for the past year. I figured if the quality of my encodes so far has been good then i would just keep using them, but if i dont need them then i can remove them.
OK, so I went back and encoded the video again, trying the File Indexer this time. I left the input as 4:3 ITU and just let the program AutoCrop the 10pixels off the left side. Then the resizer chose the closest size to the original video (using mod2) which was "720x534" with a "-0.00528% AR Error". Since that was lower than the "0.10000%" you recommended to me, I just left it at that. Of course, that size is upscaling both the Width and Height, but I guess that is ok. Anyway, the video turned out just as good as the rest I have been doing, and it was not shaking during in the beginning like it was when I used DirectShowSource. So I guess that is good and what you are recommending I continue doing, right?
Considering that I would MUCH rather upscale the video then have to crop out any of the actual image (unless i really have to), I understand that if I were to encode an entire season of a tv show that way then every episode would most likely be a different frame size, as apposed to your preference which is to do extra cropping in order to maintain the same frame size for each episode.
I have used the "Trim()" command before, although not as elaborately as your example. I just used it when I had a Deleted Scene off a Bluray for example, and before the deleted scene there was the director talking about it first. I would trim and encode just the scene and remove the commentary. Its always a pain because then I have the cut the audio and fix the subs as well, so I try to avoid it when i can.
Your example of different cropping in different scenes makes me think about what a challenge some rencent movies like Interstellar or The Hunger Games could be considering they have IMAX scenes in them and constantly change they Aspect Ratio from 1.77:1 to 2.40:1. Those would be a real pain if you were to try and perfectly crop the entire movie that way.
I totally understand your theory behind using a constant CRF value to maintain a constant level of quality for all your encodes, and yes even my method can be wasteful if I am assigning some videos more pixels then they need. My real problem is just maintaining the amount of hard drive space I would need to encode all videos at a CRF of 18. Part of my main goal in encoding was to keep my videos at a manageable size. I wanted then to be small enough to be portable and yet still maintain a good picture quality. Like I said, some "Scene" encoders try to do this also, but I just never felt there quality was good enough, so I following the same method, but just increased my bitrate to a higher number for improved quality (and improved upon their audio, but thats another story). I mean, my average encoded movie is probably around 2GB in size for around a 2 hour length. Encoding the same movie at crf18 would probably make a lot of them 4GB+ in size. Not only is that a lot more space, but for example if I were trying to play one of my movies on a USB Flash Drive formatted to FAT32 then I could not even put a video over 4GB onto it. Of course I could solve that problem by formatting it to NTFS instead, but thats not the point.
Just to test the theory, I just encoded 3 1920x1080 16:9 cartoons (no cropping needed as they filled the entire screen). The cartoons were only 8-9 Minutes long. I first encoded them using my method and goal Bitrate, then again all using CRF18. As you can see, the crf18 encodes are ridiculously large in file size for a 8-9 minute long video, whereas the ones encoded to my bitrate seem to be a more reasonable size for just a short video. However, I will admit that the quality was noticably better at some parts of the cfr18 encode when viewed on my Desktop Computer, however I barely noticed a difference when played on my TV.
(Getting off topic for a moment, I do notice a lot more noise/pixelation/blocking in videos when viewed on my computer that I dont notice on my TV. Does that mean the decoder is better on my TV? I always keep MeGUI and my codecs up to date, but i test my videos using Windows Media Player and MPC-HC. I just built this Desktop a little over a year ago and its very powerful, so why would the picture look better on my 3-4 year old TV?)
Anyway, back to what I was saying, here are the results:
Video 1 (8m08s):
cfr27.5 = 2,295Kbps = 147MB
cfr18 = 18.0Mbps = 1.05GB
Video 2 (8m11s):
cfr28.5 = 2,408Kbps (just slighty above my norm) = 155MB
cfr18 = 20.5Mbps = 1.21GB
Video 3 (9m09s):
cfr27.5 = 2,399Kbps) = 173MB
cfr18 = 8,774Kbps = 598MB
Video #3 was the only one that resulted in a "fairly normal" range when encoded at crf18, but still very high in size for 9Minutes of video. Video #2 was absolutely crazy! 1.21GB for 8 Minutes????? And 20.5Mbps is close to the original overall bitrate of a Blu-Ray Movie. You have to admit that is too much for only 9 minutes. Based on these numbers, how would you personally encode these 8-9 minute cartoons? Would you really still use cfr18 after seeing those numbers? By many people's standards even my resulting file sizes of 147-173MB are large for 8-9 min. -
I've never seen MeGUI handle vob files the way you've described.Originally Posted by manofsteel31
Normally if a DVD is ripped "correctly" for encoding, you'll have a set of vob files per episode or a set for just the movie etc. You open the first in the set with the File Indexer and the rest will automatically be included when indexing and extracting the audio.
When you open vob files for indexing MeGUI will use DGIndex. It's very reliable. When you open an MKV for indexing MeGUI uses ffmsindex by default. It's not quite as reliable for mpeg2 video. If you have any problems, try changing the indexing method to L-Smash in the file indexer. Me..... for MKVs with mpeg2 video I tend to open them with TSMuxer, remux them as TS files and then use the TS file for encoding as MeGUI will index those with DGIndex. The default indexer used depends on the file type, what's inside, and the formats each indexer supports.
That sounds fine. I'd probably resize to 720x540 myself as it's 4:3 and fiddle with the cropping a bit, but that's just me. Actually, NTSC 4:3 DVDs are one time you can pretty much always get away with resizing "down" (640x480) and not notice a quality loss compared to resizing "up" and if the object of the exercise is to keep the file sizes down, that'll help.Originally Posted by manofsteel31
I'd still be interested to see a sample of the video to see if there's a reason why it was "shaking" or whether it was just DirectShow decoding. You didn't say whether or not you're de-interlacing.
There's an AVS Cutter under the Tools menu. Create and save your script the usual way, then open it with the AVS Cutter. Use it to apply your "cuts" and save them to the script. The AVS cutter will also save a "cuts file" you can load into the audio section. The audio can then be re-encoded with the same edits (cuts) as the video. Or the Audio Cutter under the Tools menu can use the cuts file to split and rejoin the audio to match without re-encoding it. For subtitles, you're on your own, I think.Originally Posted by manofsteel31
An alternative is to encode the whole video, then use MKVMergeGUI to split the output MKV (assuming you're using MKV), removing what you don't want. No need to cut the audio or fix the subs when doing it that way. MKV can only split on keyframes though, which can be up to 10 seconds apart, but more often than not, x264 puts a keyframe on a scene change so you can split where you want. I sometimes copy a script a few times and use different Trims for each so each script encodes a different section of video, then I append the encodes together with MKVMergeGUI while adding the audio and subtitles (you need to check the "stitchable" option in the x264 encoder configuration to append encoded video reliably). The idea behind that is it ensures each encoded section begins with a keyframe so I can split the file at that point later. I join the encoded video, add the audio and subtitles, then use MKVMerge's splitting function to split the output into the same sections again while muxing. I don't know if that makes sense but an easy way of splitting the audio and subtitles to match the video because MKVMergeGUI splits them all together. Once MKVMergeGUI has output the MKV into two sections (or more), I just delete the one I don't want to keep.
You can't really adjust the cropping for those. The aspect ratios are too different. You need to either crop lots of the picture top and bottom for the Imax parts to make them 2.40:1 (I did that for the Batman movie), or keep the black borders top and bottom for the non-Imax parts.Originally Posted by manofsteel31
Actually..... MKVs have a feature where you can join MKVs as "segments" and they'll be played as a single MKV by the player, but segments aren't supported by many hardware players and no doubt some would require the segments to be the same resolution so doing it that way isn't practical, although it's technically possible.
If you use a higher CRF value the file sizes will be smaller, but the quality will still be the same each time. How you do it though is up to you.Originally Posted by manofsteel31
What type of cartoons? If they're Simpsons type animation, are you using the x264 animation tuning? That should help reduce the file size a bit.Originally Posted by manofsteel31
Try disabling the TV's filters and I'm sure a world of noise/pixelation/blocking will reveal itself. The TV's noise/deblocking filters are just like any Avisynth noise/deblocking filter. They tend to blur a little or remove fine picture detail.Originally Posted by manofsteel31
If you go into the Picture menu and look under Picture Options you might find a Digital Noise Filter and an MPEG Noise Filter. I think that's Samsung-speak for a noise filter and a de-blocker. If it's the same as my TV, they're like most of the other picture options. They can be set individually for each input (and the USB player and the TV tuner), so don't just change them once and assume they're changed for every input.
I guess it depends on the type of animation and x264 settings. I resize a lot of 1080p stuff down to 900P or 720p as it rarely has 1080p worth of picture detail (especially animation), and even if you lose a little, I'd rather watch a higher quality 720p encode than a low quality 1080p encode. And if you're encoding for portable devices with small screens 1080p is probably a waste of time.Originally Posted by manofsteel31
I don't encode much HD animation but for the stuff I have done (Simpson's style animation) I've used the x264 Slow speed preset with the Animation tuning and CRF18, kept the original AC3 5.1ch audio, and resized down to 720p. If I had to guess without checking, I'd say they'd average about 300MB to 350MB for a 30 minute episode (including the audio).Last edited by hello_hello; 14th Apr 2015 at 20:29.
-
What that's telling you is that you don't need crf 18. Nobody is telling you you have to use 18. You might be perfectly happy with 20 or 22 or 24. Maybe even higher. You should try encoding a few representative samples with increasing crf values until you find that the results are no longer acceptable. Then you know what your quality threshold is and you can use that value for all your encodes.Originally Posted by manofsteel31
-
Lately when when I rip a DVD (considering I am focusing on Discs with multiple TV episodes), I have been using "DVD Decrypter" to extract each episode individually by the PGC #. Its the best way to do it since it keeps each episode separate from each other while retaining its own audio and subs. Then I usually just Mux the .vob file into a .mkv using MKVMergeGUI before encoding.
Perhaps the problem I experienced with the .vob file in File Indexer was a flute and I should try it again. Since i had not had good experience with MeGUI and .vob files in the past, as soon as it happened I just immediately chalked it up to the fact that the two didnt get along, lol.
I have never worked with .TS files before. I thought those were the type of files used by online Streaming Video sites when they want to break their video into multiple parts to make it harder for people to download. Maybe I am mixing that up with something else.
Great!! So I am finally doing it right. LOL That is, in regards to my resizing of DVD videos to match the original aspect ratio. I see what you mean about 640x480 being a good choice, but for some reason I feel the need to keep the frame size as close to the DVD's "720x480" as possible. I think its because I am try to relate my videos to HD content like 1280x720 or 1920x1080. So in my mind I think "Bigger is Better" It could also be because I remember finding old XVID videos online and I always found that the smaller the frame size (for example 352x240) the worse the quality was. Now maybe that just had something to do with the fact that the encoder had no idea what he/she was doing and just did a bad job, but to me I seem to think that if I keep the frame size as big as possible that somehow the quality will be better. I guess that is crazy since in reality, the smaller the frame size is the better the picture will be (based on encoding at a set bitrate) because the bitrate will not have to be spread out to as many pixels. Oh well, as long as my process is now at least correct, thats a start.
I will work on trying to upload that video for you. I will most likely P.M. you the link when I do because I dont want to post it here publicly.
Yes, I did create a "cut.clt" file which I use to cut the Audio. I have a few other subtitle programs I use to fix the subs as well.
Like I said, I do have MKVToolNix and use MKVMergeGUI. I have used it to JOIN multiple video files into one before, but never knew I could SPLIT one as well. I will have to look into that because that might make things easier. I am genuinely interested in trying that out. From my previous example in my last post, I guess I could use it to cut out the intro commentary of a deleted scene and convert the part of the original video I am interested in into a MKV, then encode it from there. That is if my desired cut corresponds to one of those Key Frames you were talking about (dont fully understand that part).
Thats right, one of the Batman movies constantly changed aspect ratios as well. For something like that I would probably just encode the entire movie to 1920x1080 and deal with the black bars in the non-IMAX scenes (even though I HATE Black Bars, lol).
Thats right, I forgot to mention, this particular Garfield cartoon was "Progressive", so no need to deinterlace. However I have many other shows I need to do that Are Interlaced. I have used the "Analyse" button before, but honestly I dont understand the results that come up after doing it, so I just leave them alone. Should I need to change anything in the "source type", "field order" or deinterlace filter? Just for reference I looked I opened an interlaced video in MediaInfo and saw some notes saying "Interlaced" and "Top Down" so i assume I would select those options if the Analyse button was unable to figure it out itself. I still dont understand much about it though.
There is also a "Source is Anime" button that I never touch. Although I have always wondered if "Cartoons" apply to that option as well or not. I do NOT watch or encode Anime because I dont like it, but I do encode regular Cartoons obviously. So again, not sure if that option would also apply.
I have also never heard of "x264 animation tuning". So I am not sure what it does or when or how to use it. Is that something i should be using for all Cartoons? Please let me know because believe it or not I do have some Simpsons episodes I will be encoding eventually as well.
Oh ... so its the TV's built in filters that make the picture look so much better. I guess that explains it. I have never come across the settings for them and therefore have never touched them.
I am a big fan of 1080p. Not only do I try to find it because i want to base my encodes on the Highest Quality Source available, but I also have started encoding everything in 1080p that I can. I used to be unable to tell the difference between SD and HD, hen got into 720p because 1080p took up too much space. Now I am addicted to 1080p content and wont even watch SD unless they are the only option available. I even get annoyed when the rest of my family watches TV in SD when they could just as easily switch to the HD channel with a much better picture (they claim they dont see a difference, lol).
Anyway, the three cartoons I encoded as examples were the Roger Rabbit Shorts off of the 25th Anniversary Blu-Ray Disc I bought. I assume they were probably re-mastered in 1080p like the movie itself. Usually when that happens the company releases the video with an extremely high bitrate (usually in the Gbps range) to make the video look better. That is probably why a CFR18 value still produces results with a 20Mbps bitrate considering it was so high to begin with. Just a hunch. -
NTSC 720x480 is not using square pixels. If you reduce the 720 to 640 you irreversibly destroy information. However if you expand the 480 instead you still may destroy some information (due to rounding in the scaling) but far less.Originally Posted by manofsteel31
So instead of going
720x480 -> 640x480 (307200 pixels)
you would be better off going
720x480 -> 720x540 (388800 pixels)
Because in the first case you destroy 12.5% of your original resolution.Last edited by newpball; 14th Apr 2015 at 23:20.
-
That's a valiant attempt at pixel-percentage-logic, but unfortunately it doesn't hold up.
#1 There is a big difference between the horizontal domain and the vertical domain in digitization of (analog) video. The horizontal domain is made up of (originally) a continuous trace of the camera sensor, whereas the vertical domain to totally discreet and an exact # of predictable lines. Therefore, the horizontal is already predisposed to being "averaged", but the vertical actually is not. This could inherently retain/reveal aliasing if not anti-aliased (read BLURRED) during a resize. (This works along similar lines to how audio resampling needs to work to remain high quality).
#2 Even for material that doesn't have an analog origin, it is better to retain the vertical detail because of various interrelated factors - interlacing & color subsampling being the strongest, and because it is already the weakest dimensional resolution and thus most susceptible to recognizable degradation.
#3 Pre-ITU digitizing of NTSC material already had a square pixel standard of 640x480 (sometimes 640x486), which also matches the VGA computer display standard, so it doesn't make sense to ignore the standards making use of a non-standard, non-common resolution.
#4 Downsampling/downrezzing objectively retains perceivable detail much more than upsampling/uprezzing (IOW, it is easier/more accurate to interpolate than to extrapolate), even though you are "losing resolution". Both forms "destroy" the original resolution, regardless. Going to 540 does NOT give you more detail, just more pixels.
Scott -
I was going to say it's a load of rubbish.Originally Posted by Cornucopia
But I'm willing to be proven wrong. If newpball would care to provide a sample to back up his claims I'd be interested in looking at it.
I'd like to see an NTSC 4:3 DVD that when resized to 720x540 it looks better running fullscreen on my TV than the same video resized to 640x480. Especially 12.5% better. I suspect I'll be waiting a while.Last edited by hello_hello; 15th Apr 2015 at 05:39.
-
As long as you're ripping correctly there's no reason why you shouldn't be able to open the first vob file in the set, and for DVD/mpeg2 video, it'll be more reliable indexing with DGIndex. In this case I ripped three episodes to the same folder (I use DVDShrink to rip and re-author at the same time), but you should end up with something like this. Opening VTS_01_1.VOB will give me episode one, VTS_02_1.VOB episode 2 and VTS_03_1.VOB episode 3.Originally Posted by manofsteel31
DVDShrink also has an option not to split the vob files into 1GB segments, although I didn't use it here. It makes no difference when indexing with DGIndex.
TS is just another container like MKV, MP4, M2TS, VOB, AVI etc that can hold different types of audio and video. DGIndex will index TS files containing mpeg2 video but it won't index MKVs at all. I think TSMuxer will open and remux vob files too (it's a bit like MKVMergeGUI for outputting TS, M2TS and Bluray formats).Originally Posted by manofsteel31
The minute you come across an episode where the required cropping changes throughout, you'll have to start making cropping/resizing compromises if you want to remove all the crud.Originally Posted by manofsteel31
If you have two videos to encode and one is 1080p and the other is 720p (same video, lower resolution) and you encode them at the same bitrate, the 720p encoding quality has to be higher because there's less video to encode.
That's not to say the 720p version will necessarily look better, but if you're trying to reduce the file size there's a point where you can't reduce the bitrate any further without reducing the resolution or you'll start to see too many compression artefacts and a slightly lower resolution might be better. Where that point is might depend on personal taste, but there'll be a line somewhere.
My method for HD is to create a script for encoding (at 1080p), then I create another script at a lower resolution (900p), then maybe another (720p). I open each script in a different instance of MPC-HC and run them all maximised on my TV. I sync them up as best I can and then switch between them. That way I know how much I can resize down without a loss of picture detail. Once I've worked that out, I usually encode at CRF18 to CRF20 (depending on the resolution). When downscaling HD you are a little at the mercy of the player when it comes to upscaling the encoded video again on playback (some upscaling is sharper than others), and I tend to use a bit of filtering such as noise removal so I take that into account when comparing scripts too. For DVD video how it's upscaled isn't as much of an issue as it's always going to be upscaled a fair bit on playback anyway (1080p TV).
For NTSC DVDs I don't even think about it. For 4:3 I use 640x480 and for 16:9 I use roughly 854 x something, vertical resolution 480 or lower dependant on the amount of black bars top and bottom to crop, and if I want exactly 16:9 I break the rules and resize to 832x468 as it's exactly 16:9, but that's just me.
If you can resize a 4:3 NTSC DVD to 720x540 and it looks better than 640x480 running fullscreen on your TV though, please provide a sample.
I saved these as part of a discussion at doom9 recently, but here's a comparison between resizing a 720x576 16:9 PAL DVD frame to 1080p, vs resizing it to 1024x576 and then to 1080p, vs resizing it to 960x540 and then to 1080p. Spline36Resize each time. I'm sure newpball will be able to calculate the amount of theoretical information lost to five decimal places, but it's an example of why I personally look at the resizing rules more as guidelines.
They're not encoded in between resizing, just resized, or resized twice as the case may be.
720x576 to 1080p
720x576 to 1024x576 to 1080p
720x576 to 960x540 to 1080p
It's fine to attach small samples to a post here if you want to. We all do it.Originally Posted by manofsteel31
If you open an MKV with MPC-HC and navigate using Shift and the left/right arrows on your keyboard, it'll jump between keyframes (or if fast seek is enabled in MPC-HCs options and you seek while the video is paused it'll always land on a keyframe).Originally Posted by manofsteel31
Keyframes are frames which don't rely on information from other frames in order to be decoded correctly. Most other frames do. That's why you can only cut on keyframes (a keyframe needs to be the first fame in each segment). If you cut on a non-keyframe you might remove information the decoder requires in order to decode the next frame correctly.
Don't pay attention to MediaInfo for stuff like that. If in doubt (as to whether MeGUI is getting the de-interlacing right) post a sample here. NTSC can be a mixture of progressive, interlaced and telecine, so it's not always easy for a program to analyse it and get it right. Especially for animation where there's lots of repeated frames.Originally Posted by manofsteel31
I think it only applies to one particular de-interlacing method and for the rest it does nothing, but you'd only select it for Simpsons type animation. Not computer generated animation that looks more like video (I can't think of the term for it at the moment).Originally Posted by manofsteel31
Originally Posted by manofsteel31
The tunings automatically change a few of x264's advanced settings. If you change a tuning and switch to the advanced tabs you'll see some of the settings change accordingly (check the deblocking strength to begin with). The same applies to changing the speed preset. I use the Film tuning most of the time as it'll retain a bit more fine detail than tuning "None". It'll also increase the bitrate a bit for a given CRF value (there's no free lunch). The animation tuning kind of does the opposite and is for animation with large flat areas of colour (Simpsons type animation).
The source bitrate itself doesn't have a direct relationship on the bitrate required for a given CRF value. The x264 encoder just sees uncompressed video and is oblivious to how it was compressed originally. Really high bitrates might mean the original Bluray video is mpeg2 rather than h264.Originally Posted by manofsteel31
If anything, higher bitrates make for a "cleaner" source, which makes it easier to re-compress. If the source video has a low bitrate and lots of compression artefacts, the x264 encoder has to re-encode the compression artefacts too.
Resolution is a big part of it naturally, but it's not "everything". No doubt there's a difference between HD and SD, but often the difference between 1080p and 720p can be fairly minuscule. Check out my downscaling/upscaling comparison screenshots. You'll probably need to open them in individual tabs at full size and switch between them to see any difference.Originally Posted by manofsteel31
https://forum.videohelp.com/threads/369485-960x540-HD?p=2367728&viewfull=1#post2367728Last edited by hello_hello; 15th Apr 2015 at 06:49.
-
A - Original 1440x1080
B - A resampled to 720x480
Video shows:
- A Original
- B resampled to 720x540 and then resampled again to 1440x1080
- B resampled to 640x480 and then resampled again to 1440x1080
Make sure you explicitly select 1080p before you watch the video.
Some details comparing the original, 720 and 640 version
One wonders how those "purists" convert 720x480 straight to 1440x1080?
Straightforward would be 2*720 and 2.25*480.
I suppose the purists prefer first to cripple the horizontal resolution to 640 and then rescale 640x480 to 1440x1080.
Last edited by newpball; 15th Apr 2015 at 12:06.
-
Nice irrelevancy there newpball.
What we're talking about is taking an anamorphic image:
And resizing it to square pixel dimensions like this:
Despite your complete confidence the sky will fall on our heads if we don't resize it like this:
Then we resize the second image to 1080p on playback
(really 864x648 to keep it to scale with the original):
And the third image to 1080p on playback
(really 864x648 to keep it to scale with the original):
We all know the theory, but show us a real world example of a 4:3 NTSC DVD image that doesn't look as good resized to 640x480 as it does resized to 720x540. You do remember that's what we were talking about?
I could show you example after example of resizing and the effect it has (or not) and you'll just continue to ignore them if they don't suit. Is there a noticeable loss of quality due to my resizing the PAL DVD image down a little before resizing it to 1080p in my previous post, or are you going to continue to ignore examples offered and continue to be irrelevant as a result?Last edited by hello_hello; 15th Apr 2015 at 13:23.
-
I sure you all do, but I recon that "we've always done it like that", "it's more standard"and "trust us we know better" take preference to some.Originally Posted by hello_hello
Quote
Similar Threads
-
DVD Architect 5 .DAR Pathing
By flucas in forum Authoring (DVD)Replies: 1Last Post: 29th Oct 2014, 18:43 -
Virtualdub: DAR?
By higgins327 in forum Video ConversionReplies: 4Last Post: 1st Apr 2011, 06:42 -
Question on DAR and best image size for a pal movie menu background
By perfection in forum Newbie / General discussionsReplies: 3Last Post: 12th Mar 2011, 10:42 -
Is 704x480 with a 16:9 DAR valid for DVD?
By Anonymous344 in forum Newbie / General discussionsReplies: 136Last Post: 5th Jan 2011, 14:11 -
Dar, sar...
By drgt in forum Newbie / General discussionsReplies: 44Last Post: 13th Dec 2010, 13:09