Re: [payload] Request to Last Call draft-ietf-vp8-payload

["Roni Even" <[e-mail]>]

Hi,

I sent an email to the list asking for feedback on the maximum receive
resolution.

Regardless I will start a WGLC next week and have this issue as one that
need to be concluded ASAP

Roni Even

Payload co-chair

 

From: payload [mailto:[e-mail]] On Behalf Of Harald
Alvestrand
Sent: 27 May, 2014 10:07 AM
To: [e-mail]
Subject: [payload] Request to Last Call draft-ietf-vp8-payload

 

Given that another week has gone by with zero feedback on
draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby ask
the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 without
any link to this draft.

The interest shown by the community in pursuing such a linkage is not
indicative of an IETF consensus for a linkage.

             Harald


On 05/20/2014 05:21 PM, Harald Alvestrand wrote:

Just a reminder, since Cullen reminded me that this issue has languished:

I have seen no response to my February 6 message raising specific issues
about max-video-resolution (reproduced below).
I have seen no update to max-video-resolution based on the discussion in
London.
I have seen no action from the chairs to either adopt or reject this work
item.

As far as I can tell, nothing is happening.

If there is no interest in pursuing this work, can we declare that it is not
an IETF work item and stop blocking other things on it?

                   Harald


On 02/06/2014 07:21 PM, Harald Alvestrand wrote:

On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:

Hello All

 

  Following draft has been submitted to specify payload format parameters
indicating an end-point's maximum image resolution receive capability in
SDP. This draft aims at solving the issue with specifying such functionality
for VP8 and is also applicable to other codecs in general.


Thank  you for finally posting this to the payload list! (The date of the
draft is Dec 7 - I've been waiting for the proponents to make a public
statement about it).

My biggest worry with this particular proposal is that it modifies the way
a=fmtp is specified.

As far as I understand, the syntax of a=fmtp has previously been assumed to
be specified completely by the payload specification (viz the rather
non-orthogonal stuff that is in the DTMF payload).

This specification proposes to add new parameters into a=fmtp that are
applicable to any payload. This seems like a doubtful architectural
decision.
I think it would be cleaner to add a new a= attribute that is independent of
codec (but linked to payload type) containing the information.

I also have a nit with the way offer/answer is specified:




                          ..... When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.
 
   ......
 
   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.
 
 
If taken literally, an SDP answerer wishing to state its limitations on an
a=sendonly M-line would not have the option to do so. Also, it's not clear
what values would be appropriate if the values were meaningless.
 
My suggestion would be to say that the SDP Offerer should include
max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it
understands the parameters, but has no meaningful values to supply.
 

Note: I see absolutely no reason to link this functionality, if desirable,
to the RTP format for VP8. If it needs mandating, it should be mandated for
all video types going forward, including H.265, and strongly recommended for
all video types that have been standardized in the past.

If it doesn't need mandating, it doesn't need mandating for anyone.








 

 

URL:
http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-r
esolution-00.txt
Htmlized:
http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution
-00



Looking forward for the inputs on how do we take his work ahead.

 

 

Thanks

Suhas Nandakumar






_______________________________________________
payload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/payload






-- 
Surveillance is pervasive. Go Dark.






_______________________________________________
payload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/payload






-- 
Surveillance is pervasive. Go Dark.






_______________________________________________
payload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/payload