|
Re: Genart last call review of draft-ietf-avtext-lrr-05
2017-06-15 15:28:39
On Jun 14, 2017, at 1:37 AM, Roni Even
<roni(_dot_)even(_at_)huawei(_dot_)com> 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:jonathan(_at_)vidyo(_dot_)com]
Sent: יום ד 14 יוני 2017 01:49
To: Roni Even
Cc: Roni Even; draft-ietf-avtext-lrr(_dot_)all(_at_)ietf(_dot_)org; General
Area Review Team;
avtext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05
On Jun 13, 2017, at 1:13 PM, Roni Even
<ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com> 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:jonathan(_at_)vidyo(_dot_)com]
Sent: Tuesday, June 13, 2017 7:03 PM
To: Roni Even
Cc: Roni Even; draft-ietf-avtext-lrr(_dot_)all(_at_)ietf(_dot_)org;
General Area
Review Team; avtext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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
<roni(_dot_)even(_at_)huawei(_dot_)com> 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:jonathan(_at_)vidyo(_dot_)com]
Sent: יום ד 07 יוני 2017 18:30
To: Roni Even
Cc: Roni Even; draft-ietf-avtext-lrr(_dot_)all(_at_)ietf(_dot_)org;
General Area
Review Team; avtext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05
On Jun 7, 2017, at 1:15 AM, Roni Even
<roni(_dot_)even(_at_)huawei(_dot_)com>
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:gen-art-bounces(_at_)ietf(_dot_)org] On Behalf Of
Jonathan Lennox
Sent: יום ד 07 יוני 2017 00:30
To: Roni Even
Cc: draft-ietf-avtext-lrr(_dot_)all(_at_)ietf(_dot_)org; General Area
Review Team;
avtext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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
<ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com>
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
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art
|
|