[Dorian Stage]

Thank you very much Michael, for your time and very valuable help!

Dorian

[Dorian Stage]

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 53×40 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 320×240 this time, not 640×480 (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 320×240 -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 320×240 -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 320×136 -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 320×136 -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 240×574 and flipped vertically. The letter-boxed output plays in the same 240×574 window, but the image is not flipped vertically.

VLC Player and KMPlayer play the anamorphic output in the correct 574×240 window, but they play the letter-box output in the same 574×240 window (instead of 320×240). If the aspect ratio is chosen manually as 4:3, they both play correctly.

Windows CorePlayer plays the anamorphic output in a 320×240 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!

[Dorian Stage]

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.

[Dorian Stage]

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 640×480 -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 640×480 -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 1148×480 with the aspect ratio set to default or auto. However, in less intelligent players like QuickTime Player and CorePlayer, the 3gp clip plays in 640×480 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 640×268 -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 640×268 -padtop 106 -padbottom 106 clip.3gp

The clip created by SUPER is 320×240 (I don’t have 640×480 available there). However, with the aspect ratio set to default in SMPlayer, VLC and KMPlayer, SUPER’s clip plays in a window 320×430 with 95 pixels black bars top and bottom. The movie itself is 320×240. However, QuickTime plays this clip in a letter-boxed 320×240 window at the correct aspect ratio. CorePlayer plays it also in a letter-boxed 320×240 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 (640×268=171520) plays differently. In SMPlayer it plays in the 1148×480, 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 640×480 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 (640×480=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 1148×480 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,

Dorian

[Dorian Stage]

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 356×288) 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!

[Dorian Stage]

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!