[Michael Rampe]

You are targeting q=2-31 as this is the default. Instead of setting bitrate, try to limit the q factor.

For example:
ffmpeg -i arthur_bay_lookout.mts -vcodec mjpeg -qmax 1 -qmin 1 arthur_bay_lookout.mov

This should increase file size as well as quality.

Michael

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

[Michael Rampe]

Your source file reported:
[Christopher Smith] “22.58 fps, 23.98 tbr, 2997 tbn, 5994 tbc”
Is this 24 fps material in a ntsc stream using 3:2 pulldown?

tbn, tbc & tbr all refer to the timebase. (AVStream, AVCodecContext, assumed). This can differ between container, codec and assumed rate. (due to some containers being able to hold both interlaced and non-interlaced material, the time base can be double the required frame rate and these warnings are normal in that case.) fps refers to the frame rate but I find this can be inaccurate.

IMHO, tbr is the most trustworthy.

For example, if I do a header read of one of my test animation files I get:
Seems stream 0 codec frame rate differs from container frame rate: 600.00 (600/1) -> 25.00 (25/1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘fluid8.mov’:
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
Duration: 00:00:08.64, start: 0.000000, bitrate: 68055 kb/s
Stream #0.0(eng): Video: qtrle, rgb24, 1024×576, 68053 kb/s, 24.65 fps, 25 tbr, 600 tbn, 600 tbc

This is a .mov container holding video in the animation codec at 25 frames per second (I know this because I made it ;-). In this example, you can see that tbr is the only correct one and that would also be the correct choice for -r if I wanted to force the frame rate. You can always just exclude the -r flag and the frame rates will pass from source to destination.

Finally, be careful of rounding errors using 23.98. (It is actually 23.976 which is 30/1.001/1.25)

Michael

p.s. Please always post full command lines.

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

[Michael Rampe]

Have a look into FFserver.

https://www.ffmpeg.org/ffserver-doc.html

Michael

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

[Michael Rampe]

I have recently been working on a shell script that detects size and aspect ratio amongst other things. This example might give you some ideas of writing your own shell script.

Basically,
1. perform a header read of the input file and write to a file
2. use grep/sed/awk combination to isolate the required data
3. assign required data to variables
4. use variables to build the FFmpeg command line
5. run the FFmpeg command line

EXAMPLE OF COPYING INPUT SIZE TO OUTPUT SIZE:
(This will happen anyway with FFmpeg if not specifying size but should give you an idea of the method)

1. Use “ffmpeg -i inputfile 2> data.txt”
This will write the console text output to a file which will contain the stream data including size

2&3. This can be a bit tricky but what I use as an example is:
INPUTWIDTH=$(cat data.txt | grep “[0-9]x[0-9]” | sed ‘s/x/ /g’ | awk ‘{ print $1 }’)
INPUTHEIGHT=$(cat data.txt | grep “[0-9]x[0-9]” | sed ‘s/x/ /g’ | awk ‘{ print $2 }’)

4&5. Once the variables are set:
ffmpeg -i inputfile [encoding parameters] -s $INPUTWIDTH\x$INPUTHEIGHT outputfile.mp4

Although this doesn’t directly solve your problem, it should be possible to run and “if” scenario based on the size variables to allow the script to make the right decision to encode or resize based on input size.

I will have a go on the logic when I get the chance.

Michael

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

[Michael Rampe]

I would like to see the full terminal output to correctly diagnose but:

I am guessing that it is a combination of using the -sameq flag and not specifying a video codec. The full command line output will verify that.

Instead of using “-sameq”, try using “-vcodec copy” which will not recompress the frames and should result in a more realistic file size.

Michael

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

[Michael Rampe]

This worked for me when trying to replicate your issue:

ffmpeg -loop_input -f image2 -i test.png -r 25 -t 20 -s 3000×500 OUTPUT.FLV

This produced a 20 second flv file which was 3000 by 500 in size.

What version of FFmpeg do you have installed? Can you post the full terminal output for more information?

Michael

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

[Michael Rampe]

It appears that there is an audio stream in your input. Unless FFmpeg is told to ignore the audio (using -an for example on the command line), it will pass the stream through to the output. That is why I think you are having the problem of unsupported codec.

Michael

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

[Michael Rampe]

[tom pepe] “I’ve builded ffmpeg with the following configurations:

./configure –enable-gpl –enable-swscale –enable-nonfree”

You have not installed or enabled the libfaad or libfaac libraries. This is why it is reporting:

[tom pepe] “Unsupported codec!”

Your ffplay does have these libraries installed and configured. This is why it works in FFplay but not FFmpeg.

add –enable-libfaad and –enable-libfaac to your FFmpeg configure line.

Michael

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

[Michael Rampe]

First thoughts:

Why are you using -vcodec libx264 when the input file is an mp3 and thus, no video stream?

The majority of the settings in your command line relate to video encoding but the source has no video.

[david gill] “Unknown encoder ‘libfaac'”

You haven’t installed this library and enabled it in your configure line. You have libfaad installed and configured but not libfaac. The “d” in libfaad stands for decode and the “c” in libfaac stands for code. You need libfaac to encode aac streams and it is not standard with FFmpeg itself.

Try to install libfaac and remove all of the video specific settings from your command line and post the result.

Michael

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

[Michael Rampe]

Hi David,

Sorry for the delay but I have been traveling internationally for the last week.

To be honest, I still use compressor for all my dvd encoding needs as it is a rare delivery format for me nowadays but am interested in working on some command lines to delve into the FFmpeg alternative. I have used FFmpeg for mpeg2 encoding for HD transport stream delivery and have found the quality to be excellent.

You have stated that you are using FFmpegX which is reliant on an older version of FFmpeg. Just to be clear, FFmpeg is a command line tool and FFmpegX is a GUI that relies on FFmpeg as well as other solutions such as mencoder. They are not the same thing. FFmpegX has not been updated in over two years and the underlying FFmpeg has undergone massive improvements in that time. I strongly recommend using the latest FFmpeg from the command line.

If you are interested in pursuing this option, let me know and I will work on some command lines when I return from abroad.

Michael

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