[asterisk-dev] H.263 Buffer size

[John Martin]

Hi Devs,
  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.

 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.

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?

  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.

  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.

  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'm cross posting this to the video list in case someone there has a
better reason for the change...

  Or maybe I've got it all wrong :-)

John