> On Jun 14, 2017, at 1:37 AM, Roni Even <[email protected]> wrote: > > Hi Jonathan, > Probably part of my comment was based on the draft name , the message name > and the abstract (all about refresh). I did not see any text about the same > usage limitation on FIR from RFC5104 > "Using the FIR command to recover from errors is explicitly disallowed, and > instead the PLI message defined in AVPF [RFC4585] should be used. The PLI > message reports lost pictures and has been included in AVPF for precisely > that purpose." > > I am OK with similar approach as you suggested, so do you mean that PLI > should be used also in this case to recover from errors.
Yes, either PLI itself or some future to-be-defined per-layer PLI equivalent. I’ll add corresponding text for LRR. Would that satisfy your comments? > Practically it will interesting to see if applications are using PLI and not > FIR for packet loss cases and what encoders do when receiving PLI. (-: I suspect PLI and FIR are actually handled identically by most applications, but in low-bitrate scenarios it likely makes sense to treat them differently. > BTW: errors is a general term, I assume that for FIR it meant errors due to > packet loss (congestion) Packet loss is the most likely, but packet corruption (in the absence of UDP checksums), or encoder or decoder bugs, are also possible. > Roni > >> -----Original Message----- >> From: Jonathan Lennox [mailto:[email protected]] >> Sent: יום ד 14 יוני 2017 01:49 >> To: Roni Even >> Cc: Roni Even; [email protected]; General Area Review Team; >> [email protected]; [email protected] >> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 >> >> >>> On Jun 13, 2017, at 1:13 PM, Roni Even <[email protected]> wrote: >>> >>> Hi Jonathan, >>> This will be good but maybe explain the upgrade means also refresh. >> Because my poor understanding in English is that upgrade is adding a new >> layer that was not available to the media receiver while refresh is to >> restore >> existing layer (e.g. decoder synchronization loss). >>> Roni >> >> Ah, I see. >> >> The design goal of LRR was for it to be used for upgrade, not for >> synchronization loss, though of course now that you mention it, it could >> certainly be used for the latter as well. (I.e. it was designed to be >> analogous >> to FIR, not to PLI.) >> >> As with the difference between FIR and PLI, the congestion considerations >> are somewhat different between upgrade and synchronization loss. Do you >> think it's worth addressing the synchronization loss cases explicitly? >> >>> >>>> -----Original Message----- >>>> From: Jonathan Lennox [mailto:[email protected]] >>>> Sent: Tuesday, June 13, 2017 7:03 PM >>>> To: Roni Even >>>> Cc: Roni Even; [email protected]; General Area >>>> Review Team; [email protected]; [email protected] >>>> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 >>>> >>>> Hi, Roni — >>>> >>>> You seem to be assuming that a refresh and an upgrade are two >>>> different actions. That’s not the intention — a refresh is a >>>> characteristic of a stream that allows a decoder to upgrade. >>>> >>>> I’ll try to draft some text that makes it clear that it’s possible >>>> either to independently upgrade temporal or spatial, or else upgrade both >> at once. >>>> >>>>> On Jun 11, 2017, at 7:20 AM, Roni Even <[email protected]> wrote: >>>>> >>>>> Hi Jonathan, >>>>> I assume the new text you propose is >>>>> >>>>> "When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be >>>>> less than CLID; at least one of TTID or TLID MUST be greater than >>>>> CTID or CLID respectively. That is to say, the target layer index >>>>> <TTID, TLID> MUST be a layer upgrade from the current layer index >>>>> <CTID, CLID>. A sender MAY request an upgrade in both temporal and >>>>> spatial/quality layers simultaneously." >>>>> >>>>> I think that this text still only implies the behavior, also the >>>>> current text talks about upgrade but I assume it is also for a >>>>> refresh not only to upgrade >>>>> >>>>> Maybe " A sender MAY request an upgrade or refresh in both temporal >>>>> and spatial/quality layers simultaneously by either having C =1 or >>>>> by having both >>>> CLID and CTID with lower values then TTID and TLID. If the sender >>>> want to upgrade or refresh only one layer then C MUST be equal to 1 >>>> and only the CTID or the CLID of the layer to be upgraded or >>>> refreshed should be lower than the TTID or TLID respectively " >>>>> >>>>> >>>>> Roni >>>>>> -----Original Message----- >>>>>> From: Jonathan Lennox [mailto:[email protected]] >>>>>> Sent: יום ד 07 יוני 2017 18:30 >>>>>> To: Roni Even >>>>>> Cc: Roni Even; [email protected]; General Area >>>>>> Review Team; [email protected]; [email protected] >>>>>> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 >>>>>> >>>>>> >>>>>>> On Jun 7, 2017, at 1:15 AM, Roni Even <[email protected]> >> wrote: >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> I did not see the text you added yet as a response to my first >>>>>>> question So to better clarify my question . If the FCI has TTID=0 >>>>>>> and TLID=2 >>>> . >>>>>> does it mean that it is a request to update both? >>>>>>> This was also the reason for the question about both TTID=0 and >>>>>>> TLID=0, >>>>>> which layer need update or is it both? >>>>>>> Can you say that you want just to update temporal or spatial? >>>>>> >>>>>> Yes, if the FCI has TTID=0 and TLID=2, it’s a request to update >>>>>> both layers — or more specifically, to make sure that you can start >>>>>> decoding the substream with TTID=0 and TLID=2. (For most >>>>>> scalability structures this would mean updating both, but exotic >>>>>> structures are >>>>>> possible.) >>>>>> >>>>>> If you want to just update one part of the stream, that’s what CTID >>>>>> and CLID are for. If you sent TTID=0 and TLID=2, accompanied by >>>>>> CTID=0 and CLID=0, that means that you already have TID 0, and you >>>>>> just want to increase the LID. >>>>>> >>>>>> The current text is at >>>>>> https://github.com/juberti/draughts/tree/master/lrr , if you want >>>>>> to take a look at the latest revisions, or suggest text that you >>>>>> think would make >>>> it cleaner. >>>>>> >>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Gen-art [mailto:[email protected]] On Behalf Of >>>>>>>> Jonathan Lennox >>>>>>>> Sent: יום ד 07 יוני 2017 00:30 >>>>>>>> To: Roni Even >>>>>>>> Cc: [email protected]; General Area Review Team; >>>>>>>> [email protected]; [email protected] >>>>>>>> Subject: Re: [Gen-art] Genart last call review of >>>>>>>> draft-ietf-avtext-lrr-05 >>>>>>>> >>>>>>>> Hi, Roni — thanks for your review. Responses inline. >>>>>>>> >>>>>>>>> On Jun 1, 2017, at 2:53 AM, Roni Even <[email protected]> >>>> wrote: >>>>>>>>> >>>>>>>>> Reviewer: Roni Even >>>>>>>>> Review result: Ready with Issues >>>>>>>>> >>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The General >>>>>>>>> Area Review Team (Gen-ART) reviews all IETF documents being >>>>>>>>> processed by the IESG for the IETF Chair. Please treat these >>>>>>>>> comments just like any other last call comments. >>>>>>>>> >>>>>>>>> For more information, please see the FAQ at >>>>>>>>> >>>>>>>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>>>>>>>> >>>>>>>>> Document: draft-ietf-avtext-lrr-?? >>>>>>>>> Reviewer: Roni Even >>>>>>>>> Review Date: 2017-05-31 >>>>>>>>> IETF LC End Date: 2017-06-08 >>>>>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The document is ready with issues for a standard track RFC Major >>>>>>>>> issues: >>>>>>>>> >>>>>>>>> Minor issues: >>>>>>>>> >>>>>>>>> 1. Can you specify both TTID and TLID in the same FCI. >>>>>>>> >>>>>>>> Syntactically, they must both occur. >>>>>>>> >>>>>>>> If you mean can you request an upgrade in both at once, yes; I’ve >>>>>>>> added text to clarify this. >>>>>>>> >>>>>>>>> 2. What is the meaning of value 0 for TTID and TLID - TID or LID >>>>>>>>> =0 in frame marking draft means base layer if there is scalability. >>>>>>>>> This relates to the previous question. >>>>>>>> >>>>>>>> I’m not sure I understand this question. >>>>>>>> >>>>>>>> I’ve added text that if C=1, at least one of <TTID, TLID> MUST be >>>>>>>> greater than <CTID, CLID>, and both MUST be greater than or equal >>>>>>>> to their counterpart, so the LRR is actually requesting a layer >> upgrade. >>>>>>>> Is that what you were asking about? >>>>>>>> >>>>>>>>> 3. What would an FCI with both TTID and TLID equal 0 mean. >>>>>>>> >>>>>>>> It means you want a refresh of the base temporal/spatial layer, only. >>>>>>>> >>>>>>>>> Nits/editorial comments: >>>>>>>>> >>>>>>>>> 1. Section 3 "an Real-Time Transport Control Protocol" should be >>>>>>>>> "a Real…". >>>>>>>> >>>>>>>> Colin pointed out that it should say “an RTP Control Protocol” >> anyway. >>>>>>>> >>>>>>>>> 2. In section 3 " [RFC5104](Section 3.5.1)" there is a link to >>>>>>>>> section >>>>>>>>> 3.5.1 but it does not work. >>>>>>>> >>>>>>>> xml2rfc doesn’t have any way to link to sections of other >>>>>>>> documents, so the “(Section 3.5.1)” part is just a comment. >>>>>>>> >>>>>>>> I think the internet-draft tooling may have thought I was trying >>>>>>>> to link to a non-existent section 3.5.1 of this document, but >>>>>>>> that’s outside >>>>>> my control. >>>>>>>> >>>>>>>>> 3. In section 3.2 "(see section Section 2.1)" section appears twice. >>>>>>>> >>>>>>>> Fixed. >>>>>>>> _______________________________________________ >>>>>>>> Gen-art mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>> >>> >>> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
