JPEG Decoder fails to fail on CMYK JPEG file (detects as yuva444p)

[dbuitenh]

How to reproduce:

$ ffmpeg -loglevel debug -i bug.jpg decoded.png

git HEAD has the same issue and output.

Output:

ffmpeg version N-60776-gd089e9a Copyright (c) 2000-2014 the FFmpeg developers
  built on Feb 20 2014 11:17:04 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-3)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-decoder=dirac --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-decoder=amrnb --disable-decoder=amrwb --enable-libopus --enable-libx264 --enable-libschroedinger --disable-static --enable-shared --disable-ffplay --disable-ffserver --enable-libfdk-aac --enable-libspeex --enable-avresample --enable-openssl --enable-pic
  libavutil      52. 65.100 / 52. 65.100
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 33.100 / 55. 33.100
  libavdevice    55. 10.100 / 55. 10.100
  libavfilter     4.  1.103 /  4.  1.103
  libavresample   1.  1.  0 /  1.  1.  0
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
Reading option '-i' ... matched as input file with argument 'bug.jpg'.
Reading option 'decoded.png' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file bug.jpg.
Successfully parsed a group of options.
Opening an input file: bug.jpg.
[AVIOContext @ 0x23bcdc0] Statistics: 1129716 bytes read, 0 seeks
[mjpeg @ 0x23bb060] marker=d8 avail_size_in_buf=1129714
[mjpeg @ 0x23bb060] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x23bb060] marker=e0 avail_size_in_buf=1129712
[mjpeg @ 0x23bb060] marker parser used 16 bytes (128 bits)
[mjpeg @ 0x23bb060] marker=ee avail_size_in_buf=1129694
[mjpeg @ 0x23bb060] marker parser used 14 bytes (112 bits)
[mjpeg @ 0x23bb060] marker=e1 avail_size_in_buf=1129678
[mjpeg @ 0x23bb060] marker parser used 6005 bytes (48040 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=1123670
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=1058133
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=992596
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=927059
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=861522
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=795985
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=730448
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=664911
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=599374
[mjpeg @ 0x23bb060] marker parser used 33031 bytes (264248 bits)
[mjpeg @ 0x23bb060] marker=ed avail_size_in_buf=566340
[mjpeg @ 0x23bb060] marker parser used 43 bytes (344 bits)
[mjpeg @ 0x23bb060] marker=e1 avail_size_in_buf=566294
[mjpeg @ 0x23bb060] marker parser used 3898 bytes (31184 bits)
[mjpeg @ 0x23bb060] marker=db avail_size_in_buf=562393
[mjpeg @ 0x23bb060] index=0
[mjpeg @ 0x23bb060] qscale[0]: 2
[mjpeg @ 0x23bb060] marker parser used 67 bytes (536 bits)
[mjpeg @ 0x23bb060] marker=c0 avail_size_in_buf=562324
[mjpeg @ 0x23bb060] sof0: picture: 1280x720
[mjpeg @ 0x23bb060] component 0 1:1 id: 66 quant:0
[mjpeg @ 0x23bb060] component 1 1:1 id: 76 quant:0
[mjpeg @ 0x23bb060] component 2 1:1 id: 88 quant:0
[mjpeg @ 0x23bb060] component 3 1:1 id: 74 quant:0
[mjpeg @ 0x23bb060] pix fmt id 11111111
[mjpeg @ 0x23bb060] marker parser used 20 bytes (160 bits)
[mjpeg @ 0x23bb060] marker=c4 avail_size_in_buf=562302
[mjpeg @ 0x23bb060] class=0 index=0 nb_codes=10
[mjpeg @ 0x23bb060] marker parser used 29 bytes (232 bits)
[mjpeg @ 0x23bb060] marker=c4 avail_size_in_buf=562271
[mjpeg @ 0x23bb060] class=1 index=0 nb_codes=242
[mjpeg @ 0x23bb060] marker parser used 78 bytes (624 bits)
[mjpeg @ 0x23bb060] escaping removed 1699 bytes
[mjpeg @ 0x23bb060] marker=da avail_size_in_buf=562191
[mjpeg @ 0x23bb060] component: 66
[mjpeg @ 0x23bb060] component: 76
[mjpeg @ 0x23bb060] component: 88
[mjpeg @ 0x23bb060] component: 74
[mjpeg @ 0x23bb060] marker parser used 560491 bytes (4483924 bits)
[mjpeg @ 0x23bb060] marker=d9 avail_size_in_buf=0
[mjpeg @ 0x23bb060] decode frame unused 0 bytes
Input #0, image2, from 'bug.jpg':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0, 1, 1/25: Video: mjpeg, yuva444p(pc), 1280x720 [SAR 300:300 DAR 16:9], 1/25, 25 tbr, 25 tbn, 25 tbc
Successfully opened the file.
Parsing a group of options: output file decoded.png.
Successfully parsed a group of options.
Opening an output file: decoded.png.
Successfully opened the file.
detected 24 logical cores
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'video_size' to value '1280x720'
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'pix_fmt' to value '299'
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'time_base' to value '1/25'
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'pixel_aspect' to value '300/300'
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'sws_param' to value 'flags=2'
[graph 0 input from stream 0:0 @ 0x23a4760] Setting 'frame_rate' to value '25/1'
[graph 0 input from stream 0:0 @ 0x23a4760] w:1280 h:720 pixfmt:yuva444p tb:1/25 fr:25/1 sar:300/300 sws_param:flags=2
[format @ 0x23a49c0] compat: called with args=[rgb24|rgba|rgb48be|rgba64be|pal8|gray|gray8a|gray16be|monob]
[format @ 0x23a49c0] Setting 'pix_fmts' to value 'rgb24|rgba|rgb48be|rgba64be|pal8|gray|gray8a|gray16be|monob'
[auto-inserted scaler 0 @ 0x23a5c80] Setting 'flags' to value '0x4'
[auto-inserted scaler 0 @ 0x23a5c80] w:iw h:ih flags:'0x4' interl:0
[format @ 0x23a49c0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
[AVFilterGraph @ 0x23be4a0] query_formats: 4 queried, 2 merged, 1 already done, 0 delayed
[auto-inserted scaler 0 @ 0x23a5c80] picking rgba out of 8 ref:yuva444p alpha:1
[swscaler @ 0x23ab020] Forcing full internal H chroma due to input having non subsampled chroma
[auto-inserted scaler 0 @ 0x23a5c80] w:1280 h:720 fmt:yuva444p sar:300/300 -> w:1280 h:720 fmt:rgba sar:1/1 flags:0x4
Output #0, image2, to 'decoded.png':
  Metadata:
    encoder         : Lavf55.33.100
    Stream #0:0, 0, 1/90000: Video: png, rgba, 1280x720 [SAR 1:1 DAR 16:9], 1/25, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg -> png)
Press [q] to stop, [?] for help
[mjpeg @ 0x23bb060] marker=d8 avail_size_in_buf=1129714
[mjpeg @ 0x23bb060] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x23bb060] marker=e0 avail_size_in_buf=1129712
[mjpeg @ 0x23bb060] marker parser used 16 bytes (128 bits)
[mjpeg @ 0x23bb060] marker=ee avail_size_in_buf=1129694
[mjpeg @ 0x23bb060] marker parser used 14 bytes (112 bits)
[mjpeg @ 0x23bb060] marker=e1 avail_size_in_buf=1129678
[mjpeg @ 0x23bb060] marker parser used 6005 bytes (48040 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=1123670
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=1058133
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=992596
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=927059
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=861522
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=795985
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=730448
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=664911
[mjpeg @ 0x23bb060] marker parser used 65534 bytes (524272 bits)
[mjpeg @ 0x23bb060] marker=e2 avail_size_in_buf=599374
[mjpeg @ 0x23bb060] marker parser used 33031 bytes (264248 bits)
[mjpeg @ 0x23bb060] marker=ed avail_size_in_buf=566340
[mjpeg @ 0x23bb060] marker parser used 43 bytes (344 bits)
[mjpeg @ 0x23bb060] marker=e1 avail_size_in_buf=566294
[mjpeg @ 0x23bb060] marker parser used 3898 bytes (31184 bits)
[mjpeg @ 0x23bb060] marker=db avail_size_in_buf=562393
[mjpeg @ 0x23bb060] index=0
[mjpeg @ 0x23bb060] qscale[0]: 2
[mjpeg @ 0x23bb060] marker parser used 67 bytes (536 bits)
[mjpeg @ 0x23bb060] marker=c0 avail_size_in_buf=562324
[mjpeg @ 0x23bb060] sof0: picture: 1280x720
[mjpeg @ 0x23bb060] component 0 1:1 id: 66 quant:0
[mjpeg @ 0x23bb060] component 1 1:1 id: 76 quant:0
[mjpeg @ 0x23bb060] component 2 1:1 id: 88 quant:0
[mjpeg @ 0x23bb060] component 3 1:1 id: 74 quant:0
[mjpeg @ 0x23bb060] pix fmt id 11111111
[mjpeg @ 0x23bb060] marker parser used 20 bytes (160 bits)
[mjpeg @ 0x23bb060] marker=c4 avail_size_in_buf=562302
[mjpeg @ 0x23bb060] class=0 index=0 nb_codes=10
[mjpeg @ 0x23bb060] marker parser used 29 bytes (232 bits)
[mjpeg @ 0x23bb060] marker=c4 avail_size_in_buf=562271
[mjpeg @ 0x23bb060] class=1 index=0 nb_codes=242
[mjpeg @ 0x23bb060] marker parser used 78 bytes (624 bits)
[mjpeg @ 0x23bb060] escaping removed 1699 bytes
[mjpeg @ 0x23bb060] marker=da avail_size_in_buf=562191
[mjpeg @ 0x23bb060] component: 66
[mjpeg @ 0x23bb060] component: 76
[mjpeg @ 0x23bb060] component: 88
[mjpeg @ 0x23bb060] component: 74
[mjpeg @ 0x23bb060] marker parser used 560491 bytes (4483924 bits)
[mjpeg @ 0x23bb060] marker=d9 avail_size_in_buf=0
[mjpeg @ 0x23bb060] decode frame unused 0 bytes
[output stream 0:0 @ 0x23a4e60] EOF on sink link output stream 0:0:default.
No more output streams to write to, finishing.
[AVIOContext @ 0x240ec20] Statistics: 0 seeks, 50 writeouts
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A    
video:1569kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead -100.001370%
1 frames successfully decoded, 0 decoding errors

[dbuitenh]

The problem file.

[dbuitenh]

The broken output.

[Carl Eugen Hoyos]

Looks like a duplicate of ticket #2799

[dbuitenh]

Even if it is CMYK, it's not being properly parsed as such (broken output is not OK.) This is not the same as #2799, as it *does not* fail, unlike #2799, and produces invalid output.

[dbuitenh]

Carl, you're an asshole.

This is *not* a duplicate. Try to learn to comprehend english:

#2799 is lack of CMYK support.
This bug is misdetection of CMYK as 444A.

[Carl Eugen Hoyos]

To elaborate a little on your general behaviour (not necessarily related to your constructive comments here):
Last time we had a discussion on the mailing list, you started a flamewar with me when we 100% agreed on the matter. When I read my email yesterday I wasn't sure if it may have been too rude to a possible new contributor (although I was quite sure all developers would agree), when I read your mail, I suddenly realized how nice and courteous I am;-)
When I closed this ticket, I had not yet done a complete analysis and I was not 100% sure if it is really a duplicate. I had tested it completely before you reopened it for the first time (indicating it is simple and easy to compare the issues) and there is indeed (apart from the naming of the ticket) not even the slightest difference so I am not sure what you are complaining about.
If you are unhappy about the title of ticket #2799, please fix it!

[dbuitenh]

When I closed this ticket, I had not yet done a complete analysis and I was not 100% sure if it is really a duplicate.

This is not acceptable.

If you are unhappy about the title of ticket #2799, please fix it!

IT IS NOT THE SAME THING

[gjdfgh]

Closing tickets even though another *developer* disagrees doesn't seem to be acceptable.

Generally, this behavior is not useful for the ffmpeg project, and will just scare people away from reporting actual bugs. This includes closing tickets just because someone didn't paste full uncut console output blabla whatever.

In fact, this behavior is not only not useful, it's actively harmful.

So can we please be a bit more... cordial about this stuff?

[dbuitenh]

I am reopening this one last time:

These are two separate bugs.

There should be two separate bug IDs.

One for CMYK support.
One for fixing a regression in detection/failing.

These are two separate issues, and need two separate bug IDs.

Support != Regression in Failing.

[dbuitenh]

Not a duplicate, Carl.

'Fixed' by 6904168c79f21911a04bf1a17b3e11abeedd5250.

[dbuitenh]

Not a duplicate, Carl.

'Fixed' by 6904168c79f21911a04bf1a17b3e11abeedd5250.

[dbuitenh]

Silent changes without reason, with no response to valid arguments? Is this a grudge against me?

Since Carl insist on making the bug track a hostile environment for devs, I'll take this moment to stop bothering sending patches to FFmpeg. There's a nice fork I can send to.

[dbuitenh]

Since Carl insist on making the bug track a hostile environment for devs

I should have added: And everyone seems fine with that.

[Clément Bœsch]

Replying to dbuitenh:

Since Carl insist on making the bug track a hostile environment for devs

I should have added: And everyone seems fine with that.

Well, Carl is acting like a kid, and you're overreacting. What should we do? Should we scold Carl?

I do not support Carl behavior, but nor your reaction. I'm personally happy with Carl work on the trac, as well as your contributions.

I'm pretty sure you can figure something out, you are - biologically speaking - both adults.

So OK, Carl drives you nut, maybe you are not alone. The main reason, apart from that particular ticket dup-close trolling, seems to be about the reporting "rules". Maybe you can suggest something as a RFC on ffmpeg-devel. Remember, Carl is basically doing a lot of work in the trac, so we basically trust him with that stuff; it's kind of a meritocracy. From a dev perspective, we see less garbage and there is a tendency of purging ticket which are rotting because of a lack of information. And this is a good thing. Maybe you don't agree with that, so again, suggestions welcome.

[Alexander Strasser]

Replying to ubitux:

Replying to dbuitenh:

Since Carl insist on making the bug track a hostile environment for devs

I should have added: And everyone seems fine with that.

Well, Carl is acting like a kid, and you're overreacting. What should we do? Should we scold Carl?

I do not support Carl behavior, but nor your reaction. I'm personally happy with Carl work on the trac, as well as your contributions.

I fully agree with you Clément. Only thing I can do about it is plea:

Carl Eugen and Derek, please try respect each other again!

Concerning this ticket I agree with Derek it is and was about the behaviour of the decoder and thus not a duplicate of #2799.

Actually we had a discussion about the fix of the behavior and this ticket on IRC and this ticket should have probably been re-opened. But as it turns out Micheal was faster and the whole behavior that was topic of this ticket now is gone for good since commit a05635ee.

Thus I am changing the resolution of this ticket to fixed which seems the most appropriate to me.

[Alexander Strasser]

Replying to beastd:

Concerning this ticket I agree with Derek it is and was about the behaviour of the decoder and thus not a duplicate of #2799.

Actually we had a discussion about the fix of the behavior and this ticket on IRC and this ticket should have probably been re-opened. But as it turns out Micheal was faster and the whole behavior that was topic of this ticket now is gone for good since commit a05635ee.

Pardon me, I wasn't very precise here. With behavior of the decoder I meant error behavior.

Initially the decoder just detected it wrong and silently continued. Later it was changed to print an error and go on if AV_EF_EXPLODE wasn't set (commit 6904168c79f2).

Finally there was commit a05635ee that implemented a conversion from CMYK to GBRAP in
the decoder and replaced the changes of above mentioned commit 6904168c79f2.

[Carl Eugen Hoyos]

Thank you for your additional comments, this should now make clear for everybody that this was a duplicate of ticket #2799.

[compn]

you kids keep this up and i'm liable to petition the admins to remove 'open' and 'closed' statuses and only have 'fixed' or 'new' .

[Balling]

This is CMYK. As mediainfo prints:

08A868  Component - C - 1 (0x1) - 1 (0x1) (3 bytes)
08A868   Ci - Component identifier:            67 (0x43)
08A869   Hi - Horizontal sampling factor:      1 (0x1) - (4 bits)
08A869   Vi - Vertical sampling factor:        1 (0x1) - (4 bits)
08A86A   Tqi - Quantization table destination selector: 0 (0x00)
08A86B  Component - M - 1 (0x1) - 1 (0x1) (3 bytes)
08A86B   Ci - Component identifier:            77 (0x4D)
08A86C   Hi - Horizontal sampling factor:      1 (0x1) - (4 bits)
08A86C   Vi - Vertical sampling factor:        1 (0x1) - (4 bits)
08A86D   Tqi - Quantization table destination selector: 0 (0x00)
08A86E  Component - Y - 1 (0x1) - 1 (0x1) (3 bytes)
08A86E   Ci - Component identifier:            89 (0x59)
08A86F   Hi - Horizontal sampling factor:      1 (0x1) - (4 bits)
08A86F   Vi - Vertical sampling factor:        1 (0x1) - (4 bits)
08A870   Tqi - Quantization table destination selector: 0 (0x00)
08A871  Component - K - 1 (0x1) - 1 (0x1) (3 bytes)
08A871   Ci - Component identifier:            75 (0x4B)
08A872   Hi - Horizontal sampling factor:      1 (0x1) - (4 bits)
08A872   Vi - Vertical sampling factor:        1 (0x1) - (4 bits)
08A873   Tqi - Quantization table destination selector: 0 (0x00)

It should have been fixed by 84170d4be053a4c7901965fe1977970b5c5e85e5 but something went wrong.

On the other hand CMYK should not be signaled like that (in Cis), only PhotoYCC and PhotoYCC-A, it should be signaled using APP14 marker. Whatever. Not a duplicate though.

Chrome does parse it as CMYK and so is windows/Photoshop/Gimp though, so may be a point to do so.

[Balling]

Should not you remove ​https://github.com/FFmpeg/FFmpeg/blob/7b100839330ace3b4846ee4a1fc5caf4b8f8a34e/libavcodec/mjpegdec.c#L2405

I do not like it.

Fix this stuff ASAP.