SV: SV: DCCP voice quality experiments
Arne Lie <arne.lie <at> item.ntnu.no>
2006-09-12 08:48:22 GMT
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.
> -----Opprinnelig melding-----
> Fra: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de]
> Sendt: 12. september 2006 09:27
> Til: Arne Lie
> Kopi: dccp <at> ietf.org
> Emne: Re: SV: [dccp] 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
> > 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
> > 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 Eggert NEC Network