have a dvdr probably made of a VHS recording of a TV broadcast. Seems to be hard telecine of blended fields. I wanted to make an MKV conversion, but when I IVTC (TFM/TDecimate) and crop/resize to make it widescreen, some scenes look pretty bad - very bouncy sharp/blurry images. I dont think it's phaseshifted; deblending with Srestore didnt improve it. Attaching clip of original letterbox video.
+ Reply to Thread
Results 1 to 30 of 51
Looks like normal hard 3:2 pulldown to me. The video was oversharpened on the vertical axis at some point. So try adding pp=0 to TFM() -- to reduce some of the bad post processing. You'll still have some aliasing problems though.
Last edited by jagabo; 18th Jul 2014 at 22:05.
wow, that was a big improvement! I, er, dont always read the usage notes on these filters.
I looked for aliasing fixes before posting, but didnt find anything that seemed applicable. Any suggestions?
Santiag(), AAA(), daa3(), etc.
thanks, I'll check them out.
Have another question - I cropped this with
It's suppose to be Cinemascope, so I resized 700x298 (2.35:1)for making an MKV. Is this incorrect?
Looks about right.
thanks. that's a nice change for me (getting something right).
Though I don't like the mod2 frame size. You may run across devices that don't like it.
I thought with MKV, as long as you got the DAR right, it didnt matter?
Some decoders don't like mod2 frame sizes. They will crash, render a distorted picture, or refuse to play the video. It's safest to stay with mod 4 or higher.
- My sister Ann's brother
what if I change my crop values to mod16 (black borders are barely visible), and set the encoder DAR to 2.35?
Megui custom setting: --sar 17:20
I understand that resizing would be better compatibility
but doesnt it effect the picture quality? And the cropped version above is mod16 - just not the right DAR.
Last edited by spiritgumm; 19th Jul 2014 at 13:19.
I would just go with 700x296 (mod4, mod16). That's less than a 1 percent error. Not worth worrying about. Or if you're going to use SAR flags just crop and use the SAR of your source, 10:11 in this case. The SAR of the pixels doesn't change when cropping. Just like cutting off the edges of a piece of graph paper leaves the grid exactly the same size it was before you cropped.
The graph paper analogy makes sense intuitively, but mathematically it does change when you crop
In this example , I'm going to call these Display Aspect Ratio, Frame Aspect Ratio, Sample Aspect Ratio
DAR = FAR * SAR
Lets' say I have a regular 4:3 DAR NTSC 720x480, and I am using non ITU aspect ratios:
ok, no problem, the --sar is 8:9
4/3 = 720/480 * 8/9
Lets say I have noisy side borders, and I crop 8 pixels from each side, for a final width of 704
4/3 = 704/480 * 10/11
The --sar is now 10:11 . If I had used the same --sar 8:9 , the DAR would be 1.304 instead of 1.333
regarding Jagabo's last post, I'm confused. I thought mod16 was a priority, so cropping to that size would be better than resizing.
If cropping without resizing, and entering Sar 10:11 in Megui, I get 2.50, not 2.35, according to mediainfo. The source was fullscreen, and cropped, it's not the correct aspect ratio.
DAR = FAR * SAR
Oops, duplicate post.
You left a little of the black bars at the sides. And I think you cropped a little off the top or bottom of the picture. So the full picture (including the remaining small black borders) is slightly wider than 2.35:1. Also, don't trust what MediaInfo says about aspect ratios.
I'm lost. I thought my original cropping 700x258 (mod4,mod2) was inadequate because of the mod2, so changing at least the vertical to 256 would fix that.
Instead of hypotheticals, please tell me how the equation above works with my video. And if mediainfo isnt to be trusted, what's the point of using it, and what else should we use? Gspot doesnt seem to work with mkv.
Probably confused you by mentioning the equation.
Well. forget the equation. For what you are doing, the equation is not useful. Mediainfo isn't useful. The equation is just explaining to you what is going on, because that's what the media player goes by. That's what mediainfo is reporting
Basically you're confusing the DAR, with the actual aspect ratio of the content
By definition, the Display Aspect Ratio is
The aspect ratio of a display is the proportional relationship between the width of a display and its height
Yes, the software mediaplayer will go by that math equation (and usually what mediainfo says about DAR). It basically "stretches" or "squeezes" the image to a square pixel equivalent.
e.g. a 16:9 NTSC DVD is stored at 720x480, but the square pixel equivalent for display will "stretch" it to ~854x480 display area . The nonITU sar is --sar 32:27 .
16/9 = 720/480 * 32/27
But when you've cropped the image, the remaining active image area is no longer supposed to fit in the same square pixel equivalent dimension of 854x480 (or other 16:9 ratio), or it will be stretched or distorted
Here is a drastic example. Lets say you have that 16:9 NTSC DVD, but really noisy junk on the left and right , and you crop away a massive 156 pixels each side , leaving you 408px width total
If you solve for that equation
16/9 = 408/480 * SAR , --sar is about 20915:10000
But if you encode with that crop and sar value, that centre image will stretch to ~854x480, which will make the image too fat. Think of jagabo' s grid analogy - you're changing the width of the little squares from ~ 1.185 (32:27) to ~ 2.091 in order to "fill" the 854x480.
If you use the old SAR of 32:27
DAR = 408/480 * 32/27, you get a DAR ~1.007 . That's because it's the new , correct DAR. That's the value mediainfo is reporting, that the mediaplayers are using, because that's the value where jagabo's little squares retain their "little square" shapes instead of becoming "rectangles"
ahhh! hypotheticals again!
I started with a 4:3, 740x480 letterboxed video. It was filmed in Cinemascope. I want to encode to MKV (h264).
After cropping the black borders, in order for it to look right, I need to either resize or encode with flagging (whichever looks better) so the result is 2.35.
Can you show me what you're talking about using my video?
Last edited by jagabo; 19th Jul 2014 at 21:33.
The DAR changes when you crop with a non-proportional w:h value. That's normal , because you want to retain the actual content aspect ratio. To keep circles looking like circles instead of ovals
The "new SAR" is the value required to keep the old DAR, which of course doesn't work when you crop. Things become distorted. The reason for that (bad) example is he's fixated on the DAR, which is not useful
Last edited by poisondeathray; 19th Jul 2014 at 21:39.
DAR = 704:480 * 10:11 DAR = 704/480 * 10/11 DAR = 1.3333
DAR = 704:256 * 10:11 DAR = 704/256 * 10/11 DAR = 2.5
still lost, so I visited this old nightmare thread: http://forum.videohelp.com/threads/308552-Resolution-vs-Aspect-Ratio
I see there's two different SARs (Sample and Storage) - very considerate of software writers for the extra confusion.
Regarding my video, when I enter the d2v into AvsP, and click on Resize Calculator tool, it says the pixel aspect ratio is 8:9, which is what I thought the SAR was...but as per Jagabo's explanation, it's a given that the SAR is the 10:11.
So, bottom line. The original video looked okay (sphere looked round), so after cropping, I only need to enter the original SAR when encoding with MEGui. No need to resize, etc., or worry about the DAR, correct?
For both computer and standalone compatibility, I would like to avoid the Mod2 (as Jagabo suggested). So instead of cropping 700x258, will crop an extra line at bottom for 700x256.
Last edited by spiritgumm; 20th Jul 2014 at 14:57. Reason: after more research
DAR = FAR * SAR DAR = Display Aspect Ratio, the final shape of the displayed picture FAR = Frame Aspect Ratio, the width and height of the stored video, in # of pixels SAR = Sample Aspect Ratio, the relative width:height of individual pixels
Basically, rec.601 specifies the 4:3 image is captured in a 704x480 frame. An extra 8 pixels is usually captured at the left and right edges in case the picture isn't perfectly centered. So the full 720x480 frame represents a picture that's slightly wider than 4:3.
The DVD spec refers to the MPEG 2 spec regarding aspect ratios. MPEG 2 (as far as DVD is concerned) doesn't directly specify the SAR, only the DAR, 4:3 or 16:9. And it says the full 720x480 frame comprises that aspect ratio. So in MPEG 2 video a 720x480 4:3 DAR frame has a SAR of 8:9.
When ITU captured video is made into a DVD the difference in SAR between the ITU spec and the MPEG 2 spec is usually ignored. The 720x480 10:11 SAR frame is simply written to the DVD. To be 100 percent correct the ITU frame should be cropped down to 704x480, or the inner 704x480 of the ITU frame should be stretched out to 720x480. But nobody in the industry seems to care about the difference (most probably don't even know). And virtually nobody notices the ~2% error when they watch DVDs. Even many DVD players are schizophrenic with respect to this, using the ITU spec on the analog outputs (composite, s-video) but the MPEG 2 spec for the HDMI output (ie the full 720x480 frame is upscaled to 1280x720 or 1920x1080 at the HDMI port).
x264 encoder configuration and MeGUI will take care of the rest.
When you create a script for encoding using MeGUI's script creator, the only aspect ratio choice you really need to make is choosing the Input DAR for DVDs (ITU or non-ITU). When you open a DVD, the Input DAR will probably default to "ITU 4:3 NTSC" or "ITU 16:9 NTSC" etc. You can change it to straight 16:9 or 4:3 resizing if you want to, but it seems ITU 4:3 is likely correct in this case. If you use any of the anamorphic encoding options which don't resize (there's only one which does) you won't change the SAR (pixel aspect ratio)* see note. You can simply crop to mod4 or mod8 or to whatever your particular level of mod paranoia might be. If I'm using anamorphic encoding I usually try to stick to a mod4 width, but the height doesn't seem to matter (I've never had a playback problem using a mod2 height).
Alternatively, you can enable the anamorphic encoding option which lets you resize. That way instead of cropping extra to make the width/height mod4, you can crop exactly what you want to and resize to mod4 instead. MeGUI will adjust the pixel aspect ratio (SAR) accordingly if you use the resize anamorphic option.
* There's one setting in MeGUI you might want to change. It's hidden away in the AVS Profile configuration, under the extra setup tab, and it's labelled "acceptable anamorphic aspect error". It's set to 1% by default, which lets MeGUI fudge the aspect ratio a little so you can crop a few pixels and still output nice 4:3 and 16:9 aspect ratios fairly easily.... but if you change it to 0% MeGUI won't do any aspect ratio fudging.
Along the lines of what's been posted earlier......
If you enable MeGUI's anamorphic encoding and switch to the Script tab, you'll see MeGUI has added a DAR to the script. It uses the DAR, along with the output resolution, to set the correct SAR. If you crop with anamorphic encoding enabled the DAR in the script will change accordingly. If you just resize though, the DAR in the script won't change. For example:
If you take a 4:3 video and crop half the width away, the remaining video would be 2:3. Half the width is gone. However you can resize to whatever resolution you like (without cropping) and the DAR won't change. It doesn't matter if you encode a DVD at 720x480, or 640x354, or 966x200, it's got to have a 4:3 (or 16:9) aspect ratio to display correctly. Not that you'd resize that way.... it's just an example. If you did though, MeGUI would change the SAR (pixel aspect ratio) accordingly so the DAR remains unchanged.
My rule of thumb.... pretty much all 4:3 DVDs use ITU resizing. Most 16:9 DVDs don't. If a 16:9 DVD has a picture which covers the whole 720 width (minus a pixel or two) then most likely, straight 16:9 resizing would be correct. If there's a reasonable amount of black/crud down the sides (8 pixels or more) then it's probably 16:9 ITU.
For the record.... I checked some video which came from itunes. For whatever reason, it's often not exactly 720p or 1080p. A few of the files I looked at were 1280x718, and 1276x718 wouldn't be unusual (I'd need to do some more checking, but I think they stick to mod4 widths).
Last edited by hello_hello; 21st Jul 2014 at 07:40.
Last edited by spiritgumm; 3rd Oct 2014 at 17:36. Reason: wrong thread -delete message
I have a similar video as the one I posted originally. Still had combing with TFM.Tdecimate, but QTGMC and Srestore(23.976) works well except the fields still have mice teeth. Trying to minimize the aliasing with Vinverse, or Blur.Sharpen, hasnt improved it. From AMC channel.