On Tuesday 18 July 2006 01:29, Sergio García Murillo wrote: > John Martin wrote: > > 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? > > I really don't see the point if it either (perhaps someone can > enlighten us). I don't know if there is any special case in which > it's needed, but if you work with rtp you shouldn't exceed the MTU > to avoid problems.
That's all well and good, but the fact is we COULD receive frames that are larger than the MTU, and we SHOULD NOT corrupt those frames if we store them and read them back at a later time. Short of downsampling those frames to keep them below the MTU, there is pretty much nothing reasonable to do, except to pass out frames identical to the frames we received. Hence, bigger buffer. I'm not so sure that downgrading the quality of the frame is even within the purview of a format_ module. If Asterisk is acting as a temporary storage location for an image that the user has decided that it needs to be a particular sample size, then a decision on frame size has already been made by the operator, and Asterisk SHOULD NOT override that decision. > Avoiding memory corruption could be the only explanation I see to > it, but I don't think it's a very good idea in the long term. Avoiding memory corruption is not a very good idea in the long term? -- Tilghman _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
