Add SourceBuffer implementations of Audio/VideoTracks

third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp

Index: third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
diff --git a/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp b/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
index 9e48afb2becb85d97f5f713249b3768643e65c95..f30f3062842a60579d6e19970d911c3bfca41cab 100644
--- a/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
+++ b/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
@@ -227,6 +227,18 @@ void SourceBuffer::setTimestampOffset(double offset, ExceptionState& exceptionSt
     m_timestampOffset = offset;
 }
 
+AudioTrackList& SourceBuffer::audioTracks()
+{
+    ASSERT(RuntimeEnabledFeatures::audioVideoTracksEnabled());
+    return *m_audioTracks;

[philipj_slow, 2016/02/23 04:35:07]

Has m_audioTracks actually been created, won't this crash? This looks like
HTMLMediaElement, but if it works I don't understand why, since Member<T> can be
null. Right?

[servolk, 2016/02/24 00:11:36]

Yeah, that's right. I need to figure out a good place where to init the
m_audio/videoTracks. IIUC we can't do this directly in the constructor because
at that point the media source might be not yet attached to the HTMLMediaElement
and so m_source->getElement might be null. We'll probably need to notify the SB
when MediaSource gets attached to an HTMLMediaElement and create the track
collections at that point.

[philipj_slow, 2016/02/26 13:36:54]

Until this works and doesn't crash, can you instead ASSERT_NOT_REACHED here? If
it can be reached, I guess remove things until it's unreachable, we ought not
have things that can crash even behind a flag I think.

[philipj_slow, 2016/03/10 13:13:48]

Ping.

[servolk, 2016/03/11 02:00:57]

How strongly do you feel about this? One reason I haven't added an
ASSERT_NOT_REACHED here yet, is that these collections actually do get
created/populated after SourceBuffer::initializationSegmentReceived runs, and
being able to actually access these makes it easier to test (e.g. I can access
these lists in developer console after loading some video, since the
initializationSegmentReceived is guaranteed to run at least once before playback
starts). Plus, you are right, these are currently hidden behind the experimental
feature flag anyway, so they are not easily accessible and shouldn't cause any
accidental crashes.

[servolk, 2016/03/11 02:03:37]

Oh, yes, and also these new collections are also accessed by the newly added
code in the layout test mediasource-avtracks.html. If we add ASSERT_NOT_REACHED
here, the test will crash.

[philipj_slow, 2016/03/24 06:47:48]

OK, so if it's used for testing it surely shouldn't ASSERT_NOT_REACHED, but can
you ensure that never crashes by just creating the objects in the constructor,
as for HTMLMediaElement? That they're only populated later isn't a problem.
Creating the lazily on access here is also an option, of course.

+}
+
+VideoTrackList& SourceBuffer::videoTracks()
+{
+    ASSERT(RuntimeEnabledFeatures::audioVideoTracksEnabled());
+    return *m_videoTracks;
+}
+
 double SourceBuffer::appendWindowStart() const
 {
     return m_appendWindowStart;
@@ -866,6 +878,8 @@ void SourceBuffer::didFail(FileError::ErrorCode errorCode)
 DEFINE_TRACE(SourceBuffer)
 {
     visitor->trace(m_source);
+    visitor->trace(m_audioTracks);
+    visitor->trace(m_videoTracks);
     visitor->trace(m_trackDefaults);
     visitor->trace(m_asyncEventQueue);
     visitor->trace(m_appendBufferAsyncPartRunner);