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.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 30 of 51
Thread
-
-
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? -
-
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.
-
Not quite. Almost all standard BD, AVCHD, DVD has mod-8 frames. Many encoders and filters don't work properly unless they see 8x8 pixel blocks. Some say it can be mod-4 minimum, but I don't trust 'em. I've used some Avisynth filters that give an error if 8x8 isn't there.
- 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?
crop(6,112,-10,-112)#704x256, mod16
and
Megui custom setting: --sar 17:20
I understand that resizing would be better compatibility
spline36resize(688,292)#mod16
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. -
All h.264 decoders work with mod16. Pretty much all h.264 decoders work with mod8 (because the 1080 in 1920x1080 is mod8). Almost all h.264 decoders work with mod4.
Because DAR is a product of FAR and SAR:
Code:DAR = FAR * SAR
-
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.
-
Yes, you're right. The SAR doesn't change if you want to keep the content aspect ratio. It's explained poorly. I wrote out a longer explanation in the next post
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 usefulLast edited by poisondeathray; 19th Jul 2014 at 21:39.
-
Your source was obviously captured according to the ITU spec. With that the 4:3 picture is contained in a 704x480 portion of the 720x480 frame, and the SAR is 10:11.
Code:DAR = 704:480 * 10:11 DAR = 704/480 * 10/11 DAR = 1.3333
Code:DAR = 704:256 * 10:11 DAR = 704/256 * 10/11 DAR = 2.5
-
still lost, so I visited this old nightmare thread: https://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
-
Let's define our usage here. We'll use the more modern terminology:
Code: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).
Since your video appears to be captured from video tape and has ~8 pixel black borders left and right I would assume the SAR is 10:11, not 8:9. But either way, the difference isn't noticeable unless you measure something on screen. And if you're using a CRT display... the CRT probably has a bigger aspect ratio error than that. -
If you're using MeGUI, are you enabling the anamorphic encoding option in MeGUI's script creator? If so, you don't need to specify the SAR/DAR yourself. Leave the SAR set to "default" in the 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 h264, I really don't know how much it matters. I tend to stick to a mod4 width out of habit, but that's mostly because DirectShow decoding doesn't always behave properly when the width is mod2, but I've never had a problem playing the encoded video. The height.... I've never had a mod2 playback problem.
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.
-
wrong thread
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.