1217220 - Received videos through MMS do not play and a serious error occurs when trying to watch them in video app

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

When the user receives a video via MMS from an iPhone, they will notice that the video will not play in the messaging app. The play/pause buttons will not function.

If they try to play the video in the video app, they will be prompted that "another app is currently using the video player." 

Repro Steps:
1) Update a Aries to 20151021143908
2) Record any length video at any resolution on an iPhone 6S. (I did a 2 second video at 720p 30fps)
3) Send that video through messaging to the DUT.
4) On the DUT, open the messaging app and tap on the video to play it.
5) Save the video and then open the video app and try to play the received video.

Actual:
The user cannot view videos received from an iPhone 6s in the messaging app and they will receive an error when trying to view them from the video app.

Expected:
The user can play and pause videos received in a MMS and they can also view them in the video app. 

Environmental Variables:
Device: Aries 2.5
Build ID: 20151021143908
Gaia: 32d827a70af90a05918f234e5b16b35d5d2a07e8
Gecko: 473aefe5bd85842eeb142e0cde8e2cd21edbf40b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: 5/5 100%
See attached: video clip, logcat

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue also occurs on the Flame 2.5

Videos received from an iPhone 6s through messaging will not play in the messaging app and an error is encountered when trying to view them in the video app. 

Environmental Variables:
Device: Flame 2.5 (Full Flash)(KK)(319mb)
Build ID: 20151021064220
Gaia: 32d827a70af90a05918f234e5b16b35d5d2a07e8
Gecko: 473aefe5bd85842eeb142e0cde8e2cd21edbf40b
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

--------------

This issue does not occur on Flame 2.2

The received MMS video plays without issue and no issue is encountered when playing them from the video app. 

Environmental Variables:
Device: Flame 2.2 (Full Flash)(KK)(319mb)
Build ID: 20151019032501
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: 6b4e563acaf9
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: NonplayingMMSVideoLogcat.txt

Comment 3

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

[Blocking Requested - why for this release]:
User is blocked from using the video app after receiving a video from an iOS device.  No-Jun can I get your opinion on this issue?

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Note: We do not have a test iOS device/SIM.  This bug was written using a personal device that does not have unlimited data so getting a regression window at QAnalysts will not be possible.

Comment 5

[KTucker [:KTucker][Inactive 3/4/2016]]

