1045351 - [B2G][RTSP] When pausing an AAC file via RTSP, the audio will not play again

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RTSP, defect)

Description

[pete siphantong [:Petes]]

Attachment: ad.txt

Description:
When the user pause an AAC file via RTSP, the audio will not play again 

Setup Steps:
1) Flame device is set to 319mb

Repro Steps:
1) Update a Flame device to BuildID: 20140728000238
3) Go to Browser 
4) Go to https://goo.gl/BhJd77
5) Play the audio > Pause 
6) Tap play

Actual:
the audio will not play again 

Expected:
the audio will plays again 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0



Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/11143/
See attached: video, logcat, https://www.youtube.com/watch?v=RtFmVkGz2R0

Comment 1

[pete siphantong [:Petes]]

This issue also reproduces on the Flame 2.1 (319mb), Open_C 2.1, Flame 2.0(512mb), Open_C 2.0, Flame 1.4(319mb), Base Image v122, and the Base Image v121-2 . The audio will not play again 


Flame 2.1 (319mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140728040209
Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd
Gecko: a4dcfbebcb58
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open_C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140728040209
Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd
Gecko: a4dcfbebcb58
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0(512mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open_C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4(319MB)

Environmental Variables:
Device: Flame 1.4
Build ID: 20140728063001
Gaia: eb3b185325901d4c04e2d43eb58d90835213bea9
Gecko: aae9112f1fc6
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Base Image
v122

Environmental Variables:
Device: Flame 1.3 
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Base Image
v121-2

Environmental Variables:
Device: Flame 1.3 
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3)
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

_______________________________________________________________________________________________________________________

The issue does not reproduce on the Buri 2.1, Buri 2.0, Buri 1.4, and the Open_C v1.4. The audio will play again 

Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140728073003
Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd
Gecko: d77f6a96ff96
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140726063007
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 1.4

Environmental Variables:
Device: Buri 1.4
Build ID: 20140728063001
Gaia: eb3b185325901d4c04e2d43eb58d90835213bea9
Gecko: aae9112f1fc6
Version: 30.0 (1.4) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open_C v1.4 

v1.4 Environmental Variables:
Device: Open_C v1.4 MOZ
BuildID: 20140728000238
Gaia: 0a864988f5dce7f9f3dea9609e8ef054679c30ff
Gecko: 2da96d621030
Version: 32.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[StevenLee[:slee]]

Hi Benjamin,

Please look this bug, thanks.

Comment 3

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

Does this happen with other file types or only AAC?

Comment 4

[pete siphantong [:Petes]]

On https://goo.gl/BhJd77, besides the 'AMX' link, this issue also occurs on the 'http redirect to rtsp'(h264 accplus), and the 'hyperlink detection of rtsp feature'(mp4).

The issue does not occur on link 2-9, 11.

Comment 5

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

[Blocking Requested - why for this release]:

The file stops playing and will not resume no matter how many times the user taps the play/pause button. This will frustrate the end user. Nominating 2.0?

Comment 6

[Benjamin Chen [:bechen]]

Update status:
I had tried the latest pvt build on flame devices, the symptom not only occurs on audio only stream but also video stream.

Comment 7

[Bruce Sun [:brsun]]

Attachment: bug1045351_flame_pause_paly_fail.patch

Hi Benjamin,
As we discussed offline, OMXCodec::resumeLocked() might have some logic flaws in it. Kindly have a try on this patch to see if it helps or not.

Comment 8

[bhavana bajaj [:bajaj]]

Since was already shipped with 1.3 and we passed certification and given the time we have left for 2.0 unfortunately we would have to fix this in 2.1 so not blocking for 2.0 but lets get this fixed for 2.1

Comment 9

[Benjamin Chen [:bechen]]

Comment on attachment 8465294 [details] [diff] [review]
bug1045351_flame_pause_paly_fail.patch

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

(In reply to Bruce Sun [:brsun] from comment #7)
> Created attachment 8465294 [details] [diff] [review]
> bug1045351_flame_pause_paly_fail.patch
> 
> Hi Benjamin,
> As we discussed offline, OMXCodec::resumeLocked() might have some logic
> flaws in it. Kindly have a try on this patch to see if it helps or not.

The patch works good.

Let me briefly explain the bug....

When the OMXCodec is pause/start, there are 2 entry points to trigger the |drainInputBuffer|.
1. At the OMXCodec::resumeLocked.
2. Component send EMPTY_BUFFER_DONE message.

Obviously entry point 1 now is broken due to the basic logic error....
So everything works fine relies on the entry point 2. That's why the RTSP streaming is different to HTTP streaming.

HTTP:
HTTP streaming always caches the data so there are always multiple buffers in OMX. When OMX is paused, entry point 2 is closed by pause for one buffer. After OMX is started, there are other buffers to trigger entry point 2 again.

RTSP:
When OMX is paused, entry point 2 is closed for one buffer.  After OMX is started, there is no other buffer to trigger the enrty point 2 because the network speed is slower than HW decooder makes the buffer often empty.

Comment 10

[Bruce Sun [:brsun]]

mvines: Need your help to check how drainInputBuffers() could be called in OMXCodec::resumeLocked() on Flame:
 - https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/libstagefright/OMXCodec.cpp?h=b2g_jb_3.2#n5004

Comment 12

[Jason Smith [:jsmith]]

Blocking since it blocks the CAF CC meta bug.

Comment 13

[William Hsu [:whsu]]

A duplicate bug of Bug 1021570?

Comment 14

[bhargavg1]

(In reply to Bruce Sun [:brsun] from comment #10)
> mvines: Need your help to check how drainInputBuffers() could be called in
> OMXCodec::resumeLocked() on Flame:
>  -
> https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/
> libstagefright/OMXCodec.cpp?h=b2g_jb_3.2#n5004

Did you look at KK [1], looks like we dont need a patch there. We always make sure to flush buffers

[1] https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/libstagefright/OMXCodec.cpp?h=b2g_kk_3.5#n4937

Comment 15

[Bruce Sun [:brsun]]

(In reply to bhargavg1 from comment #14)
> (In reply to Bruce Sun [:brsun] from comment #10)
> > mvines: Need your help to check how drainInputBuffers() could be called in
> > OMXCodec::resumeLocked() on Flame:
> >  -
> > https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/
> > libstagefright/OMXCodec.cpp?h=b2g_jb_3.2#n5004
> 
> Did you look at KK [1], looks like we dont need a patch there. We always
> make sure to flush buffers
> 
> [1]
> https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/
> libstagefright/OMXCodec.cpp?h=b2g_kk_3.5#n4937

There is a problem on Flame JB (refer to the link on comment 10), right?

Comment 16

[bhargavg1]

(In reply to Bruce Sun [:brsun] from comment #15)
> (In reply to bhargavg1 from comment #14)
> > (In reply to Bruce Sun [:brsun] from comment #10)
> > > mvines: Need your help to check how drainInputBuffers() could be called in
> > > OMXCodec::resumeLocked() on Flame:
> > >  -
> > > https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/
> > > libstagefright/OMXCodec.cpp?h=b2g_jb_3.2#n5004
> > 
> > Did you look at KK [1], looks like we dont need a patch there. We always
> > make sure to flush buffers
> > 
> > [1]
> > https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/
> > libstagefright/OMXCodec.cpp?h=b2g_kk_3.5#n4937
> 
> There is a problem on Flame JB (refer to the link on comment 10), right?

I dont think there are any plans for CAF to support v2.0 with JB. 

No action for CAF on this bug anymore

Comment 17

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #12)
> Blocking since it blocks the CAF CC meta bug.

Removing the blocking flag since this is no longer true.

Comment 18

[Mike Lien[:mlien]]

verify with Flame KK build v162-3, reproduce rate is 40%