Mauro,
I've suggesteted to keep "ph_astream_decoded_framesize_get" calls...
1) The media encapsulation/decapsulation layer should be capable to
accept non-negotiated framesizes from the network.
We've encountered pretty often situation where the SDP contains
ptime:20 but the RTP stream has 30 or 40 msec payload.
2) This layer should NOT access codec->xxxx_framesize directly but
through accesors functions this will simplfy future modifications to
dynamically modulate outgoing framesizes as function variable link
quality
3) codec->xxxx_framesize should be considered as PREFERED
framesize, and it could be nice to have a optimized operation when
rtp framesize and audio framszies are equal to preferred frame
size.
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi Vadim!
I think I was a little precipitated.
When you said to keep "ph_media_retrieve_decoded_frame" method, was you
thinking on keep its implementation as well ?
I'm asking you that because although method
"ph_media_retrieve_decoded_framesize" with it's current implementation
won't be of any use considering the changes I'll make, method
"ph_media_retrieve_encoded_framesize" will still be necessary and
"with" it's current implementation.
Now I would like to have a good suggestion from you, because I have two
conditions to consider:
1- Lots of places that use method "ph_media_retrieve_decoded_framesize"
that must be changed to return the value of framesize considering fixed
20ms packetization;
2- The outcoming (TX) adaption buffer routine that needs the result of
method "ph_media_retrieve_encoded_framesize" without changes (i.e.
considering the real rtp frame size to be send to network);
Should we split it up to 4 methods being: 2 returning the internal
framesize (considering always 20ms packetization); and 2 considering
the framesizes that actually are transmited to, and received from,
network ?
Any ideas, suggestions ?
Thanks and best regards,
Mauro.
Mauro Sergio Ferreira Brasil escreveu:
Hi Vadim!
But... do you agree, considering what I've exposed on prior message,
that this method will always return the value given by
"codec->decoded_framesize" despite of channel (concept added on last
patch), right ?
I mean... considering that we will make the entire "phapi" core work
with 20ms packetization the value returned by this method will always
be the values used on all codecs (phcodec_t structure for all codecs)
initialization, right ?
Because both channels will work with same framesize that will be always
the associated with 20ms packetization.
On the scope of use of this method, of course (RTP packets will still
flow through network with negotiated framesizes).
If your answer is "YES", no problem with that.
In fact, this will reduce the number of changes.
I'm just not certain if it's signature should be returned to prior
version that don't consider channels (incoming and outcoming), now that
this will be useless.
Or keep this channel parameter to reduce changes and still leave it for
some possible future use.
What do you think ?
Just to synchronize thoughts...
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Mauro,
It's agood plan, except that is is BAD idea to remove
"ph_astream_decoded_framesize_get" calls....
Please keep them....
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi Guys!
Let me explain why have I made that question so maybe we can get to a
conclusion here.
The point is quite simple: I want to remove all those "reformatation"
blocks on "ph_media_retrieve_decoded_frame" method because I think they
won't be necessary any more.
And they won't be necessary because of the solution I'll propose here
to the "device with same framesize" issue.
Having some thought about this problem I realized that the simplest and
easier solution is to get all "phapi" core to the way it was before,
blocking all device initialization, buffer allocation, and code/decode
stuff to operate always considering a framesize correspondent to 20ms
packetization.
Methods that use "ph_astream_decoded_framesize_get" today will use
"codec->decoded_framesize" directly.
The changes to codec initialization will be removed too, because we
will use code/decode routines only with buffers which their encoded and
decoded sizes correspond to 20ms packetization.
The rest of the magic will happen with adaption buffers that will be
used on incoming and outcoming edges of "phapi" with "ortp".
For example: for incoming (RX) path, the adaption buffer code will be
placed on "ph_media_retrieve_decoded_frame" method so it process and
return only a buffer with the correspondent size of 20ms packetization,
keeping the rest of the current RTP packet to be processed on next call.
I have already validated that point and it seems it will work pretty
fine, but I still have to validate the outcoming (TX) point.
Any of you have any disagreements or questions about this approach ?
Can you point some problems that maybe I couldn't see yet ?
Thanks and best regards,
Mauro.
--
TQI - Technology and Quality on Information
| At.,
|
 |
| Technology
and Quality
on Information |
| Mauro Sérgio
Ferreira Brasil |
| Coordenador
de Projetos e
Analista de Sistemas |
| + mauro.bra...@tqi.com.br |
| : www.tqi.com.br |
| ( + 55 (34)3291-1700 |
| ( + 55 (34)9971-2572 |
|
