Title: TQI - Technology and Quality on Information
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" ?
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.,
|
 |
| Technology and Quality
on Information |
| Mauro Sérgio Ferreira Brasil |
| Coordenador de Projetos e
Analista de Sistemas |
| + [email protected] |
| :
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
