Implement a way to measure realtime (webrtc et al) video performance
Categories
(Core :: WebRTC: Audio/Video, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox109 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
Details
Attachments
(24 files, 2 obsolete files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
To find what video performance bottlenecks to prioritize we need a way to measure them.
I intend to add profiler markers to gecko for all known video copies and conversions. Getting into capture/decode/encode steps would be handy too.
Then in an extension to the profiler frontend I intend to write something to group and analyze the markers.
This bug is for adding a first round of markers.
| Assignee | ||
Comment 1•3 years ago
|
||
| Assignee | ||
Comment 2•3 years ago
|
||
| Assignee | ||
Comment 3•3 years ago
|
||
| Assignee | ||
Comment 4•3 years ago
|
||
This will allow time consuming tasks (copies, capture, etc.) along the pipe to
be grouped per-track-source when visualizing profiler markers.
| Assignee | ||
Comment 5•3 years ago
|
||
| Assignee | ||
Comment 6•3 years ago
|
||
| Assignee | ||
Comment 7•3 years ago
|
||
For use cases where PerformanceRecorderMulti has Start() called on one thread,
and Record() on another, typically a callback thread from an underlying decoder.
| Assignee | ||
Comment 8•3 years ago
|
||
| Assignee | ||
Comment 9•3 years ago
|
||
| Assignee | ||
Comment 10•3 years ago
|
||
| Assignee | ||
Comment 11•3 years ago
|
||
| Assignee | ||
Comment 12•3 years ago
|
||
| Assignee | ||
Comment 13•3 years ago
|
||
| Assignee | ||
Comment 14•3 years ago
|
||
| Assignee | ||
Comment 15•3 years ago
|
||
| Assignee | ||
Comment 16•3 years ago
|
||
| Assignee | ||
Comment 17•3 years ago
|
||
| Assignee | ||
Comment 18•3 years ago
|
||
| Assignee | ||
Comment 19•3 years ago
|
||
| Assignee | ||
Comment 20•3 years ago
|
||
| Assignee | ||
Comment 21•3 years ago
|
||
| Assignee | ||
Comment 22•3 years ago
|
||
| Assignee | ||
Comment 23•3 years ago
|
||
| Assignee | ||
Comment 24•3 years ago
|
||
This patch uses thread-local storage through nspr to register a destructor
that will unregister the current thread from CallbackThreadRegistry, and
by extension, from the profiler and nsThreadManager too.
~CallbackThreadRegistry will block as part of shutdown to wait for threads
to exit, should there be any tracked ones registered.
| Assignee | ||
Comment 25•3 years ago
|
||
In XPCOMShutdownFinal, nsThreadManager has shut down any non-main nsThreads,
so functions such as GetCurrentThread or IsNSThread cannot be relied on.
XPCOMShutdownThreads is a safe time for CallbackThreadRegistry to be
destroyed since any tracked threads are external, and we should get
release any references to such resources in an earlier phase.
Updated•3 years ago
|
| Assignee | ||
Comment 26•3 years ago
|
||
Callback threads that need to be registered with CallbackThreadRegistry are by
definition externally managed; otherwise they wouldn't need to be registered in
the first place.
We may not have any control of the lifetime of the externally managed thread,
which, when registered with the profiler has an nsThread wrapper created
around it. If the thread outlives all xpcom shutdown stages, the nsThread
wrapper instance will leak (it implements nsIThread and nsISupports!). If
refcnt logging is enabled when it leaks, this particular instance will be
flagged as a leak, and could mark a run on try as failed.
To work around this potential leak, this patch makes CallbackThreadRegistry
registration and unregistration noops when refcnt logging is enabled.
I will also note, that the lifetime issues found with externally managed
threads were most notable on Mac with Grand Central Dispatch's Dispatch Queues.
Over time a large number of real threads could be seen, and the risk of one of
them outliving xpcom shutdown was close to 100% for a common use case involving
camera capture (though timing dependent).
Updated•3 years ago
|
Comment 27•3 years ago
|
||
Comment 28•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3386fd76208c
https://hg.mozilla.org/mozilla-central/rev/fb8bcc54d864
https://hg.mozilla.org/mozilla-central/rev/2477d101c651
https://hg.mozilla.org/mozilla-central/rev/e5a0e684e6a9
https://hg.mozilla.org/mozilla-central/rev/132d57446788
https://hg.mozilla.org/mozilla-central/rev/a968b1ab1a0c
https://hg.mozilla.org/mozilla-central/rev/b70e54dd3ec7
https://hg.mozilla.org/mozilla-central/rev/1219fc624920
https://hg.mozilla.org/mozilla-central/rev/353c027b2929
https://hg.mozilla.org/mozilla-central/rev/2304ce742aea
https://hg.mozilla.org/mozilla-central/rev/d89846418f30
https://hg.mozilla.org/mozilla-central/rev/db2aa9c89371
https://hg.mozilla.org/mozilla-central/rev/7a522a083f8e
https://hg.mozilla.org/mozilla-central/rev/089c68e8f61f
https://hg.mozilla.org/mozilla-central/rev/c207e5d2bf3c
https://hg.mozilla.org/mozilla-central/rev/2fa6734258d2
https://hg.mozilla.org/mozilla-central/rev/d0e0b7bf4303
https://hg.mozilla.org/mozilla-central/rev/ab47ea1bc28a
https://hg.mozilla.org/mozilla-central/rev/461b7234402c
https://hg.mozilla.org/mozilla-central/rev/08691c305d21
https://hg.mozilla.org/mozilla-central/rev/a09f857b4881
https://hg.mozilla.org/mozilla-central/rev/63105f58a332
https://hg.mozilla.org/mozilla-central/rev/76e9498e7e20
https://hg.mozilla.org/mozilla-central/rev/edde6d7420b7
Description
•