[FFmpeg-user] Output file experience pix_format change

Moritz Barsnick barsnick at gmx.net
Fri Jan 30 09:16:55 CET 2015

Hi Bazza,

On Fri, Jan 30, 2015 at 13:40:07 +1100, Bazza wrote:
> ...the outputfile has a pix format of yup420p (same as it's input
> file). For most (all ?) of the "standard" -vf parameters and for 
> all of the mp4 input files I used as tests, the pix_format remains 
> at yuv420p in the resulting output.
> However when using colorbalance/colorlevels/colorchannelmixer, 
> the output files has undergone a pix_format change to yuv444p 

Inputs and outputs of demuxer/decoder, encoder/muxer and all filters in
their chains support defined sets of colorspaces. If a connecting point
doesn't match somewhere - e.g. as in your case from the decoder output
to the filter input - ffmpeg will implicitly insert a format change.

For the colorspace filter this is required, as it only supports RGB
type formats (as input, I guess):

    static const enum AVPixelFormat pix_fmts[] = {


If you want to see which filters ffmpeg inserts, use the "-loglevel
debug" option. It will be an eye-opener for your case.

> Irritating though the Mplayer malfunction(?) might be, it is the
> _format_ change I am focussing on (and yes, I see that H264 likes a
> 444 default).

I don't know why mplayer is disturbed by yuv444p - I have heard that it
should handle that well.

> circumstances? Or, put another way, does libx264 ignore some
> recognition of the pix format some of the time? If so, why?
> Perhaps those color commands are forcing new 'acknowledgements'
> on the 264 filter by necessity?

By the time the video stream reaches the encoder, it has already
changed its colorspace, so ffmpeg makes a new decision based on the
output capabilities of the filter chain and the input capabilites of
libx264. ffmpeg does not (seem to) take into consideration what the
original format of the movie was at the input.

> It seems odd that some parameters leave the file untouched and a
> little confusing when one has to remember extra behaviour patterns.

Yes, it is a little confusing (to you and me at least) that a "regular"
conversion chain maintains the colorspace, and inserting a filter
suddenly changes the game.

ffmpeg _does_ warn about the chosen colorspace and its incompatibility
with certain players though!

This is from your output:
> No pixel format specified, yuv444p for H.264 encoding chosen.
> Use -pix_fmt yuv420p for compatibility with outdated media players.

Disclaimer: I don't know very much about colorspaces. ;-)


More information about the ffmpeg-user mailing list