Lou Logan
Forum Replies Created
-
[Reuben Martin] “(Or the build of ffmpeg you are using is broken)”
Very likely. Usage of libfaad as a decoder is not a good sign. That was removed from FFmpeg several years ago. At the rate of FFmpeg development the chance of encountering a known or fixed bug is high with such an ancient version.
-
Unfortunately, you did not supply the complete ffmpeg command and the complete ffmpeg console output. ffmpeg will always include its version information and how it was configured which is just as important as the rest of the output.
If you use the “code” button on your command and the console output text it will be easier to read. Like this:
ffmpeg -i input ... output -
Additionally, remove “-threads 4”. Recent ffmpeg deals with threads automatically by default (which is “-threads 0”, or number of logical processors * 1.5, rounded down), so forcing a value of “4” may not be optimal. However, you’re using the fork and not FFmpeg, and I don’t know its default behaviour.
-
The is the FFmpeg COW forum. Are you using ffmpeg? If yes, what command have you tried?
-
Please include your full ffmpeg command and the complete ffmpeg console output. I suspect you are using a very ancient ffmpeg build, but I can only guess without seeing the required information.
If you use the “code” button on your command and the console output text it will be easier to read.
-
See the CRF section of the FFmpeg and x264 Encoding Guide. This will allow you to set a specific quality that the encoder will attempt to achieve. The basic methodology is to use the highest crf value that still gives an acceptable quality and the slowest preset that you have patience for. The link as an example and a more in-depth explanation.
As for the audio see Encoding VBR (Variable Bit Rate) mp3 audio with FFmpeg and LAME.
-
It is converting from one pixel format to another. The old default was to automatically convert everything to yuv420p, which is supported by all decoders. libx264 can now encode up to yuv444p (there is also libx264rgb), so the default behavior with your version of ffmpeg now attempts to use the highest supported pixel format that is inferred from your input. This is technically “good” but not always in practice; the result may not be supported by most decoders (except anything from FFmpeg of course), and you may or may not see artifacts, blurring, and or color loss due to chroma sub-sampling.
-
Concatenating videos isn’t always a trivial task, and more information is needed to answer your question. Are all of the inputs the same format? What is your OS? Please show some information about the videos and the clips with ffmpeg:
ffmpeg -i video.mp4 -i credits.mp4
The resulting console output will contain useful information on how to proceed. -
Please provide the complete ffmpeg console output. Without it I can only guess what the issue is, but I’m assuming that it is creating an output, which your player (QuickTime?) can not properly decode, due to the colorspace and/or subsampling of your input. FFmpeg, by default, will attempt to convert to the highest supported sampling mode by the encoder to avoid degradation of color information.
Try adding the following option as an output option:
-pix_fmt yuv420p -
Late reply, but you need to add an output option:
-pix_fmt yuv420p
Many non-FFmpeg based players, such as QuickTime, currently do not yet support 4:2:2 H.264, and ffplay simply converts to 4:2:0 upon playback anyway, AFAIK.