Generate and assign media track ids in demuxers.

media/base/media_track.h

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef MEDIA_BASE_MEDIA_TRACK_H_
 #define MEDIA_BASE_MEDIA_TRACK_H_
 
 #include <string>
 
 #include "media/base/media_export.h"
 #include "media/base/stream_parser.h"
 
 namespace media {
 
 class MEDIA_EXPORT MediaTrack {
  public:
   enum Type { Text, Audio, Video };
+  using Id = std::string;
   MediaTrack(Type type,
              StreamParser::TrackId bytestream_track_id,
              const std::string& kind,
              const std::string& label,
              const std::string& lang);
   ~MediaTrack();
 
   Type type() const { return type_; }
 
   StreamParser::TrackId bytestream_track_id() const {
     return bytestream_track_id_;
   }
   const std::string& kind() const { return kind_; }
   const std::string& label() const { return label_; }
   const std::string& language() const { return language_; }
 
+  Id id() const { return id_; }
+  void set_id(Id id) {
+    DCHECK(id_.empty());
+    DCHECK(!id.empty());
+    id_ = id;
+  }

[xhwang, 2016/06/10 17:06:53]

I wonder whether we can generate this ID when we create MediaTrack, instead of
getting it somewhere else (e.g. from ChunkDemuxer) and set it later.

Does it matter where and how we generate this |id|. Is uniqueness (within one
MediaSource or media element) the only requirement? If so, can we have a static
global incrementing counter here so that every MediaTrack in this process will
get a unique ID? For example, you can move GenerateMediaTrackId() to this file.

But that means for FFmpegDemuxer, the ID will be different from the
bytestreadm_track_id. If we still want to maintain this, we can add a |id|
parameter in the constructor, so that FFmpegDemuxer can just use
bytestreadm_track_id, and ChunkDemuxer parsers can use a global counter defined
somewhere.

Actually do we care whether bytestreadm_track_id is the same as |id| for
FFmpegDemuxer? won't it be nicer that the TrackId is in a consistent format,
e.g. starting from 1, no matter what demuxer we are using?

[servolk, 2016/06/10 22:05:25]

I don't think we can simplify this much further. In MSE case media track are
created in stream parsers. But stream parsers don't keep track of whether a
demuxer stream already exists for a given media track or if it's going to be
created later. So media track ids must be generated (or reused) where we
establish the associations between media tracks and demuxer streams, i.e. in
MediaSourceState::OnNewConfigs. That's the only place where we make a decision
if we need to create a new demuxer stream or reuse an existing one.

I have chosen to use bytestream track ids as unique track ids in the
FFmpegDemuxer case since it was just the easiest thing to do (in FFmpeg we know
that bytestream track ids are guaranteed to be unique, so we don't need to
introduce some other track id generation logic). I guess we could use the same
logic for generating track ids in FFmpeg as we do in ChunkDemuxer, but I'm not
sure if that's the right thing to do. W3C spec says this about HTMLMediaElement
track ids:
According to Matt MSE doesn't support MEDIAFRAG uri by design, but I wasn't sure
about FFmpegDemuxer and so I've decided to leave things unchanged by using
bytestream track ids for FFmpeg case to avoid accidentally breaking something
that I don't fully understand :)

+
  private:
   Type type_;
+
+  // |bytestream_track_id_| is read from the bytestream and is guaranteed to be
+  // unique only within the scope of single bytestream. But we might have
+  // multiple bytestreams (MediaSource might have multiple SourceBuffers
+  // attached to it, which translates into ChunkDemuxer having multiple
+  // MediaSourceStates and multiple bytestreams). Thus bytestream track ids
+  // are not guaranteed to be unique at the Demuxer and HTMLMediaElement level.
+  // So we generate truly unique media track |id_| on the Demuxer level.

[xhwang, 2016/06/10 17:06:54]

I <3 this comment. Thanks!

[servolk, 2016/06/10 22:05:25]

Acknowledged.

   StreamParser::TrackId bytestream_track_id_;

[xhwang, 2016/06/10 17:06:53]

nit: I wonder whether StreamParser::TrackId should be
StreamParser::BytestreamTrackId, or just StreamParser::BytestreamId, since it's
not used for Blink TrackId directly. But I might be missing the big picture.

[servolk, 2016/06/10 22:05:25]

Yes, I think we could rename StreamParser::TrackId into
StreamParser::BytestreamTrackId or something like this. Matt/Chris, WDYT? If
everyone agrees then I'll do that in a separate follow up CL.

+  Id id_;
+
+  // These properties are read from input streams by stream parsers as specified
+  // in https://dev.w3.org/html5/html-sourcing-inband-tracks/.
   std::string kind_;
   std::string label_;
   std::string language_;
 };
 
 }  // namespace media
 
 #endif  // MEDIA_BASE_MEDIA_TRACK_H_