Resent on different list … I would like to raise an issue interoperability with this payload specification that we are currently having with WebRTC implementations. In WebRTC, and many other places, you want SDP to be able to control the resolution of the image (or at least the outer limits of the resolution). Yes, I realize there are applications where you know the resolution vis a some out of band mechanisms but O/A SDP is not one of the where this is guaranteed. We do need to specify how this works for use with O/A SDP. Some implementations think that if you want the resolution to by 720 lines by 1280, you control the resolution of codec with a SDP line something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/90000 a=ssrc:5 imageattr:* [1280, 720] Some other implementers think you control the resolution using RFC 6236 with something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/90000 a=imageattr:96 [x=1280,y=720] There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/90000 a=fmtp:96 max-fr=30;max-fs=3600 What resolution do you think "max-fs=3600" is? I have no idea. It is not possible to implement so it is not surprising no one is doing it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. I raised this in the WG and the WG came to consensus that current draft is fine. So I actually believe that current draft does represent IETF consensus and that I was merely in the rough on that consensus. I had decided to just ignore it in LC because I was under the impressing that all the implementations would just ignore the RFC and do "a=imageattr:96 [x=1280,y=720]". However, when it came to my attention that many were doing "a=imageattr:96 [x=1280,y=720]" but some where doing the non interoperable "a=ssrc:5 imageattr:* [1280, 720]", I decided that this problem actually needed to be fixed. I think this draft is broken and will create interoperability problems for years to come. I encourage the IESG to fix it. I don't care how it is resolved, I care that there is a way to for O/A to sort out the resolution and since the approach used be SDP to do this is codec specific, it needs to be in this draft. Cullen On Jun 4, 2013, at 3:25 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from the Audio/Video Transport Payloads > WG (payload) to consider the following document: > - 'RTP Payload Format for VP8 Video' > <draft-ietf-payload-vp8-08.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2013-06-18. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This memo describes an RTP payload format for the VP8 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1622/ > > > > _______________________________________________ > payload mailing list > payload@xxxxxxxx > https://www.ietf.org/mailman/listinfo/payload