This came up in comment #19 of  crbug.com/597127 .

"If we expect progressive jpegs to fail to decode to YUV, we should be able to disable these decode in onQueryYUV8() rather than waiting to fail in onGetYUV8Planes().

We successfully do this *some* of the time now.  yuvSubsampling() catches jpegs where (info.comps_in_scan < info.num_components).
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp&q=JPEGImageDecoder&sq=package:chromium&l=222

However, some progressive jpegs (including the ones in this bug) still have 3 components in their first scan.  They just have additional information on at least one of the components in subsequent scans.

We can detect all progressive/multi-scan jpegs by instead calling jpeg_has_multiple_scans().

FWIW, skia's decoders support YUV decoding of progressive images.  Is this something Chrome would want?  I *think* this can be fixed in Chrome if we use "comp_info" instead of "cur_comp_info" in outputRawData().

Chrome currently decodes all progressive images in buffered image mode.  I'm not sure it makes much sense to decode to YUV in buffered image mode, since we would have to repeatedly draw YUV->RGBA every time the YUV data was updated.  Maybe this is not so bad though?

Another alternative would be to disable buffered image mode on YUV decodes of progressive images (again if that was something we wanted to support)."