I am converting a movie from an old PAL DVD to MP4. The original MPEG-2 content in the VOBs is reported by FFmpeg as 720x576 [SAR 64:45 DAR 16:9].
I'm using an AVISynth script to crop the anamorphic content (sans letterbox) to its actual stored size of 704x414*, to clean up the picture a bit, and to interpret the frame rate as 24 instead of 25. I am then using FFmpeg to read the raw video output from AVISynth and do an x264 encode into an MP4 or MKV container. (I'll deal with the audio later.)
What FFmpeg aspect ratio settings (-aspect and/or -vf setsar,setdar) should I use to signal that the resulting MP4 should be stretched horizontally by the appropriate amount upon display? Do I need to take into account that the movie was shot at 2.35:1?
I thought perhaps setsar=64/45,setdar=235/100 might be right, and it doesn't look bad in VLC, but with those settings, FFmpeg reports the output file has [SAR 9729:7040 DAR 47:20], so I am misunderstanding something fundamental, I think, and I'm not sure if it really is the perfect aspect ratio after all.
When researching this issue before posting, I saw other examples saying that people tend to go for maximum compatibility instead by just doing the stretching with the scale filter, so that the resulting file can have 1:1 pixels, but I'd rather keep the file size down by keeping it anamorphic until final display. Or is that foolish?
Here's my FFmpeg command line:
Here's my AVISynth script:Code:ffmpeg -i template.avs -vf setsar=64/45,setdar=235/100 -c:v libx264 -profile:v high -level:v 3.2 -preset ultraslow -crf 20 -y out.mkv
* The movie's picture is more like 700x422 in the anamorphic frame; I'm cropping it to 704x414 to ditch the letterboxing and fuzzy top/bottom edges; I'm not worried about the pillarboxing as it's only a couple of pixels on each side.Code:LoadPlugin("E:\apps\DGMPGDec\DGDecode.dll") MPEG2Source("G:\blahblahblah\VIDEO_TS\pw.d2v",iPP=false,cpu2="xxxxxx",idct=3) Trim(39560,end=233824) Crop(10,80,-6,-82) # various picture cleanup settings omitted for brevity AssumeFPS(24)
+ Reply to Thread
Results 1 to 20 of 20
Last edited by ItaloFan; 23rd Aug 2019 at 14:45. Reason: Made asterisk note smaller
SAR doesn't change when you crop. Regardless of what VLC reports, if SAR was 64:45 before cropping it's still 64:45 after cropping.
I know zilch about FFmpeg and even less about Avisynth but....
Your approach could be foolish if you player/tv can not handle non-square pixels in a non-dvd container
Now this may equally be foolish but consider how that 16:9 720*576 dvd actually displays. It will become 1024*576. So whatever height you get from the crop you still have a width of 1024 pixels and I would have thought you set you DAR accordingly.
Actually, the ~8 pixel pillarboxing at the left and right edge suggests the video is an ITU cap giving a SAR of 16:11.
As jagabo wrote, cropping does not change the SAR. The SAR is only changed when you would also resize.
From your description I do however have have some doubts that the SAR is really 64:45 (even though ffmpeg reports it as such) and that the movie aspect ratio is 2.35. Old 16:9 PAL DVDs do often have an ITU SAR of 4600/3159 (approximated by 16:11) which would give an active anamorph picture of 704x428 for a 2.40 movie which would be pretty close to your "700x422" finding for the cropped size. Just speculating …….
Edit: Ooops, jagabo was faster
^^ That may be so but there is no escaping that the original source is a dvd and 16:11 does not exist in that medium.
Surely better to crop/resize to that and then remove the pillar-boxing. In my eyes the OP just complicates the whole issue in insisting on retaining non-square rather than work with square pixels 1:1 which will display correctly whatever the combination of tv/player
I'm not advocating resizing, even though I resize myself, however some shameless promotion might help you. Use the script to resize to square pixel dimensions so you can compare one pixel or display aspect ratio with another, and so you'll know what to expect when it's encoded, then start with the aspect ratio you think is correct, whatever you do from there. The script has a mode that will stretch the width while only cropping the height, or resizing can be disabled completely if that's your preference.
Personally, I only choose between a generic or an mpeg4 input display aspect ratio because they're easy to remember and the same for PAL and NTSC.
For 16:9 the mpeg4 equivalent is 20:11 and for 4:3 it's 15:11. If you do the maths they give you the correct mpeg4 sample aspect ratios, which are so close to ITU it doesn't matter. https://forum.doom9.org/showthread.php?p=1058927#post1058927
I don't think I've met a 4:3 DVD that wasn't 15/11 (or ITU), although I think most modern 16:9 DVDs are exactly 16:9, but if there's crud down the sides I'd assume 20/11.
Last edited by hello_hello; 23rd Aug 2019 at 19:34.
I tried and tried, including using the suggested CropResize(), but just got more confused. FFmpeg's setdar/setsar always puts in the output file different values than I specify, it never quite looked right, CropResize() was doing unexpected additional cropping, and I did not know what to do with the values it gave me anyway... so I gave up on the idea of keeping the transcoded movie anamorphic, and just went ahead and did the horizontal resize in my filters before the crop:
Spline36Resize(976, 576) Crop(18,80,-12,-80)
I happen to have the NTSC DVD which gives me perfect circles at 16:9, so I messed around with VLC screenshots in Photoshop a bit and figured out how much to scale the images to get them perfectly synced. This was complicated slightly by the fact that I was not dealing with the borders but rather the actual movie picture; the PAL version was mastered such that it was cropped more than the NTSC. The ideal PAL scaling ended up being a few pixels away from the mod 16 values of 976x576 (61:36), but the error is too small to notice, so I went with the nice round numbers. After cropping out the letterbox and pillarbox, it's 946x416.
Original PAL 720x576:
Original PAL playing in VLC at 1024x576:
Original NTSC 720x480:
Original NTSC playing in VLC at 853x480:
PAL resized to 976x576, cropped to 946x416, with color adjustment (this is my final version):
Last edited by ItaloFan; 27th Aug 2019 at 01:56.
If DVD is not messed up and with some bars on left and right as well:
1.crop 8pixels left and right to 704x576 (or 704x480 for NTSC)
-- forget whatever there is left on side, no one cares
-- if there is more on one side , cut off 2 or 4 more pixels from one sides but total only 16pixels
3.crop top and bottom
Last edited by _Al_; 26th Aug 2019 at 23:42.
Thanks again. I understand the reasoning; why not keep it simple and create what you get when you play the DVD on a real player, and not strive for anything better than that level of good-enough?
I also just pored over the delightful debate you guys had a couple years ago about this stuff.
The problem for me is that this particular PAL DVD seems to be mastered in such a way that making it 16:9 (regardless if you crop to 704 or leave it at 720 before widening to 1024 or 1048) is not ideal; round things on screen end up very slightly oval. Not sure if this is the ITU issue mentioned above, or a mistake, or standard practice in the early 2000s, or what.
PAL DVD cropped (10 left, 6 right) to 704x576 before resize to 1024x576:
(it's comparable to the VLC 1024x576 image in my previous post)
Also, I am just one of those newbies who wants:
- aspect ratio as intended for the film, rather than for the viewer of the DVD, i.e. round things like the clock in these screenshots are perfectly round
- reasonably good quality before it gets to the player, so no changes to vertical resolution, aside from cropping
- minimal black bars in my files
- minimal loss of picture boundaries due to cropping to mod 4, 8, 16, whatever (dimly lit rows/columns are expendable though)
- compatibility with my own devices only
I thought that keeping it anamorphic and relying on the player to honor PAR & DAR metadata would be a nice-to-have, but if player compatibility is really that big of an issue, I am fine with doing the resize myself, and sticking to tried-and-true methods.
Regardless, I thought surely someone would have worked out a guide for how to do it all by now in a mathematically sound and idiot-proof way, but the issue of cropping and aspect ratios seems to still be firmly in the realm of arcane voodoo, everyone just winging it in their own ways, with conflicting philosophies and different levels of tolerance for imperfection (or for each other's views).
I am familiar with this from the world of audio. "How perfect does it really have to be?" someone once asked me, referring to the latest and greatest digital format, and I had to admit that I was worried about basically nothing. Same here. So the clock is a little oval, a couple pixels too wide to be a perfect circle...so what? I wasted all my spare time for a week on this, for a movie I don't even like that much anymore. I just want to get it into a more convenient format than the stupid DVD and then never have to think about it again...yet here I am, worried that I have settled for some imperfection that nobody will ever notice in real life. I just was naively hoping that it was not really so difficult to get a slightly-better-than-good-enough result.
There's several ways to do it, but when resizing to square pixel dimensions, the simplest way is to specify just an output width or height, or neither, and let the script do the rest. The picture is not resized while a cropping preview is enabled, so there's "with" and "without" screenshots. By default, the picture is also darkened a bit when Info=true to make the text easier to read. I used your cropping, and 0 for the width and height (not specified).
So the idea was to use the script to compare how the picture looks when resized to square pixel dimensions using different input DARs. The result should be the same when using anamorphic encoding and the picture is resized on playback.
mpeg4 vs generic input DAR
(Pics removed as the forum software is resizing them. They were the same as the resized thumbnails below anyway, so click on them)
Link to gallery. https://postimg.cc/gallery/14k1bc602/
mpeg4 Input DAR
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, CPreview=1, Info=true)
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, Info=true)
Generic Input DAR
CropResize(0,0, 18,80,-12,-80, InDAR=16.0/9.0, CPreview=1, Info=true)
CropResize(0,0, 18,80,-12,-80, InDAR=16.0/9.0, Info=true)
There's a mode that works much the same way, but it prevents the script from resizing the height (it only crops). You can specify an output width, but for the same reason as mentioned previously, that could cause the script to crop the width, so it's simplest not to specify one. Examples for an mpeg4 input DAR.
mpeg4 Input DAR
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, ResizeWO=true, CPreview=1, Info=true)
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, ResizeWO=true, Info=true)
With resizing disabled, the sample (pixel) aspect ratio doesn't change, but the output DAR and SAR are both displayed. For anamorphic encoding you'd disable resizing and use the specified SAR for encoding.
mpeg4 Input DAR
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, NoResize=true, CPreview=1, Info=true)
CropResize(0,0, 18,80,-12,-80, InDAR=20.0/11.0, NoResize=true, Info=true)
In full resizing mode, if you specify just a width or height, the script will calculate the other one for you and any extra cropping to prevent aspect error will be fairly minimal.
CropResize(960,0, 18,80,-12,-80, InDAR=20.0/11.0, Info=true)
Last edited by hello_hello; 28th Aug 2019 at 13:56.
hello_hello, thanks for trying, but I can't say those examples help me understand CropResize()'s utility here, given that you got four different interpretations for one 20/11 input DAR (why not input SAR?), and none of them make the clock be as close to perfectly round as I'd like.
The behavior when CropResize() is given the anamorphic source is also confusing; I would have thought 18 and -12 probably aren't the ideal values for the left and right crop on that example; those are what I used after stretching the 720x576 original to the 976x576 close-to-ideal. Don't you want to use 10 and -6 instead?
Using this info to set the FFmpeg setsar/setdar filters or its -aspect option correctly when encoding a cropped anamorphic source is still a mystery. Even if I figure out some combination of inputs to CropResize() that looks right, it's unclear whether I could actually reproduce that result with FFmpeg. My initial attempts were disappointing.
I'd be happy to provide a source clip as suggested by video.baba; I'll do that as soon as I can.
Last edited by ItaloFan; 28th Aug 2019 at 19:03.
Keep in mind that camera lenses sometimes distort near the edges of the frame. And clocks aren't always perfectly round (see Salvador Dali). So I wouldn't take a single shot like this as a definitive indicator of the aspect ratio.
If you're not using an image program to check for "roundness" by drawing circles it's easy for your brain to fool you because it adjusts to what it expects to see in real life. That's why the slight difference between mpeg4 and generic aspect ratios isn't overly-critical. I've used an image program to draw circles around round objects that I would've sworn were round, but they weren't.
You can enter either a SAR or an equivalent DAR and the result will be the same.
InDAR=20.0/11.0 and InSAR=16.0/11.0 will give you the same result for a PAL DVD. The script displays both input DAR and SAR regardless of which way you enter it.
InDAR=16.0/9.0 and InSAR=64.0/45.0 will also give you the same result for a PAL DVD.
For the mpeg4 vs generic screenshots (the 1st and 2nd resized ones) the first one, based on the mpeg4 DAR, ends up a little wider because the source pixels are wider. The input DAR wasn't the same for the second one. The reason the cropping is a little different is because the picture has to be resized to "whole pixel" dimensions (a mod4 width or a width divisible by 4 is the default), so the script crops a fraction more from the width or height before resizing to compensate. If you compare the first two after resizing, you'll see the main difference is simply the amount the picture is stretched due to the difference in input DAR/SAR.
For the third example the script is in a mode where it's not allowed to resize the height, so when the width is resized it has to be reduced for mod4 dimensions (if need be), and the script can only crop extra from the width to prevent aspect error. If you compare the first and third resized screenshots you'll see objects in the picture have exactly the same shape, as they both started with the same InDAR, but the script cropped extra from the sides for the "ResizeWO" example to prevent distortion (the resized width is 1000 rather than 1004 for full resizing mode).
For the fourth screenshot the script isn't resizing so it can only crop whole pixels, and by default it increases the cropping to mod4 dimensions if necessary. It doesn't have to worry about the picture being stretched/resized to whole pixel dimensions on playback or resized to a mod4 width, and couldn't do anything about it anyway, so it crops the picture, you set the appropriate SAR for encoding, and resizing becomes the player's problem.
The way I understand it, for ffmpeg's cropping you tell it how much picture you want to keep and where to start keeping it from.
An Avisynth cropping of Crop(18,80,-14,-80) would translate to the following for a 720x576 picture.
720 - 18 - 14 = 688
576 - 80 - 80 = 416
I assume you just tack-on the appropriate SAR. ie.
If that's correct and you crop with the script as per the fourth "no resize" example and use the same cropping and SAR for encoding as for ffmpeg, the encoded video should be resized the same way on playback. How it's resized depends on the SAR you decide to use. I'd go with 16/11 for that one.
Last edited by hello_hello; 28th Aug 2019 at 22:16.
Thanks. I am indeed using Avisynth to crop and clean up, and am using FFmpeg to invoke Avisynth and encode x264 into an MKV container.
Attached are two clips showing round things. I do understand the point about it all being subjective because there's no way to know what the camera lens was doing or whether objects are perfectly facing the camera or what. I just decided I liked the roundness of the clock on the NTSC DVD playing at its natural 16:9 ratio, so I set out to find an aspect ratio that would make the PAL DVD match it, after cropping out the black bars. And yes I also was using Photoshop to draw circles, but as you mentioned, it's so tiny an object, it's hard to know anything for sure.
I'm including the NTSC DVD's versions of the clips for reference and fun. I'm only using the PAL for my transcode.
The reason for my crop not being perfect was because I thought there was some advantage to sticking with mod-16 values.
Last edited by ItaloFan; 29th Aug 2019 at 16:35.
One of them must be borked, or both.
To make the PAL version display the same as the NTSC version with an input display aspect ratio of 16:9 before cropping (SAR 32:27), you need to use a display aspect ratio of 32:19 or 16:9.5 for the PAL version (SAR 128:95).
It's pretty close anyway. You can always fiddle with it some more. However you crop or resize or don't etc, an input SAR of 128:95 for the PAL version should display much the same way as the NTSC version using SAR 32:27.
The first is (NTSC)
CropResize(960,0, 6,54,-8,-60, InDAR=16.0/9.0, Info=true)
CropResize(960,0, 6,54,-8,-60, InSAR=32.0/27.0, Info=true)
The second is (PAL)
CropResize(936,0, 16,80,-14,-80, InDAR=16.0/9.5, Info=true)
CropResize(936,0, 16,80,-14,-80, InSAR=128.0/95.0, Info=true)
I made the output widths different to match the height, as one has more black down the sides than the other and it's easier to compare them, but objects in the picture are now much the same shape.
Mod2 is generally fine for h264. I've seen some itunes video with a mod2 height. It's probably safest to stick with mod4 for the width, or for both the width and height (the CropResize default), but mod16 is unnecessary these days.
Edit: I did something stupid, will replace the screenshots shortly.
Edit: Screenshots replaced.
Last edited by hello_hello; 29th Aug 2019 at 19:26.
OK, I'm still pretty lost, but I did have some success in trying to keep it anamorphic by using setsar with values provided by CropResize. Thanks for your patience.
To crop the black from the PAL source, mod 2 (actually mod 8), in my script I have:
Crop(14,80,-10,-80) # 696x416
Through trial and error, I arrived at 16/9.525:
CropResize(696,0, 14,80,-10,-80, ResizeWO=true, InDAR=16.0/9.525, Mod=2, Info=true)
Then I was able to use the 512:381 SAR the info screen gave me:
ffmpeg -i foo.avs -vf setsar=512/381 ...
The output is 696x416 [SAR 43:32 DAR 3741:1664] (I have no idea where FFmpeg gets these numbers). It plays in VLC at 935x416, and works perfectly on my TV via a Roku. Hallelujah! Thanks!
It's a pity the PAL transfer is so blurry. The NTSC DVD is quite a bit sharper, despite the reduced vertical resolution. My attempts to apply IVTC to it were not to my liking, though. After undoing the 3:2 pulldown there are still occasional blended fields, i.e. in a frame that is supposed to be progressive, one field looks like a badly scaled interlaced picture, itself... some kind of artifact from a PAL conversion? Possibly also chroma interlaced separately from luma. I see other people have experienced the same problems and like me, decided it's just too difficult to restore 100% 24 fps progressive frames with the blended fields properly replaced.
The original SAR is probably converted from a fraction to floating point, which for these sorts of numbers can be relied upon to be accurate to 4 decimal places, and when it's converted back to a fraction there's generally some margin for error allowed to prevent the numerator and denominator from being really huge numbers. For Avisynth the "allowable error" is set by the limit argument.
CropResize uses Limit=5000, which is plenty for this sort of thing, but it's only used for displaying aspect ratios as fractions when Info=true, or for calculating the DAR for MeGUI.
ffmpeg has a "max" argument that sets the maximum integer value for numerator and denominator when converting to a fraction. It looks like the default is 100.
LSFMod(Strength=75) # the default is 100
gradfun3() # from DitherTools to help prevent color banding.
MCDeGrainSharp can also be quite effective.
They're all pretty slow.
Last edited by hello_hello; 1st Sep 2019 at 05:31.