Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
379693002:
Update SourceBufferStream and its unit tests to always expect valid durations. (Closed)
|
Created:
6 years, 5 months ago by acolwell GONE FROM CHROMIUM Modified:
6 years, 5 months ago CC:
chromium-reviews, feature-media-reviews_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Project:
chromium Visibility:
Public. |
DescriptionUpdate SourceBufferStream and its unit tests to always expect valid durations.
This change fixes the SourceBufferStream unit tests so that they always
provide valid durations for buffers that it passes to SourceBufferStream.
I've also added code to SoureBufferStream to verify that it always gets
buffers with valid durations.
Minor tweaks to test expectations were needed to compensate for the
SourceBufferStream behaving differently when it got actual durations instead
of using the durations it made up. In most cases I just used the duration
the SourceBufferStream was ultimately using. In a few cases the duration
the SourceBufferStream was generating didn't make any sense so I simply
changed the expectations to match the new behavior.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=283365
Patch Set 1 #
Total comments: 54
Patch Set 2 : Rebase and address CR comments #
Total comments: 2
Patch Set 3 : Address CR comment #
Messages
Total messages: 11 (0 generated)
https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (left): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1597: CheckExpectedBuffers("70 100K 120K 130K"); I haven't 100% convinced myself that this particular change in behavior is right. The old behavior does appear to rely on the fact that the old durations were super tiny instead of 30ms like they were actually intended to be when the test was written. I'm pretty sure when 90 gets appended it now causes 100 to get deleted, where that wouldn't have happened before because 90 would have only spanned 90-90.000001.
First round of comments/nits/questions: https://codereview.chromium.org/379693002/diff/1/media/base/decoder_buffer.h File media/base/decoder_buffer.h (right): https://codereview.chromium.org/379693002/diff/1/media/base/decoder_buffer.h#... media/base/decoder_buffer.h:82: << duration.InSecondsF(); nit: disallow kInfiniteDuration() buffer duration? https://codereview.chromium.org/379693002/diff/1/media/base/stream_parser_buf... File media/base/stream_parser_buffer.cc (right): https://codereview.chromium.org/379693002/diff/1/media/base/stream_parser_buf... media/base/stream_parser_buffer.cc:112: << " dts " << GetDecodeTimestamp().InSecondsF(); nit: add dur to logging https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (left): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1597: CheckExpectedBuffers("70 100K 120K 130K"); On 2014/07/09 02:07:02, acolwell wrote: > I haven't 100% convinced myself that this particular change in behavior is > right. The old behavior does appear to rely on the fact that the old durations > were super tiny instead of 30ms like they were actually intended to be when the > test was written. I'm pretty sure when 90 gets appended it now causes 100 to get > deleted, where that wouldn't have happened before because 90 would have only > spanned 90-90.000001. I think your analysis is correct, and the new behavior is also spec compliant (CFP step 15.2, specifically, should remove original 100K (and step 16 should then remove original 125)). I'm less clear why the previous code behaved as it did (how does SBS determine frame_end_timestamp for the purposes of step 15?) reference spec: https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source....) https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (right): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:279: if (timestamps[i] == "C") Something seems wrong here, too. We're checking that status is kConfigChange inside a block that guarantees this. Instead, ISTM like we should assert that timestamps[i] is "C" in this block, and add an else clause for this block that asserts timestamps[i] isn't "C". https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:443: // The config id for non-splice frame appends will not be affected. nit: Update comment for new ..D##.. syntax https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:498: timestamps[i] = timestamps[i].substr(0, duration_pos ); nit: s/ )/)/ https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:542: buffer->ConvertToSpliceBuffer(pre_splice_buffers); Something seems wrong to me, or I've lost my clarity on this since previous CLs: why do we test appending buffers that have splice frames already converted, instead of testing that SBS append properly creates the splice buffers? ILTM like SBS::GenerateSpliceFrame() is essentially simulated here (not tested here), and that the purpose of this is to attempt to cover the GetNextBuffers and buffered range calculations in the presence of splice frames. ChunkDemuxerTest other pipeline / integration / layout tests might cover GenerateSpliceFrame, but I'm wondering if there is a better way to unit test it here. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:810: NewSegmentAppend("0D30K"); curious: without D30 and frame_duration_ set to 30ms, what would the resulting ranges be on the next line? https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1579: // Overlap with a new segment from 0 to 120ms. nit: s/120/130? https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1618: // Overlap with a new segment from 0 to 120ms. nit: s/120/130? (or 125, see next comment) https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1619: NewSegmentAppendOneByOne("0K 30 60 90 120D10K"); s/120D10K/120D5K/ to better test that old buffer at 125ms is deleted since its prerequisite keyframe was deleted? This might match more closely the intention in the next source code comment, below. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1656: // Should expect buffers 70ms and 100ms from the track buffer. Then it should nit: s/expect buffers 70ms and 100ms/return frame 70ms/ https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1682: // Now overlap the keyframe at 120ms. There's no keyframe after 70ms, so 120ms nit: s/*/Now overlap the keyframes at 120ms and 130ms./ ? https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1702: // track: 70 100K nit: s/100K// https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1732: // track: 70 100K nit: s/100K// https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1737: NewSegmentAppendOneByOne("10K 40 70 100K"); nit: is s/100K/100D30K/ necessary to match my other nits in this test? https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1744: // Overlap with a new segment from 0 to 120ms; 70ms and 100ms go in track nit: s/and 100ms go/goes/ https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1749: // Now append a keyframe at 80ms. The buffer at 100ms should be deleted from nit s/The...// https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3808: NewSegmentAppend("9D2K"); Is D2 necessary since SetAudioStream()->SetStreamInfo() sets |frame_duration_|? https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3834: NewSegmentAppend("1K 4D2K"); ditto https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3871: NewSegmentAppend("0D2K"); ditto https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3873: NewSegmentAppend("1D2K"); ditto
https://codereview.chromium.org/379693002/diff/1/media/base/decoder_buffer.h File media/base/decoder_buffer.h (right): https://codereview.chromium.org/379693002/diff/1/media/base/decoder_buffer.h#... media/base/decoder_buffer.h:82: << duration.InSecondsF(); On 2014/07/09 22:42:16, wolenetz wrote: > nit: disallow kInfiniteDuration() buffer duration? Done. https://codereview.chromium.org/379693002/diff/1/media/base/stream_parser_buf... File media/base/stream_parser_buffer.cc (right): https://codereview.chromium.org/379693002/diff/1/media/base/stream_parser_buf... media/base/stream_parser_buffer.cc:112: << " dts " << GetDecodeTimestamp().InSecondsF(); On 2014/07/09 22:42:16, wolenetz wrote: > nit: add dur to logging Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (right): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:279: if (timestamps[i] == "C") On 2014/07/09 22:42:18, wolenetz wrote: > Something seems wrong here, too. We're checking that status is kConfigChange > inside a block that guarantees this. > Instead, ISTM like we should assert that timestamps[i] is "C" in this block, and > add an else clause for this block that asserts timestamps[i] isn't "C". I just changed this to EXPECT_EQ("C", timestamps[i]) since I agree the condition above guarantees the expectation ins always true. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:443: // The config id for non-splice frame appends will not be affected. On 2014/07/09 22:42:17, wolenetz wrote: > nit: Update comment for new ..D##.. syntax Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:498: timestamps[i] = timestamps[i].substr(0, duration_pos ); On 2014/07/09 22:42:16, wolenetz wrote: > nit: s/ )/)/ Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:542: buffer->ConvertToSpliceBuffer(pre_splice_buffers); On 2014/07/09 22:42:17, wolenetz wrote: > Something seems wrong to me, or I've lost my clarity on this since previous CLs: > why do we test appending buffers that have splice frames already converted, > instead of testing that SBS append properly creates the splice buffers? ILTM > like SBS::GenerateSpliceFrame() is essentially simulated here (not tested here), > and that the purpose of this is to attempt to cover the GetNextBuffers and > buffered range calculations in the presence of splice frames. ChunkDemuxerTest > other pipeline / integration / layout tests might cover GenerateSpliceFrame, but > I'm wondering if there is a better way to unit test it here. This sounds like a question for Dale and should be addressed in a separate CL. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:810: NewSegmentAppend("0D30K"); On 2014/07/09 22:42:18, wolenetz wrote: > curious: without D30 and frame_duration_ set to 30ms, what would the resulting > ranges be on the next line? Removed the set_frame_duration() call since it was left over from some old changes. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1579: // Overlap with a new segment from 0 to 120ms. On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/120/130? Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1618: // Overlap with a new segment from 0 to 120ms. On 2014/07/09 22:42:16, wolenetz wrote: > nit: s/120/130? (or 125, see next comment) Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1619: NewSegmentAppendOneByOne("0K 30 60 90 120D10K"); On 2014/07/09 22:42:17, wolenetz wrote: > s/120D10K/120D5K/ to better test that old buffer at 125ms is deleted since its > prerequisite keyframe was deleted? This might match more closely the intention > in the next source code comment, below. I'm just trying to explicitly document the original test behavior. I'm not trying to refine the tests here. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1656: // Should expect buffers 70ms and 100ms from the track buffer. Then it should On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/expect buffers 70ms and 100ms/return frame 70ms/ Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1682: // Now overlap the keyframe at 120ms. There's no keyframe after 70ms, so 120ms On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/*/Now overlap the keyframes at 120ms and 130ms./ ? Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1702: // track: 70 100K On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/100K// Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1732: // track: 70 100K On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/100K// Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1737: NewSegmentAppendOneByOne("10K 40 70 100K"); On 2014/07/09 22:42:17, wolenetz wrote: > nit: is s/100K/100D30K/ necessary to match my other nits in this test? The D30 is not needed because the duration is implied by the previous frames. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1744: // Overlap with a new segment from 0 to 120ms; 70ms and 100ms go in track On 2014/07/09 22:42:17, wolenetz wrote: > nit: s/and 100ms go/goes/ Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1749: // Now append a keyframe at 80ms. The buffer at 100ms should be deleted from On 2014/07/09 22:42:16, wolenetz wrote: > nit s/The...// Done. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3808: NewSegmentAppend("9D2K"); On 2014/07/09 22:42:17, wolenetz wrote: > Is D2 necessary since SetAudioStream()->SetStreamInfo() sets |frame_duration_|? Yes. frame_duration_ is not used by string based appends. I wanted to force durations to be specified explicitly in the 1 buffer case. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3834: NewSegmentAppend("1K 4D2K"); On 2014/07/09 22:42:16, wolenetz wrote: > ditto The duration is only specified here because the normal rule of using the duration between the current and last frame is not what the original test was expecting. This is just preserving the old test behavior. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3871: NewSegmentAppend("0D2K"); On 2014/07/09 22:42:17, wolenetz wrote: > ditto ditto re: making 1 buffer case explicit. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3873: NewSegmentAppend("1D2K"); On 2014/07/09 22:42:17, wolenetz wrote: > ditto ditto re: making 1 buffer case explicit.
lgtm % one nit https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (right): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:279: if (timestamps[i] == "C") On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:18, wolenetz wrote: > > Something seems wrong here, too. We're checking that status is kConfigChange > > inside a block that guarantees this. > > Instead, ISTM like we should assert that timestamps[i] is "C" in this block, > and > > add an else clause for this block that asserts timestamps[i] isn't "C". > I just changed this to EXPECT_EQ("C", timestamps[i]) since I agree the condition > above guarantees the expectation ins always true. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:542: buffer->ConvertToSpliceBuffer(pre_splice_buffers); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > Something seems wrong to me, or I've lost my clarity on this since previous > CLs: > > why do we test appending buffers that have splice frames already converted, > > instead of testing that SBS append properly creates the splice buffers? ILTM > > like SBS::GenerateSpliceFrame() is essentially simulated here (not tested > here), > > and that the purpose of this is to attempt to cover the GetNextBuffers and > > buffered range calculations in the presence of splice frames. ChunkDemuxerTest > > other pipeline / integration / layout tests might cover GenerateSpliceFrame, > but > > I'm wondering if there is a better way to unit test it here. > > This sounds like a question for Dale and should be addressed in a separate CL. I've pinged Dale in email. Thanks. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:810: NewSegmentAppend("0D30K"); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:18, wolenetz wrote: > > curious: without D30 and frame_duration_ set to 30ms, what would the resulting > > ranges be on the next line? > Removed the set_frame_duration() call since it was left over from some old > changes. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1619: NewSegmentAppendOneByOne("0K 30 60 90 120D10K"); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > s/120D10K/120D5K/ to better test that old buffer at 125ms is deleted since its > > prerequisite keyframe was deleted? This might match more closely the intention > > in the next source code comment, below. > I'm just trying to explicitly document the original test behavior. I'm not > trying to refine the tests here. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:1737: NewSegmentAppendOneByOne("10K 40 70 100K"); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > nit: is s/100K/100D30K/ necessary to match my other nits in this test? > > The D30 is not needed because the duration is implied by the previous frames. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3808: NewSegmentAppend("9D2K"); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > Is D2 necessary since SetAudioStream()->SetStreamInfo() sets > |frame_duration_|? > Yes. frame_duration_ is not used by string based appends. I wanted to force > durations to be specified explicitly in the 1 buffer case. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3834: NewSegmentAppend("1K 4D2K"); On 2014/07/15 18:49:26, acolwell wrote: > On 2014/07/09 22:42:16, wolenetz wrote: > > ditto > The duration is only specified here because the normal rule of using the > duration between the current and last frame is not what the original test was > expecting. This is just preserving the old test behavior. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3871: NewSegmentAppend("0D2K"); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > ditto > ditto re: making 1 buffer case explicit. Acknowledged. https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:3873: NewSegmentAppend("1D2K"); On 2014/07/15 18:49:26, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > ditto > ditto re: making 1 buffer case explicit. Acknowledged. https://codereview.chromium.org/379693002/diff/20001/media/base/decoder_buffer.h File media/base/decoder_buffer.h (right): https://codereview.chromium.org/379693002/diff/20001/media/base/decoder_buffe... media/base/decoder_buffer.h:82: duration == kInfiniteDuration()) nit: this doesn't disallow set_duration(kInfiniteDuration());
https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... File media/filters/source_buffer_stream_unittest.cc (right): https://codereview.chromium.org/379693002/diff/1/media/filters/source_buffer_... media/filters/source_buffer_stream_unittest.cc:542: buffer->ConvertToSpliceBuffer(pre_splice_buffers); On 2014/07/15 18:49:27, acolwell wrote: > On 2014/07/09 22:42:17, wolenetz wrote: > > Something seems wrong to me, or I've lost my clarity on this since previous > CLs: > > why do we test appending buffers that have splice frames already converted, > > instead of testing that SBS append properly creates the splice buffers? ILTM > > like SBS::GenerateSpliceFrame() is essentially simulated here (not tested > here), > > and that the purpose of this is to attempt to cover the GetNextBuffers and > > buffered range calculations in the presence of splice frames. ChunkDemuxerTest > > other pipeline / integration / layout tests might cover GenerateSpliceFrame, > but > > I'm wondering if there is a better way to unit test it here. > > This sounds like a question for Dale and should be addressed in a separate CL. 1. These tests were written before the splice frame implementation was complete. I wrote the unpacking logic first. 2. Splice frames aren't generated for Video which is what all tests except the special Audio_XXX tests use. 3. IIRC, crafting some of the corner cases is ugly/non-trivial through the standard interface. Probably this path can be killed, but it may be non-trivial to do so. Definitely something for another CL.
https://codereview.chromium.org/379693002/diff/20001/media/base/decoder_buffer.h File media/base/decoder_buffer.h (right): https://codereview.chromium.org/379693002/diff/20001/media/base/decoder_buffe... media/base/decoder_buffer.h:82: duration == kInfiniteDuration()) On 2014/07/15 21:05:38, wolenetz wrote: > nit: this doesn't disallow set_duration(kInfiniteDuration()); oops. Fixed.
The CQ bit was checked by acolwell@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/acolwell@chromium.org/379693002/40001
Message was sent while issue was closed.
Change committed as 283365
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/392193003/ by falken@chromium.org. The reason for reverting is: This seems to have broken several layout tests: event-attributes.html media-controller-time-clamp.html video-currentTime-delay.html video-currentTime-set.html video-duration-known-after-eos.html video-loop.html video-playbackrate.html video-played-collapse.html video-seek-past-end-paused.html video-seek-past-end-playing.html video-seek-to-duration-with-playbackrate-zero.html See for example this build: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.6%20(dbg).... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
