[Michael Rampe]

Merging two mono streams into a left/right panned single stream….

short answer is: not yet;-)

I found this task on the google summer of code wiki related to ffmpeg:

Implement negotiation of sample format and number of channels analogously to the libavfilter colorspace negotiation
* Does this imply a channel mixing filter? This would be the second most desirable basic audio filter in my opinion.

https://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010

As this states, this is a work in progress and a very much needed feature.

My question for you is: what are you trying to do with the output file?

If you intend to edit it in a NLE later, you CAN map two streams to two new streams. They will both be mono but will be separate tracks which will work in an NLE. I recreated a 4channel movie to test with similar in stream layout to your .gxf file. I then used this command line to map audio channel 1 and 2 to two new streams in the output file.

ffmpeg -i input.mov -map 0:0 -map 0:1 -map 0:2 -vcodec dvvideo -s 720×576 -aspect 5:4 -acodec copy output.mov -acodec copy -newaudio

This came into my NLE (Final Cut Pro) as two center panned mono tracks. It is then simple to pan them left and right respectively in the NLE. NOTE: I could not get it working with the .dv wrappper or -target dv50 settings which is why I set the codec/size/aspect myself.

Finally, from the research I have done, mencoder (another free command line tool) DOES have a pan function so you may want to investigate that.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

[Dave Navarro] “I spent a solid day one weekend comparing encoded files with different commands line settings and various files encoded using QuickTime Pro”

Can you give me some examples of command lines you were trying?

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

I have not built FFmpeg on windows (only osx and linux) but I did some digging on the topic for you anyway.

The FFmpeg documentation page refers to this page for all windows needs:
https://ffmpeg.arrozcru.org/

This wiki seems to have step by step instructions for the various build options on windows:
https://ffmpeg.arrozcru.org/wiki/index.php?title=Main_Page

I will give it a go myself when I get the chance.

Let me know how this goes for you.

Michael

“half-way to world domination A.K.A. the belligerent blue bike shed”

[Michael Rampe]

[Michael Rampe] “Type: ffmpeg -codecs
…for a list of available codecs
Type: ffmpeg -formats
…for a list of available containers”

Type ffmpeg -formats
…for a list of available codecs AND containers.

The -codecs command works in more current revisions only.

[Michael Rampe]

looks good but out of my price range…..

Anything cheaper? It ONLY needs to graph data rate over time, no other fancy features or alarms etc.

[Michael Rampe]

Missed this bit on the Blackberry page:

* Video Format Support: XviD (MPEG4 Advance Simple Profile), H.263, WMV3
* Audio Format Support: .3gp, WAV, MIDI, AMR-NB, G711u/A, GSM610, PCM, MP3, AAC/AAC+/eAAC+, WMA9/10 Standard/Pro

Although it does not list .3gp as a video format, I would give it ago anyway as it will most probably work;-) (xvid, H.263 and wmv3 are codecs, not container formats)

Michael

[Michael Rampe]

Firstly, .3gp is a container format developed for the 3g mobile phone platform, so thinking that just because the phone is 3g, .3gp is a working format is a correct choice.

From the Blackberry website:
* High resolution 480×360 pixel color display
* Supports over 65,000 colors

Your target device has a 4:3 square pixel output display.
It also looks like it is only capable of thousands of colours!!!
.3gp has problems with the anamorphic flag so encoding to square pixel is your best choice. see thread here for more detail:https://forums.creativecow.net/thread/291/5#5

This means letterboxing any non-4:3 content and outputting 480×360.

Secondly, the .3gp container can contain several different codecs. H.264, H.263 and Mpeg4Layer2… and others.
1. H.264 might not play on all phones but is the most efficient.
2. H.263 is widely compatible but limited to several pre-defined sizes and less efficient.
3. Mpeg4Layer2 (standard mpeg4) is the most flexible and compatible but the lowest of efficiency.

Finally,
Do not export this from final cut pro. Export a full quality master file from final cut pro and feed it to compressor. In compressor, you might want to create a custom .3gp template to be able to target your device size (480×360) and take care of any letterboxing issues.

Michael

[Michael Rampe]

Hi Dorian,

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. (1920×1080 or 1280×720) 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.

Michael

[Michael Rampe]

Not too sure about what you mean by “C program”.

Do you mean writing a program in C++ that uses ffmpeg or simply running ffmpeg in the command line?

[Michael Rampe]

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.

Some news:
The Nokia N95 has a screen res of 320×240 (4:3)
The Nokia N97 has a screen res of 640×360 (16:9)
The Nokia N800 and N900 have a screen res of 800×480 (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 320×240 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.

So try:

% ffmpeg -i input.avi -vcodec libx264 -vpre libx264-hq -vpre libx264-baseline -s 320×134 -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 320×134 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 640×360.

So try:
% ffmpeg -i input.avi -vcodec libx264 -vpre libx264-hq -vpre libx264-baseline -s 640×268 -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 640×268 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 800×480 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 800×334 -padtop 72 -padbottom 74 -b 1000k output.3gp

Hope this helps.

Michael