[Bug 797280] webrtcbin: video pixelated

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from Dmitriy <degtyaryov at gmail.com> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #15)
> 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. 
Webrtcbin does not create in sdp fec, ulpfec, red in offer/answer.
How to use fec with webrtcbin?

> 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.
Even if you adjust the parameters of the kernel, even though it will bear
fruit, but this is not a solution. Packet loss is inevitable. Also, the
gstreamer can be run on a machine on which there is no possibility to change
the parameters of the kernel.

If a lot of independent video streams are launched on one machine and the
machine for some reason or other slows down, the image will broken in all
streams at once. And it will not depend on the characteristics of the
processor. No matter how powerful it may be, the problem will be!

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