ffmpeg command line value for SUPER "Stretch it"
The free front-end for a few encoders, SUPER, has an option available only when ffmpeg is used. It is a check box under the Options panel named "Stretch It". I've looked through all ffmpeg documentation, but I couldn't figure out which ffmpeg command line parameter corresponds to that SUPER setting. Many thanks for any help.
I just had a look at the "stretch-it" command in Super.
It reports it's function as "stretches the video image over the entire canvas"
FFmpeg does this automatically using the libswscale library based on the output dimensions. (eg. -s 1920x1080)
For example: If you had a 4:3 640x480 movie and wanted to stretch it to 960x480, you would only need to specify the ouytput dimension and ffmpeg takes care of the rest.
example command line:
ffmpeg -i test.mov -vcodec libx264 -s 960x480 output.mov
...of course this can be further manimulated using the -aspect flag.
Thank you very much Mike for the FAST answer. What I don't get yet is how the "Stretch It" box is translated into the ffmpeg command line when it's checked in SUPER, and how the ffmpeg command line looks when it's unchecked. I know the SUPER output is different, but SUPER being just a front-end, the ffmpeg commands must be different. Many thanks again!
Maybe I should explain in more detail what I'm trying to do.
I encode a video clip with an aspect ratio of 2.39:1 to a 4:3 frame size using SUPER with the "Stretch It" box checked. The resulting image is stretched on all the frame. That output I can then modify with mp4box command: mp4box -par 1="67:38" clip.3gp. The modified clip is played at 2.39:1 by players which can read the aspect ratio field from the 3GP file header (VLC Player, KMPlayer and SMPlayer cand do that). However, QuickTime Player, WMP, CorePlayer and other players ignore the aspect ratio field and play the clip at the 4:3 aspect ratio, derived from the frame resolution.
If I encode the clip in SUPER with the "Stretch It" box unchecked, at the same 4:3 aspect ratio, the resulting clip is 4:3 image (not the source 2.39:1), but all the players add black bars top and bottom. After I run mp4box, all players run the clip letterboxed but at the correct 2.39:1 resolution.
The problem is that SUPER offers only small frame sizes for encoding to 3GP (maximum 356x288) and I need to encode to higher resolutions than that. Since SUPER is only the front-end for for ffmpeg, I'm trying to understand how to run ffmpeg in one case, or the other, and skip using SUPER.
Thank you for your attention!
It seems to me that the confusion over the SUPER "stretch it" command is related to the function of what it turns off in FFMpeg rather than what it turns on.
To replicate the behavior using the FFMpeg command line tool:
1. "Stretch it" button ON
This occurs in ffmpeg as standard behavior.
Take this command line for example to produce a stretch between source and destination:
NOTE: source size is 1024x576, hence square pixel 16:9 or 1.777778
NOTE: ignore the "%", it is just my way of saying: type the following into the command line and hit return.
% ffmpeg -i fluid.mov -vpre libx264-hq -vcodec libx264 -s 1024x768 -b 3000k stretch.mov
This will produced a stretched output. It is the 4:3 output image size which is causing the stretch because it is 1024x768, hence square pixel 4:3 or 1.333333
2. "Stretch it" button OFF
This requires the -padtop and -padbottom commands as well as the image size intended before black bars are added, NOT the final image size.
% ffmpeg -i fluid.mov -vpre libx264-hq -vcodec libx264 -s 1024x576 -b 3000k -padtop 96 -padbottom 96 letterboxed.mov
This will produce a 1024x768 4:3 square pixel result with black letterboxing top and bottom.
You can also perform the aspect ratio setting you are making with mp4box by adding a simple command in ffmpeg: -aspect
% ffmpeg -i fluid.mov -vpre libx264-hq -vcodec libx264 -s 1024x768 -b 3000k -aspect 16:9 stretch_and_correct.mov
This produced a file with a 4:3 source frame size which displays as 16:9 in Quicktime X and Quicktime 7 (on Snow Leopard).
Hopefully this is enough to solve your size/aspect issues.
As for your container choice, why 3gp? As this is designed for mobile devices, I am guessing that there is a maximum size which is why super wont allow you make it larger. Makes sense. I'll give it a go anyway....
% ffmpeg -i fluid.mov -vpre libx264-hq -vcodec libx264 -s 1024x768 -b 3000k -aspect 16:9 -f 3gp stretch_and_correct.3gp
Yep. works. Aspect ratio conversion works. Plays in Quicktime. I seriously doubt it will play on any mobile devices though seeing it is a High Profile, Level 3.1 AVC stream!!!
I would suggest doing some googling to find out maximum sizes for the devices you are targeting (as well as the profile and level limits for H.264 which is a whole other story). Supposedly, 3gp works with other codecs as well so you might even need to go H.263 for compatibility with all devices.
If it was for computers and the web only, I would definitely go for mp4 as the container and the proper square pixel dimensions for 2.35:1 material ie. 470x200 or 1692x720 and forget about the aspect ratio conversions. This will ensure the material is always played back in the correct dimensions.
Which OS are you using?
Are you running ffmpeg from the command line?
Thanks again Michael for your help.
To create the "Stretch It" box checked in SUPER from ffmpeg command line, for 2 pass encoding I did this:
ffmpeg -i clip.avi -an -vcodec mpeg4 -pass 1 -b 1280k -s 640x480 -aspect 2.39 -f rawvideo -y NUL
ffmpeg -i clip.avi -acodec libfaac -ab 128k -ac 2 -ar 44100 -vcodec mpeg4 -pass 2 -b 1280k -s 640x480 -aspect 2.39 clip.3gp
The output of this command is identical, from a player point of view, with that of SUPER checked box. It plays in VLC, SMPlayer and KMPlayer in a window 1148x480 with the aspect ratio set to default or auto. However, in less intelligent players like QuickTime Player and CorePlayer, the 3gp clip plays in 640x480 window, 4:3 aspect ratio.
I wasn't yet able to reproduce what SUPER does with the unchecked "Stretch It" box.
These two commands, don't create the same output like that created by SUPER:
ffmpeg -i clip.avi -an -vcodec mpeg4 -pass 1 -b 1280k -s 640x268 -padtop 106 -padbottom 106 -f rawvideo -y NUL
ffmpeg -i clip.avi -acodec libfaac -ab 128k -ac 2 -ar 44100 -vcodec mpeg4 -pass 2 -b 1280k -s 640x268 -padtop 106 -padbottom 106 clip.3gp
The clip created by SUPER is 320x240 (I don't have 640x480 available there). However, with the aspect ratio set to default in SMPlayer, VLC and KMPlayer, SUPER's clip plays in a window 320x430 with 95 pixels black bars top and bottom. The movie itself is 320x240. However, QuickTime plays this clip in a letter-boxed 320x240 window at the correct aspect ratio. CorePlayer plays it also in a letter-boxed 320x240 window with the default Zoom option (Fit Best) and the Auto aspect ratio. That is before modifying it with mp4box.
The ffmpeg output using pading and encoding using only only 58.83% of the available pixels to render the movie (640x268=171520) plays differently. In SMPlayer it plays in the 1148x480, but letter-boxed which obviously renders the movie compressed horizontally. To watch this output correctly, I have to manually choose the 4:3 aspect ratio in the player. VLC and KMPlayer have a similar behavior. QuickTime and CorePlayer play the movie correctly in a letter-boxed 640x480 window with the correct 2.39:1 resolution.
My problem is that I don't want to encode black bars top and bottom. I'm trying to encode the movie using all available pixels (640x480=307200) and somehow tell the CorePlayer (which runs on a Nokia N9x smartphone) to compress the movie when playing it and add black bars top and bottom.
I can do that using an AVI container, TMPGenc Xpress 4.xxx and ffdshow. I use the same MPEG4 Part 2 video codec, but in ffdshow settings, under the encoder tab, Output Options, I can modify the DAR and the PAR. I leave the DAR at 4:3, but change the PAR to 95:53. The resulting video plays in all the Windows players in the 1148x480 window, BUT it also plays correctly in CorePlayer on the smartphone in a letter-box at the Auto aspect ratio and Fit Best zoom.
The difference between the AVI and 3GP videos and is that AVI is using anamorphic pixels, but renders the image using all 302700 of them, while the output from ffmpeg with padding uses only 171520 pixels to render the movie. Obviously 302700 pixels is better than 171520.
With AVI there is the audio limitation of being stuck with MP3 (no AAC).
That's why I'm trying to figure out what SUPER does when that "Stretch It" box is not checked. It doesn't seem to encode black bars top and bottom, but rather, somehow, suggest to QuickTime and CorePlayer to compress the image and add the black bars.
3GP is a friendlier container for GSM phones than AVI. That's why I'm trying to find a way to encode using anamorphic pixels to a 3GP container.
I'll very much appreciate any help I can get from an expert like you!
Many thanks again,
Both the PAR and DAR are being written correctly as verified by mediainfo and ffmpeg itself.
Like I said previously, anamorphic 3gp files play with the correct aspect for me in Quicktime X BUT NOT in quicktime 7 on the same computer.
(MacPro, OS 10.6.2, QT 7.6.3 and QT 10.0)
It may be an issue of the 3gp anamorphic flag not being implemented in all players or devices.
Let me investigate further.....
In the meantime, you could try to replicate the success you had with avi files in ffmpeg which would help narrow down the issue of setting the PAR and DAR. I do not have a device capable of testing the final nokia result unfortunately.
Thank you Michael. As expected from any serious video professional, you are using a MAC. I'm just a hobbyist and I use Windows 7 Ultimate 64 bit. The version of my Windows QuickTime is 7.6.5.
I don't know how to follow your suggestion about replicating the success I had with ffdshow, to encode using anamorphic pixels. Is there a way to encode with ffmpeg using anamorphic pixels? I'm not sure how it actually works. Is the same thing to set the aspect ratio flag in the video file header as with actually encoding with rectangular pixels? I mean, when I encoded using ffdshow and I changed the PAR, were the pixels created by the encoder actually rectangular, or they were square and only the player was told they are rectangular? It's pretty foggy for me here. Are there rectangular pixels in reality, or just aspect ratio flags in the file headers?
I'd very much appreciate if you can enlighten me on this subject.
Many thanks again for anymore help.
OK, now I know your target format. I have looked into the Nokia N-series and some other posts about the subject as well as doing some testing with Super at work this morning.
The Nokia N95 has a screen res of 320x240 (4:3)
The Nokia N97 has a screen res of 640x360 (16:9)
The Nokia N800 and N900 have a screen res of 800x480 (16:9)
>>>this is the best anyone with one of these phones is ever going to see it.<<<
The Nokia N95 can have an aspect ratio of 11:9, 5:4 OR 4:3 (which is another level of insanity)
>>>With my experiments with super, it automatically added this aspect to the videos regardless of the stretch it button. Do you own one of these nokias? Which one? I would like to know the exact display aspect ratio which could be calculated using one of these phones and a ruler. just measure the full width and full height of the screen area and divide the width by the height. (I am pretty sure it is true 4:3 or 16:9 but without one in my hands, cannot be totally sure<<<
The Nokia N-series can except h.264 video (still looking for accurate information on the profile/level limitations)
>>>h.264 is a far more efficient codec than mpeg4layer2 and should be used in preference where available.<<<
[Dorian Stage] "Is there a way to encode with ffmpeg using anamorphic pixels?"
Yes. it is the -aspect flag. This sets the PAR and DAR flags on the output container.
[Dorian Stage] "Are there rectangular pixels in reality, or just aspect ratio flags in the file headers?"
just aspect ratio flags in file headers;-) in the file, pixels are just pixels, it is the aspect flags that tell the player (software, DVD player, set top box etc.) to stretch or squash the video based on the output screen. Your problems are arising because some players ignore this flag for some container formats. On a hardware device, ie. a tv or a mobile phone, the physical pixels themselves can be rectangular which is why all this trouble started in the first place.
Anyway, back to your issue of publishing to the Nokia N-series.
Firstly, seeing the N95 physical screen has only 320x240 actual pixels, encoding larger is overkill, hence the super program limiting the size options. I am guessing super hasn't been updated for the newer phones.
Secondly, using anamorphic pixels to increase quality is not really needed here and if anything, may reduce quality depending on the scaling engine in the phone. Adding black bars to the top and the bottom seems the best option as no scaling will occur, hence no scaling blurring or artifacts.
And the aspect ratio mess:
Super has several 3gp preset sizes, WITH DIFFERENT BASE ASPECT RATIOS:
128:96 = 4:3
176:144 = 11:9
220:176 = 5:4
240:192 = 5:4
320:240 = 4:3
352:288 = 11:9
The ideal choice from this list for the NOKIA N95 is 320:240 for several reasons.
1. It is identical to the actual screen pixel dimensions which means no scaling needs to be performed by the device.
2. It's aspect ratio is the same as the actual screen so no aspect flags are needed.
3. It will play back with a pixel for pixel match so best possible quality for that device.
% ffmpeg -i input.avi -vcodec libx264 -vpre libx264-hq -vpre libx264-baseline -s 320x134 -padtop 52 -padbottom 54 -b 1000k output.3gp
Note the padtop and padbottom are set to 52 and 54, not 53 each. ffmpeg needs even numbers for these flags. Also, I have limited the h.264 profile to baseline as this stage for wider compatability.
This will give you a letterboxed square pixel 4:3 version for the Nokia N95. Keep in mind that 320x134 is the largest anyone will ever see a 2.39:1 image on a Nokia N95, regardless of the image size of your file.
Seeing that the Nokia N97 has a screen res of 640x360.
% ffmpeg -i input.avi -vcodec libx264 -vpre libx264-hq -vpre libx264-baseline -s 640x268 -padtop 46 -padbottom 46 -b 1000k output.3gp
This will give you a letterboxed square pixel 16:9 version for the Nokia N97. Keep in mind that 640x268 is the largest anyone will ever see a 2.39:1 image on a Nokia N97, regardless of the image size of your file.
The N800 and N900 have a screen res of 800x480 which is also native 16:9.
The command line would look like this:
% ffmpeg -i input.avi -vcodec libx264 -vpre libx264-hq -vpre libx264-baseline -s 800x334 -padtop 72 -padbottom 74 -b 1000k output.3gp
Hope this helps.
WOOOW!! This is impressive and VERY useful information! Thank you very much for taking the time (long time) to research and put all that into writing.
You guessed right, from the DAR I was using, that I'm talking about Nokia N95, which I own. Its screen is 53x40 mm which is only 1.325 not 1.333. As you mentioned, the hardware pixels are anamorphic on this phone, but just slightly.
I've done some test to follow your advice about replicating the success I had with the AVI container in TMPGenc with ffdshow. I encoded only to 320x240 this time, not 640x480 (The phone records to this larger resolution and the visual quality is sensibly better, but I agree with you that is kind of overkill).
I've encoded using 2 passes, like in TMPGenc with these two commands:
ffmpeg -i clip.avi -an -vcodec mpeg4 -pass 1 -b 512k -s 320x240 -aspect 2.39 -f rawvideo -y NUL
ffmpeg -i clip.avi -acodec libmp3lame -ab 64k -ac 2 -ar 44100 -vcodec mpeg4 -pass 2 -b 512k -s 320x240 -aspect 2.39 ffmpeg.mpeg2.avi
The phone can handle much more than that video bitrate with MPEG-4 Part 2 codec, but 512 gives a good quality, not very much raised by dramatic increses to higher numbers.
I've encoded then to letter-boxed frame with these two commands:
ffmpeg -i clip.avi -an -vcodec mpeg4 -pass 1 -b 512k -s 320x136 -padtop 52 -padbottom 52 -f rawvideo -y NUL
ffmpeg -i clip.avi -acodec libmp3lame -ab 64k -ac 2 -ar 44100 -vcodec mpeg4 -pass 2 -b 512k -s 320x136 -padtop 52 -padbottom 52 ffmpeg.lbox.2p.avi
For whatever reason, SMPlayer doesn't like the ffmpeg outputs. The first output (anamorphic) is played in SMPlayer in a window 240x574 and flipped vertically. The letter-boxed output plays in the same 240x574 window, but the image is not flipped vertically.
VLC Player and KMPlayer play the anamorphic output in the correct 574x240 window, but they play the letter-box output in the same 574x240 window (instead of 320x240). If the aspect ratio is chosen manually as 4:3, they both play correctly.
Windows CorePlayer plays the anamorphic output in a 320x240 window ignoring the aspect ratio. Instead it plays correctly the letteb-box output. However, CorePlayer in the phone plays the anamorphic output correctly with the default aspect ratio (Auto). It messes up though with the letter-box output playing it by adding its own black bars on top and under those encoded in the movie. It plays correctly if the aspect ratio is chosen from the menu (either Square or 4:3).
TMPGenc output to AVI (with the same parameters used by ffmpeg), plays correctly in all players (Windows and on the phone). Only Windows CorePlayer ignores the aspect ratio when playing the anamorphic output from TMPGenc.
Now that you've explained the magic of anamorphic encoding, I believe the 3GP container has problems with the aspect ratio. 3GP video, if not letter-boxed, does not play correctly on the phone, while the anamorphic AVI works fine at the default settings (no manual choosing of the aspect ratio).
I've watched the anamorphic and the letter-boxed outputs with a magnifier. It seems that the anamorphic output is slightly better, but I wouldn't bet money on it.
On this phone, AVC at video bitrares over 480 kbps jamms on scenes with rapid motion and rapid changes or frame composition. Under that level, at equal bitrates it looks better than MPEG-4 Part 2 and xvid.
I don't expect a free command line utility like ffmpeg to rival one of the best commercial encoders (that's my personal opinion about TMPGenc Xpress, but I'm of course talking at the hobbyist level), but I'm kind of curious why ffmpeg outputs are not as correctly readable as those from TMPGenc. What do you think?
Many thanks again for all the time you put into schooling me! VERY valuable information!
Glad I could be of help.
[Dorian Stage] "For whatever reason, SMPlayer doesn't like the ffmpeg outputs."
In my experience, the problems with playback/display usually reside with the player, not the file.
[Dorian Stage] "However, CorePlayer in the phone plays the anamorphic output correctly with the default aspect ratio (Auto). It messes up though with the letter-box output playing it by adding its own black bars on top and under those encoded in the movie. It plays correctly if the aspect ratio is chosen from the menu (either Square or 4:3)."
Hopefully, one day soon, anamorphic issues will be a thing of the past. That is why all the main HD formats are square pixel 16:9. (1920x1080 or 1280x720) Until then, if you are having issues, square pixel is always the safest choice.
[Dorian Stage] "Now that you've explained the magic of anamorphic encoding, I believe the 3GP container has problems with the aspect ratio. 3GP video"
It is what I have been suspecting the whole time.
[Dorian Stage] "I don't expect a free command line utility like ffmpeg to rival one of the best commercial encoders"
Just because it is free, doesn't mean that it is not as good. Remember, many commercial encoders rely on ffmpeg, libx264 and other open source libraries for their core functionality. They are charging you for the GUI which in my mind usually limits the possibilities of many codecs. (As you found with the SUPER limitations on frame size.) And yes, I know SUPER is not commercial, just an example of GUI implementing restrictions.
[Dorian Stage] "but I'm kind of curious why ffmpeg outputs are not as correctly readable as those from TMPGenc. What do you think?"
I am curious as well. The best way to be sure of the differences is to use a utility to compare the container flags of the two outputs. I use Dumpster on Mac which shows all of the "atoms" of QT and mp4 containers and essence. There must be something similar on PC for AVI and 3gp files.
And finally, always work to your target format/device. If it is for the NokiaN95, it only matters how it looks on that device. Ignore the other players results as they are unimportant for the NokiaN95.
Thank you very much Michael, for your time and very valuable help!
The .3gp file plays stretched in Quicktime 7 but not in Quicktime X.
Looks like the flag is there but pre-snow leopard versions of Quicktime ignore it.