Is there a way to disable video retransmission?
Selena Liu
Hi all,
I’m working on a project based on BBB. We use Netem at BBB server to emulate different levels of network degradation, and conduct subjective tests by having two people making audio-visual calls using the lab deployment. But we are now facing a major issue concerning the actual possibility of simulating video packet loss on real-time audio-visual calls. We hope that you can help to provide some suggestions on how to solve this issue. Thanks.
- Packet loss is emulated at server side using Netem. By analyzing the captured network traces, we can see that the actual audio packet loss rate is roughly the same as the value set by Netem. But actual video packet loss rate is almost zero.
- There are no duplicate audio RTP packet, and sequence number follows an ascending order. But for video stream, there are duplicate packets (some packets are retransmitted), and packets are out-of-order.
- We tested different packet loss at the ‘downlink’ side of clients (from 5% to 25%). In all cases, the video lost packets were retransmitted, and the actual video stream shows roughly no packet loss at the client side. The video quality was not affected.
In this situation, we won’t be able to simulate video degradation caused by packet loss. Video RTP packets are retransmitted, and video quality is not affected. Possible solution is to disable quality feedback or disable packet retransmission. But currently we’re not clear how to disable them. These mechanisms may be embedded in the core of the applications and cannot be turned on/off via configuration files. Can you provide some suggestions or help regarding this issue? Any comment will be welcomed. If you need any further information, please let us know. Thanks.
Best Regards。
Fred Dixon
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/af10edbb-f9a8-4c18-ae10-b78b91984f2fn%40googlegroups.com.
Selena Liu
You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-dev/rzlq9O7yxZg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/CAOeuy5Mg1OBpAuy%2BxgoGUJt21UawLLV7kAcxTy0fUQK%2Bev6KdQ%40mail.gmail.com.
Pablo Pico
My tests were focused on audio.
The Opus codec, which is used in BigBlueButton and most modern webrtc applications, has a very limited resistance to packet loss because of the way the codec was designed.
A user may have lots of bandwidth to spare, and yet the codec will not send repeated packets to compensate for packet loss. On the other hand, the video coded does that.
I remember i found a research of something called Red which basically is seding the streaming more than once, reducing the packet loss effect. One of these days i will take a look to see if there is a way to do this with freeswitch.
First i must mention that i am not sure this settings exist on that version 2.3 (i am using 2.5.4)
At least in v 2.4+ you could try to alter the codec params in
Pablo - BBBPlugin
Selena Liu
codec_video_main: H264
codec_video_main_priority: H264
codec_video_content: H264
codec_video_content_priority: H264
codec_audio: ANY
codec_audio_priority: OPUS
H264:
profile_level_id: "42e01f"
packetization_mode: "1"
level_asymmetry_allowed: "1"
tias_main: "300000"
as_main: "300"
tias_content: "1500000"
as_content: "1500"
max_mbps_main: "0"
max_fs_main: "0"
max_br_main: "0"
max_mbps_content: "0"
max_fs_content: "12288"
max_br_content: "0"
VP8:
tias_main: "300000"
as_main: "300"
tias_content: "1500000"
as_content: "1500"
OPUS:
useinbandfec: "1"
maxaveragebitrate: "30000"
maxplaybackrate: "48000"
ptime: "20"
minptime: "10"
maxptime: "40"
kurentoRembParams:
rembOnConnect: 300
upLosses: 12
decrementFactor: 0.5
thresholdFactor: 0.8
# Munges/removes the SDP REMB rtcp-fb support attribute (ie tries to disable REMB)
kurentoRemoveRembRtcpFb: false
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/089b7a7c-8ec7-423b-826b-cd2754ffbeb2n%40googlegroups.com.
Marcel Hellkamp
I'm using BigBlueButton Server 2.3.15. Thanks. Is there other information needed?
This is a very old (and unsupported) release that works different
than the current release in many ways. You should probably upgrade
first.
> I’m working on a project based on BBB. We use Netem at BBB server to emulate different levels of network degradation, and conduct subjective tests by having two people making audio-visual calls using the lab deployment. But we are now facing a major issue concerning the actual possibility of simulating video packet loss on real-time audio-visual calls.
I'm confused. You ARE simulating package loss, but the protocol can compensate for that. Up to a certain amount of package loss there is no visible change in video quality. This is your result. If you disable built-in compensation and error correction techniques you are no longer testing a real-world scenario.
Selena Liu
I checked the update from 2.3 to 2.4, there was no updated function related to audio-visual calls itself. But you’re right, 2.3 is already a very old version, now 2.6 is available. I should check what’s new from 2.3 to 2.6. Thanks.
Regarding the second point, our aim is not to test robustness of videotelephony platform regarding packet loss. The project is to simulate different levels of network degradation, and conduct subjective tests to build a subjective test dataset. The dataset will contain many subjects’ opinion scores under different network conditions, and it will be used to build a videotelephony quality assessment model. So we need to have different video packet loss rates at the client’s receiving side, and obtain the corresponding MOS values. BBB may have very good mechanisms to protect video quality (maybe through retransmission. And the video packet loss rate of client’s downlink is zero), but other videotelephony platforms may not have such good performance (video packet loss rate of client’s downlink could be 5% or 10%). These tests of our project uses BBB as videotelephony tool, but the project itself to not limited to BBB.
Best Regards.
Selena
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/67008610-3868-bd5b-c5ff-768f05ee1f07%40gsites.de.
Marcel Hellkamp
I checked the update from 2.3 to 2.4, there was no updated function related to audio-visual calls itself. But you’re right, 2.3 is already a very old version, now 2.6 is available. I should check what’s new from 2.3 to 2.6. Thanks.
2.6 is not released yet, but BBB switched from kurento to
mediasoup in 2.5, that's a pretty significant change.
Regarding the second point, our aim is not to test robustness of videotelephony platform regarding packet loss. The project is to simulate different levels of network degradation, and conduct subjective tests to build a subjective test dataset. The dataset will contain many subjects’ opinion scores under different network conditions, and it will be used to build a videotelephony quality assessment model. So we need to have different video packet loss rates at the client’s receiving side, and obtain the corresponding MOS values. BBB may have very good mechanisms to protect video quality (maybe through retransmission. And the video packet loss rate of client’s downlink is zero), but other videotelephony platforms may not have such good performance (video packet loss rate of client’s downlink could be 5% or 10%). These tests of our project uses BBB as videotelephony tool, but the project itself to not limited to BBB.
This is the point I do not understand. BBB does not do anything
special, packet loss compensation is a built-in feature of the
used protocols and implemented by browsers. BBB just enables (or
does not disable) these features. So, if you want to "test
robustness of videotelephony platform regarding packet loss" but
disable standard packet loss compensation techniques, you distort
your own test results. You are testing a degraded version of the
protocol, not the actual protocol used by actual videotelephony
software.
It's a bit more complicated than just loss-rate anyway: For audio, a single lost packet now and then means a short 20ms interruption. Not great, but you can still communicate. Bursts of lost packets (which are quite common for mobile devices) are way more annoying. For video, a single lost packet during an i-frame can result in several seconds of unusable video because other p- or b-frames need the i-frame to render. This is why video streams usually have a way to request specific frames (or packets?) from the sender or increase error correction coverage on these frame types.
For a proper test, you would have to consider at least three aspects: Different percentages of lost packets, different durations for each error-event, and if the error happens between sender and server, or server and client. This is also important, because media servers may use different compensation techniques or settings for incoming or outgoing streams.
Gunnar Heikkilä
This is the point I do not understand. BBB does not do anything special, packet loss compensation is a built-in feature of the used protocols and implemented by browsers. BBB just enables (or does not disable) these features. So, if you want to "test robustness of videotelephony platform regarding packet loss" but disable standard packet loss compensation techniques, you distort your own test results. You are testing a degraded version of the protocol, not the actual protocol used by actual videotelephony software.
Think about it as a project of building a voltmeter for use in cars. We all know that the voltage in a normally functioning car only varies between ~11.5V to ~14.4V. But building and calibrating a voltmeter which only can measure between these limits is not enough, as in rare circumstances the voltage can go outside these bounds (especially lower than 11.5V, if the battery becomes depleted). Thus, to build and calibrate this voltmeter, the car must be manipulated (generator, voltage regulator, battery, whatever) to also produce voltages much lower (and maybe higher) than the normal range.
Well, actually you don't need the actual car just to build a voltmeter, but you get the analogy. Research around video quality very often need to cover the total range of qualities, from the worst possible experience (meaning extensive packet losses affecting the final video), up to the best possible experience. It's not enough to only test for the "normal case" (which would mean basically no visible errors ever).
It's a bit more complicated than just loss-rate anyway: For audio, a single lost packet now and then means a short 20ms interruption. Not great, but you can still communicate. Bursts of lost packets (which are quite common for mobile devices) are way more annoying. For video, a single lost packet during an i-frame can result in several seconds of unusable video because other p- or b-frames need the i-frame to render. This is why video streams usually have a way to request specific frames (or packets?) from the sender or increase error correction coverage on these frame types.
For a proper test, you would have to consider at least three aspects: Different percentages of lost packets, different durations for each error-event, and if the error happens between sender and server, or server and client. This is also important, because media servers may use different compensation techniques or settings for incoming or outgoing streams.