[FFmpeg-devel] [PATCH] RTP depacketizer for AMR
Wed Jan 27 21:25:51 CET 2010
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.
More information about the ffmpeg-devel