Can you provide some more specific examples of what you want? I.e. refer to the actual video event names. It's hard to tell what events you're referring to in the above aside from sourceopen.

For video, the number 1 thing we care about is sourceopen.

In general there are two large buckets of latency sensitive areas that we want to monitor:
1. Getting to the point where we can append bytes (sourceopen).
2. Getting to video playback after we have finished appending bytes (playing event? something else?).

For #1, tracking latency for sourceopen would give us a pretty good picture, this is probably the most important.

For #2, I'm less sure of. Maybe its the playing event, or maybe we need the whole series of fine-grained events like updateend.
After we append data, we'd like to track any event that blocks playback from starting. According to wolenetz@, after buffer append, there are a few more post-backs that occur which block us from getting to video being painted. We would be interested in any latency information during this period.
We currently track time of data append and time of video playback (a). It seems like this period of time between data append and playback is latency sensitive, we are able to measure in broad strokes what the delta between these two events is. What we can't do, is attribute this latency to chrome doing work vs. us doing work. Partially because there is no event that allows us to say the video has started playing from the users perspective. So... I'm less sure of what events we need further instrumentation on.


(a) We currently detect video render based on timeupdate events or polling and then checking when the media time is > 0.


tl;dr We need sourceopen, and we probably need something else, I'm less sure what that something else is but it has to do with blocking playback after buffer append.

Still not quite explicit enough :) To be more explicit:

1. The stat you want is the time between addSourceBuffer() and sourceopen() that is due to "media" work and not other work happening on the main render thread?

2. It seems like you're looking for the time between appendBuffer() and currentTime > 0.

In both cases I'm not sure we could add in-the-wild type stats for these. These types of things are generally better suited to chrome://tracing. 

1. I think having the time between event being queued and the event actually being dispatched would give a lot of insight into where the time went.

E.g. Chrome is done with attaching the source, sourceopen fires... which is handled 100ms later because the render thread was busy. Knowing that there was a 100ms delay in the hand off is valuable. From that, we should be able to determine how much time was spent in chrome land.

We use similar information from resource timing to determine how much time was spent waiting on network + chrome and how much was waiting on the render thread. E.g. we take the time between responseEnd and when we receive the data on the main thread.

Although it'd be nice to have how much is due to 'media' work, knowing how long it took to dispatch the event would tell us a lot. This seems to be complicated by the 2 post-backs to the main thread before sourceopen though. Which would indicate that there are additional areas where render thread work could delay the sourceopen event.

Would it possible to return data on 'time spent waiting for render thread to respond' ? 

2. For this, I'm also looking for some type of event delay similar to #1. There's got to be a few signals.

Whoops, just realized I'm confusing sourceopen with updateend. You're actually looking for the time between video.src = MSE and the sourceopen event. Sorry for the confusion.

1. IIRC, this event sequence looks like:
JS sets src= -> <create WebMediaPlayer> -> <create Demuxer/Pipeline> -> control returns to main thread.
<Pipeline initializes demuxer on media thread> -> posts task to render thread indicating readiness.
...
<some time later on main thread sourceopen is queued>.

If we timestamp the sourceopen queue time that should be fine, but I think you're also probably interested in the time it takes to actually get to the point of queuing. 

2. currentTime() pierces across threads, so the millisecond it's > 0 playback has tarted. So your current recording is accurate modulo whatever may be blocking your code from running. If you query this from a requestAnimationFrame() it should be fairly accurate. An event would be nice of course though. Perhaps we could timestamp the playing event in some way.

What's the next step here? Dale, can you own this?

=>wolenetz since this is related to MSE. For (1) It sounds like we just need to timestamp the sourceopen event.

For (2) there's no spec'd event for that, so we'd need a new specification; the best you can do currently is requestAnimationFrame() until currentTime > 0. +foolip in case there's a spec bug already for this somewhere.

I'm not aware of any spec bug for this. As long as a value on the same timeline as performance.now() is needed, making event.timeStamp accurate shouldn't require any spec changes.

Unfortunately such a change wouldn't be possible to feature detect, whether that's a problem depends on the intended usage I suppose.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ping - this continues to be reasonably high priority for Youtube.
wolenetz@, are you a reasonable owner here?