Log FilterHost events in PipelineImpl to MediaLog.

media/base/media_log_event.h

Index: media/base/media_log_event.h
diff --git a/media/base/media_log_event.h b/media/base/media_log_event.h
index 9d4e15e0a141a1d159d02e602abf27ef4d19350a..a942012d117f13f26e41109fd0e3c7d25c06e270 100644
--- a/media/base/media_log_event.h
+++ b/media/base/media_log_event.h
@@ -40,6 +40,36 @@ struct MediaLogEvent {
     // params: "pipeline_state": <string name of the state>.
     PIPELINE_STATE_CHANGED,
 
+    // An error has occurred in the pipeline.
+    // params: "pipeline_error": <string name of the error>.
+    PIPELINE_ERROR,
+
+    // The size of the video has been determined.
+    // params: "width": <integral width of the video>.
+    //         "height": <integral height of the video>.
+    VIDEO_SIZE_SET,
+
+    // A property of the pipeline has been set by a filter.
+    // These take a single parameter based upon the name of the event and of
+    // the appropriate type. e.g. DURATION_SET: "duration" of type TimeDelta.
+    TIME_SET,

[scherkus (not reviewing), 2011/08/10 23:14:42]

a few these events fire like... A LOT (esp. time)

are you aware of some of the perf impact of some of these changes?

[Scott Franklin, 2011/08/11 21:29:14]

The ones that get set a lot are time, buffered time, current read position, and
buffered bytes. The rest combined all fit nicely on a single screen on the
webpage, so I'm assuming their performance impact is minimal.

I previously filtered those four out in javascript to prevent them from
overflowing the page, and I didn't realize they got called as astoundingly often
as they do.

Fortunately, those were also the least useful of the bunch; current playback
time is interesting, but likely not something that provides much value. The rest
all reveal something interesting about the video encoding or media pipeline (for
instance, loaded appears to only ever be set to true for file:// urls? weird).

[scherkus (not reviewing), 2011/08/11 23:09:00]

I was referring to the performance impact of constantly IPC'ing this information
even though media-internals isn't open

[Scott Franklin, 2011/08/12 01:35:33]

Ah. I did look into it a bit.
A system could exist wherein new MediaLogs notify MediaInternals of their
existence and only IPC data if there's a tab open. New tabs likewise notify
MediaInternals of _their_ existence as usual, at which point MediaInternals can
tell existing and new MediaLogs to send their data.

Two things would need to happen.
1. MediaInternals needs a way to send IPC messages. I'm... not sure how to do
this one.

2. MediaLog needs a way to receive them. Simply adding another message filter to
content/renderer/media will do the trick. MediaLogs can then just blindly send
their messages through the filter, which can, well, filter them out if there's
no one on the other end who wants them.

The question is, is it worth it for the number of messages being sent?
Without the 4 big ones, this set will amount to < 100 messages over the lifetime
of a video, which I'm assuming is a drop in the bucket. BUFFERED_EXTENTS_CHANGED
is much more common (perhaps several per second), but that could be rate-limited
to 1-2Hz or something.
On the other hand, only sending in the presence of a media-internals tab has the
benefit that people can add whatever logging calls they want with little to no
regard for performance.

So basically, I don't know if it's a good idea to do it or not.

+    DURATION_SET,
+    BUFFERED_TIME_SET,
+    TOTAL_BYTES_SET,
+    BUFFERED_BYTES_SET,
+    STREAMING_SET,
+    LOADED_SET,
+    NETWORK_ACTIVITY_SET,
+    CURRENT_READ_POSITION_SET,
+
+    // Playback has ended.
+    // params: none.
+    ENDED,
+
+    // The audio renderer has been disabled.
+    // params: none.
+    AUDIO_RENDERER_DISABLED,
+
     // The extents of the sliding buffer have changed.
     // params: "buffer_start": <first buffered byte>.
     //         "buffer_current": <current offset>.