Closed Bug 1045351 Opened 7 years ago Closed 5 years ago

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

Categories

(Firefox OS Graveyard :: RTSP, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: psiphantong, Assigned: bechen)

References

()

Details

(Whiteboard: permfail, [POVB])

Attachments

(2 files)

Attached file 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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Hi Benjamin,

Please look this bug, thanks.
Flags: needinfo?(bechen)
Flags: needinfo?(bechen)
Assignee: nobody → bechen
Status: NEW → ASSIGNED
Does this happen with other file types or only AAC?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(psiphantong)
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.
Flags: needinfo?(psiphantong) → needinfo?(ktucker)
[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?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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.
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.
Attachment #8465294 - Flags: feedback?(bechen)
See Also: → 1045889
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
blocking-b2g: 2.0? → backlog
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.
Attachment #8465294 - Flags: feedback?(bechen) → feedback+
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
Flags: needinfo?(mvines)
Whiteboard: [2.0-flame-test-run-3] → [2.0-flame-test-run-3][POVB]
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Duplicate of this bug: 1048982
Blocking since it blocks the CAF CC meta bug.
blocking-b2g: backlog → 2.0+
A duplicate bug of Bug 1021570?
Flags: needinfo?(mvines) → needinfo?(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
Flags: needinfo?(bhargavg1) → needinfo?(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?
Flags: needinfo?(brsun) → needinfo?(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
Flags: needinfo?(bhargavg1)
(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.
blocking-b2g: 2.0+ → ---
verify with Flame KK build v162-3, reproduce rate is 40%
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ktucker)
Whiteboard: [2.0-flame-test-run-3][POVB] → [2.0-flame-test-run-3][2.1-flame-test-run-2][POVB]
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Whiteboard: [2.0-flame-test-run-3][2.1-flame-test-run-2][POVB] → permfail, [POVB]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.