Subject: [AVT] draft-feher-avt-approx-auth-srtp

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 18:14:12 -0600

I wonder about the the whole premise of this draft. First of all I'm skeptical about the bit rate error arguments but lets just assume for a second that the application could and did want to get damaged packets and there were radio networks that damaged a bunch but not too much of the packet. 

Let's say we were using 20 ms G.711 packets where 5% of the packets (with random distribution) had a single bit error in the payload section. If you just dropped these packets, the PLC would make it so you barely noticed they were missing in the end audio quality. Now consider if you played them - many of them would have a high order bit set at a time when the surrounding samples did not and it make a huge pop when you played them back. It suspect it would sound atrocious. With condecs that actually compress like AAC, the impact of messing up random bits seems like it would even be worse - keep in mind, it's not like you know which bit got corrupted. 

So my questions is, where would we imagine using this, what sort of network, codecs, and bit rate errors? And then we can figure out if could make things sound better but I'm having a hard time imaging a scenario where it will improve things.

---

From: Feher Gabor <[email-masked]>
Date: Sun, 07 Nov 2010 04:28:53 +0100

Hi!

> Let's say we were using 20 ms G.711 packets where 5% of the packets (with random distribution) had a single bit error in the payload section. If you just dropped these packets, the PLC would make i…
I think the key line is the last one. If we are using compression then a 
video or audio decoder will know better what to do with a bit error than 
it is known by the layers below. That is the main idea, to allow the 
decoder to judge on bit errors and do not filter them on the lower 
layers. Today we have intelligent decoders, using resync markers, data 
partition and RVLC. Thanks to this a big portion of the erroneous packet 
can be saved.

> So my questions is, where would we imagine using this, what sort of network, codecs, and bit rate errors? And then we can figure out if could make things sound better but I'm having a hard time ima…
The best scenario is real-time video streams. Real-time because at that 
case we have delay constraints and video because there are lots of data 
there, so the MAC will cause less bw increase (8 byte vs 1000 bytes). It 
will work with audio as well, but the efficiency on bw is lower aand you 
might consider alternative solutions. We already have measurements in 
this scenarios proving that the video quality is better with the damaged 
packets, in the case, if it is only a small damage. I read other 
measurements proving that error resilient decoders work better on 
damaged data than dropping the packets. It is possible to filter packets 
based on the amount of the damage, setting different threshold in the 
approximate authentication. This evening I try to send these articles as 
well. Also note, that current error resilient decoder implementations 
are not so perfect, there is a place to improve there. I would say that 
currently if you have a bad situation, that it is possible to improve 
it, however if it is a very bad situation, then we can not improve it. 
And you will see the difference between drop and damage in bad 
situations only.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 21:51:01 -0600

On Nov 6, 2010, at 9:28 PM, Feher Gabor wrote:

> I think the key line is the last one. If we are using compression then a video or audio decoder will know better what to do with a bit error than it is known by the layers below. That is the main idea, to allow the decoder to judge on bit errors and do not filter them on the lower layers. Today we have intelligent decoders, using resync markers, data partition and RVLC. Thanks to this a big portion of the erroneous packet can be saved.
> 
> The best scenario is real-time video streams. Real-time because at that case we have delay constraints and video because there are lots of data there, so the MAC will cause less bw increase (8 byte vs 1000 bytes). It will work with audio as well, but the efficiency on bw is lower aand you might consider alternative solutions. We already have measurements in this scenarios proving that the video quality is better with the damaged packets, in the case, if it is only a small damage. I read other measurements proving that error resilient decoders work better on damaged data than dropping the packets. It is possible to filter packets based on the amount of the damage, setting different threshold in the approximate authentication. This evening I try to send these articles as well. Also note, that current error resilient decoder implementations are not so perfect, there is a place to improve there. I would say that currently if you have a bad situation, that it is possible to improve it, however if it is a very bad situation, then we can not improve it. And you will see the difference between drop and damage in bad situations only.

Fantastic - look forward to seeing the details.

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt