[asterisk-dev] H.263 Buffer size

[Tilghman Lesher]

On Monday 17 July 2006 16:09, John Martin wrote:
>   I was just watching the SVN commits going by and I was wondering
> why the H.263 buffer size in format_h263.c had to be increased to
> 32kB?
>
>  Sure, when sending the most common H.263 images (CIF) the default
> max "image" size is 256kb (32kB), but I didn't think that was the
> typical way that Asterisk stored the stream to file. From what I've
> seen Asterisk stores (and expects to read in return) ast_frames from
> off the network to file (so less than MTU), and they'll usually be
> split by whatever created them into sizes that will fit onto the
> network before transmission or being stored.

I'm not sure how this relates to MTU.  The previous size documented in
the format spec was 2048 bytes per frame, which is bigger than the MTU
on most networks.  What we had, though, was a difference between the
maximum storable frame size, as declared by the header on each frame
and the size that we could read out of a file.  The net effect of this
is that we could store frames which exceeded 4096 bytes, but if we tried
to read them back out, the frames would be truncated.  Not only that,
but any frames beyond that point in the file would also be sent
corrupted, as we would not be reading a sufficient amount of bytes out
of the file.

We got to this point specifically because somebody WAS sending frames
that were larger than 4096 bytes, which was originally causing a buffer
overflow when the frames were read back from a file and crashing
Asterisk.  The buffer overflow was fixed, but I decided that corruption
was not a smart idea, especially if we had received and stored the
frames correctly.

>  If it's possible to store bigger frames than the MTU in an
> ast_frame, and for rtp.c to try and write them to the network, then
> there's a lot of work to be done to change the RTP payload mode of
> the H.263 video header as it progresses through ast_rtp_write/read.
> H.263 has a payload header that would need to be re-calculated if
> ast_frames get larger than the MTU - you can't just split the h263
> payload up and transmit it over RTP.

Actually, you can, because the fragmentation occurs at the IP layer,
and the fragments are reassembled by the OS prior to handing them
over to the application.  Of course, if not all the fragments are
received, then you'll get a lost frame.

> Is this something that IAX can do - I'm not very up on IAX - I didn'
> think that chan_sip and chan_h323 would be able to handle ast_frames
> bigger than the MTU?

They can.

>   This of course doesn't allow for when Asterisk is mutli homed and
> the MTU is different between the n networks, but I guess that's a
> second order problem.

Again, MTU has no effect on the application directly, other than to
increase the chances that a packet will be lost due to not all fragments
being received on the remote end.

>   If people are having problems with streamed (from file) video
> images being corrupted then perhaps it's caused by whatever created
> the file making the ast_frame chunks too big to fit in a network
> packet.

The ast_frame chunks can generally be up to somewhere between 63k
and 64k in size.  They are limited only by the maximum size of the UDP
packet, minus the size of any headers.

And since the payload cannot be 64k in length (due to headers), it makes
further sense that 32k should be made the maximum buffer size.

>   This isn't a big deal but it would affect some of the work I've
> done in H.323 if this change is needed.

I have no qualms currently with corrupting video frames, but I'm sure
there are others who would prefer if we did all that we could to prevent
that.  ;-)

-- 
Tilghman