Hello.

Welcome to continue the discussion initiated in .

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

<http://sites.google.com/site/fiensprototyping/home>

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

De : de la part de Graeme Geldenhuys
Envoyé : vendredi 3 février 2017 10:17
À :
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

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..

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..

De : de la part de Lars
Envoyé : samedi 4 février 2017 11:53
À : Other FPC related discussions
Objet : Re: [fpc-other] fpc and voip.

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

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-endiannative-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

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

Fred van Stappen wrote

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

________________________________
De : de la part de José Mejuto
Envoyé : mercredi 8 février 2017 14:55
À :
Objet : Re: [fpc-other] fpc and voip.

Fred van Stappen wrote

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

e : de la part de Fred van Stappen
Envoyé : mercredi 8 février 2017 19:11
À : Other FPC related discussions
Objet : Re: [fpc-other] fpc and voip.

________________________________
De : de la part de José Mejuto
Envoyé : mercredi 8 février 2017 14:55
À :
Objet : Re: [fpc-other] fpc and voip.

Fred van Stappen wrote

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

Fred van Stappen wrote

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.

Fred van Stappen wrote

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 <https://en.wikipedia.org/wiki/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.

Hello Jose.

... and there is also a fpc-icecast package.

No it seems that IceCast is a executable and there are no fpc-package.

Streaming protocols are usually hard to understand.

Huh, yes indeed. I will try to make it work. But maybe a guru will have more chance than I.

Many thanks Jose for your precious infos.

Fre;D

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

Hello everybody.

OK, all is in the pocket ;-)

The fpc shout Pascal header works like charm:

https://github.com/fredvs/uos/blob/master/src/uos_shout.pas

<https://github.com/fredvs/uos/blob/master/src/uos_shout.pas>I will clean everything in code and create something easier in fpc for IceCast installation and run.

For uos, uos_AddIntoIceServer() will be added + examples of web-radio and voip.

Many thanks to support me.

Fre;D