Installing NVENC SDK and CUDA SDK on Ubuntu 14.04

After I set up my streaming server, there are some problems brought by the design. Using CPU to process the streams will consume lots of CPU cycles and if the streaming server have lots of connections, resource to handle them will run low if the machine itself does not have strong CPUs. NVIDIA’s NVENC is a way of offload the transcoding to GPUs that is dedicated to such processing and leaves much more CPU cycles for other purposes. However, installing NVIDIA’s driver is a nightmare, which is why I decided to write it down for future reference.

Then the below installs NVENC SDK’s header into your system.

You can then now compile programs that uses NVIDIA’s NVENC to speed up video processing, including ffmpeg.

Setting Up Adaptive Streaming with Nginx

Recently, I’m working out a system to smoothly stream live events for an organization. That is pretty new to me and, after a bunch of research, found that Nginx with the RTMP module seems to be a good choice. There are many difficulties when setting all this up and after several days of testing, I found a good setting that is worth a post.

Setup Nginx and RTMP module

First, let’s get Nginx set up. In order to use the RTMP module, we need to compile that as an Nginx module. It would look something like this:

After all things are done, check whether nginx is compiled properly.

Capture

If you can see that Nginx RTMP is included, you can go to the next step. Before we proceed to configuring Nginx for live streaming, we should confirm what kind of resolution we should provide for live streams and how much hardware power you have.

Prerequisites

For converting live streams into several streams for adaptive streaming, you need to make sure your server have enough CPU for such workload. Otherwise, the live stream will suffer from continuous delays and/or server becomes unresponsive. I have spawn some EC2 c3.large and c3.xlarge instances, test with them and I found out their optimized CPU can handle such workload with ease. Something that also worth mention is about the I/O limits of the disks. If possible, store the HLS fragments generated to an high-speed SSD helps maintain smooth streaming experiences.

ec2CPU Usage when using an EC2 c3.xlarge instance.

Then, you also need to think about what kind of resolutions you will be offering for adaptive streaming. Generally about 4-5 variants are good enough to provide great loading speeds for different network speeds and devices. Here’s my recommended list of variants used for live streaming:

  1. 240p Low Definition stream at 288kbps
  2. 480p Standard Definition stream at 448kbps
  3. 540p Standard Definition stream at 1152kbps
  4. 720p High Definition stream at 2048kbps
  5. Source resolution, source bitrate

Configuring nginx for live streaming

Here is my own nginx.conf with comments that you can have references on.

Then, configure your live encoder to use these settings to stream into the server:
  • RTMP Endpoint: rtmp://yourserver/live/
  • RTMP Stream Name: [Whatever name you like]
Finally, configure your player for live playback. The HLS URL would look like this:
http://yourserver/hls/[The stream name above].m3u8

Recommended encoder settings for live events

If you can adjust the encoder, the following settings can help to gain better experiences.

  • Full HD Resolution (1920×1080) is recommended
  • H.264 Main profile, with target bitrate of 4000Kbps, maximum 6000Kbps
  • 25fps, 2 second keyframe interval
  • AAC audio at 128Kbps, 44.1kHz sample rate

And that’s all! I hope you can enjoy doing live events with these techniques.

Windows XP ends service at today

I think everyone know the news that Microsoft is ending support for Windows XP at today. Despite the fact that the system itself is old and difficult to maintain, it is Microsoft’s best seller in the history. Since 2001, it sold more than 500 million copies around the globe.

image

Source: http://www.acuitytraining.co.uk/news/microsoft-windows-xp-infographic/

Auto updates is out with WordPress 3.7!

You know, almost 20% of all websites are created with WordPress. Many of them have security risks as their version of WordPress is not updated and old versions usually will have lots of vulnerabilities and make them easy to be hacked in. Cases of WordPress sites getting hacked is getting more serious today.

Finally, in the WordPress 3.7 update, it introduces a new feature that is quite attractive to me and solve the problem of using old versions of the WordPress core. Now, the WordPress system will check for core updates, plugins updates and themes updates & automatically install them when they have new versions.

For me, this feature has a great potential that I don’t need to check and install updates as often as what I’ve done in this blog. Also for blogs & sites that don’t need to update so often, this feature reduces the work to keep up the site.

However, as I tried, I can’t see any controls to fine tune the behaviour of this great auto update feature as some people may not want auto updates or they want to control how it should behave.

Overall, I’ve waited this feature to be available in WordPress for a long time and it has come true!

My own Text-To-Speech (TTS) Service!

Update: Multi-language support added.

I’m now release my own Text-To-Speech Service made with node.js. I think an easy-to-use TTS service is necessary for web applications nowadays. However, creating your own one isn’t easy. So I created one based on eSpeak and hosted an API for you to use easily.

The API is fairly simple. Just issue a HTTP GET or HTTP POST request to the address below (https protocol also supported):

And it’ll return a wave file representing the result. Here’s some parameters you need to provide with the request.

  1. text – The text to read. (required)
  2. speed – The speed of reading. (optional) Default: 180 (Range 10-300)
  3. pitch – The pitch of reading. (optional) Default: 50 (Range 0-100)
  4. wordgap – The addtional time delay between each word. (optional) Default: 0
  5. lang – The language of the text. (optional) Default: en/en  See all language options below.

Here’s an example of using the API through HTTP GET requests:

Supported languages:

  1. ca (Catalan)
  2. cs (Czech)
  3. de (German)
  4. el (Greek)
  5. en/en (English)
  6. en/en-n (English, regional)
  7. en/en-rp (English, regional)
  8. en/en-sc (English, Scottish)
  9. en/en-us (English, US)
  10. en/en-wm (English, regional)
  11. eo (Esperanto)
  12. es (Spanish)
  13. es-la (Spanish, Latin America)
  14. fi (Finnish)
  15. fr (French)
  16. hu (Hungarian)
  17. it (Italian)
  18. kn (Kannada)
  19. la (Latin)
  20. lv (Latvian)
  21. nl (Dutch)
  22. pl (Polish)
  23. pt (Portuguese, Brazil)
  24. pt-pt (Portuguese, European)
  25. ro (Romanian)
  26. sk (Slovak)
  27. sv (Swedish)
  28. tr (Turkish)

These parameters can be sent as query parameters or form body when using HTTP POST. Beware that long passages should be splitted in parts to avoid long processing times. If you need to render a long passage, send the text with HTTP POST because query parameters have a length limit of 2,000 characters.

Here’s an example of the speech: http://ow.ly/kHtxK. If you like, please help me do this survey in order to improve the service.