Roll FFmpeg for M37.

media/base/media_file_checker.cc

Index: media/base/media_file_checker.cc
diff --git a/media/base/media_file_checker.cc b/media/base/media_file_checker.cc
index 418839d6f1d121268c9c32346d81e60a82aa76e1..4a49ac7c6a29c5c8bed2b8863e0d04ca6c812d4a 100644
--- a/media/base/media_file_checker.cc
+++ b/media/base/media_file_checker.cc
@@ -84,18 +84,20 @@ bool MediaFileChecker::Start(base::TimeDelta check_time) {
       // decoded; otherwise av_free_packet() will corrupt memory.
       AVPacket temp_packet = packet;
       do {
-        avcodec_get_frame_defaults(frame.get());

[wolenetz, 2014/05/16 19:45:58]

nit: In CL description, s/get_buffer_defaults/get_frame_defaults

[DaleCurtis, 2014/05/20 01:13:45]

Done.

         result = avcodec_decode_audio4(av_context, frame.get(), &frame_decoded,
                                        &temp_packet);
         if (result < 0)
           break;
+        av_frame_unref(frame.get());
         temp_packet.size -= result;
         temp_packet.data += result;
+        frame_decoded = 0;
       } while (temp_packet.size > 0);
     } else if (av_context->codec_type == AVMEDIA_TYPE_VIDEO) {
-      avcodec_get_frame_defaults(frame.get());
       result = avcodec_decode_video2(av_context, frame.get(), &frame_decoded,

[wolenetz, 2014/05/16 19:45:58]

(Possibly for a different CL): Per
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...,
ILTM like we might not be protecting against overreads for damaged MPEG streams.
By design or am I missing something? 

[DaleCurtis, 2014/05/16 19:54:26]

DecoderBuffer automatically pads and zeros.

[wolenetz, 2014/05/20 22:37:10]

(Clarification from offline / CR reply comment in other file: ffmpeg packet
creation in this path pads (in ffmpeg code). In main media pipeline path (not in
this file), ffmpeg_demuxer.cc code using DecoderBuffer that similarly pads and
zeros is used).

                                      &packet);
+      if (result >= 0 && frame_decoded)

[wolenetz, 2014/05/16 19:45:58]

(Possibly for a different CL): Per
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...,
some decoders may support multiple frames in a single AVPacket. For video, why
don't we use temp_packet, and update its size & data like we do for audio? Is
this possibly because the return value (unlike audio) is zero if no frame could
be decompressed, instead of number of bytes consumed regardless?

[DaleCurtis, 2014/05/16 19:54:26]

Hmm, that comment has changed I think. When I talked to Ronald about this in the
past FFmpeg only outputs 1 frame per packet.

We could add a check to ensure this is true though.

[DaleCurtis, 2014/05/20 01:13:45]

Done.

[wolenetz, 2014/05/20 22:37:10]

Clarification from offline: DCHECK is added to main media pipeline, but not this
checker.

+        av_frame_unref(frame.get());
     }
     av_free_packet(&packet);
   } while (base::TimeTicks::Now() < deadline && read_ok && result >= 0);