Hi Tilghman, Firstly, I think you're absolutely right that video corruption should be protected against. I have spent a lot of the last 6 months trying to get Asterisk to behave nicely with video :-)
However, I guess the current fix doesn't actually protect against it, it just makes it more unlikely. H263_write() can still write packets bigger than 32k and h263_read() will still not read in the big packets after checking the packet size and will therefore corrupt the filestream through not keeping track of the file pointer correctly. Shouldn't big packets be dropped before being written in h263_write()? I guess it would also be a good idea to set an AST_MAX_FRAME_SIZE in frame.h and police it in rtp.c and elsewhere. The issue of what AST_MAX_FRAME_SIZE should be is a different matter... And on that note, I think for many reasons allowing large packets is a bad thing (e.g. fragmentation leading to packetloss, latency, jitter, sub-frame error concealment issues, etc). I think this will lead to problems in the future. I guess you didn't set out to fix these problems but it's something we think about on the video dev list. Oh, don't you need to reflect any changes in format_h264.c as well :-( John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:asterisk-dev- > [EMAIL PROTECTED] On Behalf Of Tilghman Lesher > Sent: 18 July 2006 08:16 > To: Asterisk Developers Mailing List > Subject: Re: [asterisk-dev] H.263 Buffer size > > 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 _______________________________________________ --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
