Do not set m_decodeFailed in ImageFrameGenerator::decodeToYUV

third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp

 /*
  * Copyright (C) 2012 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 222 matching lines @@
 
     OwnPtr<ImageDecoder> decoder = ImageDecoder::create(*data, ImageDecoder::AlphaPremultiplied, ImageDecoder::GammaAndColorProfileApplied);
     if (!decoder)
         return false;
 
     decoder->setData(data, allDataReceived);
 
     OwnPtr<ImagePlanes> imagePlanes = adoptPtr(new ImagePlanes(planes, rowBytes));
     decoder->setImagePlanes(imagePlanes.release());
 
     ASSERT(decoder->canDecodeToYUV());

[Justin Novosad, 2016/03/24 14:13:57]

Does this assert hit?

[xidachen, 2016/03/24 14:40:24]

This condition is always true, so it doesn't hit this ASSERT.

 
     if (decoder->decodeToYUV()) {
         setHasAlpha(0, false); // YUV is always opaque
         return true;
     }
 
     ASSERT(decoder->failed());

[Justin Novosad, 2016/03/24 14:13:57]

Does this assert fire when you try to repro the bug with assertions enabled
(debug build)?

[xidachen, 2016/03/24 14:40:24]

The example loads and calls drawImage() on 25 images, debugging shows that 15 of
them hit this assert which means decoding failed. But 10 of them go into the
above if() block which returns true.

-    m_decodeFailed = true;
     return false;

[Justin Novosad, 2016/03/24 14:13:57]

Can you explain why the decode flow reaches this point if the decode did not
actually fail?  Is there something special about the way the jpegs are encoded?

[Noel Gordon, 2016/03/25 08:16:46]

Concur with these questions.

https://codereview.chromium.org/1719533002 was a the most recent change that
touched the body of the YUV decoding path in the JPEGImageDecoder.  Possible
regression (not sure), bugs is marked NeedsBisect so we can wait for that

But meanwhile, you could try reverting the changes to JPEGImageDecoder routine

  static bool outputRawData(JPEGImageReader* reader, ImagePlanes* imagePlanes)

that got added on https://codereview.chromium.org/1719533002 to see if that
helps?

 }
 
 SkBitmap ImageFrameGenerator::tryToResumeDecode(size_t index, const SkISize& scaledSize)
 {
     TRACE_EVENT1("blink", "ImageFrameGenerator::tryToResumeDecode", "frame index", static_cast<int>(index));
 
     ImageDecoder* decoder = 0;
     const bool resumeDecoding = ImageDecodingStore::instance().lockDecoder(this, m_fullSize, &decoder);
     ASSERT(!resumeDecoding || decoder);
 
@@ skipping 146 matching lines @@
 
     // Setting a dummy ImagePlanes object signals to the decoder that we want to do YUV decoding.
     decoder->setData(data, allDataReceived);
     OwnPtr<ImagePlanes> dummyImagePlanes = adoptPtr(new ImagePlanes);
     decoder->setImagePlanes(dummyImagePlanes.release());
 
     return updateYUVComponentSizes(decoder.get(), sizeInfo->fSizes, sizeInfo->fWidthBytes);
 }
 
 } // namespace blink