Closed Bug 1217220 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla45
blocking-b2g 2.5+
Tracking Status
firefox45 --- fixed
b2g-v2.2 --- unaffected
b2g-v2.5 --- verified
b2g-master --- verified

People

(Reporter: KTucker, Assigned: jhlin)

References

()

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(5 files, 2 obsolete files)

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
Component: Gaia::System::Window Mgmt → Audio/Video
Product: Firefox OS → Core
Whiteboard: [2.5-Daily-Testing][Spark][Systemsfe] → [2.5-Daily-Testing][Spark]
No longer depends on: 1217145
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
[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?
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(npark)
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.
(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.
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.
Flags: needinfo?(npark) → needinfo?(dflanagan)
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.
Flags: needinfo?(npark)
Flags: needinfo?(ktucker)
Flags: needinfo?(jmercado)
Flags: needinfo?(dflanagan)
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.
Flags: needinfo?(npark)
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)
Video sent from iPhone to DUT
Flags: needinfo?(ktucker)
Attached video 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.
Flags: needinfo?(jmercado)
Attachment #8677648 - Attachment description: MOV_5581.MOV → iPhonevideobeforebeingsent.MOV
See Also: → 1217989
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.
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Contact: jthomas
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
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
Blocks: 1210232
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
John this issue seems to have been caused by the changes for bug 1210232.  Can you please take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(jolin)
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...
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?
Component: Audio/Video → Audio/Video: Playback
Looks like the number of AMR deocder output buffers doesn't match the input ones, which Gonk PDM doesn't handle properly.
Assignee: nobody → jolin
Flags: needinfo?(jolin)
Blocking for 2.5 with a P2 priority for fix to land on 2.5 branch post RA
blocking-b2g: 2.5? → 2.5+
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?
Flags: needinfo?(jyavenard)
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.
Flags: needinfo?(jyavenard)
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.
Attachment #8683024 - Flags: review?(jyavenard)
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.
Attachment #8683024 - Flags: review?(jyavenard)
(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.
Blocks: 1220778
Duplicate of this bug: 1220778
Attachment #8683024 - Attachment is obsolete: true
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.
Attachment #8683024 - Flags: review?(jyavenard)
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
Attachment #8683598 - Flags: review+
(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.
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
(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. :(
Blocks: 1220575
Duplicate of this bug: 1220575
Attachment #8683598 - Attachment is obsolete: true
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.
Attachment #8684117 - Flags: review+
Attachment #8683024 - Flags: review?(jyavenard)
https://hg.mozilla.org/mozilla-central/rev/0bf47a09f438
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Keywords: verifyme
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
Attachment #8684117 - Flags: approval‑mozilla‑b2g44?
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
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
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
Attachment #8684117 - Flags: approval‑mozilla‑b2g44? → approval‑mozilla‑b2g44+
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.