Subject: [AVT] RFC3016 packetization question

From: "Cesar Trobianni" <[email-masked]>
Date: Fri, 17 Aug 2007 13:58:12 -0700

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 <[email-masked]>
Sent: Thursday, August 16, 2007 11:44 AM
To: Randell Jesup <[email-masked]>
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
> [email-masked]
> "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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt