Re: [fpc-other] fpc and voip.

[Fred van Stappen]

>> I see IceCast that is from the same developer Xiph.Org Foundation
>>  than Opus codec and

>> there is also a fpc-icecast package.

> Starting with an iceCast server is a good starting point to understand
> the background. I think fpc-icecast package is a server control package,
> so you can control an iceCast server.

Hello fpc-voip fans.

Ok, IceCast is ok to be the main audio-streaming-server.

Now, for sending data to IceCast there is:

IceS: It is a executable that can sent data from local opus-ogg files or the 
sdtin input sent to the sound-card.
Nice but... I loose control, I can not choose what to give to the server, it is 
all what goes out of the soundcard or nothing...

A other solution is to use libshout:
https://github.com/xiph/Icecast-libshout

I have already translated the shout.h header into fpc Pascal. It works.
I am busy to annoy libshout forum to have some demo how to use their library 
(aargh, sad to not give demos when you create a project).

PS: Of course if there are some libshout or IceCast gurus around here, your 
advices are welcome.

Fre;D



___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[José Mejuto]

El 08/02/2017 a las 19:33, Fred van Stappen escribió:


Maybe a solution would be to use some existing streaming engine before
to reinvent the hot-water ?


Hello,

Yes for sure. Some things will be out of your control but in the end you 
will gain compatibility. The background idea of all streaming protocols 
is the same, is the API that changes and the know-how.



I see IceCast that is from the same developer Xiph.Org Foundation
 than Opus codec and
there is also a fpc-icecast package.


Starting with an iceCast server is a good starting point to understand 
the background. I think fpc-icecast package is a server control package, 
so you can control an iceCast server.



But of course, your advice about existing streaming engines will be
extremely appreciated.


Streaming protocols are usually hard to understand and real use 
conditions are very different that the lab ones.


--

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[José Mejuto]

El 08/02/2017 a las 19:11, Fred van Stappen escribió:


Huh, last question, do you think that fpc has the tools to do
web-server-streaming ?



Hello,

Yes, sure, in the end everything is socket based. Maybe you will need 
something a bit more advanced than fpc's httpserver as I had never used it.



--

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

e : fpc-other-boun...@lists.freepascal.org 
<fpc-other-boun...@lists.freepascal.org> de la part de Fred van Stappen 
<fi...@hotmail.com>
Envoyé : mercredi 8 février 2017 19:11
À : Other FPC related discussions
Objet : Re: [fpc-other] fpc and voip.



________
De : fpc-other-boun...@lists.freepascal.org 
<fpc-other-boun...@lists.freepascal.org> de la part de José Mejuto 
<joshy...@gmail.com>
Envoyé : mercredi 8 février 2017 14:55
À : fpc-other@lists.freepascal.org
Objet : Re: [fpc-other] fpc and voip.

El 08/02/2017 a las 14:25, Fred van Stappen escribió:

> My knowledge in web-server things are too poor to attack the
> streaming-server part of voip.
>

Hello,

Streaming is different (when well done) than simple http file send. To
send audio as a regular http transfer the web engine must provide an API
(callback or alike) call in which you can return a data block, the last
encoded audio chunk, or finish the transfer.

For a simple job, you just need a thread that is constantly encoding the
audio input and buffering the encoded audio in a queue. This buffer is
not unlimited, usually from 1 to 60 seconds. Once you receive an http
request for data (the http engine callback) you start to send from the
beginning of the audio queue and take note of client identifier (maybe
only the port is needed) and the amount of data sent, not all buffer,
you must send small chunks, probably less than 32K. Once you receive
another callback request you take the identifier and with it you start
to sending data from queue beginning + already sent size. Of course the
queue beginning, at byte zero, has an absolute counter which is
incremented since the start of compression. If client new position, once
calculated, if located before the queue start the client is slow than
encoding speed so you decide, drop connection or restart to send from
zero offset in the queue, the client will try to resync probably with
some audio artifacts.

