Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

[Stephen Botzko <[e-mail]>]

Delaying until 28 March makes sense for several reasons.

The related change to H.241 should be submitted for consent on 25 March.
Since the max-dbp parameter is intended to provide an equivalent codepoint
to the one in H.241, it is sensible to wait for the H.241 outcome before
locking this down.

On the text itself, I am fine with it (presuming H.241 progresses as
expected).  It makes little sense for these new RFCs to refer to a
superseded version of H.264, so there needs to be some change to the current
text.  In the end, the proposed change simply adjusts the units to be
consistent with the current H.264.  Since the units are scaled so the actual
value on the wire is unchanged, it provides backwards compatibility.

I don't personally see the need to send it back to the Working Group, but
allowing time for WG comment is prudent.

Stephen Botzko

On Mon, Mar 21, 2011 at 11:29 AM, DRAGE, Keith (Keith) <
[e-mail]> wrote:

> Technical changes can be made, but they require the approval of the area
> director, who has the right to either ask for consensus of the mailing list
> first or indeed send it back to the working group.
>
> I would suggest we allow significantly longer than over the weekend for WG
> comment before accepting the change, e.g. until Monday 28th March.
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Glen
> > Zorn
> > Sent: 21 March 2011 06:11
> > To: Roni Even
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload
> > drafts
> >
> > On 3/20/2011 7:25 PM, Roni Even wrote:
> >
> > > Hi Glen,
> > > The technical change is more in H.264/AVC specification. In the payload
> > > specifications (3984bis/ RCDO and SVC) the change is to specify the
> > > conversion between the old and new parameter and to explain the change
> > in
> > > H.264.
> > > It can be looked as a technical and I will leave it to the AD to help
> > here.
> > >
> > > As for the quality of the change it was done by YK with the help of
> > Steve
> > > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that
> > does
> > > the video codec in a f2f meeting. It was also reviewed by me and by
> some
> > > other experts on video coding and I feel good about the solution,
> >
> > I'm admittedly not an expert on H.264, so I can't quibble about the
> > quality of the proposed solution.  My comment is a procedural one: I
> > don't believe that technical changes are allowed after the completion of
> > IETF review, nor should they be.  My understanding is that the AUTH48
> > review is provided only as a last-minute opportunity to catch typos or
> > make small editorial changes, not to modify the technical content of a
> > document.  BTW, I'm in the same boat myself right now: one of my
> > co-authors has fairly significant technical changes (and has proposed
> > even bigger ones) to a draft now in AUTH48 & I'm saying the same thing
> > about that one.  I'm _not_ looking forward to restarting the whole
> > process, but OTOH my co-author (& for that matter, I) should have had
> > our act together before requesting publication.
> >
> > >
> > > This change involves also an update to H.241 that has the same issue
> and
> > the
> > > objective is to approve the H.241 change this week at the ongoing ITU
> > Study
> > > Group 16 meeting. The solution for the IETF draft and ITU draft should
> > be
> > > the same to address interoperability.
> > >
> > > Thanks
> > > Roni Even
> > > As individual.
> > >
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > >> Glen Zorn
> > >> Sent: Sunday, March 20, 2011 11:17 AM
> > >> To: Ye-Kui Wang
> > >> Cc: [e-mail]; [e-mail]
> > >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO
> > >> payload drafts
> > >>
> > >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote:
> > >>> Folks,
> > >>>
> > >>>
> > >>>
> > >>> The three H.264/AVC related payload formats, namely,
> > >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and
> > >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage.
> > >>>
> > >>>
> > >>>
> > >>> The RFC-Editor has found the following problem: In
> > >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media
> > >>> parameter refers to the MaxDPB that was defined the first version of
> > >> the
> > >>> H.264/AVC spec, but not any more in the latest version (the 2010
> > >>> version). The parameter in the latest H.264/AVC version corresponding
> > >> to
> > >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e.,
> > >>> macroblocks) is different from the original one (i.e. 1024 bytes).
> > >>
> > >> ...
> > >>
> > >>> Since the drafts are at the AUTH48 stage, please provide comments by
> > >>> Monday, March 21, if any. Many thanks!
> > >>
> > >> Just my opinion but these seem like technical changes that can't
> really
> > >> be dealt with in AUTH48.
> > >>
> > >> ...
> > >> _______________________________________________
> > >> Audio/Video Transport Core Maintenance
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> > >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload
>