(No comment was entered for this change.)

Upon talking to LaForge we decided to mark it M4 P0.

How soon can we get a fix?

Restricting view to security....

Where did you get the video from?
Was this reported to us externally?
Will be SecSeverity-High if it is indeed memory corruption.

Glen Murphy encoded it for internal purposes.
I havent tracked down the exact location, but here is what I think it is

the video reports 1366x768 and we allocate buffers of that size.
but either ffmpeg, or the pipeline, at some point decodes/copies 1376 wide.
Its a best guess... this is a fairly common issue with video players.
A quick work around would be to allocate more memory for the frame buffers.
The patch will likely be in the renderer.

Stack trace:

 	media_player.exe!fastcopy_I(void * dst=0x00000000, void * src=0x00000500, int len=9308899)  + 
0x20 bytes	C
 	media_player.exe!_VEC_memcpy(void * dst=0x00000300, void * src=0x00000000, int len=0)  + 0x52 
bytes	C
>	media_player.exe!operator new(unsigned int size=85852192)  Line 59 + 0x8 bytes	C++
 	media_player.exe!_VEC_memcpy(void * dst=0x00000300, void * src=0x00000000, int len=0)  + 0x52 
bytes	C
 	media_player.exe!operator new(unsigned int size=85852192)  Line 59 + 0x8 bytes	C++
 	media_player.exe!media::FFmpegVideoDecoder::CopyPlane(unsigned int plane=1368, const 
media::VideoSurface & surface={...}, const AVFrame * frame=0x00000300)  Line 241	C++
 	media_player.exe!media::FFmpegVideoDecoder::EnqueueVideoFrame(media::VideoSurface::Format 
surface_format=YV12, const media::FFmpegVideoDecoder::TimeTuple & time={...}, const AVFrame * 
frame=0x034d8c90)  Line 215	C++
 	media_player.exe!media::FFmpegVideoDecoder::OnDecode(media::Buffer * buffer=0x034d8c90)  Line 180 
+ 0x1f bytes	C++

(No comment was entered for this change.)

Confirmed that mplayer works.
Note that since Adobe Media Encoder created this clip, these issues may affect flash
video as well.
Under chrome3, the video does not play well.
On just playback, the video pauses after awhile, but music continue.  There is no
crash, but frames do not update.
If you seek alot, you get "aww snap".  This does not occur in mplayer.

My first work around is to allocate an extra 16 rows in
media\base\video_frame_impl.cc
Index: media/base/video_frame_impl.cc
===================================================================
--- media/base/video_frame_impl.cc	(revision 32056)
+++ media/base/video_frame_impl.cc	(working copy)
@@ -127,7 +127,7 @@
   // to avoid any potential of faulting by code that attempts to access the Y
   // values of the final row, but assumes that the last row of U & V applies to
   // a full two rows of Y.
-  size_t alloc_height = RoundUp(surface_.height, 2);
+  size_t alloc_height = RoundUp(surface_.height, 2) + 16;  // align height to 16
   size_t y_bytes_per_row = RoundUp(surface_.width, 4);
   size_t uv_stride = RoundUp(y_bytes_per_row / 2, 4);
   size_t y_bytes = alloc_height * y_bytes_per_row;

It seems like more than one issue here.  The top 4 suspects are
1. resolution causes overflow. The same encoder can produce a valid 1280x720 video.
2. encoder.  ffmpeg decoder produces many warnings on this file.  Can ffmpeg produces
a valid video of this resolution?
3. null pointer/seek.  The easiest repro is to seek, and you get a null pointer crash.
4. av sync - the video seems to fall behind, even on a high end machine.  As if the
framerate of the video is much faster than the audio.  If/when this happens, the
video will stop updating frames, but the audio continues.

Re #2 encoder
If I transcode the video, it plays okay.
http://fbarchard-kir.ad.corp.google.com/mediatests/runthrough2.mp4

Also if I keep the original video, but only remux with transcoded audio, it is okay.
 Limiting the scope of the issue to container or audio, not the video.  The crash in
video is likely due to a fatal problem in audio.

Step to partial remux
ffmpeg -i runthrough.mp4 -r 25.00 -vcodec copy -an ffrunthrough0.mp4
ffmpeg -y -threads 16 -i runthrough.mp4 -vn -ac 2 -acodec pcm_s16le runthrough2.wav
faac -s runthrough2.wav -o runthrough2.m4a
ffmpeg -i runthrough0.mp4 -vcodec copy -i runthrough2.m4a -acodec copy ffrunthrough.mp4

(No comment was entered for this change.)

