Re: [AVTCORE] RFC4566 - understanding maxptime

[Simon Perreault <[e-mail]>]

On Mon, Jan 5, 2015 at 9:20 AM, Harald Radke <[e-mail]> wrote:

> 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?)
>
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?
>

My own policy regarding this is:

- I will not spend any effort dealing with crazy ptime bullshit (e.g., 21).
If the codec implementation I use works on byte boundaries, you're lucky,
but if it works on e.g. 10ms blocks then just too bad.
- Other than that, I don't really care about ptime. It all just goes into
one big queue. So you can vary ptimes as much as you like, you can ignore
my SDP, etc. Just don't go crazy.

Simon