[AVT] RFC3016 packetization question

["Cesar Trobianni" <ctrobianni at ecotronics.com>]

All,

I don't have very clear how to behave in this case. If I have a very big MPEG4 VOP (bigger than the MTU), do I 

1. Put it in a single RTP (marker == true)
2. Put it in multiple RTPs using RFC2190/RFC2429 (short header mode)?

Thank you

---

From: Stephan Wenger <stewe at stewe.org>
Sent: Thursday, August 16, 2007 11:44 AM
To: Randell Jesup <rjesup at wgate.com>
Subject: Re: [AVT] RFC 3984 offer/answer Question

3984 bis is on our list for a while now.  It has almost become a  
ritual between (at least) Magnus and me: a the end of an AVT session,  
we talk and say "we really should get started on 384 bis".
Seriously, this is not the only known ambiguity in the spec.   
Somewhere, I even have a list of the others :-).  I'll devote cycles  
once the ccm spec is out (hint hint).
Stephan


On Aug 16, 2007, at 7:21 AM, Randell Jesup wrote:

> "Even, Roni"

writes:
>> I went back to the mailing list and found the attached email.
>> It is in line with my thought that the level can be downgraded
>
> Darn! :-) I knew this whole conversation sounded familiar. I
> remember
> (now) seeing that, and in fact I've kept the article "ticked" in Gnus
> so it doesn't disappear on me.
>
> There really should be an rfc 3984bis (or at least an informational
> RFC; I
> don't know how this is supposed to work); everyone who comes to
> read it
> without searching the mail-archives will make the same set of
> mistakes and
> mis-readings.
>
> Magnus?
>
> Magnus wrote:
>> We authors was made aware of an issue in the Offer/Answer usage
>> for the
>> H.264 RTP payload format by Tang Yongliang.
>>
>> The issue is that section 8.2.2 says:
>>
>> o The parameters identifying a media format configuration for
>> H.264
>> are "profile-level-id", "packetization-mode", and, if
>> required by
>> "packetization-mode", "sprop-deint-buf-req". These three
>> parameters MUST be used symmetrically; i.e., the answerer MUST
>> either maintain all configuration parameters or remove the
>> media
>> format (payload type) completely, if one or more of the
>> parameter
>> values are not supported.
>>
>> And later
>>
>> " o Parameters declaring a configuration point are not
>> downgradable,
>> with the exception of the level part of the "profile-level-id"
>> parameter."
>>
>> That is contradicting for the "profile-level-id" parameter. The
>> intention of the authors was that the profile part (profile_idc and
>> profile_iop) would be fixed but the level (level_idc) can be
>> downgraded.
>> That way you as an receiver state the profiles and highest level for
>> that profile you are willing to accept. The answerer can then respond
>> with the same profile but with a possibly lower level.
>>
>> So for clarification: An answerer MUST only maintain the
>> profile_idc and
>> profile_iop bytes of the profile-level-id value and MAY downgrade the
>> level part.
>>
>> Please note: This may require the offering party to make a new
>> offer to
>> provide its "sprop" parameters correctly due to the reduction in
>> level.
>>
>> However without this clarification the only way of getting a
>> successful
>> offer/answer for H.264 when not fully aware of the counter-parts
>> capabilities would be to write one payload type for each profile-
>> level
>> combination that one could downgrade to.
>
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-
> Amiga OS team
> rjesup at wgate.com
> "The fetters imposed on liberty at home have ever been forged out
> of the weapons
> provided for defence against real, pretended, or imaginary dangers
> from abroad."
> - James Madison, 4th US president (1751-1836)
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt