[fpc-other] fpc and voip.

[Fred van Stappen]

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



________________________________
De : fpc-other-bounces at lists.freepascal.org <fpc-other-bounces at lists.freepascal.org> de la part de José Mejuto <joshyfun at gmail.com>
Envoyé : mercredi 8 février 2017 14:55
À : fpc-other at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-other/attachments/20170208/379bd4f4/attachment.html>