[Ffmpeg-devel] [PATCH] RTP payload format for AMR
Kite Flyer
kiteflyer77
Mon Mar 12 15:46:42 CET 2007
Hi Michael,
Thanks for your input. Attached patch is based on the same. Pls see inline.
-Subrata
On 3/10/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
>
> On Fri, Mar 09, 2007 at 09:31:47PM +0530, Kite Flyer wrote:
> > 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
>
> non constant static and global arrays are forbidden in libav* (with exceptions
> for debug code and arrays which are initalized once but never changed)
> 2 RTP instances could not coexist otherwise ...
>
Very true. My indifference.
> one easy way to pack the AMR frames is:
>
> uint8_t *toc_buf= s->buf;
I made it s->buf + 1 to take care of the (CMR,RRRR) byte before TOC.
> uint8_t *buf= s->buf + TOC_MAX;
I have set TOC_MAX to max_payload_size/ 13 where 13 = 1 (toc_byte) +
12 (4.75 kbps frame length). It should take care of the one byte
length for the (CMR,RRRR) byte too.
>
> payload_size= s->buf_ptr - buf + size;
> if( s->foobar >= TOC_MAX
> || TOC_MAX + payload_size > sizeof(s->buf)
> || s->foobar + 1 + payload_size > s->max_payload_size){
>
First condition checks if TOC buffer is full. Second condition should
check if speech buf alone is full. If so, is the third condition
needed? Pls see my patch.
> memmove(buf - s->foobar, toc_buf, s->foobar);
I didn't know of such a nice readymade function memmove!
> send (buf - s->foobar, s->foobar + s->buf_ptr - buf);
> s->buf_ptr= buf;
> s->foobar=0;
> }
>
> toc_buf[ s->foobar++ ]= toc_byte
> memcpy(s->buf_ptr, input, size);
> s->buf_ptr+= size;
>
> [...]
> > + /* append speech data after ToC and send */
>
> trailing whitespace (this is forbidden in svn)
>
oops
>
> [...]
> > + flen = packed_size[ft];
> > + if (flen > 0)
> > + {
> > + if (size >= flen)
>
> isnt flen always == size if so this code isnt needed, also packed_size[] isnt
> needed OTOH if flen can be != size id like to know how that is possible
>
Actually I had an impression that encoder gives multiple frames at a
time. Now removed the lines.
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
> _______________________________________________
> 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_payload3.patch
Type: application/octet-stream
Size: 3106 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070312/00b7aee1/attachment.obj>
More information about the ffmpeg-devel
mailing list