[Bug 797280] webrtcbin: video pixelated

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797280

--- Comment #15 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
So, my notes. We can see that chrome raises the bitrate, and resolution, till
it reaches 720p 1.2MB. The where you start having packet lost. Then it reduces
the frame rate aggressively before reducing the encoding rate to about 1Mb,
after that you have stopped everything.

There is warning about not getting RTCP RR in time, would need investigation. I
don't see any trace that would indicate that retransmission is enabled. Does
that demo advertise this ? If you aren't using some sort of FEC or
transmission, the rate adaptation will always lead to visual corruption. There
is not trace that would indicate a keyframe request, if this is broken,
obviously this is a problem. I'm not sure how to interpre the hitogram traces.

Histogram: WebRTC.Video.KeyFramesSentInPermille recorded 1 samples, mean = 12,0
(flags = 0x41)

Does this mean it has sent 12 keyframes ? Maybe keyframe at the edge rate just
never make it.

Btw, on slow computer, you have packet lost whenever the CPU is too busy to
dequeue the packet from the UDP socket, it's not always related to the network
capacity. I don't think that chrome algo is really designed to cope with that.
Though, you can increase the queue size (see buffer-size on udpsrc), and then
sysctl net.core.rmem_max=value to ask the kernel to allow more then the small
default. You could also just try and add a queue after udpsrc, not sure how
that work with webrtcbin (if it's not already the case). There is already a
queue of course, it's the rtpjitterbuffer, but it does not perform very well
iirc on loaded systems.

(Haven't looked at the gst logs yet)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.