This job involves several threads and careful synchronization, it is not
a trivial task. The base job can be tested with files, so you not need
to be really coding audio.

A "good" streaming service is usually coding audio in several queues and
qualities, start to send in medium quality and jump from queue to queue
in function of the client bandwidth. In this case you can not use the
absolute byte position in the stream, but frame compressed position, or
time position but the choose is encoder dependent. Also in the streaming
engine you must fully understand how frames are encoded in the stream
and the engine must send only complete frames (logically encoded frames,
usually a bunch of audio samples) because the quality change can only be
performed at frames boundaries for the codecs that support it, old ones
like mp3 does not support arbitrary quality change, nor at frame
boundaries (without an audible bleeepssseees).

To better understand the caveats take a look to this wikipedia pages:

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol


https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol


And a list of common streaming engines.

https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems#Protocol_support


--

___


Hello Jose.

Ooops, that is more than some explanations, it is all what I need to understand 
and become the king of audio-streaming.

Many, many thanks.

Write you (much) later when all is in the head.

Huh, last question, do you think that fpc has the tools to do 
web-server-streaming ?

Fre;D

___

Re-hello Jose.

> Write you (much) later when all is in the head.

Sorry, I am already there. ;-)

Maybe a solution would be to use some existing streaming engine before to 
reinvent the hot-water ?

I see IceCast that is from the same developer Xiph.Org 
Foundation<https://en.wikipedia.org/wiki/Xiph.Org_Foundation> than Opus codec 
and there is also a fpc-icecast package.

But of course, your advice about existing streaming engines will be extremely 
appreciated.

Fre;D

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

De : fpc-other-boun...@lists.freepascal.org 
<fpc-other-boun...@lists.freepascal.org> de la part de José Mejuto 
<joshy...@gmail.com>
Envoyé : mercredi 8 février 2017 14:55
À : fpc-other@lists.freepascal.org
Objet : Re: [fpc-other] fpc and voip.

El 08/02/2017 a las 14:25, Fred van Stappen escribió:

> My knowledge in web-server things are too poor to attack the
> streaming-server part of voip.
>

Hello,

Streaming is different (when well done) than simple http file send. To
send audio as a regular http transfer the web engine must provide an API
(callback or alike) call in which you can return a data block, the last
encoded audio chunk, or finish the transfer.

For a simple job, you just need a thread that is constantly encoding the
audio input and buffering the encoded audio in a queue. This buffer is
not unlimited, usually from 1 to 60 seconds. Once you receive an http
request for data (the http engine callback) you start to send from the
beginning of the audio queue and take note of client identifier (maybe
only the port is needed) and the amount of data sent, not all buffer,
you must send small chunks, probably less than 32K. Once you receive
another callback request you take the identifier and with it you start
to sending data from queue beginning + already sent size. Of course the
queue beginning, at byte zero, has an absolute counter which is
incremented since the start of compression. If client new position, once
calculated, if located before the queue start the client is slow than
encoding speed so you decide, drop connection or restart to send from
zero offset in the queue, the client will try to resync probably with
some audio artifacts.

This job involves several threads and careful synchronization, it is not
a trivial task. The base job can be tested with files, so you not need
to be really coding audio.

A "good" streaming service is usually coding audio in several queues and
qualities, start to send in medium quality and jump from queue to queue
in function of the client bandwidth. In this case you can not use the
absolute byte position in the stream, but frame compressed position, or
time position but the choose is encoder dependent. Also in the streaming
engine you must fully understand how frames are encoded in the stream
and the engine must send only complete frames (logically encoded frames,
usually a bunch of audio samples) because the quality change can only be
performed at frames boundaries for the codecs that support it, old ones
like mp3 does not support arbitrary quality change, nor at frame
boundaries (without an audible bleeepssseees).

To better understand the caveats take a look to this wikipedia pages:

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol
Real-time Transport Protocol - 
Wikipedia<https://en.wikipedia.org/wiki/Real-time_Transport_Protocol>
en.wikipedia.org
The Real-time Transport Protocol (RTP) is a network protocol for delivering 
audio and video over IP networks. RTP is used extensively in communication and 
...




