[Fugu][A/V]audio/video playback keep paused state ,even if pressed play button

RESOLVED WONTFIX

Status

Firefox OS
Vendcom
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: cheng.luo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [POVB])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 822697 [details]
music playback log

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19

Steps to reproduce:

Steps to reproduce:
1、apply 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch in bug 927242(fixed music crash first);
2、entry music app,select anyone  to play in the song list;
3、press pause  button;
4、press resume button;


Actual results:

the player keep paused state


Expected results:

player continue to  playback
(Reporter)

Comment 1

4 years ago
error log:E/OMXCodec(  338): [OMX.sprd.mp3.decoder] Timed out waiting for output buffers: 4/0
In google code,OMXCodec::pause() only set mPaused to true, don't change mState which is still on EXECUTING state. When resume, OMXCodec::start() directly retrun after find it is not on LOADED state. there is no chance to recover mPaused to false.
So, OMXCodec::drainInputBuffer return before emptyBuffer--> no output buffers --> OmxDecoder::ReadAudio  alway return ETIMEDOUT --> AudioQueue is empty --> MediaDecoderStateMachine::AudioLoop alway waits.

Maybe it caused by different HW platform.In Hamachi, it add PAUSING state for OMX component MXCodec::pause() could notify OMX component to change to PAUSING.When resume, OMXCodec::start could change to EXECUTING state and recover mPaused to false after find on PAUSING state.

Comment 2

4 years ago
Hi Cheng,

Please refer to the comment as below.
http://mxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder.cpp#915

And it seems that AOSP will return error when paused function is not implemented.
http://androidxref.com/4.0.4/xref/frameworks/base/include/media/stagefright/MediaSource.h#99

So could you just modify your pasued function to return error?
Thanks.
(Reporter)

Comment 3

4 years ago
(In reply to Marco Chen [:mchen] (Business Trip 10/21 ~ 10/23) from comment #2)
> Hi Cheng,

Please refer to the comment as below.
> http://mxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder.
> cpp#915

And it seems that AOSP will return error when paused function is
> not implemented.
> http://androidxref.com/4.0.4/xref/frameworks/base/include/media/stagefright/
> MediaSource.h#99

So could you just modify your pasued function to return
> error?

Yes,but now Multimedia use Stagefright frameworks integrated OpenMAX. 
The OMXCodec class inherits the MediaSource class,
OMXCodec::pause() always return OK.
http://androidxref.com/4.0.4/xref/frameworks/base/media/libstagefright/OMXCodec.cpp#4627
(Reporter)

Comment 4

4 years ago
Maybe need disable OMXCodec::pause(),so MediaSource::pause() return ERROR_UNSUPPORTED default.
Is it right?

Comment 5

4 years ago
(In reply to cheng.luo from comment #4)
> Maybe need disable OMXCodec::pause(),so MediaSource::pause() return
> ERROR_UNSUPPORTED default.
> Is it right?

The basic idea is that since OMXCodec didn't support "pause()" actually so it makes sense to return value of non-ok. You can choose your own way to do this.
Bug 919590 might be related to this bug.

Comment 7

4 years ago
Change this bug to POVB first and to see the status on Bug 919590.

For fixing this issue.
1. Vendor can modify their OMXCodec::pause() to return error code.
2. Or if Bug 919590 is reviewed then vendor can choose to add Android property too.
Whiteboard: [POVB]

Updated

4 years ago
Component: General → Vendcom
Our OMXCode pause interface return ERROR_UNSUPPORTED, it works fine now.
Cheng, can we close this bug?
Flags: needinfo?(cheng.luo)
(Reporter)

Comment 9

4 years ago
(In reply to James Zhang from comment #8)
> Our OMXCode pause interface return ERROR_UNSUPPORTED, it works fine now.
> Cheng, can we close this bug?

Agree.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(cheng.luo)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.