Re: [AVTCORE] RFC4566 - understanding maxptime

[Magnus Westerlund <[e-mail]>]

Hi,

I think I can provide some explanation as the one that actually wrote
this originally

On 2015-01-05 15:20, Harald Radke wrote:
> Hi all,
>  
> I have slight troubles to understand the RFC4566 definition of the
> maxptime attribute
>  
> (if this mailing list is not the right place to ask questions to
> understand RFCs, just to discuss them, I  am sorry, just tell me and I
> wont bother you any further).
>  
> RFC4566 states:
>  
> a=maxptime:<maximum packet time>
> This gives the maximum amount of media that can be encapsulated
> in each packet, expressed as time in milliseconds. The time
> SHALL be calculated as the sum of the time the media present in
> the packet represents. [...]
>  
> 1) I kinda get the first sentence, but what does that second sentence
> actually mean? I kinda have problems understanding the SUM
> statement. Does that "only" mean that in case of multiple frames in one
> packet that all frame durations are summed up? I wonder because the
> ptime definition does not contain a similar statement.

The second part is there to deal with the cases when an RTP payload
contains multiple frames, for example AMR frames that has a duration of
20 ms. But, as the AMR RTP payload format supports Interleaving also,
the maxptime is the amount of audio frames actually contained in payload
rather than the duration between the oldest and newest media present. So
maxptime=100 allows for 5 AMR audio frames, independent of how far
between they are interleaved.

>  
> 2) Actually somebody already asked a similar question some time
> (actually years) ago, actually the difference between ptime and
> maxptime, the answer was:
>  
>>The "a=ptime:" attribute is a hint to the encoder on the preferred
> packetisation interval for the media. The encoder may follow the hint,
> or it may vary the packetisation >interval up to the value indicated by
> "a=maxptime:". The receiver is expected to be able to decode any
> reasonable packetisation.
>  
> a)is the receiver expected to decode ANY packetisation? (e.g. ptime=20,
> maxptime=40 -> incoming RTP packets of the stream might contain payloads
> worth of any length between 20 and 40ms, in case of sample based codecs
> with sample duration granularity?)

With the most liberal interpretation the answer is yes. But, in practice
I think reasonable number of samples is expected. Unfortunately there
are no defined list of these lengths to my knowledge.

>  
> b) must the receiver be able to handle varying packetisation during a
> session? that is receiving RTP packets with different payload lengths
> and different interarrival times or does "vary" just mean  that the
> sender "selects" one packetisation interval between ptime and maxptime
> at the beginningbut keeps it constant during the session?

Yes, the amount of media in the different RTP payloads are expected to
be changed during the RTP session. This to deal with changing latency,
available bandwidth and other changes during the duration of the session.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------