Hi I maybe wrong but I remember this happening sometimes during codec renegociation (early media like ring tone negociated by a server, and then media is negociated with the endpoint using another codec).Jerome
2009/7/30 Vadim Lebedev <[email protected]> > Hi Mauro > > Le 29 juil. 09 à 20:01, Mauro Sergio Ferreira Brasil a écrit : > > Hello there! > > I was checking method "ph_media_retrieve_decoded_frame" in order to make > this final adjustment, and I've got stuck on some considerable blocks of > code intended to handle a condition where the size of RTP packet received > from the other part is bigger than expected. > This is indicated by variable "needreformat". > > Is this intended to handle situations where the other part of conversation > don't respect the negotiated packetization ? > For example, we indicated preferable packetization through "ptime:20" > attribute, but the other part keeps sending RTP packets with a bigger frame > size than expected. > > Is for this only reason that these code are used, or am I missing some > other situation that will demand such "reformatation" ? > > > Yes, it is the only reason... > > > > Thanks and best regards, > Mauro. > > > > > jerome wagner escreveu: > > Mauro, I would follow Vadim on this one. > > There are 2 cases that should be checked : > - 1/ really be careful about Linux and MacOSX sound drivers. I agree > windows drivers always give you the "standard" framesizes you ask but this > is not the case for Linux or MacOSX > - 2/ pay attention to the far-end media mixing during 3-way conference. > Payloads may arrive on different end points with different framesizes. > mixing must occur at a shared framesize. > > The current phapi approach is optimized in many cases I think (less > intermediary buffers = less memory usage) and I think that a dynamic graph > construction 'a la gstreamer' would be a + : > * no buffers when they are not needed (and for embedded targets they are > more than often are not needed) > * buffers for some scenarios > > So a step by step approach could be to add an entity with a > meta-description of the graph inside phapi to known which graph elements are > activated and which are not, with what parameters. I don't know about the > mediastreamer (ortp side project) integration that Vadim was talking about > recently so I can't really give you more help on this one. > > Hope this helps, > Jerome > > > Jerome > > > > 2009/7/28 Vadim Lebedev <[email protected]> > >> IMO this is the correct way... >> >> Thanks >> Vadim >> Mauro Sergio Ferreira Brasil wrote: >> >> Hi Jerome! >> >> I've asked information about how common is that condition because I had no >> problem here initializing the audio devices of the same soundcard with >> different framesizes. >> I've made lots of test calls using my onboard soundcard on Windows with >> some variety of framesize scenarios, like: 40ms on TX and 20ms on RX; 30ms >> on both paths (iLBC's "mode" parameter config), etc. >> >> Now, considering that I can't rely on anything, I suppose the best choice >> is to get back the audio devices initialization blocked (i.e. hardcoded) to >> work with the framesize resulting of 20ms packetization for both paths. >> This will avoid lots of changes and the inevitable demanded tests. >> >> We initialize incoming and outcoming audio paths to work always with >> framesize of 160 shorts (or 320 if we work at 16 KHz) - that is the way it >> used to work before the patch I've sent, and create buffer adaption routines >> to both paths oh "phmedia-audio.c" in order to process the incoming and >> outgoing data accordingly. >> >> What do you think ? >> >> Thanks and best regards, >> Mauro. >> >> > -- > *At., > * <CMMI_2.jpg> *Technology and Quality on Information* Mauro Sérgio > Ferreira Brasil Coordenador de Projetos e Analista de Sistemas + > [email protected] <@tqi.com.br> : www.tqi.com.br ( + 55 > (34)3291-1700 ( + 55 (34)9971-2572 > > >
_______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
