Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4305 closed defect (duplicate)

V_UNCOMPRESSED matroska files get invalid colour space for many pixel formats

Reported by: vi Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: mkv
Cc: nfxjfg@googlemail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (10)

comment:1 by gjdfgh, 10 years ago

Cc: nfxjfg@googlemail.com added

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

comment:2 by Carl Eugen Hoyos, 10 years ago

Keywords: rawvideo pixel format V_UNCOMPRESSED colour space rgb24 removed
Resolution: duplicate
Status: newclosed

See ticket #3263

comment:3 by vi, 10 years ago

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...

comment:4 by gjdfgh, 10 years ago

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

comment:5 by vi, 10 years ago

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.

comment:6 by Hendrik, 10 years ago

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.

comment:7 by vi, 10 years ago

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

comment:8 by gjdfgh, 10 years ago

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.

Last edited 10 years ago by gjdfgh (previous) (diff)

comment:9 by vi, 10 years ago

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.

comment:10 by gjdfgh, 10 years ago

Yeah, that sounds fine.

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

Note: See TracTickets for help on using tickets.