Den 07. april 2016 23:17, skrev Thomas Davies (thdavies): > I don’t think a time delay is a requirement that a codec can fulfil all > on its own, so this requirement could not be directly applied as it > stands. What is important is that if you have a system with a specific > latency requirement, down to 100ms or below, is that when you’ve worked > out what contribution to the latency you can allow a codec to have, you > can readily design an encoder to meet that. For low delay that means no > reordering of pictures, but that is trivial for a conventional hybrid > codec. More importantly I think it means supporting bitstream features > that allow for fine-grained rate control so that you can meet really > tight buffer constraints with single-pass encoding.
I think this hits the nail on the head. "No forward references" = "zero structural delay", but in addition the *implementation* of the codec has to be capable of meeting a budget constraint. One limit is that the encoder has to have enough CPU or hardware to encode one frame in less than one frame interval under ~all circumstances. Another one is that it's able to clock it out on the wire in less than one frame interval. > > > > In practice I think that will mean supporting some kind of sub-frame > quantisation method so you can hit a bit rate target for a frame or even > parts of a frame. We probably want such mechanisms to allow for visual > optimization and region-of-interest coding too. I tried implementing a measurement tool for delay imposed by bufffering into a limited-bandwidth pipe (accounting for the delay imposed by, for instance, over-large i-frames) as part of compare-codecs.appspot.com. It showed that for commercially available codecs, this wasn't a big issue - it's a good tool to have in the toolbox, though. > > > > Best regards > > > > Thomas > > > > > > *From:*video-codec [mailto:[email protected]] *On Behalf Of > *Martin Thomson > *Sent:* Thursday, April 07, 2016 7:57 PM > *To:* Adam Roach > *Cc:* Filippov Alexey; [email protected]; Maire Reavy; Timothy B. > Terriberry; Randell Jesup; Jose Alvarez > *Subject:* Re: [video-codec] NETVC encoding/decoding delay > > > > As a user who frequently enjoys a network delay in the order of 320ms, I > can confirm that this is highly unpleasant. > > > > On 7 April 2016 at 15:27, Adam Roach <[email protected] > <mailto:[email protected]>> wrote: > > To be clear, the 320 figure from G.1091 is consistent with the data from > G.114: 320ms is approximately where the the R-value drops below "users > satisfied." The issue at play here is that both documents (G.1092 and > G.114) deal with total system end-to-end delay. But this is a total > number that represents a budget, and the budget must be shared by > capture, encoding, packetization, network transit, dejittering, > decoding, and playout. Grabbing the entire budget amount for encoding > and decoding requires an assumption that the remaining steps will take 0 ms. > > /a > > > > On 4/7/16 15:07, Jose Alvarez wrote: > > Dear Mo, > > > > The end-to-end delay of 320 ms value came from section 10.1 of > reference [2] <https://www.itu.int/rec/T-REC-G.1091-201410-I/en> > Recommendation ITU-T G.1091: Quality of Experience requirements for > telepresence services, 2014. Certainly your data shows that this > value is not adequate and we should consider adjusting it. > > > > Best Regards, > > > > *José Roberto Alvarez* > > *Futurewei Technologies, Inc. * > > 2330 Central Expressway, Santa Clara, CA 95050 > > *Email: [email protected] > <mailto:[email protected]>* > > *Tel: 408-330-5443 | Mbl: 408-829-5219* > > cid:[email protected] > > > > > ---------------------------------------------------------------------------------------------------------- > This e-mail and its attachments contain confidential information > from HUAWEI or any of its subsidiaries, > > which is intended only for the person or entity whose address is > listed above. Any use of the information > > contained herein in any way (including, but not limited to, total or > partial disclosure, reproduction, or dissemination) > > by persons other than the intended recipient(s) isprohibited. If you > receive this e-mail in error, please notify > > the sender by phone or email immediately and delete it. > > > > *From:*Adam Roach [mailto:[email protected]] > *Sent:* Thursday, April 07, 2016 10:48 AM > *To:* [email protected] <mailto:[email protected]> > *Cc:* Randell Jesup; Maire Reavy; Timothy B. Terriberry; Jose > Alvarez; Filippov Alexey > *Subject:* NETVC encoding/decoding delay > > > > [as participant] > > In today's meeting, Jesup brought up an issue that Maire had raised > at our previous session: the section on Video Conferencing (section > 2.2 in the current version) calls out a "preferable" end-to-end > delay value of 100ms. I think the discussion at today's meeting may > have introduced some confusion on this point. > > To be clear, this section of the document talks about "two-way video > and audio transmission for communication in real-time." For this use > case, there is a dramatic drop-off in system usability that starts > around 200ms. Keeping in mind that this data also must traverse a > network that frequently will add on the order of 100ms or > thereabouts, it's pretty clear that 100ms encoding/decoding delay > per direction is well outside of ideal. > > I'll also note that specifying 320ms as a "maximum acceptable" would > result in an experience that is only barely passable even without > network delay, and likely to become actually unusable for most users > once you send it across a network: > > > So, for conversational cases, I would argue that the "maximum > acceptable" value may be in the 100ms range. The preferable delay is > clearly much smaller than that. > > /a > > > > > _______________________________________________ > video-codec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/video-codec > > > > > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec > _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
