Hi Herman,
I think I have FINALLY figured out how to achieve some acceptable results!!
I used WinFF in Windows as follows:
WinFF Parameters: the file {INPUT_FILE.VOB} was the input file which
had:
width=352
height=480
Output Details:
Convert to: DVD
Preset NTSC DVD HQ Widescreen
Output Folder:
{PATH_TO_OUTPUT_FOLDER}
Video:
2 pass checked
Video Bitrate, Frame Rate and Video Size all left blank
Aspect Ratio:
16:9
The ffmpeg command executed was:
ffmpeg.exe “ -i {INPUT_FILE.VOB} -f dvd -target ntsc-dvd -r 29.97
-vf scale-720,crop=iw-0-0:ih-64-64:0:64 -aspect 16:9 -b:v 8000k -g
12 +mdb rd -trellis 1 -flags +mv0 -cmp 0 -subcmp 2 -an -passlogfile
{INPUT_FILE.log} -pass1 -y “NUL.avi”
Selected further information:
Input:
... bitrate: 2147483 kb/s
Stream: ... Video: mpeg2video <Main>, yuv420p, 352X480 [SAR 20:11
DAR 4:3], 3758 kbs, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Output:
dvd, to 'NUL.avi':
Stream: Video: mpeg2video <hq>, yuv420p, 720X352 [SAR 93:107 DAR
4185:23541],
q=2-31, 8000 kb/s, 90 ktbn, 29.97 tbc
Stream mapping:
stream -> #0:0 <mpeg2video -> mpeg2video>
Some of the parameters were new to me. I used this as a sort of template
to try ffmpeg in LINUX. I got lots of errors, so I just kept
eliminating some of the elements until I finally got to this point:
ffmpeg -i {INPUT_FILE.VOB} -f dvd -target ntsc-dvd -r 29.97 -vf
scale=720:480,crop=iw-0-0:ih-64-64:0:64 -aspect 16:9 -b 8500k -g 12
-trellis 1 {OUPUT_FILE.mpg}
This resulted in similar results, but I only did one pass. The stuff for
2 pass here did not work, so I will have to figure out how to adapt it.
I think the scale has to come before the crop (at least this worked,
whereas when I tried it before with the crop before the scale, the crop
was completely ignored).
Anyway, now I have a much better workflow which results in better
results than I can get by importing the DVD using Pinnacle Studio. I
have streamlined it further by doing something like:
cat /media/DVD*/VIDEO_TS/VTS_01_1.VOB ... (add all the .VOB files) |
ffmpeg -i - -f dvd -target ntsc-dvd -r 29.97 -vf
scale=720:480,crop=iw-0-0:ih-64-64:0:64 -aspect 16:9 -b 8500k -g 12
-trellis 1 {OUPUT_FILE.mpg}
This converts all of the .VOB files on the DVD directly to the
OUTPUT_FILE.mpg on my Hard Drive.
WinFF creates separate files for each .VOB file with the names
VTS_01_{N}.mpg.
I am now starting to use this for my Philips DVD recorder as well, as I
can create the cropped, widescreen input video .mpg which seems to be of
better quality than that which I would get within Pinnacle, changing the
4:3 original video to 16:9 widescreen.
In LINUX, it is a lot faster, and if I have a couple of DVDs, I can
convert them both at the same time, taking full advantage of the
multiple processors. In Windows, it is only possible to do one at a time.
Thanks to those who have offered suggestions. If anyone else is faced
with this, I hope this might be of some help.
Now all I have to do is figure out how to do all of my editing in LINUX instead
of Pinnacle Studio in Windows!!!!!
Murray
--- On Fri, 4/6/12, Ichthyostega <[email protected]> wrote:
From: Ichthyostega <[email protected]>
Subject: Re: [CinCV] Confused about ffmpeg -vf crop=h:w:x:y
To: [email protected]
Received: Friday, April 6, 2012, 5:59 PM
Am 03.04.2012 13:44, schrieb Murray Strome:
Hi Murray,
thanks for the detailed output.
Several things puzzled me here, both your input format and the apparent
(mis)behaviour of ffmpeg. I don't have much time right now, but I did
a quick test, just using a bit of OGG 256x192 video I had right here.
First thing I found out is that I mixed up the syntax and told you something
wrong. My apologies for that. Actually, when we want to build a *filter-chain*
(which is what we want), we need to define all the filters to apply within a
*single* argument, separated by comma. If we give multiple '-vf' arguments, it
seems that just the last one wins.
Thus, in my example case, it needs to be:
-vf crop=in_w:in_w*9/16,scale=1280:720
(note there is no whitespace!)
The second thing I found out is: the parameter -s hd720 seems to add some
further magic, which seems to work against our intentions here. When I use
this setting, ffmpeg does an *additional* scaling right at the beginning,
*before* applying our filter chain.
Thus, in my experiments:
ffmpeg -i INPUT.ogg -vf crop=in_w:in_w*9/16,scale=1280:720 \
-t 150 -sameq OUTPUT.mov
This yielded the expected result of cutting out a 16:9 middle part and
scaling this up to fill the full 1280 x 702 sized frame
('-sameq' just picks the same bitrate as the input has)
When running this command, I see
...
ENCODER : ffmpeg2theora 0.20
[buffer @ 0xaa6220] w:256 h:192 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:
[crop @ 0xac4020] w:256 h:192 -> w:256 h:144
[scale @ 0xac4aa0] w:256 h:144 fmt:yuv420p -> w:1280 h:720 fmt:yuv420p flags:0x4
Output #0, mov, to 'output.mov':
...
...
> Here is an example of the first part of the message. Here the video is
> 352X480 aspect 4:3 and I want to get a result which cuts off the black bands
> at the top and bottom. I am assuming that the crop is supposed to work on the
> input video, so I set the crop to keep the original width but remove the top
> and bottom, then rescale.
> $ ffmpeg -i VTS_01_1.VOB -vf crop=352:270:0:0 -vf scale=1280:720 -s hd720 -b
> 8500k WC-VOB-1B.mpg
...
> Input #0, mpeg, from 'VTS_01_1.VOB': Duration: 01:00:10.37, start: 0.521789,
> bitrate: 2379 kb/s Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p,
> 352x480 [PAR 20:11 DAR 4:3], 3758 kb/s, 29.97 fps, ....
> [buffer @ 0x210b520] w:352 h:480 pixfmt:yuv420p
> [scale @ 0x210b1e0] w:352 h:480 fmt:yuv420p -> w:1280 h:720 fmt:yuv420p
> [scale @ 0x210fec0] w:1280 h:720 fmt:yuv420p -> w:1280 h:720 fmt:yuv420p
> Output #0, mpeg, to 'WC-VOB-1B.mpg':
> Metadata: encoder : Lavf53.3.0
> Stream #0.0: Video: mpeg1video, yuv420p, 1280x720 [PAR 20:11 DAR 320:99],
...
Well, first off, you hit the same problem as in my case (no crop, and the
-s hd720 has added an additional scaling right after the "[buffer]..." stage)
But besides, your situation is somewhat more complicated.
I'll try to work out a solution "theoretically"...
Your input video has non-square pixels. It is "anamorphotic", i.e. it is
compressed horizontally:
[PAR 20:11 DAR 4:3]
this means, the pixel aspect ratio is 20:11, while the result is to be presented
with an display aspect of 4:3.
Thus, the decoder will stretch each pixel horizontally by the factor 20/11
Measured in sqare pixels (as on your screen) 352 * 20 / 11 = 640
(this makes sense, 640:480 == 4:3)
What seems to happen next is that these non-square pixels are just stretched
out (maybe rounded to get an even number of 16-pixel blocks). The result is
just labeled with the resulting aspect ratio of 320:99, and the non-square
pixels are retained: "[PAR 20:11 DAR 320:99]"
When encoding video, the display aspect ratio is always just placed into the
metadata, since it's the *de*coder's job to stretch the video to fit this
presentation aspect ratio.
This leads me to the conclusion that we need to state explicitly that the result
is intended to have the aspect ratio of 19:9 (and since we additionally also
stretch explicitly while transcoding, the resulting pixels should be square).
One final note: in your crop-command, "-vf crop=352:270:0:0", you also set the
origin of the crop window explicitly to the upper left corner (0,0). This is not
what you want, it will result in a huge black bar and the image shifted down.
Just leave out those parameters, the default is to center the crop window,
which is just a perfect fit for our purpose.
Thus, in your case, you might want to try out the following command....
ffmpeg -i VTS_01_1.VOB -vf crop=352:360,scale=1280:720 -aspect 16:9 \
-b 8500k WC-VOB-1B.mpg
alternatively we could just let ffmpeg do the math; the following should
yield exactly the same result:
ffmpeg -i VTS_01_1.VOB -vf crop=in_w:in_w*20/11*9/16,scale=1280:720 \
-aspect 16:9 -b 8500k WC-VOB-1B.mpg
Hopefully now this behaves as intended (?)
Please feel free to ask if I should explain some details more in-depth.
Cheers,
Hermann V
