[FFmpeg-devel] [PATCH] RTP depacketizer for AMR

[Martin Storsjö]

Hi Ronald,

On Wed, 27 Jan 2010, Ronald S. Bultje wrote:

> On Wed, Jan 27, 2010 at 3:08 PM, Martin Storsj? <martin at martin.st> wrote:
> > Also, another point that came to my mind regarding splitting in the
> > depacketizer vs in a parser: AMR/RTP does allow interleaving (which I
> > don't support yet, haven't run across any samples with that). In this
> > case, the first RTP packet may contain audio frames 1, 4, 7, the second
> > packet contains frames 2, 5, 8, etc.
> >
> > In this case, I don't see any other option than buffering this within the
> > depacketizer and then returning the individual frames in the correct
> > order. Or is there another solution to that case?
> 
> It is exactly for this that the return values are intended. Also, for
> something like RDT, the demuxer itself might "parse" already. If you
> can return full frames, it is generally more memory-efficient (b/c you
> need fewer memcpy()s), and then that's better, IMO.

Ok, so for the current non-interleaved case, we still should return all 
frames at once - only for the potential future case of interleaved frames 
should we return them one at a time?

But do you agree that the depacketizer may need to set the timestamp if we 
return individual frames, in scenario described above?

To me, lines 414-417 (sorry, the line numbers were wrong in some of the 
earlier mails) in rtpdec.c clearly say that this is the intended use of 
the timestamp pointer. If the timestamp pointer parameter was to be 
removed, we could only set pkt->pts = AV_NOPTS_VALUE there, instead of 
doing the finalize_packet call.

// Martin