https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
Real Time Streaming Protocol - 
Wikipedia<https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol>
en.wikipedia.org
The Real Time Streaming Protocol (RTSP) is a network control protocol designed 
for use in entertainment and communications systems to control streaming media 
servers.




And a list of common streaming engines.

https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems#Protocol_support


--

___


Hello Jose.

Ooops, that is more than some explanations, it is all what I need to understand 
and become the king of audio-streaming.

Many, many thanks.

Write you (much) later when all is in the head.

Huh, last question, do you think that fpc has the tools to do 
web-server-streaming ?

Fre;D


___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[José Mejuto]

El 08/02/2017 a las 14:25, Fred van Stappen escribió:


My knowledge in web-server things are too poor to attack the
streaming-server part of voip.



Hello,

Streaming is different (when well done) than simple http file send. To 
send audio as a regular http transfer the web engine must provide an API 
(callback or alike) call in which you can return a data block, the last 
encoded audio chunk, or finish the transfer.


For a simple job, you just need a thread that is constantly encoding the 
audio input and buffering the encoded audio in a queue. This buffer is 
not unlimited, usually from 1 to 60 seconds. Once you receive an http 
request for data (the http engine callback) you start to send from the 
beginning of the audio queue and take note of client identifier (maybe 
only the port is needed) and the amount of data sent, not all buffer, 
you must send small chunks, probably less than 32K. Once you receive 
another callback request you take the identifier and with it you start 
to sending data from queue beginning + already sent size. Of course the 
queue beginning, at byte zero, has an absolute counter which is 
incremented since the start of compression. If client new position, once 
calculated, if located before the queue start the client is slow than 
encoding speed so you decide, drop connection or restart to send from 
zero offset in the queue, the client will try to resync probably with 
some audio artifacts.


This job involves several threads and careful synchronization, it is not 
a trivial task. The base job can be tested with files, so you not need 
to be really coding audio.


A "good" streaming service is usually coding audio in several queues and 
qualities, start to send in medium quality and jump from queue to queue 
in function of the client bandwidth. In this case you can not use the 
absolute byte position in the stream, but frame compressed position, or 
time position but the choose is encoder dependent. Also in the streaming 
engine you must fully understand how frames are encoded in the stream 
and the engine must send only complete frames (logically encoded frames, 
usually a bunch of audio samples) because the quality change can only be 
performed at frames boundaries for the codecs that support it, old ones 
like mp3 does not support arbitrary quality change, nor at frame 
boundaries (without an audible bleeepssseees).


To better understand the caveats take a look to this wikipedia pages:

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol

And a list of common streaming engines.

https://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems#Protocol_support

--

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

Hello.

Here updated demo of translated opus_trivial_example.c into pacal:

https://sites.google.com/site/fredvsbinaries/opus_demo.tar.xz

This demo uses opus_encoder_ctl (that was not implemented in previous version).
The program shows how to use the encoder of opus.

For playing-decoding opus files in streaming, please take a look at 
SimpleWebPlayer demos in uos.

https://github.com/fredvs/uos

Voila, it is all I can do.

My knowledge in web-server things are too poor to attack the streaming-server 
part of voip.

I will stop to annoy you with voip.

Thanks.

Fre;D

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

Hello.

Here demo of opus encoder.
It is the translation in fpc of opus_trivial_example.c

https://sites.google.com/site/fredvsbinaries/opus_demo.tar.xz

It opens a pcm buffer, encodes it, does some dsp (convert 
little-endian<>native-endian) and saves the decoded pcm to file.

Opus libraries for Linux64 + Windows32 included. Only compile and test it.

So all is ready for web-server-streaming.

Only something like a THttpPutBufferonServer is missing to make it live (save 
the decoded pcm-packet to server)...


Fre;D
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

