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
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
