1600295 - Move DecodedStream for audio to new ProcessedInputTrack subclass

Status: NEW

(Core :: Audio/Video: MediaStreamGraph, task, P3)

Description

[Dan Minor [:dminor]]

In Bug 1581074 we're removing blocking from the MediaTrackGraph. As part of that, we need to update MoveToSegment to guarantee that MediaTrack::mSegment always contains enough data. If null data is inserted, this throws off the accounting in NotifyOutput. Bug 1581074 hacked around that, but the long term solution is to add a new ProcessedInputTrack class.

Some notes from Andreas on implementing ProcessedInputClass:

Long-term we're gonna make a new ProcessedInputTrack subclass for DecodedStream's audio track, and use that instead of SourceMediaTrack. This allows it to be pulled (ProcessInput) instead of pushed (AppendData) so that this state can be tracked in the new subclass itself and not in a general class (as SourceMediaTrack has to support now). If you want to attempt a new ProcessedInputTrack subclass you can of course, but there are a number of considerations to take. Most importantly we try our hardest to stay away from locks as doing a syscall on the high-prio audio thread would be devastating.
The simplest would be to pull from the AudioQueue directly in ProcessInput, since pulling data from the queue triggers the other end to download, decode and push more. With another approach of pulling the data off the graph thread, and using perhaps a lock-free queue to relay it to the graph thread, one has to make sure not to pull too much out of the AudioQueue as that will trigger more download, decode and all.

Comment 1

[Andreas Pehrson [:pehrsons]]

I'll add that this is talking about a new subclass of ProcessedInputTrack, specifically for DecodedStream's audio path because it is the only one that pushes audio into the graph (and contends for a lock with the audio thread).