Update BufferedDataSource class documentation.

media/blink/buffered_data_source.h

Index: media/blink/buffered_data_source.h
diff --git a/media/blink/buffered_data_source.h b/media/blink/buffered_data_source.h
index fc462b84ef69cf070bb77fbe07c5e7648fcb585d..dea8275ac3a7ffa7ffcc038b5edfb665b17307e0 100644
--- a/media/blink/buffered_data_source.h
+++ b/media/blink/buffered_data_source.h
@@ -42,8 +42,9 @@ class MEDIA_EXPORT BufferedDataSourceHost {
 // A data source capable of loading URLs and buffering the data using an
 // in-memory sliding window.
 //
-// BufferedDataSource must be created and initialized on the render thread
-// before being passed to other threads. It may be deleted on any thread.
+// BufferedDataSource is accessed from multiple threads, and it exposes WeakPtrs
+// for posting methods to be run on the main thread. It must therefore also be
+// deleted on the main thread.

[Wez, 2014/11/19 21:38:55]

It doesn't look like it actually exposes WeakPtrs; they seem to be an internal
implementation detail, in which case I'd suggest simply stating that this class
is designed to be created and destroyed from the render thread, although it may
be accessed by other threads while alive.

How are you making sure that the accesses from other threads are synchronized
with this object's teardown, though?

e.g. how do you know that SetBitrate or Stop won't be called on one thread while
this object is being torn down, or after it has been torn down, on the render
thread?

[no sievers, 2014/11/19 21:42:48]

Done.

 class MEDIA_EXPORT BufferedDataSource : public DataSource {
  public:
   // Used to specify video preload states. They are "hints" to the browser about