H264 video packet drops in the source device (laptop) where the firefox runs

RESOLVED WORKSFORME

Status

()

Core
WebRTC: Networking
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: nkmurali23@gmail.com, Unassigned)

Tracking

35 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36

Steps to reproduce:

I was connecting two WebRTC clients (Client A and Client B) through my server (my private Janus GW Plugin). I have one Audio/Video full duplex RTP session setup between the WebRTC Client and my Janus GW plugin, and three one way (from my Janus GW plugin to WebRTC Clients) audio RTP sessions.


Actual results:

Audio seems to work ok, but have an  issue with video where I see very few seconds of video clip and then frozen - it may or may not recover from this state. Even if it recovers, it works very few seconds again and goes back to frozen state.

ollowing is the topology, where Firefox (version 35.0.1) WebRTC client A and B  
are connected back-to-back through my private Janus plugin:

WebRTC Client A  <====> (My Janus GW Plugin)   <====>  WebRTC Client B


I am hitting an issue where there are packets are dropped in both WebRTC clients 
itself (when I ran the Wireshark in the laptop where the WebRTC clients run, I can 
see the packet drops from the Wireshark trace - meaning that the missing packets 
didn't leave my laptop). Remember that the packets are not dropped in the network, rather that the packets are dropped before hitting the wire in my laptop 
itself where the FF browser is running - this happens in  both of my laptop.

Observations from the logs and traces:

1. Basically, when H264 video packets are missing from Client A and when Client B 
    requests for those missing packets, my Janus GW plugin doesn't have those 
   packets for retransmission. Same thing from Client B to A.

2. Noticed the packet loss from the wireshark trace provided for both Client A 
   and Client B:

   For Client A: Src Addr: 192.168.1.79:55516, Dst Addr: 192.241.224.149:51817

   For example, watch out for the missing sequence numbers from the given 
   sequence numbers range below:

   5233 to 5239, 5703 to 5708, 6140 to 6145, 6835 to 6840, many packets from 
   6738 to 6900


   For Client B: Src Addr: 192.168.1.88:65091, Dst Addr: 192.241.224.149:5434

   For example, watch out for the missing sequence numbers from the given 
   sequence numbers range below:

   2394 to 2404, 3255 to 3259, 3380 to 3384, 3589 to 3597, 3606 to 3614, 3754 to 
   3764, 3834 to 3842


2. Noticed the Frame drop in the Firefox "about_webrtc" log - for example, check 
    out the RTP statistics for the first RTP session for both the Clients.

   Note: You may notice 3 additional one way audio RTP sessions for which there is 
           no issues.



Expected results:

The back to back video (to/from Client-A/Client-B) should be working fine.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Can you upload the traces/logs?  They likely will need to be compressed.  If that's a problem, you could provide them to me directly.

"frame drops" in stats is fairly meaningless here.

Packet loss *before* transmission would be very unusual.

Updated

3 years ago
Flags: needinfo?(kmurali)
(Reporter)

Comment 2

3 years ago
Created attachment 8560900 [details]
zip file of all the logs/traces.
Flags: needinfo?(kmurali)
(Reporter)

Comment 3

3 years ago
Created attachment 8560901 [details]
Client_B_Logs.zip

I  have uploaded the logs/trace into two zip files - one from the Client A and the other from the Client B.
Is this still an issue in Dev Edition (Fx40) or Nightly (Fx41)?
Flags: needinfo?(kmurali)
(Reporter)

Comment 5

3 years ago
The issue is no more reproducible. We can close this ticket.
Flags: needinfo?(kmurali)
Thanks for retesting
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.