1115759 - Implement slow video decode simulator

Status: RESOLVED DUPLICATE of bug 1194518

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

Description

[Bobby Holley (:bholley)]

By inserting some busy-waiting in AppleV{DA,T}Decoder::Input, I was able to find some very interesting bugs in our performance on low-end machines (bug 1114830, bug 1114840).

It seems like it would be a pretty useful feature to land this machinery behind a pref. This would allow QA and testers to simulate low-end hardware, and we could even turn it on for certain mochitests to widen our test coverage.

Chris, does this seem like a good idea to you? If so, which other places throughout the stack would be interesting to instrument with delays?

Comment 1

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

Yes, this sounds like a great idea.

We can add a Decorator that inserts a wrapper around the PDM created in PlatformDecoderModule::Create, that wraps the MediaDataDeocoder created with something that injects waits in Input(), and/or other functions even. Then it will be cross platform.

You could also put random waits into MediaTaskQueue's processing loop.

Adding sleeps to seeks would also be interesting, but it may be covered by adding waits to MediaTaskQueue.

If we're really sadistic we can re-order the MediaTaskQueue. Now that we have MediaPromises, I think we can potentially uncouple many of the ordering related things in our stack. But I think we should not reorder the task queue until we have time to spend making our pipeline more robust.

Comment 2

[Bobby Holley (:bholley)]

(In reply to Chris Pearce (:cpearce) from comment #1)
> If we're really sadistic we can re-order the MediaTaskQueue. Now that we
> have MediaPromises, I think we can potentially uncouple many of the ordering
> related things in our stack. But I think we should not reorder the task
> queue until we have time to spend making our pipeline more robust.

FWIW, I don't believe this is possible or desirable - ordering is basically the only invariant we have. For example, we have a common pattern where we dispatch a 'cancel' task and immediately follow it with some new unrelated command. Inverting the order of those two operations would be disastrous.