De : fpc-other-boun...@lists.freepascal.org 
<fpc-other-boun...@lists.freepascal.org> de la part de Lars <nore...@z505.com>
Envoyé : samedi 4 février 2017 11:53
À : Other FPC related discussions
Objet : Re: [fpc-other] fpc and voip.

On Thu, February 2, 2017 4:09 pm, Fred van Stappen wrote:

>
> Hum, what did we say?
>
>
>
> Ha yes, about the sample rate of Opus codec: 48k that is used by mainly
> all converter by default.
>

Will there be consumer products that can play Opus files?

Major use for MP3 I have is existing consumer products can play them...

my mp3 usb sticks.

Any Opus usb sticks ?? Sorry, I should just google it..
___

Hello.

Sure that Opus is the future.

In their doc, they say that:

Opus is standardized by the Internet Engineering Task Force (IETF) as RFC 
6716<http://tools.ietf.org/html/rfc6716> which incorporated technology from 
Skype's SILK codec and Xiph.Org's CELT codec.

Some tenor audio-player can use it (vlc for example).

 > Any Opus usb sticks ??

Sorry but I do not understand...
Do you mean if it exists usb sticks full of Opus audio-files ?

Fre;D
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Lars]

On Fri, February 3, 2017 2:17 am, Graeme Geldenhuys wrote:
> Hi Fred,
>
>
> I didn't follow the whole discussion... So what is Opus? A new open
> source alternative to MP3, OGG etc?  How long has it been around, or is it
> very new (possibly untested [by the masses] technology).
>
> Regards,
> Graeme
>
>

Well, hopefully based on the movie Mr. Holland's Opus..

But that's completely irrelevant as I don't think a deaf baby and a school
music project lead to a software project... Could be, Could be..
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Fred van Stappen]

De : fpc-other-boun...@lists.freepascal.org 
<fpc-other-boun...@lists.freepascal.org> de la part de Graeme Geldenhuys 
<mailingli...@geldenhuys.co.uk>
Envoyé : vendredi 3 février 2017 10:17
À : fpc-other@lists.freepascal.org
Objet : Re: [fpc-other] fpc and voip.

Hi Fred,

I didn't follow the whole discussion... So what is Opus? A new open
source alternative to MP3, OGG etc?  How long has it been around, or is
it very new (possibly untested [by the masses] technology).

Regards,
  Graeme

_-

Hello Graeme.

Opus is a audio codec open source that is a alternative to mp3 and wav.
It is also perfect for voip because it has a special compression for voice.

At encoding you may choose for voice or music compression.

Opus is very new, the first release was in 2012.

https://en.wikipedia.org/wiki/Opus_(audio_format)

> possibly untested [by the masses] technology

Huh, it is absolutely possible. The extremely rare (in fact nothing) demos or 
examples prove it.
I am like you, before that Jose suggest Opus as much better alternative for mp3 
to do voip, I did not knew Opus.

Fre;D



___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] fpc and voip.

[Graeme Geldenhuys]

Hi Fred,

I didn't follow the whole discussion... So what is Opus? A new open
source alternative to MP3, OGG etc?  How long has it been around, or is
it very new (possibly untested [by the masses] technology).

Regards,
  Graeme

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[fpc-other] fpc and voip.

[Fred van Stappen]

Hello.


Welcome to continue the discussion initiated in 
f...@lists.freepascal.org.


Hum, what did we say?


Ha yes, about the sample rate of Opus codec: 48k that is used by mainly all 
converter by default.

But yes, Opus can deal with rate of 8000, 12000, 16000, 24000, or 48000.

.

Also, what fpc tools/units do I need to do internet server-streaming?


I noted that with Opus, unlike other codec, a initial buffer must be given for 
open a new Opus-thread.

This for op_memory_open and op_callback_open.

My first idea was to have the beginning of a opus-file with the opus-head on 
the server.

This file will be used to fill the initial buffer.

And on a other file, the encoded data as packets.


But sure there is better ways.


Fre;D





Fre;D


___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other