Lars, Thanks for detailed answers. My TFRC research has been with rate adaptive video only, and not audio so far. Ingemar: Yes, I suppose the AMR could be of interest for many researchers when it comes to VoIP. I have long been working on a framework for trace driven ns-2 simulation for real rate adaptive MPEG-4 video. My current implementation includes (among one more) TFRC support (as of ns-2.28). The code is currently being tested by an "external party". I will be happy to give the web address when the code provides stable operation. The solution includes received MPEG-4 media assembly, for PSNR calculations and visual inspection. - Arne > -----Opprinnelig melding----- > Fra: Lars Eggert [mailto:lars.eggert@xxxxxxxxxxxxx] > Sendt: 12. september 2006 09:27 > Til: Arne Lie > Kopi: dccp@xxxxxxxx > Emne: Re: SV: DCCP voice quality experiments > > Hi, Arne, > > On Sep 11, 2006, at 11:01, Arne Lie wrote: > > 1. What I find difficult to understand is if your applications have > > any native rate adaptation, except packet drops at sender when the > > sender buffer (of 5 packets?) have been saturated. > > the codecs we used don't change their rate in the presence of > losses, no matter where they occur (send buffer or along the path. > > > Is it so that *if* (and when) TFRC > > gives you an equivalent rate below G.711 rate of 95.2kbps, > or 39.2kbps > > for G.729, your sender WILL drop packets when using TFRC (any > > variant), while the UDP system will hand the problem over to the > > network routers? > > TFRC can cap the send rate at the sender, which UDP doesn't. > > > I.e., my > > main question is if G.711 and G.729 have any methods for > lowering the > > codec rate output below 64 and 8kbps, respectively (by > quantiser scale > > change, or any other means) > > No, see above. Tom has a draft on how codecs that adapt their > rate may interact with DCCP. > > > 2. You have an experimental set-up. Why do you not also set-up real > > receivers (players) so that the perceptual quality can be > evaluated, > > instead of, or in addition to, your "E-model R-score" > > You mean use PESQ as a metric instead of the E-model? We > could have done that, but most related work has used the > E-model and we wanted to more directly compare our results to > theirs. Also, it would have required additional work and we > were not sure that we'd get significantly more precise > results this way. > > > 3. You use DummyNet to insert packet loss and delay. Are you > > considering experimenting without DummyNet, but instead inject more > > real traffic to create real router congestion? I think that > will give > > you a more natural environment in which you can test TFRC > performance > > under more realistic scenarios. > > Yes, definitely. In this first evaluation, however, we wanted > to be able to very tightly control the environment, in order > to be able to analyze the behavior we were seeing. > > We did run additional tests with multiple competing flows up > to and past the point of congestion, to investigate the > relative fairness of the different TFRC flavors, but these > aren't in the current paper. > > Lars > -- > Lars Eggert NEC Network > Laboratories > > >
