V_UNCOMPRESSED matroska files get invalid colour space for many pixel formats

[vi]

How to reproduce:

% ffmpeg  -f rawvideo -pix_fmt rgb24 -r 1 -t 1 -s 32x32 -i /dev/zero -c copy -y /tmp/z.mkv && mkvinfo -v -x /tmp/z.mkv | grep Colour
|   + Colour space: length 4, data: 0x00 0x00 0x00 0x00

When colour format is not yuyv422, yuv422p ,yuv410p ,yuv411p ,gray, uyvy422, uyyvyy411 ,nv12, nv21 or yvyu422, ColourSpace element gets value of 4 zeroes. No warnings are issued when muxing.

Such files can't be easily decoded, even if I specify "-pix_fmt" option when decoding.

Saving any raw data to mkv can be useful, for example, for recoring fast uncompressed lossless screen captures. Additionally I think FFmpeg should be able to save anything whatsoever to Matroska, as it is an extensible format.

[gjdfgh]

Yeah, it should not write such files without having a (standard!) FourCC.

[Carl Eugen Hoyos]

See ticket #3263

[vi]

And if FourCC is not defined, I suggest just to write short name of pixel format instead (av_get_pix_fmt_name) instead.

Better to store rgb24 in a nonstandard way rather then not store at all.

I'll try to implement a patch...

[gjdfgh]

No. Fuck non-standard, especially if ffmpeg produces such a file. Use a different container format if mkv doesn't work for you.

[vi]

What container format to use instead? I expect Matroska to be able to store anything, one way or another.

Now it produces broken mkv files; it should produce working files.

[Hendrik]

The format by definition requires a FourCC, if no FourCC exists, then you cannot store this format in V_UNCOMPRESSED. What you expect doesn't match the reality.

Like you said, it should produce working files, and for files to be working, V_UNCOMPRESSED requires a *VALID* FourCC, not something arbitrarily invented based on the short name ffmpeg assigned to it.

[vi]

May FFmpeg store, for example, V_UNCOMPRESSED_FFMPEG with it's colour format as CodecPrivate; if is no conforming way to store V_UNCOMPRESSED?

[gjdfgh]

What container format to use instead?

nut is the format that can store anything FFmpeg can handle (by definition, because the format is defined by FFmpeg devs and reflects some FFmpeg internals directly).

I expect Matroska to be able to store anything, one way or another.

That's not true. There are a lot of things Matroska can't store (at least not in a way every player would understand). This doesn't mean Matroska is bad or anything; it's just a normal restriction for container formats. Sure, you could add a hack that makes FFmpeg alone understand your format "extension", but what value does it have if only FFmpeg understands it? The point of container formats is interchanging data in a standardized way, not a place for implementations to dump hacks.

[vi]

NUT? Thanks, looks like it the proper FFmpeg->FFmpeg format.

In this case, storing any raw video in mkv is of low priority;

Going to implement:

• Warning when trying to produce broken mkv;
• FourCC for RGB24 and RGBA.

[gjdfgh]

Yeah, that sounds fine.

Also note that nut might not support some formats; but the point is that FFmpeg can freely extend it.