#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 , 10 years ago
Cc: | added |
---|
comment:2 by , 10 years ago
Keywords: | rawvideo pixel format V_UNCOMPRESSED colour space rgb24 removed |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
See ticket #3263
comment:3 by , 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 , 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 , 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 , 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 , 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 , 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 implementation to dump hacks.
comment:9 by , 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 , 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.
Yeah, it should not write such files without having a (standard!) FourCC.