1032652 - Have a way for MediaDecoderReader to read MediaResource in an unblocking / asynchronous fashion.

Status: RESOLVED INVALID

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

Description

[Bruce Sun [:brsun]]

Current data-flow between MediaResource and MediaDecoderReader is through blocking read. It is good to have a unblocking / asynchronous reading mechanism to avoid blocking when MediaResource don't have enough data for MediaDecoderReader.

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

Do we still need this when MediaDecoderReader can work in async mode? Async MediaDecoderReader + sync MediaResource still provide async interfaces to the user of MediaDecoderReader. On the other hand, sync MediaDecoderReader + async MediaResource still provide sync interfaces.

Comment 2

[Bruce Sun [:brsun]]

If we don't want to waste any thread blocking on reading data from MediaResource, then there should be something we could do to improve this call-flow.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

In fact, there is always a thread blocked waiting for data. It could be the caller thread or the internal thread of MediaResource that is waiting for data.

Comment 4

[Bruce Sun [:brsun]]

The intention of this bug is trying to avoid any blocking read in MediaDecoderReader.

If there are any threads necessary for waiting data (ex. inside MediaResource or necko), maybe we can 
just keep it as usual. But if there are any threads waiting on other blocked threads (ex. blocking read between MediaDecoderReader and MediaResource), probably we could adapt another threading / buffering model to improve it.

Comment 5

[Benjamin Chen [:bechen]]

I'm starting to evaluate what we need to do in this bug.

Comment 6

[Benjamin Chen [:bechen]]

Attachment: WIP-bug-1032652.v01.patch

1. Create MediaTaskQueue for both video and audio.
2. Let decode thread returns immediately => the 2 new thread of MediaTaskQueue will do the "block decoding".

Now the patch is not stable, seek function is not work, sometimes the playback will stuck or crash.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

If you want asynchronous decoding, you should implement MediaDecoderReader::RequestAudioData() and RequestVideoData() instead of the synchronous MediaDecoderReader::DecodeAudioData() and MediaDecoderReader::DecodeAudioFrame().

Then you can have async non-blocking decoding without having to cram it into a synchronous interface.

For am example, see the patch in bug 1032633, which I updated this morning.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8459387 [details] [diff] [review]
WIP-bug-1032652.v01.patch

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

::: content/media/omx/MediaCodecReader.cpp
@@ +373,5 @@
> +    return false;
> +  }
> +  aKeyframeSkip = false;
> +  RefPtr<nsIRunnable> task =
> +    NS_NewRunnableMethodWithArg<int64_t>(this,

This is bad, because the MediaDecoderStateMachine calls this (and DecodeAudioData) in a loop, so you'll end up dispatching many more of these events than you need, and burning through the CPU and battery.

Implement MediaDecoderReader::RequestAudioData and RequestVideoData to avoid that.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Patches here touch MediaCodecReader, which has been removed.