[Ffmpeg-devel] [PATCH] RTP payload format for AMR

[Kite Flyer]

Hi Michael,

Please see inline. New patch is attached.

Thanks,
Subrata

On 3/8/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
>
> On Thu, Mar 08, 2007 at 06:21:34PM +0530, Kite Flyer wrote:
> [...]
> > >
> > >
> > >[...]
> > >
> > >> +        //TODO: find a way to pack maximum number of frames based on
> > >max_payload_size
> > >
> > >yes
> > >
> >
> > Keeping it as fixed no of frames as of now.
> >
> > payload format requires that all speech data frames be written after
> > all frame headers i.e. ToC. If encoder always generates constant bit
> > rate frames then offset of data frames can be calculated and maximum
> > no of frames can be packed. But if encoder can generate variable bit
> > rate frames, then two memory areas can be taken: one for ToC and
> > another for data but the memcpy to concatenate the memories would be
> > expensive per send.
>
> no, copying a ToC (that ends at about 50 byte per second is totally
> negligible)
>
> 8khz (only one supported by AMR NB) / 160 (frame size) = 50 (1 byte Toc bytes)
>
> additionally AMR is low bitrate stuff so copying the encoded bitstream
> around cannot be timeconsuming, copying part of it even less so ...
>

OK. Implemented at the cost of having a static buffer in rtp_send_amr
routine. No more amr specific code in RTPDemuxContext common code. Now
it sends  maximum no of frames. Should also support variable bit rate,
if output from encoder.

>
> >
> > >
> > >[...]
> > >>      }
> > >>  }
> > >>
> > >> +/* Send AMR audio. Note: AMR_NB, single channel is supported now. */
> > >> +static void rtp_send_amr(AVFormatContext *s1,
> > >> +                               const uint8_t *buf1, int size)
> > >> +{
> > >> +    RTPDemuxContext *s = s1->priv_data;
> > >> +    AVStream *st = s1->streams[0];
> > >> +    const static uint8_t packed_size[16] = {12, 13, 15, 17, 19, 20, 26,
> > >31, 5, 0, 0, 0, 0, 0, 0, 0};
> > >> +    uint8_t toc, ft;
> > >> +    int dlen;
> > >> +
> > >> +    if (st->codec->codec_id != CODEC_ID_AMR_NB)
> > >> +        return; //FIXME: clean if reqd
> > >> +
> > >> +    if (size < 1)
> > >> +        return;
> > >> +
> > >> +    /* correct table of contents and add frames */
> > >> +    while (size > 0) {
> > >
> > >this function cannot receive more then 1 frame at a time, if it does then
> > >there is a bug somewhere, (if the amr encoder outputs several frames
> > >concatenated then it is buggy, if a demuxer outputs such mess a AVParser
> > >is needed to split it up, reimplementing such split up code everywhere
> > >will not be accepted)
> > >
> >
> > True. Changed the comments though keeping the while like other codec
> > pack routines.
>
> no other codec in rtp.c contains code which splits the data stream into
> frames, if this is not removed from the patch then the patch is rejected
>

Hmmm. while loop removed with faith in encoder that it would always
give one frame at a time.

> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amr_rtp_payload2.patch
Type: application/octet-stream
Size: 2757 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070309/8816d588/attachment.obj>