Just found that this is a bug in ffmpeg-mt. I tested this on ffmpeg r20471 everything
decodes okay and there isn't a crash. This can be simulated by using media_bench but
without any threads.

Confirmed with media_bench.  Note the number of Frames below

With no threads:

media_bench --stream=video runthrough.mp4 mbrunthrough.1366x768_25Hz_P420.yuv
* Stream #0: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
  Stream #1: aac (Advanced Audio Coding)

     Frames:       2999
      Total:   69859.06 ms
  Summation:   33449.88 ms
    Average:      11.15 ms
     StdDev:       8.18 ms

With 2 threads:

media_bench --stream=video --video-threads=2 runthrough.mp4
mb2runthrough.1366x768_25Hz_P420.yuv
* Stream #0: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
  Stream #1: aac (Advanced Audio Coding)

     Frames:        117
      Total:   14051.15 ms
  Summation:     188.64 ms
    Average:       1.61 ms
     StdDev:       3.06 ms

The crash is easily avoided.  Check for null before doing the memcpy.  Code is up for 
review here:
http://codereview.chromium.org/401021

The content is corrupt, so it would still be nice to make it work properly, but thats 
lower priority.  Adobe Media Encoder is not a popular encoder, and Glen claims it 
works if he does 1280x720.

in media_bench, a symptom is av_read_frame fails (return -1).

we could consider reporting the issue to adobe?
discussion could lead to improvements for FLV

the issue also occurs in mplayer if you use threads and the ffmpeg-mt version of 
mplayer.
mplayer -lavdopts threads=2 runthrough.mp4 -v

Removing "Security" label since this is a NULL ptr crash (and the "attacker" does not 
get to control any offset from NULL).

A fix is checked in
CL32455
http://codereview.chromium.org/401021

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32455 

------------------------------------------------------------------------
r32455 | fbarchard@chromium.org | 2009-11-18 16:59:14 -0800 (Wed, 18 Nov 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/ffmpeg_video_decoder.cc?r1=32455&r2=32454

Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchard-kir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32474 

------------------------------------------------------------------------
r32474 | laforge@chromium.org | 2009-11-18 18:35:15 -0800 (Wed, 18 Nov 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/media/filters/ffmpeg_video_decoder.cc?r1=32474&r2=32473

Merge 32455 - Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchardkir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021

TBR=fbarchard@chromium.org
Review URL: http://codereview.chromium.org/399107
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32475 

------------------------------------------------------------------------
r32475 | laforge@chromium.org | 2009-11-18 18:35:42 -0800 (Wed, 18 Nov 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249/src/media/filters/ffmpeg_video_decoder.cc?r1=32475&r2=32474

Merge 32455 - Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchardkir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021

TBR=fbarchard@chromium.org
Review URL: http://codereview.chromium.org/405028
------------------------------------------------------------------------

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32455 

------------------------------------------------------------------------
r32455 | fbarchard@chromium.org | 2009-11-18 16:59:14 -0800 (Wed, 18 Nov 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/ffmpeg_video_decoder.cc?r1=32455&r2=32454

Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchard-kir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32474 

------------------------------------------------------------------------
r32474 | laforge@chromium.org | 2009-11-18 18:35:15 -0800 (Wed, 18 Nov 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/media/filters/ffmpeg_video_decoder.cc?r1=32474&r2=32473

Merge 32455 - Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchardkir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021

TBR=fbarchard@chromium.org
Review URL: http://codereview.chromium.org/399107
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=32475 

------------------------------------------------------------------------
r32475 | laforge@chromium.org | 2009-11-18 18:35:42 -0800 (Wed, 18 Nov 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249/src/media/filters/ffmpeg_video_decoder.cc?r1=32475&r2=32474

Merge 32455 - Check for null frame pointers and do nothing to avoid a crash.
BUG=27675
TEST=play this http://fbarchardkir.ad.corp.google.com/mediatests/runthrough.mp4 and do lots of seeks.  A crash will occur after about 5 or 10 seeks without this patch.

Review URL: http://codereview.chromium.org/401021

TBR=fbarchard@chromium.org
Review URL: http://codereview.chromium.org/405028
------------------------------------------------------------------------

The fix has been verified in 3.0.195.38 (Official Build 34131).
Not marking the status as verified, will change once the build has been released to 
public.

-Venkat.

Thanks for verifying venkataramana!

(No comment was entered for this change.)

(No comment was entered for this change.)

Releasing details; it looks like there was no particular security impact anyway (crash 
due to NULL).

(No comment was entered for this change.)

hey, dont have much time to comment much but hope this helps,Chrome 14.0.835.186 m (windows).

Chrome starts to play video using html5 tags its a mp4 video then crashes after a few seconds.

link to site: www.markcoker.com.au