Stream without encoding/decoding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 1, 2010 at 7:27 PM, P.Muge Ersoy <muge.ersoy at gmail.com> wrote:

> Hi Kabil;

Hi again M?ge,

> Could you explain more about what you are trying to do..
> I mean as a first look at your mail i suspect that you are trying to build
> an rtp stream from one point to another ...
> you may use only rtp libraries such as ortp ..
>
Because my application involves actually SIP, rather than isolating SIP, I
needed to modify whole pjsua and underlying pjmedia and etc. Currently any
SIP client can connect to another for m=application, m=audio (also m=video,
but there is no codec for video) (multiple lines of media is supported.)

> Does sip involve with your application ?
>
So yes.

> May be it is better to think about what you really need? Modifying pjsips
> rtp and media management would not be an answer for your application since
> pjsips rtp and audio media bounds are really tight as far as  i see..
>
As you said, stream, codecs, jitter is really very tightly bound. But I
already modified upper levels (pjmedia, pjnath, pjsip...) on 1.6 and will
migrate to 1.8. So the latest step is to decide on either removing
encoder/decoder, jitter or introduce dummy encoder/decoder and circular
buffer. But first is rather easier than the latter, just bypassing codec
things. I preferred this way because I will use all pjsua features.

> regards
>
best regards

> muge
>
> (I tried to reach you after your vacation (by guessing the date), but I was
unsuccessful.)


> 2010/10/1 Kabil Akp?nar <kabilakpinar at gmail.com>
>
>>  So anybody?
>>
>> 2010/10/1 Kabil Akp?nar <kabilakpinar at gmail.com>
>>
>> Hi all;
>>> I am trying to give m=application support in pjsip, and close to the end.
>>> But before I proceed, I need to double check the "stream" issue.
>>> For m=audio stream has encoder and decoder attached and a jitter buffer.
>>> In m=application case, incoming data does not need any encoder or decoder
>>> for the moment, so incoming/outgoing must just pass without any
>>> modification. In this case I need to either remove enc/dec parts for
>>> m=application and modify get_frame/put_frame or I should introduce a dummy
>>> encoder/decoder, but removing seems easier, latter is not that hard in fact.
>>> Also the buffer used for storing incoming/outgoing data is not necessary,
>>> simply the data can be immediately passed to upper level by callback
>>> mechanism..
>>>
>>> So what would be your very valuable suggestions?
>>>
>>> --
>>> Kabil Akp?nar
>>>
>>>
>>
>>
>> --
>> Kabil Akp?nar
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>


-- 
Kabil Akp?nar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20101001/a21bf1f2/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux