Re: [fpc-other] M$ has bought GitHub

[José Mejuto]

El 05/06/2018 a las 20:24, Graeme Geldenhuys escribió:


I've had plans to move many of my projects off SourceForge to GitHub


Hello,

Try GitLab...

--

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

Re: [fpc-other] Your thoughts on cloud based server instances?

[José Mejuto]

El 12/03/2017 a las 19:06, Graeme Geldenhuys escribió:

On 2017-03-11 17:13, José Mejuto wrote:

IPv6 in most ISPs will continue to be dynamic :-/ which have its
advantages and problems.


With my ISP (Sky Broadband in the UK), they allocate a huge amount of
IPv6 addresses to each Sky Fibre customers. These addresses don't change
as far as I know - unlike the IPv4 ones.



Hello,

Taken from helpforum.sky.com:

"... however do note that Sky's IPv6 allocation to you is dynamic, so 
this may change over time."



--

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

Re: [fpc-other] Your thoughts on cloud based server instances?

[José Mejuto]

El 10/03/2017 a las 18:05, Graeme Geldenhuys escribió:


Brilliant idea, thanks for suggesting it. I see my router has a few such
entries like DynDNS.org etc. I'll research this a bit more over the
weekend, and yes it will save me a lot of time (not having to
reconfigure servers from scratch).



Hello,

I'm running a mini VPS (19€/year) where I host minimal services and one 
of them is my own DynIP system (not fully configured right now, 
currently still using No-IP), because free No-IP forces me to "verify" 
still running each month following a link sent by mail.


--

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

[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

[fpc-other] Bugtracker spammer

[José Mejuto]

Hello,

Or this curtains are fpc/lazarus based or we have a spammer in the 
bugtracker:


http://bugs.freepascal.org/view_user_page.php?id=5040

http://bugs.freepascal.org/view.php?id=31022#c96341

--

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