[Reuben Martin]

The version you are using is a build of the 0.9 version. As you can see from the output there is no “h264_changesps” in the list of supported bitstream filters. Basically you can not do what you’re trying to do with the version of ffmpeg that you are using.

Assuming you are on windows, you need this version here: https://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20%28demuxer_muxer%20only%29/ffmpeg_git_31792.7z/download

[Reuben Martin]

That bitstream filter is not a standard ffmpeg filter. You have to apply a patch before building ffmpeg in order to access that functionality.

ffmpeg -bsfs

will tell you what bitstream filters are available.

The patch for the filter you are referring to can be found here: https://forum.doom9.org/showthread.php?t=152419

I think they have some patched win32 builds available.

[Reuben Martin]

It depends on what version of ffmpeg is being used. What you are trying to do will work with the latest version of ffmpeg, but not on older versions.

You may be using an older version where you have to explicitly map each audio channel and use a “-newaudio” syntax to have more than one audio stream in the output. (“-newaudio” is depreciated and no longer works on the most recent versions)

[Reuben Martin]

Well if it’s user submitted content, that’s a whole new ballgame… For all you know, user uploaded content may have been encoded with some sort of crappy freeware encoder that jacked things up. Anything can go wrong in those cases, and it’s hard to write a script to effectively deal with any sort of oddball problem. In this case, given that it’s a h264+pcm in a mov format, and that it uses a 5994/100 frame-rate/frame-base it was probably encoded with something quicktime based. (5994/100 is incorrect. It should be 60000/1001. Apple has NEVER set NTSC timings correctly…)

All video in h264 is actually encoded with the width and height as multiples of 16. It’s just how the DCT encoding functions work. They have to break an image down into 16×16 pixel blocks. If the video width or height is not a multiple of 16, extra pixels are added, and then a flag is set to tell the decoder to chop off those extra pixels at playback time. Most likely something is broken with how that cropping information was encoded. OR the ffmpeg version used has a bug.

The version may be the latest version of ffmpeg available for RedHat 4.1.2 (or whatever RedHat clone is being used), but certainly not the version most recently available. I’m simply basing that from the copyright and build date from June of 2009. But, if this is provided by a hosting company rather than in-house you don’t have much control over that anyway.

It looks like the variable used to give the version number was not set, so you might not be able to nail down the exact version. From the date, it’s probably from the 0.5.x series. Ffmpeg and libx264 have both come a long way since then.

Try “ffmpeg -version”. My output:

ffmpeg version 0.8.7, Copyright (c) 2000-2011 the FFmpeg developers
built on Nov 30 2011 19:06:24 with gcc 4.5.3
configuration: –prefix=/usr –libdir=/usr/lib64 –shlibdir=/usr/lib64 –mandir=/usr/share/man –enable-shared –cc=x86_64-pc-linux-gnu-gcc –disable-optimizations –disable-static –enable-gpl –enable-version3 –enable-postproc –enable-avfilter –disable-stripping –disable-debug –disable-doc –enable-libmp3lame –enable-libvo-aacenc –enable-libvo-amrwbenc –enable-libtheora –enable-libvorbis –enable-libx264 –enable-libxvid –enable-libaacplus –enable-nonfree –enable-libfaac –enable-nonfree –enable-libdc1394 –disable-indev=v4l –disable-indev=v4l2 –disable-indev=oss –enable-x11grab –disable-outdev=oss –enable-frei0r –enable-libfreetype –enable-pthreads –enable-libopencore-amrwb –enable-libopencore-amrnb –enable-libgsm –enable-libdirac –enable-librtmp –enable-libschroedinger –enable-libspeex –enable-libvpx –enable-libopenjpeg –disable-altivec –disable-avx –cpu=host –enable-hardcoded-tables
libavutil 51. 9. 1 / 51. 9. 1
libavcodec 53. 8. 0 / 53. 8. 0
libavformat 53. 5. 0 / 53. 5. 0
libavdevice 53. 1. 1 / 53. 1. 1
libavfilter 2. 23. 0 / 2. 23. 0
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 51. 2. 0 / 51. 2. 0
ffmpeg 0.8.7
libavutil 51. 9. 1 / 51. 9. 1
libavcodec 53. 8. 0 / 53. 8. 0
libavformat 53. 5. 0 / 53. 5. 0
libavdevice 53. 1. 1 / 53. 1. 1
libavfilter 2. 23. 0 / 2. 23. 0
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 51. 2. 0 / 51. 2. 0

[Reuben Martin]

First, ffmpeg from 2009 is very very old.

Either ffmpeg is wrong, or the video is encoded wrong. Either way you can add “-s 710×426” to force ffmpeg to scale it to the correct size.

However you shouldn’t really need to re-encode the video. It’s already in h264 format. Just re-encode the audio to aac and copy the video stream.

ffmpeg -i profilevid.mov -vcodec copy -acodec libfaac -ar 48000 -ab 64k -f mp4 profilevid.mp4

[Reuben Martin]

There really is no standard for bitrates. It’s whatever you want to set it to. Furthermore, the bitrate is a very poor indicator of the output quality. What’s better is to set the quality level you want, and let the encoder figure out how many bits are needed to achieve that quality. Different content requires different bitrates to achieve the same quality. Fast motion content requires a lot higher bit rate than slow motion content for example.

Also, your flv video probably already has it’s video stream in h264 content, so there’s no need to re-encode it. Just dump the video and audio streams into an MP4 container without re-encoding. Much faster, and no loss in quality.

[Reuben Martin]

Some of the code was munged in the post due to discarding HTML characters.

That last code example should read something like:

ffmpeg [input_options_here] -i source.xxx [output_options_here] -vcodec foobar [vcodec_options_here] -acodec foobar [acodec_options_here] -f mp4 output.mp4

[Reuben Martin]

What few people realize is that the order of the options is very important for ffmpeg.

From ffmpeg’s point of view, your are saying “I have a frame sequence at 25fps that I want resampled into 10 fps for the same runtime.”

You need to place the “-r” option before the “-i” option so that ffmpeg understands that the 10fps is the rate of the input, not the resampled rate for the output.

example:
ffmpeg -r 10 -i frame%04d.jpg out.mp4

Please note, this command is very ambiguous. It does not specify the video or audio codec, and the MP4 standard supports several different codecs for both audio and video. ffmpeg will just select which ever video and audio codecs are programmed as default for MP4 which may or may not be what you want.

You would want something more like this:

ffmpeg -i source.xxx -vcodec foobar -acodec foobar -f mp4 output.mp4

[Reuben Martin]

There was a major code dump in September that added support for ProRes decoding, and another in October that added encoding support. There has been a lot of incremental work to improve them since that time.

However, I don’t believe that any of the official release builds have it built in yet since it is still experimental. You would need to build from git sources if you wanted to test it out.

Initial Commit for ProRes support: https://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-September/040453.html

[Reuben Martin]

Perhaps your video stream includes VBI?