MSE: Always use new FrameProcessor's coded frame processing

MSE: Always use new FrameProcessor's coded frame processing

This change ignores Blink's signalling of whether or not to use
LegacyFrameProcessor, and instead always uses the new, compliant,
FrameProcessor to handle SourceBuffer coded frame processing.

R=acolwell@chromium.org
TEST=Linux Debug: no media_unittest or MSE layout test regression; Linux Release with proprietary codecs: no regression of yt-dash-mse-test ToT
BUG=249422
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=274468

[wolenetz, 2014-06-02 22:20:23]

PTAL @ PS1

Thanks!

[acolwell GONE FROM CHROMIUM, 2014-06-02 23:14:35]

Any reason not to make the change in WebMediaSourceImpl instead? I'm just
wondering if there is any value in keeping tests against both frame processors
running for a little while longer just to prevent regressions from sneaking in
to the legacy algorithm.

[wolenetz, 2014-06-02 23:17:41]

On 2014/06/02 23:14:35, acolwell wrote:
> Any reason not to make the change in WebMediaSourceImpl instead? I'm just
> wondering if there is any value in keeping tests against both frame processors
> running for a little while longer just to prevent regressions from sneaking in
> to the legacy algorithm.

That's a great idea. Next PS will do that.

[acolwell GONE FROM CHROMIUM, 2014-06-02 23:35:03]

lgtm

[wolenetz, 2014-06-02 23:39:40]

Thank you for review.

[wolenetz, 2014-06-02 23:39:46]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2014-06-02 23:43:55]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wolenetz@chromium.org/307263003/20001

[commit-bot: I haz the power, 2014-06-03 11:53:52]

Change committed as 274468