When we are trying to recording a video element by VP8TrackEncoder or OmxTrackEncoder. The image data can not access. (SIGV) Reproduce step: 1. import vp8encoder patch or omxencoder patch. 2. https://rawgithub.com/randylin/mediaRecorder/master/MediaRecorder.html press "PlayVideoFromFile" 3. press "start" == code // aChunk is a video chunk layers::Image* img = aChunk.mFrame.GetImage(); ImageFormat format = img->GetFormat(); if (format == PLANAR_YCBCR) { layers::PlanarYCbCrImage* yuv = const_cast<layers::PlanarYCbCrImage *>(static_cast<const layers::PlanarYCbCrImage *>(img)); const layers::PlanarYCbCrImage::Data *data = yuv->GetData(); // cannot access "data->mYChannel" LOG1("%p", data->mYChannel); == Some clues. 1. the img format is PLANAR_YCBCR 2. video resolution - 640*480 is ok - 848*480 is not ok

on b2g device only.

Thanks for :cyu's help. Update status. Now we found that: 1. The image data comes from video element is allocated on ashmem. 2. When MSG calls the callback function "VideoTrackEncoder::NotifyQueuedTrackChanges", the image data is available. 3. When the encoder thread wants to access the image data queued in TrackEncoder, the data is not available. Memory map shows the ashmem is deleted but not unmapped. TODO: 1. keep tracking the ashmem to know who "un-ping" or "delete" the ashmem. (ioctl function) 2. Maybe the ashmem is deleted by b2g process because the image data is also sent to rendering through ipc? 3. different video resolution?

The root cause is that even though we hold a nsRefPtr<layers::Image>, the yuv data of this image still can be released. The release is triggered here: http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/ImageClient.cpp#150 Content process calls ImageClientSingle::UpdateImage -> TextureClient::ForceRemove() -> ipc to b2g process. b2g process calls PImageBridgeParent::DestroySharedMemory -> ipc to content process. Then the yuv data is released. b2g process call stack== 0 mozilla::layers::PImageBridgeParent::DestroySharedMemory (this=0xaffb7c00, shmem=...) at PImageBridgeParent.cpp:276 #1 0xb4ecb228 in mozilla::layers::PImageBridgeParent::DeallocShmem (this=<optimized out>, aMem=...) at PImageBridgeParent.cpp:816 #2 0xb505aa32 in mozilla::layers::ShmemTextureHost::DeallocateSharedData (this=0xb0f934c0) at ../../../../../../hg/mozilla-central/gfx/layers/composite/TextureHost.cpp:589 #3 0xb505b3f2 in mozilla::layers::TextureParent::ActorDestroy (this=0xb2bd5100, why=<optimized out>) at ../../../../../../hg/mozilla-central/gfx/layers/composite/TextureHost.cpp:704 #4 0xb4e9924c in mozilla::plugins::PBrowserStreamParent::DestroySubtree (this=0xb2bd5100, why=mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::Deletion) at PBrowserStreamParent.cpp:451 #5 0xb4f13fce in mozilla::layers::PTextureParent::Send__delete__ (actor=0xb2bd5100) at PTextureParent.cpp:69 #6 0xb4f17b64 in mozilla::layers::PTextureParent::OnMessageReceived (this=0xb2bd5100, __msg=...) at PTextureParent.cpp:209 #7 0xb4ed18ae in mozilla::layers::PImageBridgeParent::OnMessageReceived (this=0xaffb7c00, __msg=...) at PImageBridgeParent.cpp:380 #8 0xb4e86782 in mozilla::ipc::MessageChannel::DispatchAsyncMessage (this=0xaffb7c30, aMsg=...) at ../../../../../../hg/mozilla-central/ipc/glue/MessageChannel.cpp:992 #9 0xb4e884a0 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=<optimized out>) at ../../../../../../hg/mozilla-central/ipc/glue/MessageChannel.cpp:889 #10 0xb4e86234 in DispatchToMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)()> (method= (void (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0xb4e88423 <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, arg=<optimized out>)