Hi,
it would be great to get the AMR codec for Jitsi and there is already a good base for such a project: http://opencore-amr.sourceforge.net/
I think it'll be great for the most users to be able to use AMR due to the high resistence against network failures, weak networks and high jitters and as a result good audio quality even at bad network connections.
I propose it as a feature request for upcoming versions of Jitsi.
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free
(free as in beer and free as in speech)
--sent from my mobile
On 19 Oct 2014 8:43 AM, "Philipp Schuster" <ps07@online.de> wrote:
Hi,
it would be great to get the AMR codec for Jitsi and there is already a
good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due to the
high resistence against network failures, weak networks and high jitters
and as a result good audio quality even at bad network connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Re[2]: [jitsi-users] AMR Codec for Jitsi
Hi, Philipp.
For “high resistence against network failures, weak networks and high jitters and as a result good audio quality even at bad network connections.” try Speex-8000, -16000.
It’s sometimes even better than Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice - Speex-16000 and Speex-8000 works excellent.
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free (free as in beer and free as in speech)
–sent from my mobile
On 19 Oct 2014 8:43 AM, “Philipp Schuster” ps07@online.de wrote:
Hi,
it would be great to get the AMR codec for Jitsi and there is already a good base for such a project: http://opencore-amr.sourceforge.net/
I think it’ll be great for the most users to be able to use AMR due to the high resistence against network failures, weak networks and high jitters and as a result good audio quality even at bad network connections.
I propose it as a feature request for upcoming versions of Jitsi.
users mailing list
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
*–
С уважением,
Hi, Philipp.
For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000.
It's sometimes even better than Opus on poor 3G or ISP lines. In my case -
when Opus is glitchy-voice - Speex-16000 and Speex-8000 works excellent.
I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old and
abandoned codec that hasn't seen any new development for a number of years.
Jean-Marc Valin, the creator of Speex, is actually one of the main authors
of Opus. Speex has none of the resiliency or adaptivity mechanisms that
Opus has (like native Forward Error Correction or Packet Loss Concealment).
It can also operate on bitrates as low as 3kbps (and up to 512 kbps) and
would always give you better quality than Speex in any kind of conditions.
In other words, you could probably see Opus as Speex 3.0 if you really
wanted to think in those terms.
Emil
Вы писали 19 октября 2014 г., 10:47:54:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru> wrote:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free
(free as in beer and free as in speech)
--sent from my mobile
On 19 Oct 2014 8:43 AM, "Philipp Schuster" <ps07@online.de> wrote:
Hi,it would be great to get the AMR codec for Jitsi and there is already a
good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due to the
high resistence against network failures, weak networks and high jitters
and as a result good audio quality even at bad network connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users*-- С уважением, Олег *
mailto:oleg.bars.mail@yandex.ru <oleg.bars.mail@yandex.ru>_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Thanks for all the tips!
The problem is: If you use Jitsi with a sip provider who's offering no opus and no speex but AMR iLBC and G.711, AMR will be the better choice for weak network connections, definitively.
Sadly this is a very frequent case, for example for all the betamax company sip providers among others - they are offering great rates for international calling but only a few codecs.
For this reason it would be great to integrate AMR into Jitsi - I think it shouldn't be a very hard task because of the already existing opencore-amr library like Linphone is using it.
What do you think?
Am 19.10.2014 um 11:28 schrieb Emil Ivov:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru > <mailto:oleg.bars.mail@yandex.ru>> wrote:
Hi, Philipp.
For "high resistence against network failures, weak networks and
high jitters and as a result good audio quality even at bad
network connections." try Speex-8000, -16000.
It's sometimes even better than Opus on poor 3G or ISP lines. In
my case - when Opus is glitchy-voice - Speex-16000 and Speex-8000
works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old and abandoned codec that hasn't seen any new development for a number of years.
Jean-Marc Valin, the creator of Speex, is actually one of the main authors of Opus. Speex has none of the resiliency or adaptivity mechanisms that Opus has (like native Forward Error Correction or Packet Loss Concealment). It can also operate on bitrates as low as 3kbps (and up to 512 kbps) and would always give you better quality than Speex in any kind of conditions.
In other words, you could probably see Opus as Speex 3.0 if you really wanted to think in those terms.
Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is
entirely free (free as in beer and free as in speech)
--sent from my mobile
On 19 Oct 2014 8:43 AM, "Philipp Schuster" <ps07@online.de > <mailto:ps07@online.de>> wrote:
Hi,it would be great to get the AMR codec for Jitsi and there is
already a good base for such a project:
http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR
due to the high resistence against network failures, weak networks
and high jitters and as a result good audio quality even at bad
network connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users/--
С уважением,
Олег /mailto:oleg.bars.mail@yandex.ru_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Hey Oleg,
Please do not remove this list from the recipients.
More inline:
Здравствуйте, Emil.
Speex has one big attitude - it is in native support by many SIP
servers (PBX) and has no voice re-coding/double/triple/etc... on the
voice route. Opus - has no support on routes/landlines/etc by
providers. It makes multiple voice coding/decoding/re-coding and much
loss of quality. This is the way of worse Opus usage prior to Speex.
IMHO.
Now that's a totally different argument but it still doesn't make sense
to me. If middle boxes do not support Opus then they wouldn't be able to
transcode it. They would just fall back to using other codecs.
Popular servers today support Opus already (FreeSWITCH has it natively
and Asterisk can be easily tweaked). More and more commercial platforms
are adding it.
Also not that in a number of cases, Opus support is not required in the server at all because most large scale networks connect endpoints directly, without transcoding at all.
By the way, is Jitsi respecting the first codec offered by
sip-server, or negotiates from the list of codecs from itself?? If
no, this negotiation should be, and should be a setting "Honor remote
codec" (if set, local codecs will be ignored and the first supported
codec from the list sent by server will be used), and "Honor local
codecs" (if set, negotiation from the local codecs by its priority
should be used, ignoring servers list of priority).
Jitsi implements the Offer/Answer negotiation model as described by RFC3264.
Emil
On 19.10.14, 13:18, Олег wrote:
Вы писали 19 октября 2014 г., 12:28:30:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru
<mailto:oleg.bars.mail@yandex.ru>> wrote: Hi, Philipp.For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000. It's sometimes even better than
Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice
- Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old
and abandoned codec that hasn't seen any new development for a number
of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity
mechanisms that Opus has (like native Forward Error Correction or
Packet Loss Concealment). It can also operate on bitrates as low as
3kbps (and up to 512 kbps) and would always give you better quality
than Speex in any kind of conditions.In other words, you could probably see Opus as Speex 3.0 if you
really wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp, Have you checked our Opus support? Opus is arguably
better than AMR in every respect and it is entirely free (free as in
beer and free as in speech) --sent from my mobile On 19 Oct 2014 8:43
AM, "Philipp Schuster" <ps07@online.de <mailto:ps07@online.de>>
wrote: Hi,it would be great to get the AMR codec for Jitsi and there is already
a good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due
to the high resistence against network failures, weak networks and
high jitters and as a result good audio quality even at bad network
connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
Philipp, which ITSP's support any or all of SPEEX, AMR and iLBC?
On Sun, Oct 19, 2014 at 10:30 AM, Philipp Schuster <ps07@online.de> wrote:
Thanks for all the tips!
The problem is: If you use Jitsi with a sip provider who's offering no
opus and no speex but AMR iLBC and G.711, AMR will be the better choice for
weak network connections, definitively.Sadly this is a very frequent case, for example for all the betamax
company sip providers among others - they are offering great rates for
international calling but only a few codecs.For this reason it would be great to integrate AMR into Jitsi - I think it
shouldn't be a very hard task because of the already existing opencore-amr
library like Linphone is using it.What do you think?
Am 19.10.2014 um 11:28 schrieb Emil Ivov:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru> wrote:
Hi, Philipp.
For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000.
It's sometimes even better than Opus on poor 3G or ISP lines. In my case
- when Opus is glitchy-voice - Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old and
abandoned codec that hasn't seen any new development for a number of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity mechanisms
that Opus has (like native Forward Error Correction or Packet Loss
Concealment). It can also operate on bitrates as low as 3kbps (and up to
512 kbps) and would always give you better quality than Speex in any kind
of conditions.In other words, you could probably see Opus as Speex 3.0 if you really
wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free
(free as in beer and free as in speech)
--sent from my mobile
On 19 Oct 2014 8:43 AM, "Philipp Schuster" <ps07@online.de> wrote:
Hi,it would be great to get the AMR codec for Jitsi and there is already a
good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due to
the high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users*-- С уважением, Олег *
mailto:oleg.bars.mail@yandex.ru <oleg.bars.mail@yandex.ru>_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users_______________________________________________
users mailing listusers@jitsi.org
Unsubscribe instructions and other list options:http://lists.jitsi.org/mailman/listinfo/users_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Well from that perspective more is always better. Hopefully we would be
able todo this in the near future.
--sent from my mobile
On 19 Oct 2014 4:31 PM, "Philipp Schuster" <ps07@online.de> wrote:
Thanks for all the tips!
The problem is: If you use Jitsi with a sip provider who's offering no
opus and no speex but AMR iLBC and G.711, AMR will be the better choice for
weak network connections, definitively.Sadly this is a very frequent case, for example for all the betamax
company sip providers among others - they are offering great rates for
international calling but only a few codecs.For this reason it would be great to integrate AMR into Jitsi - I think it
shouldn't be a very hard task because of the already existing opencore-amr
library like Linphone is using it.What do you think?
Am 19.10.2014 um 11:28 schrieb Emil Ivov:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru> wrote:
Hi, Philipp.
For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000.
It's sometimes even better than Opus on poor 3G or ISP lines. In my case
- when Opus is glitchy-voice - Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old and
abandoned codec that hasn't seen any new development for a number of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity mechanisms
that Opus has (like native Forward Error Correction or Packet Loss
Concealment). It can also operate on bitrates as low as 3kbps (and up to
512 kbps) and would always give you better quality than Speex in any kind
of conditions.In other words, you could probably see Opus as Speex 3.0 if you really
wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free
(free as in beer and free as in speech)
--sent from my mobile
On 19 Oct 2014 8:43 AM, "Philipp Schuster" <ps07@online.de> wrote:
Hi,it would be great to get the AMR codec for Jitsi and there is already a
good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due to
the high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users*-- С уважением, Олег *
mailto:oleg.bars.mail@yandex.ru <oleg.bars.mail@yandex.ru>_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users_______________________________________________
users mailing listusers@jitsi.org
Unsubscribe instructions and other list options:http://lists.jitsi.org/mailman/listinfo/users_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Доброго времени суток, Emil.
For example, my sip-provider supports ONLY G.711, G.729, Speex. My Inet Service Provider have such lines that G.711 has no connection,
G.729 is not in Jitsi, Speex-8000\16000 - the only way AND good connection (on Speex-8000).
When I'm calling to landline - on the route is ONLY G.711\G.729.
So: Jitsi(Speex)--Server(Speex)-- Middle Servers(Speex)--Landline\GSM route(G.711) - minimum one voice re-coding on the route with loss of voice quality.
Or: Jitsi(Opus)--Server(Opus)-- Middle Servers(Some Codec...)--Landline\GSM route(G.711) - In practice - multiple times re-coding, I think. Much loss of voice quality.
In my case, with my ISP and SIP Providers - Opus has poor voice, Speex - much better. Despite that Opus is really better, I agree with Emil, but only on "point-to-point" route. I think, because Middle Servers has Speex support.
When calling to landline\GSM - servers require G.711 on the route (including my sip-provider), Jitsi gives G.711 - I have no conversation. That's the case when no priority list respect. Despite that the Speex is #1 in Jitsi local list of codecs.
In this my case the only way is to eliminate G.711 from the list totally.
Вы писали 19 октября 2014 г., 20:32:06:
Emil Ivov> Hey Oleg,
Emil Ivov> Please do not remove this list from the recipients.
Sorry, I was inattentive.
Emil Ivov> More inline:
Emil Ivov> On 19.10.14, 13:18, Олег wrote:
Здравствуйте, Emil.
Speex has one big attitude - it is in native support by many SIP
servers (PBX) and has no voice re-coding/double/triple/etc... on the
voice route. Opus - has no support on routes/landlines/etc by
providers. It makes multiple voice coding/decoding/re-coding and much
loss of quality. This is the way of worse Opus usage prior to Speex.
IMHO.
Emil Ivov> Now that's a totally different argument but it still doesn't make sense
Emil Ivov> to me. If middle boxes do not support Opus then they wouldn't be able to
Emil Ivov> transcode it. They would just fall back to using other codecs.
Emil Ivov> Popular servers today support Opus already (FreeSWITCH has it natively
Emil Ivov> and Asterisk can be easily tweaked). More and more commercial platforms
Emil Ivov> are adding it.
Emil Ivov> Also not that in a number of cases, Opus support is not required in the
Emil Ivov> server at all because most large scale networks connect endpoints
Emil Ivov> directly, without transcoding at all.
By the way, is Jitsi respecting the first codec offered by
sip-server, or negotiates from the list of codecs from itself?? If
no, this negotiation should be, and should be a setting "Honor remote
codec" (if set, local codecs will be ignored and the first supported
codec from the list sent by server will be used), and "Honor local
codecs" (if set, negotiation from the local codecs by its priority
should be used, ignoring servers list of priority).
Emil Ivov> Jitsi implements the Offer/Answer negotiation model as described by RFC3264.
Emil Ivov> Emil
Вы писали 19 октября 2014 г., 12:28:30:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru
<mailto:oleg.bars.mail@yandex.ru>> wrote: Hi, Philipp.For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000. It's sometimes even better than
Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice
- Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old
and abandoned codec that hasn't seen any new development for a number
of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity
mechanisms that Opus has (like native Forward Error Correction or
Packet Loss Concealment). It can also operate on bitrates as low as
3kbps (and up to 512 kbps) and would always give you better quality
than Speex in any kind of conditions.In other words, you could probably see Opus as Speex 3.0 if you
really wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp, Have you checked our Opus support? Opus is arguably
better than AMR in every respect and it is entirely free (free as in
beer and free as in speech) --sent from my mobile On 19 Oct 2014 8:43
AM, "Philipp Schuster" <ps07@online.de <mailto:ps07@online.de>>
wrote: Hi,it would be great to get the AMR codec for Jitsi and there is already
a good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due
to the high resistence against network failures, weak networks and
high jitters and as a result good audio quality even at bad network
connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
--
С уважением,
Олег
mailto:oleg.bars.mail@yandex.by
Please, use PGP for e-mail encryption.
Пожалуйста, используйте PGP для шифрования переписки.
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use PGP for e-mail encryption, privacy and freedom! mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad 8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6 5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3 cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u 4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY BLOCK-----
Re[2]: [jitsi-users] AMR Codec for Jitsi
Hi, Emil.
By the way, is Jitsi respecting the first codec offered by sip-server, or negotiates from the list of codecs from itself??
If no, this negotiation should be, and should be a setting “Honor remote codec” (if set, local codecs will be ignored and the first supported codec from the list sent by server will be used),
and “Honor local codecs” (if set, negotiation from the local codecs by its priority should be used, ignoring servers list of priority).
Вы писали 19 октября 2014 г., 17:41:00:
Well from that perspective more is always better. Hopefully we would be able todo this in the near future.
–sent from my mobile
On 19 Oct 2014 4:31 PM, “Philipp Schuster” ps07@online.de wrote:
Thanks for all the tips!
The problem is: If you use Jitsi with a sip provider who’s offering no opus and no speex but AMR iLBC and G.711, AMR will be the better choice for weak network connections, definitively.
Sadly this is a very frequent case, for example for all the betamax company sip providers among others - they are offering great rates for international calling but only a few codecs.
For this reason it would be great to integrate AMR into Jitsi - I think it shouldn’t be a very hard task because of the already existing opencore-amr library like Linphone is using it.
What do you think?
Am 19.10.2014 um 11:28 schrieb Emil Ivov:
On Sun, Oct 19, 2014 at 10:59 AM, Олег oleg.bars.mail@yandex.ru wrote:
Hi, Philipp.
For “high resistence against network failures, weak networks and high jitters and as a result good audio quality even at bad network connections.” try Speex-8000, -16000.
It’s sometimes even better than Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice - Speex-16000 and Speex-8000 works excellent.
I don’t believe this is accurate at all.
While Speex was promising back at the time, it is today a very old and abandoned codec that hasn’t seen any new development for a number of years.
Jean-Marc Valin, the creator of Speex, is actually one of the main authors of Opus. Speex has none of the resiliency or adaptivity mechanisms that Opus has (like native Forward Error Correction or Packet Loss Concealment). It can also operate on bitrates as low as 3kbps (and up to 512 kbps) and would always give you better quality than Speex in any kind of conditions.
In other words, you could probably see Opus as Speex 3.0 if you really wanted to think in those terms.
Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp,
Have you checked our Opus support?
Opus is arguably better than AMR in every respect and it is entirely free (free as in beer and free as in speech)
–sent from my mobile
On 19 Oct 2014 8:43 AM, “Philipp Schuster” ps07@online.de wrote:
Hi,
it would be great to get the AMR codec for Jitsi and there is already a good base for such a project: http://opencore-amr.sourceforge.net/
I think it’ll be great for the most users to be able to use AMR due to the high resistence against network failures, weak networks and high jitters and as a result good audio quality even at bad network connections.
I propose it as a feature request for upcoming versions of Jitsi.
users mailing list
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
*–
С уважением,
Олег *mailto:oleg.bars.mail@yandex.ru
users mailing list
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
–
users mailing list
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
users mailing list
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
*–
С уважением,
Доброго времени суток, Emil.
For example, my sip-provider supports ONLY G.711, G.729, Speex. My Inet
Service Provider have such lines that G.711 has no connection,
G.729 is not in Jitsi,
We do support G.729, so if you have the legal option of using it, you can simply compile it on your own and use it.
Speex-8000\16000 - the only way AND good
connection (on Speex-8000).
When I'm calling to landline - on the route is ONLY G.711\G.729.
So: Jitsi(Speex)--Server(Speex)-- Middle Servers(Speex)--Landline\GSM
route(G.711) - minimum one voice re-coding on the route with loss of
voice quality.
Well any codec can be claimed "best" in circumstances where all better options have been declared unavailable. That doesn't make it generally better which was your initial statement.
The point that I made is that, in the above scenario using Opus on the first part of your call, would give you better results than any other codec. Again, as long as it is available.
Or: Jitsi(Opus)--Server(Opus)-- Middle Servers(Some
Codec...)--Landline\GSM route(G.711) - In practice - multiple times
re-coding, I think. Much loss of voice quality.
This sounds like speculation to me. If your SIP server is terminating media then transcoding in the back bone is likely to occur anyway.
If this is the case, then covering the first leg of your call with Opus gives you the best chances to deliver good quality to the server in a way that is resilient to losses and that puts in the best position to transcode.
In other words "My provider does not support Opus" is not an argument for "Speex is a better codec than Opus".
In my case, with my ISP and SIP Providers - Opus has poor voice, Speex -
much better. Despite that Opus is really better, I agree with Emil, but
only on "point-to-point" route. I think, because Middle Servers has
Speex support.
When calling to landline\GSM - servers require G.711 on the route
(including my sip-provider), Jitsi gives G.711 - I have no conversation.
That's the case when no priority list respect. Despite that the Speex is
#1 in Jitsi local list of codecs.
In this my case the only way is to eliminate G.711 from the list totally.
Why is that not good enough? Just disable that codec for the account where you don't want to use it.
Emil
On 19.10.14, 20:33, Олег Степанович Баськив wrote:
Вы писали 19 октября 2014 г., 20:32:06:
Emil Ivov> Hey Oleg,
Emil Ivov> Please do not remove this list from the recipients.
Sorry, I was inattentive.
Emil Ivov> More inline:
Emil Ivov> On 19.10.14, 13:18, Олег wrote:
Здравствуйте, Emil.
Speex has one big attitude - it is in native support by many SIP
servers (PBX) and has no voice re-coding/double/triple/etc... on the
voice route. Opus - has no support on routes/landlines/etc by
providers. It makes multiple voice coding/decoding/re-coding and much
loss of quality. This is the way of worse Opus usage prior to Speex.
IMHO.Emil Ivov> Now that's a totally different argument but it still doesn't
make sense
Emil Ivov> to me. If middle boxes do not support Opus then they wouldn't
be able to
Emil Ivov> transcode it. They would just fall back to using other codecs.Emil Ivov> Popular servers today support Opus already (FreeSWITCH has it
natively
Emil Ivov> and Asterisk can be easily tweaked). More and more commercial
platforms
Emil Ivov> are adding it.Emil Ivov> Also not that in a number of cases, Opus support is not
required in the
Emil Ivov> server at all because most large scale networks connect
endpoints
Emil Ivov> directly, without transcoding at all.By the way, is Jitsi respecting the first codec offered by
sip-server, or negotiates from the list of codecs from itself?? If
no, this negotiation should be, and should be a setting "Honor remote
codec" (if set, local codecs will be ignored and the first supported
codec from the list sent by server will be used), and "Honor local
codecs" (if set, negotiation from the local codecs by its priority
should be used, ignoring servers list of priority).Emil Ivov> Jitsi implements the Offer/Answer negotiation model as
described by RFC3264.Emil Ivov> Emil
Вы писали 19 октября 2014 г., 12:28:30:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru
<mailto:oleg.bars.mail@yandex.ru>> wrote: Hi, Philipp.For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000. It's sometimes even better than
Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice
- Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old
and abandoned codec that hasn't seen any new development for a number
of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity
mechanisms that Opus has (like native Forward Error Correction or
Packet Loss Concealment). It can also operate on bitrates as low as
3kbps (and up to 512 kbps) and would always give you better quality
than Speex in any kind of conditions.In other words, you could probably see Opus as Speex 3.0 if you
really wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp, Have you checked our Opus support? Opus is arguably
better than AMR in every respect and it is entirely free (free as in
beer and free as in speech) --sent from my mobile On 19 Oct 2014 8:43
AM, "Philipp Schuster" <ps07@online.de <mailto:ps07@online.de>>
wrote: Hi,it would be great to get the AMR codec for Jitsi and there is already
a good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due
to the high resistence against network failures, weak networks and
high jitters and as a result good audio quality even at bad network
connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
--
/С уважением,
Олег/mailto:oleg.bars.mail@yandex.by
------------------------------------------------------------------------
/Please, use PGP for e-mail encryption.
Пожалуйста, используйте PGP для шифрования переписки./-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use
PGP for e-mail encryption, privacy and freedom!
mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz
fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad
8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl
LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6
5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3
cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u
4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs
I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM
PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx
GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv
NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp
pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld
SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY
BLOCK-----
Доброго времени суток, Emil.
Everything is right. I do not say that Speex is better than Opus, I say, that in poor conditions (my case) Speex is giving better Voice Call than Opus. Practical use showed this. And practical results makes to search for better from the poor. If SIP Provider enables Opus on server - it's the best way, of course. The more servers on the route enables Opus - the better SIP calls we'll have, and Speex will be obsolete. For now - Speex is more spreaded, that's the point.
I know that G.729 is in Jitsi, but I have insufficient skills to compile Jitsi, sorry. I've tried...
And G.729 seems to be the best, but Speex-8000 showed best results than G.729... In MY case and in MY tests and MY conditions, of course! So, I left Speex-16000 and Speex-8000 for me, and rather satisfied... Waiting for provider to enable Opus on server.
Hope my information and theoretical guesses be helpful for someone.
Best regards,
Oleg
Вы писали 19 октября 2014 г., 21:57:39:
Emil Ivov> On 19.10.14, 20:33, Олег Степанович Баськив wrote:
Доброго времени суток, Emil.
For example, my sip-provider supports ONLY G.711, G.729, Speex. My Inet
Service Provider have such lines that G.711 has no connection,
G.729 is not in Jitsi,
Emil Ivov> We do support G.729, so if you have the legal option of using it, you
Emil Ivov> can simply compile it on your own and use it.
Speex-8000\16000 - the only way AND good
connection (on Speex-8000).
When I'm calling to landline - on the route is ONLY G.711\G.729.
So: Jitsi(Speex)--Server(Speex)-- Middle Servers(Speex)--Landline\GSM
route(G.711) - minimum one voice re-coding on the route with loss of
voice quality.
Emil Ivov> Well any codec can be claimed "best" in circumstances where all better
Emil Ivov> options have been declared unavailable. That doesn't make it generally
Emil Ivov> better which was your initial statement.
Emil Ivov> The point that I made is that, in the above scenario using Opus on the
Emil Ivov> first part of your call, would give you better results than any other
Emil Ivov> codec. Again, as long as it is available.
Or: Jitsi(Opus)--Server(Opus)-- Middle Servers(Some
Codec...)--Landline\GSM route(G.711) - In practice - multiple times
re-coding, I think. Much loss of voice quality.
Emil Ivov> This sounds like speculation to me. If your SIP server is terminating
Emil Ivov> media then transcoding in the back bone is likely to occur anyway.
Emil Ivov> If this is the case, then covering the first leg of your call with Opus
Emil Ivov> gives you the best chances to deliver good quality to the server in a
Emil Ivov> way that is resilient to losses and that puts in the best position to
Emil Ivov> transcode.
Emil Ivov> In other words "My provider does not support Opus" is not an argument
Emil Ivov> for "Speex is a better codec than Opus".
In my case, with my ISP and SIP Providers - Opus has poor voice, Speex -
much better. Despite that Opus is really better, I agree with Emil, but
only on "point-to-point" route. I think, because Middle Servers has
Speex support.
When calling to landline\GSM - servers require G.711 on the route
(including my sip-provider), Jitsi gives G.711 - I have no conversation.
That's the case when no priority list respect. Despite that the Speex is
#1 in Jitsi local list of codecs.
In this my case the only way is to eliminate G.711 from the list totally.
Emil Ivov> Why is that not good enough? Just disable that codec for the account
Emil Ivov> where you don't want to use it.
Emil Ivov> Emil
Вы писали 19 октября 2014 г., 20:32:06:
Emil Ivov> Hey Oleg,
Emil Ivov> Please do not remove this list from the recipients.
Sorry, I was inattentive.
Emil Ivov> More inline:
Emil Ivov> On 19.10.14, 13:18, Олег wrote:
Здравствуйте, Emil.
Speex has one big attitude - it is in native support by many SIP
servers (PBX) and has no voice re-coding/double/triple/etc... on the
voice route. Opus - has no support on routes/landlines/etc by
providers. It makes multiple voice coding/decoding/re-coding and much
loss of quality. This is the way of worse Opus usage prior to Speex.
IMHO.Emil Ivov> Now that's a totally different argument but it still doesn't
make sense
Emil Ivov> to me. If middle boxes do not support Opus then they wouldn't
be able to
Emil Ivov> transcode it. They would just fall back to using other codecs.Emil Ivov> Popular servers today support Opus already (FreeSWITCH has it
natively
Emil Ivov> and Asterisk can be easily tweaked). More and more commercial
platforms
Emil Ivov> are adding it.Emil Ivov> Also not that in a number of cases, Opus support is not
required in the
Emil Ivov> server at all because most large scale networks connect
endpoints
Emil Ivov> directly, without transcoding at all.By the way, is Jitsi respecting the first codec offered by
sip-server, or negotiates from the list of codecs from itself?? If
no, this negotiation should be, and should be a setting "Honor remote
codec" (if set, local codecs will be ignored and the first supported
codec from the list sent by server will be used), and "Honor local
codecs" (if set, negotiation from the local codecs by its priority
should be used, ignoring servers list of priority).Emil Ivov> Jitsi implements the Offer/Answer negotiation model as
described by RFC3264.Emil Ivov> Emil
Вы писали 19 октября 2014 г., 12:28:30:
On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru
<mailto:oleg.bars.mail@yandex.ru>> wrote: Hi, Philipp.For "high resistence against network failures, weak networks and high
jitters and as a result good audio quality even at bad network
connections." try Speex-8000, -16000. It's sometimes even better than
Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice
- Speex-16000 and Speex-8000 works excellent.I don't believe this is accurate at all.
While Speex was promising back at the time, it is today a very old
and abandoned codec that hasn't seen any new development for a number
of years.Jean-Marc Valin, the creator of Speex, is actually one of the main
authors of Opus. Speex has none of the resiliency or adaptivity
mechanisms that Opus has (like native Forward Error Correction or
Packet Loss Concealment). It can also operate on bitrates as low as
3kbps (and up to 512 kbps) and would always give you better quality
than Speex in any kind of conditions.In other words, you could probably see Opus as Speex 3.0 if you
really wanted to think in those terms.Emil
Вы писали 19 октября 2014 г., 10:47:54:
Hey Philipp, Have you checked our Opus support? Opus is arguably
better than AMR in every respect and it is entirely free (free as in
beer and free as in speech) --sent from my mobile On 19 Oct 2014 8:43
AM, "Philipp Schuster" <ps07@online.de <mailto:ps07@online.de>>
wrote: Hi,it would be great to get the AMR codec for Jitsi and there is already
a good base for such a project: http://opencore-amr.sourceforge.net/I think it'll be great for the most users to be able to use AMR due
to the high resistence against network failures, weak networks and
high jitters and as a result good audio quality even at bad network
connections.I propose it as a feature request for upcoming versions of Jitsi.
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
_______________________________________________ users mailing list
users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
other list options: http://lists.jitsi.org/mailman/listinfo/users/-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
--
/С уважением,
Олег/mailto:oleg.bars.mail@yandex.by
------------------------------------------------------------------------
/Please, use PGP for e-mail encryption.
Пожалуйста, используйте PGP для шифрования переписки./-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use
PGP for e-mail encryption, privacy and freedom!
mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz
fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad
8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl
LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6
5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3
cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u
4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs
I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM
PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx
GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv
NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp
pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld
SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY
BLOCK-----
--
С уважением,
Олег
mailto:oleg.bars.mail@yandex.by
Please, use PGP for e-mail encryption.
Пожалуйста, используйте PGP для шифрования переписки.
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use PGP for e-mail encryption, privacy and freedom! mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad 8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6 5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3 cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u 4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY BLOCK-----
Okay, let's sum that up:
We've started with the feature request for AMR. Now we've discussed about the advantages of opus over speex and some special cases.
All in all my opionion about that is that it's great if all the sip providers are including better and better codecs in their systems but as a conclusion we should remember: What we can influence is not which codec is provided by the sip provider, but we can influence which codecs are integrated in the open source software we're using.
From the point of view of the developers I think it's like Emil said "more is always better". If your software supports more codecs, you've got better compatability to different providers and you can try which one works well for your special case. Therefore I hope we can come to the arrangement that it's a good idea to integrate AMR into Jitsi if it's possible to do it with not too much work time based on the opencore-amr for example. It is good that there are several codecs out there, every codec has it sense and you can't force the providers to use the newest and best available codecs.
That's all I liked to say with my initial post - I'm sure there are and there will be codecs with better performance in other cases but for general compatibility and the improvement of voice quality for specific situations it is simple the best to have more than less codecs integrated. If you don't need them simply deactivate them.
For this reason: I think AMR codec would be a nice feature.
Regards,
Philipp
Am 19.10.2014 um 21:30 schrieb Олег:
Re[2]: [jitsi-users] AMR Codec for Jitsi Доброго времени суток, Emil.
Everything is right. I do not say that Speex is better than Opus, I say, that in poor conditions (my case) Speex is giving better Voice Call than Opus. Practical use showed this. And practical results makes to search for better from the poor. If SIP Provider enables Opus on server - it's the best way, of course. The more servers on the route enables Opus - the better SIP calls we'll have, and Speex will be obsolete. For now - Speex is more spreaded, that's the point.
I know that G.729 is in Jitsi, but I have insufficientskills to compile Jitsi, sorry. I've tried...
And G.729 seems to be the best, but Speex-8000 showed best results than G.729... In MY case and in MY tests and MY conditions, of course! So, I left Speex-16000 and Speex-8000 for me, and rather satisfied... Waiting for provider to enable Opus on server.
Hope my information and theoretical guesses be helpful for someone.Best regards,
OlegВы писали 19 октября 2014 г., 21:57:39:
Emil Ivov> On 19.10.14, 20:33, Олег Степанович Баськив wrote:
>> Доброго времени суток, Emil.
>>
>> For example, my sip-provider supports ONLY G.711, G.729, Speex. My Inet
>> Service Provider have such lines that G.711 has no connection,
>> G.729 is not in Jitsi,Emil Ivov> We do support G.729, so if you have the legal option of using it, you
Emil Ivov> can simply compile it on your own and use it.>> Speex-8000\16000 - the only way AND good
>> connection (on Speex-8000).
>> When I'm calling to landline - on the route is ONLY G.711\G.729.
>> So: Jitsi(Speex)--Server(Speex)-- Middle Servers(Speex)--Landline\GSM
>> route(G.711) - minimum one voice re-coding on the route with loss of
>> voice quality.Emil Ivov> Well any codec can be claimed "best" in circumstances where all better
Emil Ivov> options have been declared unavailable. That doesn't make it generally
Emil Ivov> better which was your initial statement.Emil Ivov> The point that I made is that, in the above scenario using Opus on the
Emil Ivov> first part of your call, would give you better results than any other
Emil Ivov> codec. Again, as long as it is available.>> Or: Jitsi(Opus)--Server(Opus)-- Middle Servers(Some
>> Codec...)--Landline\GSM route(G.711) - In practice - multiple times
>> re-coding, I think. Much loss of voice quality.Emil Ivov> This sounds like speculation to me. If your SIP server is terminating
Emil Ivov> media then transcoding in the back bone is likely to occur anyway.Emil Ivov> If this is the case, then covering the first leg of your call with Opus
Emil Ivov> gives you the best chances to deliver good quality to the server in a
Emil Ivov> way that is resilient to losses and that puts in the best position to
Emil Ivov> transcode.Emil Ivov> In other words "My provider does not support Opus" is not an argument
Emil Ivov> for "Speex is a better codec than Opus".>> In my case, with my ISP and SIP Providers - Opus has poor voice, Speex -
>> much better. Despite that Opus is really better, I agree with Emil, but
>> only on "point-to-point" route. I think, because Middle Servers has
>> Speex support.
>> When calling to landline\GSM - servers require G.711 on the route
>> (including my sip-provider), Jitsi gives G.711 - I have no conversation.
>> That's the case when no priority list respect. Despite that the Speex is
>> #1 in Jitsi local list of codecs.
>> In this my case the only way is to eliminate G.711 from the list totally.Emil Ivov> Why is that not good enough? Just disable that codec for the account
Emil Ivov> where you don't want to use it.Emil Ivov> Emil
>> Вы писали 19 октября 2014 г., 20:32:06:
>>
>> Emil Ivov> Hey Oleg,
>>
>> Emil Ivov> Please do not remove this list from the recipients.
>>
>> Sorry, I was inattentive.
>>
>> Emil Ivov> More inline:
>>
>> Emil Ivov> On 19.10.14, 13:18, Олег wrote:
>>>> Здравствуйте, Emil.
>>>>
>>>> Speex has one big attitude - it is in native support by many SIP
>>>> servers (PBX) and has no voice re-coding/double/triple/etc... on the
>>>> voice route. Opus - has no support on routes/landlines/etc by
>>>> providers. It makes multiple voice coding/decoding/re-coding and much
>>>> loss of quality. This is the way of worse Opus usage prior to Speex.
>>>> IMHO.
>>
>> Emil Ivov> Now that's a totally different argument but it still doesn't
>> make sense
>> Emil Ivov> to me. If middle boxes do not support Opus then they wouldn't
>> be able to
>> Emil Ivov> transcode it. They would just fall back to using other codecs.
>>
>> Emil Ivov> Popular servers today support Opus already (FreeSWITCH has it
>> natively
>> Emil Ivov> and Asterisk can be easily tweaked). More and more commercial
>> platforms
>> Emil Ivov> are adding it.
>>
>> Emil Ivov> Also not that in a number of cases, Opus support is not
>> required in the
>> Emil Ivov> server at all because most large scale networks connect
>> endpoints
>> Emil Ivov> directly, without transcoding at all.
>>
>>>> By the way, is Jitsi respecting the first codec offered by
>>>> sip-server, or negotiates from the list of codecs from itself?? If
>>>> no, this negotiation should be, and should be a setting "Honor remote
>>>> codec" (if set, local codecs will be ignored and the first supported
>>>> codec from the list sent by server will be used), and "Honor local
>>>> codecs" (if set, negotiation from the local codecs by its priority
>>>> should be used, ignoring servers list of priority).
>>
>> Emil Ivov> Jitsi implements the Offer/Answer negotiation model as
>> described by RFC3264.
>>
>> Emil Ivov> Emil
>>
>>>> Вы писали 19 октября 2014 г., 12:28:30:
>>>>
>>>> On Sun, Oct 19, 2014 at 10:59 AM, Олег <oleg.bars.mail@yandex.ru
>>>> <mailto:oleg.bars.mail@yandex.ru>> wrote: Hi, Philipp.
>>>>
>>>> For "high resistence against network failures, weak networks and high
>>>> jitters and as a result good audio quality even at bad network
>>>> connections." try Speex-8000, -16000. It's sometimes even better than
>>>> Opus on poor 3G or ISP lines. In my case - when Opus is glitchy-voice
>>>> - Speex-16000 and Speex-8000 works excellent.
>>>>
>>>> I don't believe this is accurate at all.
>>>>
>>>> While Speex was promising back at the time, it is today a very old
>>>> and abandoned codec that hasn't seen any new development for a number
>>>> of years.
>>>>
>>>> Jean-Marc Valin, the creator of Speex, is actually one of the main
>>>> authors of Opus. Speex has none of the resiliency or adaptivity
>>>> mechanisms that Opus has (like native Forward Error Correction or
>>>> Packet Loss Concealment). It can also operate on bitrates as low as
>>>> 3kbps (and up to 512 kbps) and would always give you better quality
>>>> than Speex in any kind of conditions.
>>>>
>>>> In other words, you could probably see Opus as Speex 3.0 if you
>>>> really wanted to think in those terms.
>>>>
>>>> Emil
>>>>
>>>> Вы писали 19 октября 2014 г., 10:47:54:
>>>>
>>>> Hey Philipp, Have you checked our Opus support? Opus is arguably
>>>> better than AMR in every respect and it is entirely free (free as in
>>>> beer and free as in speech) --sent from my mobile On 19 Oct 2014 8:43
>>>> AM, "Philipp Schuster" <ps07@online.de <mailto:ps07@online.de>>
>>>> wrote: Hi,
>>>>
>>>> it would be great to get the AMR codec for Jitsi and there is already
>>>> a good base for such a project: http://opencore-amr.sourceforge.net/
>>>>
>>>> I think it'll be great for the most users to be able to use AMR due
>>>> to the high resistence against network failures, weak networks and
>>>> high jitters and as a result good audio quality even at bad network
>>>> connections.
>>>>
>>>> I propose it as a feature request for upcoming versions of Jitsi.
>>>>
>>>> _______________________________________________ users mailing list
>>>> users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
>>>> other list options: http://lists.jitsi.org/mailman/listinfo/users
>>>>
>>>> /-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
>>>>
>>>> _______________________________________________ users mailing list
>>>> users@jitsi.org <mailto:users@jitsi.org> Unsubscribe instructions and
>>>> other list options: http://lists.jitsi.org/mailman/listinfo/users
>>>>
>>>> -- https://jitsi.org
>>>>
>>>> /-- С уважением, Олег /mailto:oleg.bars.mail@yandex.ru
>>
>> --
>> /С уважением,
>> Олег
>>
>> /mailto:oleg.bars.mail@yandex.by
>> ------------------------------------------------------------------------
>> /Please, use PGP for e-mail encryption.
>> Пожалуйста, используйте PGP для шифрования переписки.
>>
>> /-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use
>> PGP for e-mail encryption, privacy and freedom!
>> mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz
>> fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad
>> 8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl
>> LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6
>> 5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3
>> cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u
>> 4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs
>> I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM
>> PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx
>> GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv
>> NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp
>> pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld
>> SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY
>> BLOCK-------
/С уважением,
Олег/mailto:oleg.bars.mail@yandex.by
------------------------------------------------------------------------
/Please, use PGP for e-mail encryption.
Пожалуйста, используйте PGP для шифрования переписки./-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 Comment: Please, use PGP for e-mail encryption, privacy and freedom! mQEPA1J8wewBbgEIAM9NbLyz64ZbyJ7ulz9/kroKeKiVFvnon2M6RHxhVyYbOYJz fjDaR3ArmepUnQLzbsE1RBMzc2vyY4MijR9CO7MNQDzz3IDWPPyIY1vLPNybMlad 8c0HP1Npf4f/NohrGnzyjBxjzCATIVzIeybhkGmGMPboi09G7ro+8XImP5Q1RZpl LxcMldcR/yKmDhY41OHeMnRH/EdtbgN2SKQsUW/18Tt02wbobTeXV+0mHCKHzXN6 5mQAIUFPBsEAVIAfbQXHeID+/i+FNgoD2aBWqbgy4vfZXaty2lp6a1HmSh/SZ/I3 cL6dVZdNmrMKb7djuWCFGJF464dYI2pr2PUhCcMAEQEAAbQyzuvl4yDR8uXv4O3u 4uj3IMHg8fzq6OIgPG9sZWcuYmFycy5tYWlsQHlhbmRleC5ydT6JARUDBRBSfMHs I2pr2PUhCcMBAcyLB/9QwihqaTspKWRlHAI+ASYBWNeKXS/YmCxXFsdHl1WDYTAM PhFD15sa7o7fc6tQTBfLywyOEQVZ5yb2r43ugq4er+HOP+3abkIZExKnU3c8I9kx GjrFReVLMl8vVHJIwVmPnF3xrWqV+CJwl8qFcIoUh5/UYQYNZSqdOdGU/Y9wzmxv NSm/k9MvH+CYuTth8BqZxSe9SicsC/rpgqLVUMEKxIeDBjt1g4D1KdQXQi6Jd1Dp pL4ECQUeI4z7HR53Tq0miZdPAbtQmwR864a8iXELfKaXCO96nDJIDVOt5Rxb1yld SAdsTwj3ooMkDd2RQRvr6b3B0O/Lj7I9tmPpGwoB =Lxf3 -----END PGP PUBLIC KEY BLOCK-----
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users