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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by 2013-06-18. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/payload