Fce 817 rtp metrics #23
Conversation
roznawsk
force-pushed
the
FCE-817-rtp-metrics
branch
from
f73c335 to
da61af6
Compare
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## master #23 +/- ##
==========================================
- Coverage 57.26% 57.14% -0.13%
==========================================
Files 57 60 +3
Lines 2607 2672 +65
==========================================
+ Hits 1493 1527 +34
- Misses 1114 1145 +31
... and 3 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
roznawsk
force-pushed
the
FCE-817-rtp-metrics
branch
3 times, most recently
from
aaa2ebb to
04f2a04
Compare
| TestVideoroomWeb.Endpoint, | ||
| {Membrane.TelemetryMetrics.Reporter, | ||
| [ | ||
| metrics: Membrane.RTC.Engine.Endpoint.ExWebRTC.Metrics.metrics(), | ||
| name: ExWebrtcMetricsReporter | ||
| ]}, | ||
| TestVideoroom.MetricsScraper |
There was a problem hiding this comment.
What is the advantage of using Membrane.TelemetryMetrics instead of regular telemetry in case of ex_webrtc_endpoint ?
There was a problem hiding this comment.
The advantage of using Membrane.TelemetryMetrics over regular Telemetry.Metrics, especially in the context of ex_webrtc_endpoint, stems from the specific adaptations in Membrane.TelemetryMetrics that are tailored for multimedia applications. Felix mentioned that regular Telemetry.Metrics might not be sufficiently suited for multimedia use cases. Furthermore, Membrane.TelemetryMetrics includes certain optimizations or "hacks" that you would need to manually implement if you were using Telemetry.Metrics, enhancing efficiency and effectiveness for multimedia-specific metrics collection and monitoring in the Membrane framework.
| defp handle_entry(%{type: :inbound_rtp} = entry, telemetry_label) do | ||
| telemetry_label = telemetry_label ++ [track_id: entry.track_identifier] | ||
|
|
||
| TelemetryMetrics.execute( | ||
| @inbound_rtp_event, | ||
| Map.take(entry, [ | ||
| :packets_received, | ||
| :bytes_received, | ||
| :nack_count, | ||
| :pli_count, | ||
| :markers_received, | ||
| :codec | ||
| ]), | ||
| %{}, | ||
| telemetry_label | ||
| ) | ||
| end | ||
|
|
||
| defp handle_entry(%{type: :outbound_rtp} = entry, telemetry_label) do | ||
| telemetry_label = telemetry_label ++ [track_id: entry.track_identifier] | ||
|
|
||
| TelemetryMetrics.execute( | ||
| @outbound_rtp_event, | ||
| Map.take(entry, [ | ||
| :packets_sent, | ||
| :bytes_sent, | ||
| :nack_count, | ||
| :pli_count, | ||
| :markers_sent, | ||
| :codec, | ||
| :retransmitted_packets_sent, | ||
| :retransmitted_bytes_sent | ||
| ]), | ||
| %{}, | ||
| telemetry_label | ||
| ) | ||
| end |
There was a problem hiding this comment.
How does it work in the case of simulcast?
There was a problem hiding this comment.
We track each variant separately (the track_identifier has a variant in its name)
| default: [], | ||
| description: "Label passed to Membrane.TelemetryMetrics functions" | ||
| ], | ||
| get_stats_interval: [ |
There was a problem hiding this comment.
What about config.exs instead of endpoint option
roznawsk
force-pushed
the
FCE-817-rtp-metrics
branch
from
db725ec to
df46999
Compare
roznawsk
force-pushed
the
FCE-817-rtp-metrics
branch
from
df46999 to
ef99d6e
Compare
No description provided.