Cálculo de Pérdida de Paquetes en Gstreamer y WebRTC.
Estaba mirando algunas llamadas que se llevan a cabo entre un Android WebRTC stack y un Gstreamer WebRTCBin stack. Me di cuenta de que las métricas de pérdida de paquetes parecen estar distorsionadas en ambos lados.
En el lado de Gstreamer, la pérdida de paquetes suele ser muy negativa:
[ -154, -697, -1234, -1764, -2288, -2823, -3350, -3869, -4409, -4988, -5533,
-6065, -6592, -7123, -7672, -8237, -8831, -9383, -9949, -10527, -11036,
-11581, -12136, -12721 ]
De la documentación:
https://gstreamer.freedesktop.org/documentation/rtpmanager/RTPSource.html?gi-language=c#RTPSource:stats
Para los campos que indican pérdida de paquetes, tenga en cuenta que los paquetes tardíos no se consideran perdidos y las duplicaciones no se tienen en cuenta. Por lo tanto, la pérdida puede ser negativa si hay duplicados.
Todo parece bien, excepto que no estoy seguro de cómo interpretar la pérdida de paquetes aquí. Parece que el Android WebRTC stack correspondiente tampoco sabe cómo hacerlo, ya que los valores que aparecen de vez en cuando se parecen a:
“packetsLost”: 16777215
Esto me hace pensar que las stacks tienen dificultades para calcular la pérdida de paquetes entre sí. Parece (según mi conocimiento) afectar todas las llamadas entre el WebRTC de Android y la implementación de WebRTC de Gstreamer.
¿Es este un problema común? ¿Cómo debo interpretar estos datos:/?
davy.ai
Según la documentación de Gstreamer WebRTCStack, pueden ocurrir valores de pérdida de paquetes negativos si hay paquetes duplicados. Los paquetes tardíos no se consideran perdidos y los duplicados no se tienen en cuenta al calcular la pérdida de paquetes. Sin embargo, el problema aquí es que el correspondiente Android WebRTC stack no puede interpretar estos valores correctamente y está mostrando valores extraños como “packetsLost”: 16777215. Esto sugiere que puede haber algunos problemas de compatibilidad entre los dos stacks en cuanto a los cálculos de pérdida de paquetes.
No está claro si este es un problema común o no. Sin embargo, se recomienda investigar más a fondo el problema examinando las implementaciones específicas de los dos stacks y su compatibilidad entre sí. Una forma de interpretar estos datos podría ser considerar la posibilidad de duplicados y tratar de eliminarlos, si es posible. Además, otras métricas relacionadas con la pérdida de paquetes, como el tiempo de ida y vuelta y las congelaciones de video, también deben tenerse en cuenta para obtener una mejor imagen del rendimiento general de los dos stacks.