MSE: Allow negative parsed frame PTS/DTS in FrameProcessor

MSE: Allow negative parsed frame PTS/DTS in FrameProcessor

r274473 did not remove sanity checks for negative PTS/DTS that occur
prior to any adjustment based on timestampOffset. Current MSE spec does
not call for issuing decode error if PTS or DTS are negative at the top
of the coded frame processing loop. This change removes the sanity
checks that are not spec-compliant.

R=acolwell@chromium.org
BUG=381114
TEST=FrameProcessorTest.AllowNegativeFramePTSAndDTSBeforeOffsetAdjustment

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=277903

[wolenetz, 2014-06-17 02:14:15]

acolwell@, PTAL @ PS1.

While this fixes the decode error problem reported in http://crbug.com/381114,
the repro site in that bug has issues with compliant coded frame processing and
our decoder preroll logic. Manually seeking beyond an initial
discontinuity-triggered gap allows all but the first ~2 seconds of the repro
site's video to play.

The first audio frame has ~-13msPTS, 0msDTS, ~23msDUR.
It is truncated due to overlapping time 0==appendWindowStart, and resulting
processed frame is PTS=0,DTS=0,~10msDUR.

The second audio frame has ~10msPTS,~23msDTS, ~23msDUR.
This triggers discontinuity since the difference between ~23msDTS and 0msDTS is
> 2 * last frame duration (which was truncated to ~10ms).

The discontinuity causes both audio and video track buffers to need a random
access point, and none such occurs for a while for video, so the net result is
two buffered ranges:
0..~41ms, and ~2s-~139s. Seeking manually to ~2s allowed the rest of the video
to play.

I believe this change makes FrameProcessor more compliant. The repro site has
issues with:
1) DTS frequently is > PTS
2) Initial PTS < 0 significantly enough to trigger discontinuity.
(repro site =
http://sr-repro.s3.amazonaws.com/gravitymux/repro-gravitymuxed.html)

Also, there is no regression specific to this change on a release build against
the yt-dash-mse conformance unit test page.

[acolwell GONE FROM CHROMIUM, 2014-06-17 15:26:10]

lgtm

[wolenetz, 2014-06-17 17:37:29]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2014-06-17 17:39:34]

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

[commit-bot: I haz the power, 2014-06-17 23:42:03]

Change committed as 277903