(In reply to Jayme Mercado [:JMercado] from comment #4)
> Note: We do not have a test iOS device/SIM.  This bug was written using a
> personal device that does not have unlimited data so getting a regression
> window at QAnalysts will not be possible.

I will work on this regression window when I get the chance.

Comment 6

[No-Jun Park [:njpark]]

I agree this is a blocker, since iphone is a relatively popular phone. Perhaps it's something to do with the codec or resolution?  pinging :djf for insight.

Comment 7

[David Flanagan [:djf]]

There is nothing of interest in the logcat. 

KTucker: can you attach a sample iphone 6s video that reproduces this problem, please? From the video it looks like it is a .3gp file.

Jayme: does the bug reproduce if you just copy the iphone video to the sdcard and try to view it in the video app? From step 5 of the STR, it sounds like it might. If so, then you can get a regression window without actually using mobile data to send the movie via text message. If this only reproduces when a movies is sent via MMS, though, then that suggests a very different bug...

No-Jun: We've landed various video patches recently. Can you verify that other, non iphone videos still work?  Is this iphone specific or did we just break everything with a recent patch?

I'd like to know:

 - is this iphone specific?
 - is it iphone 6s specific, or can it repro with older iphone models?
 - is it specific to videos received by MMS, or can we just copy videos to the sdcard

And I'd like someone to attach a video that fails to play in the video app.

With that information, Russ, or Punam or I can then take the bug and investigate further to see if it is a gaia issue that we can fix. (Set needinfo for all of us and we'll see who has time to take it.) 

The product and component for this bug are already set to Core:Audio/Video indicating that this is a codec issue, but we should confirm that before we ask the platform team to investigate too much.  From the youtube video of the bug, it appears that the Video app is able to create a thumbnail for the received video. This says to me that gecko is able to play the video and that the bug in in Gaia, not Gecko.

Comment 8

[No-Jun Park [:njpark]]

On today's build, I have not noticed video app having issues, and our daily test report shows no video app bugs, so I think this isn't caused by a general failure.  ktucker or jmercado would know whether the MMS from non-iphones worked okay.

Comment 9

[No-Jun Park [:njpark]]

I tried sending MMS from my android phone, but when I received it on my aries, it was broken into animated gif and 3gp audio files.  Not sure whether it was my service provider or the phone, but i was able to view the video and listen to audio okay. (although they were separated)

Comment 10

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: iPhonevideobeforebeingsent.MOV

Video sent from iPhone to DUT

Comment 11

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: Recieved video file

This is he file after it was recieved on the Firefox OS device.  I put this file onto a different device with usb and saw the 'Video app in use' error.

Comment 12

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Setting qawanted to verify if the file from comment 11 causes this issue to reproduce on Flame 2.2 builds.  If not we will find a regression window using that file.

Comment 13

[John Thomas [:Johnt]]

This issue is NOT occurring on the Flame 2.2.
Result: The video attached to bug labeled as "Before Received File" plays successfully within the Video app.

Environmental Variables:
Device: Flame 2.2 Kk Fullflash (512mb)
BuildID: 20151026032516
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: 9e0aa88fea7a
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 14

[John Thomas [:Johnt]]

Caused by changes made in Bug 1210232

Mozilla Inbound Regression Window

Last Working
Environmental Variables:
Device: Flame 2.5
BuildID: 20151012053412
Gaia: 87f5c9d55ab6a77dcfa48a3f3a8b4f5016f3c657
Gecko: c17c1dae6ea6cac77b687b3ecbf47b6b9f6be785
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20151012062011
Gaia: 87f5c9d55ab6a77dcfa48a3f3a8b4f5016f3c657
Gecko: f8283eaf5aad6a910ff853f12db390af45f19483
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Last Working gaia / First Broken gecko - This issue DOES occur with broken Gecko.
Gaia: 87f5c9d55ab6a77dcfa48a3f3a8b4f5016f3c657
Gecko: f8283eaf5aad6a910ff853f12db390af45f19483

Last Working gecko / First Broken gaia - This issue does NOT occur with broken Gaia.
Gecko: c17c1dae6ea6cac77b687b3ecbf47b6b9f6be785
Gaia: 87f5c9d55ab6a77dcfa48a3f3a8b4f5016f3c657

Mozilla Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c17c1dae6ea6cac77b687b3ecbf47b6b9f6be785&tochange=f8283eaf5aad6a910ff853f12db390af45f19483

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

John this issue seems to have been caused by the changes for bug 1210232.  Can you please take a look?

Comment 16

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Looks like you can reproduce the issue by taking the 3gp video and then trying to play it via the sdcard.
Looks like mp4decoder can't handle the 3gp movie encoding from iphone mms, where as quicktime can...

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

More over when you do this :
W/Video   ( 2505): [JavaScript Warning: "HTTP "Content-Type" of "text/html" is not supported. Load of media resource about:blank failed." {file: "app://video.gaiamobile.org/index.html" line: 0}]
I/OMXClient( 2505): Using client-side OMX mux.
E/OMXMaster( 2505): A component of name 'OMX.qcom.audio.decoder.aac' already exists, ignoring this one.
D/GonkAudioDecoderManager( 2505): Configure audio mime type:audio/3gpp, chan no:1, sample-rate:8000, profile:0
D/MediaCodecProxy( 2505): resourceReserved
I/OMXClient( 2505): Using client-side OMX mux.
D/GonkAudioDecoderManager( 2505): Decoder format changed
D/GonkAudioDecoderManager( 2505): Output decoded sample time is revert. time=-5000
D/GonkVideoDecoderManager( 2505): codecReserved
D/GonkVideoDecoderManager( 2505): Configure video mime type: video/avc, width:320, height:240


Looks like the code calls OMX.qcom.audio.decoder.aac twice and causes the app to think that the another app is using the video player?  Maybe I am looking at it wrong?

Comment 18

[John Lin [:jhlin][:jolin]]

Looks like the number of AMR deocder output buffers doesn't match the input ones, which Gonk PDM doesn't handle properly.

Comment 19

[Mahendra Potharaju [:mahe]]

Blocking for 2.5 with a P2 priority for fix to land on 2.5 branch post RA

Comment 20

[John Lin [:jhlin][:jolin]]

Jean-Yves, an odd thing about the test file is that the 1st AMR sample sent to the decoder has negative timestamp (-500). Is it okay for demuxer to generate such sample?

Comment 21

[Jean-Yves Avenard [:jya]]

there's nothing in the container spec that states it can't be (with mp4 timestamp are stored on a signed int).

it's fairly common with mp4 when an edit list is set to align audio and video. it often makes the first audio frame have a negative timestamp.

shouldn't have any effect on the decoder however; and we've removed all assertion that would have complained if any time was negative.
The MediaDecoderStateMachine will shift the time base accordingly so that the first sample is 0.

Comment 22

[John Lin [:jhlin][:jolin]]

Attachment: use output timestamp to decide which item needs to be removed from waiting list.

Comment 23

[John Lin [:jhlin][:jolin]]

Comment on attachment 8683024 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list.

Handle the case that decoder generates more than one output for one input sample by using the output timestamp to decide which item in the waiting list should be dropped.

Comment 24

[Jean-Yves Avenard [:jya]]

Comment on attachment 8683024 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list.

Review of attachment 8683024 [details] [diff] [review]:
-----------------------------------------------------------------

this seems a bit hacky to me... 
I can see what this work around does, but not why the problem is occurring in the first place.

Could you shed some background information please?
thank you

::: dom/media/platforms/gonk/GonkAudioDecoderManager.cpp
@@ +125,5 @@
>      return NS_ERROR_NOT_AVAILABLE;
>    }
>  
> +  // MP4 container allows samples with negative timestamp.
> +  if (timeUs >= 0 && mLastTime > timeUs) {

Why would samples with negative timestamp be treated any differently?

Your issue is that mLastTime is initialised with a value of 0. Initialise it with a value of INT64_MIN or better make it a Maybe<int64_t>

0 isn't a good initialisation value

::: dom/media/platforms/gonk/GonkMediaDataDecoder.cpp
@@ +182,5 @@
>  }
>  
> +// Use output timestamp to determine which output buffer is already returned
> +// and remove corresponding info, except for EOS, from the waiting list.
> +// This method handles the cases that audio decoder sends multiple output

How could this happen?

@@ +188,5 @@
> +void
> +GonkDecoderManager::UpdateWaitingList(int64_t aForgetUpTo)
> +{
> +  size_t i = 0;
> +  for (auto& item : mWaitOutput) {

const auto& item as it's not modified
But seeing that your aim is to find the array offset, the use of a loop such as for (size_t i = 0; i < mWaitOutput.Length(); i++) {
  const auto& item = mWaitOutput[i];
}
seems clearer to me.

Comment 25

[John Lin [:jhlin][:jolin]]

(In reply to Jean-Yves Avenard [:jya] from comment #24)

> ::: dom/media/platforms/gonk/GonkAudioDecoderManager.cpp
> @@ +125,5 @@
> >      return NS_ERROR_NOT_AVAILABLE;
> >    }
> >  
> > +  // MP4 container allows samples with negative timestamp.
> > +  if (timeUs >= 0 && mLastTime > timeUs) {
> 
> Why would samples with negative timestamp be treated any differently?
> 
> Your issue is that mLastTime is initialised with a value of 0. Initialise it
> with a value of INT64_MIN or better make it a Maybe<int64_t>
> 
> 0 isn't a good initialisation value
> 

 Agreed. Will do that in next version.

> ::: dom/media/platforms/gonk/GonkMediaDataDecoder.cpp
> @@ +182,5 @@
> >  }
> >  
> > +// Use output timestamp to determine which output buffer is already returned
> > +// and remove corresponding info, except for EOS, from the waiting list.
> > +// This method handles the cases that audio decoder sends multiple output
> 
> How could this happen?
> 

 This particular 3GPP file contains AMR audio samples of length 160 bytes, each consists of 5 AMR frames. It seems this is not unusual for AMR because the 'AMRDecSpecStruc' structure defined in spec [1] has a 'frames_per_sample' field.
 It causes problem in original code for the AMR codec on B2G produces one output buffer per AMR frame, therefore GonkAudioDecoderManager will get 5 output buffers for one input sample when decoding this file. 

 [1] http://www.etsi.org/deliver/etsi_ts/126200_126299/126244/12.04.00_60/

> @@ +188,5 @@
> > +void
> > +GonkDecoderManager::UpdateWaitingList(int64_t aForgetUpTo)
> > +{
> > +  size_t i = 0;
> > +  for (auto& item : mWaitOutput) {
> 
> const auto& item as it's not modified
> But seeing that your aim is to find the array offset, the use of a loop such
> as for (size_t i = 0; i < mWaitOutput.Length(); i++) {
>   const auto& item = mWaitOutput[i];
> }
> seems clearer to me.

 You're right. Will do that in next version.

Comment 27

[John Lin [:jhlin][:jolin]]

Attachment: use output timestamp to decide which item needs to be removed from waiting list.

Comment 28

[John Lin [:jhlin][:jolin]]

Comment on attachment 8683024 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list.

Address review comments.
As for mLastTime, Maybe<int64_t> seems a little bit too much to me because of its overhead of assignment and comparison. For the code that will be executed per frame, I prefer to do less than more.

Comment 29

[Jean-Yves Avenard [:jya]]

Comment on attachment 8683598 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list.

Review of attachment 8683598 [details] [diff] [review]:
-----------------------------------------------------------------

the samples coming back from the decoder, do they all have the same presentation timestamp?

This still seems wrong to me.
So if you attempt to decode a frame containing 5 samples, you will only output the first one returned. What happened to the other 4? They will be dropped.

I don't see anything wrong with being returned 5 output buffers from a single input (the same thing is happening with the ffmpeg decoder with VP9 content), there we loop with the decoder until we get all the frames and output then all.

r+ because I can't test and you obviously have tried it :) Still think it's wrong

::: dom/media/platforms/gonk/GonkMediaDataDecoder.cpp
@@ +214,3 @@
>    while (mWaitOutput.Length() > 0) {
>      RefPtr<MediaData> output;
> +    WaitOutputInfo wait = mWaitOutput.ElementAt(0);

const WaitOutputInfo&

Also above you use mWaitOutput[x] access, would be nicer to have consistency there

@@ +224,3 @@
>        if (output) {
>          mDecodeCallback->Output(output);
> +        UpdateWaitingList(output->mTime);

don't you want to drain all pending samples there? seems that this will never remove any frames anyway, so it seems unnecessary (and confusing) to filter the output there

::: dom/media/platforms/gonk/GonkMediaDataDecoder.h
@@ +51,5 @@
>  
>  protected:
>    GonkDecoderManager()
>      : mMutex("GonkDecoderManager")
> +    , mLastTime(kInvalidTime)

I think explicitly setting it to INT64_MIN is clearer as the test is always a comparison test rather than equality one. We want the lowest possible value

Comment 30

[John Lin [:jhlin][:jolin]]

(In reply to Jean-Yves Avenard [:jya] from comment #29)
> Comment on attachment 8683598 [details] [diff] [review]
> use output timestamp to decide which item needs to be removed from waiting
> list.
> 
> Review of attachment 8683598 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> the samples coming back from the decoder, do they all have the same
> presentation timestamp?

 No, the decoder increases the timestamp value by adding the duration of output buffer(s). In this particular case it looks like:

 Input Timestamp    Output Timestamp
 ----- ---------    ------ ---------
 #1    -5000        #1     -5000
                    #2     15000
                    #3     35000
                    #4     55000
                    #5     75000
 #2     95000       #6     95000
 ...                ...

> 
> This still seems wrong to me.
> So if you attempt to decode a frame containing 5 samples, you will only
> output the first one returned. What happened to the other 4? They will be
> dropped.

 Did the commit message and bad variable naming mislead you to think output buffer will be dropped? My apology for giving you the wrong impression. :-$

> 
> I don't see anything wrong with being returned 5 output buffers from a
> single input (the same thing is happening with the ffmpeg decoder with VP9
> content), there we loop with the decoder until we get all the frames and
> output then all.

 Exactly, the original code made a wrong assumption that only one output buffer will be produced for each input buffer. And that's what I want to fix with this patch.

 The loop to get all available output buffers is [1]. It's a bit tricky here because while MediaCodec(Proxy) is a synchronous API, the underlying decoder (ACodec) is asynchronously running in another thread. Output() is implemented as no waiting, so there is no guarantee that all output buffers for previous input are ready. That's why I set up a waiting list and use the timestamp to help me decide whether all outputs are returned.

 [1] https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/gonk/GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#197

> 
> r+ because I can't test and you obviously have tried it :) Still think it's
> wrong

 Sorry again for unable to make the code easier to understand. :)

> 
> ::: dom/media/platforms/gonk/GonkMediaDataDecoder.cpp
> @@ +214,3 @@
> >    while (mWaitOutput.Length() > 0) {
> >      RefPtr<MediaData> output;
> > +    WaitOutputInfo wait = mWaitOutput.ElementAt(0);
> 
> const WaitOutputInfo&
> 
> Also above you use mWaitOutput[x] access, would be nicer to have consistency
> there

 Okay. Will do that.

> 
> @@ +224,3 @@
> >        if (output) {
> >          mDecodeCallback->Output(output);
> > +        UpdateWaitingList(output->mTime);
> 
> don't you want to drain all pending samples there? seems that this will
> never remove any frames anyway, so it seems unnecessary (and confusing) to
> filter the output there

 Not quite sure what you mean here. |if (output)| here is to handle the case that decoder emits EOS flag w/o output buffer (because all are already returned in previous Output() calls|.

> 
> ::: dom/media/platforms/gonk/GonkMediaDataDecoder.h
> @@ +51,5 @@
> >  
> >  protected:
> >    GonkDecoderManager()
> >      : mMutex("GonkDecoderManager")
> > +    , mLastTime(kInvalidTime)
> 
> I think explicitly setting it to INT64_MIN is clearer as the test is always
> a comparison test rather than equality one. We want the lowest possible value

 Okay. Will do that.

Comment 31

[Jean-Yves Avenard [:jya]]

Then I don't see why you need a waiting map. Why can't you just loop and always output all the pending samples that have been returned?
UpdateWaitingList will drop any samples found prior the time provided?
I get that you want to detect and keep the frames output since the last drain/eos
But the whole point of draining/flushing is to guarantee that no more frames will come out after. 

As to deciding if MediaCodec has finished returning all the samples, why would it matter when you can simply call the callback's Output whenever a new samples is available. If it arrives late it doesn't matter. The MediaFormatReader and MDSM will handle any delays

Comment 32

[John Lin [:jhlin][:jolin]]

(In reply to Jean-Yves Avenard [:jya] from comment #31)
> Then I don't see why you need a waiting map. Why can't you just loop and
> always output all the pending samples that have been returned?

 The original purpose of waiting list is to save the offset of input sample so we can write it back to the output, but it won't work for the cases of multiple output per input.
 The waiting list also helps ProcessToDo() to decide whether it needs to request notification about buffer availablity [1].

 [1] https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/gonk/GonkMediaDataDecoder.cpp?from=GonkMediaDataDecoder.cpp#232
> UpdateWaitingList will drop any samples found prior the time provided?

 Yes.

> I get that you want to detect and keep the frames output since the last
> drain/eos
> But the whole point of draining/flushing is to guarantee that no more frames
> will come out after. 

 The waiting list has nothing to do with keeping the output since the last drain/eos. It's there to let me know whether I should keep listening to notification from MediaCodec.

>
> As to deciding if MediaCodec has finished returning all the samples, why
> would it matter when you can simply call the callback's Output whenever a
> new samples is available. If it arrives late it doesn't matter. The
> MediaFormatReader and MDSM will handle any delays

 Because of the limitation of MediaCodec API, GonkDecoderManager need to know when it needs to stop requesting notification from MediaCodec. Or the notification will keep firing even when there is no new output.

 Gonk PDM implementation could be much more simpler if MediaCodec has asynchronous mode. Unfortunately that's not available until Lollipop. :(

Comment 34

[John Lin [:jhlin][:jolin]]

Attachment: use output timestamp to decide which item needs to be removed from waiting list. r=jya

Comment 35

[John Lin [:jhlin][:jolin]]

Comment on attachment 8684117 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list. r=jya

Rebase and carry r+ from jya.

Comment 36

[John Lin [:jhlin][:jolin]]

Try result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ceaf507a6ce3

Comment 37

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0bf47a09f438

Comment 38

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0bf47a09f438

Comment 39

[John Lin [:jhlin][:jolin]]

Comment on attachment 8684117 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list. r=jya

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 1217220
User impact if declined: cannot play 3GPP video with AMR audio
Testing completed: video files can be played normally
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none

Comment 40

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue has been verified as fixed on Aries 2.6 and Flame 2.6

The user can play the received MMS and no error occurs in the video app when playing the video.

Device: Aries 2.6
BuildID: 20151110122027
Gaia: c0482775b1526add626b170dd53a72d10bcaf07c
Gecko: cc473fe5dc512c450634506f68cbacfb40a06a23
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.6 (Full Flash)(KK)(512mb)
Build ID: 20151110030237
Gaia: c0482775b1526add626b170dd53a72d10bcaf07c
Gecko: cc473fe5dc512c450634506f68cbacfb40a06a23
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

--------------------------

This issue still occurs on Aries 2.5 and Flame 2.5

The received MMS video cannot be played and an error occurs when trying to view the video in the video app.

Device: Aries 2.5
BuildID: 20151110170210
Gaia: 07baf613699fa6225359c7f04825c5caeb71d424
Gecko: 361f2673aadc988918a551b45ecef4cce58edf1e
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 44.0a2 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0


Environmental Variables:
Device: Flame 2.5 (Full Flash)(KK)(512mb)
Build ID: 20151109004552
Gaia: cf646c52bb947af28329b0a100df91d1b1f2a907
Gecko: 4eafef5b80f8985c94c4a067f130d37513e1a581
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 41

[Mahendra Potharaju [:mahe]]

Comment on attachment 8684117 [details] [diff] [review]
use output timestamp to decide which item needs to be removed from waiting list. r=jya

Approved for 2.5

Thanks

Comment 42

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/59faaf2d79ac

Comment 43

[Carrie.Yang Leave from Mozilla]

This bug has been verified as pass on latest build of Flame KK v2.5 512mb and Aries KK v2.5 by the STR in comment 0.
Actual results: The user can play the received MMS and no error occurs in the video app when playing the video.
See attachment: Verified_Aries_v2.5.3gp.
Reproduce rate: 0/10.

Device: Flame KK v2.5 512mb  (Pass)
Build ID               20151202161543
Gaia Revision          2d54c29f429bed790b5d8284633812dc2b782518
Gaia Date              2015-12-02 14:41:15
Gecko Revision         http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/90cfa13f91aa4bb811f6f651e2e3ad7d2bddbb3d
Gecko Version          44.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151202.152541
Firmware Date          Wed Dec  2 15:25:51 UTC 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK v2.5 (Pass)
Build ID               20151202162902
Gaia Revision          2d54c29f429bed790b5d8284633812dc2b782518
Gaia Date              2015-12-02 14:41:15
Gecko Revision         http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/90cfa13f91aa4bb811f6f651e2e3ad7d2bddbb3d
Gecko Version          44.0a2
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151202.153536
Firmware Date          Wed Dec  2 15:35:44 UTC 2015
Bootloader             s1

Comment 44

[Carrie.Yang Leave from Mozilla]

Attachment: Verified_Aries_v2.5.3gp