In the first phase, vteam #616 developed a feature to update songs information live on the media (radio) player using Socket as a server. The client required an additional functionality in his custom media player where a guest user would be allowed to listen to 5 songs only. After that, he/she would be allowed to listen to the previews (of songs) of 1 minute only. The music library of this portal was near to half a million (in size) songs and it was mandatory to provide this functionality to all the guest users.
vteam #616 had to devise a solution within Angular2, PHP and Amazon S3 bucket as the songs library was stored on Amazon S3 instance. Any one of the following approaches could be used to achieve this goal:
- Check the songs quota of a user after every song (which was played). If the user exceeded the assigned quota, stop the current song and display him a pop up notification to login while playing the next song. This could be managed at the client side (Angular2) and events broadcasted by the Sound API (SoundManager2).
- Create a PHP proxy that would serve the songs. The created proxy script would check whether the user is logged in or not and then it would serve the appropriate song depending on the user’s quota. Using proxy script, mp3 files would be trimmed on the fly.
- Create a parallel music library in which the songs would be preprocessed to 1 minute versions and it would reside along the original one. Using ffmpeg tool, mp3 clipping would be done. The rest of the part would be easy after the creation of parallel music library.
As the music library size was nearly half a million, a solution which is more practical in implementation and efficient in speed had to be selected.
The first approach is less efficient as it would incur more processing on the client side to manage everything. Also, it would make the original music library vulnerable to users.
Creating a proxy looks like a promising approach but in actual, it would consume a lot of bandwidth (both upload and download side). Also, trimming songs on the fly for every single user every time would increase the load on server.
So it was decided to trim the whole music library and keep a parallel instance of it. As the songs library was stored on Amazon S3, increasing storage capacity was much cheaper than processing power and bandwidth.
At first, vteams engineer created a parallel library. After that, a new instance of Amazon S3 was created on which the shortened versions of songs would host. To install ffmpeg on the server, run the following commands:
# installing libavtools sudo apt-get install libav-tools
#installing ffmpeg sudo nano /etc/apt/sources.list
deb http://www.deb-multimedia.org jessie main non-free deb-src http://www.deb-multimedia.org jessie main non-free sudo apt-get update
sudo apt-get install deb-multimedia-keyring sudo apt-get updatel
sudo apt-get install php7.0-xml #installing php-xml as aws sdk uses it for parsing response sudo apt-get install ffmpeg
Once the installation is completed, the engineer had to manage the library autonomously. A script was written which would download the original song, clip it to 1 minute preview and upload the shortened versions on Amazon S3 bucket.
For this purpose, Amazon S3 SDK (for PHP) was used. After getting proper Access Keys, the SDK would allow the files to manage themselves programmatically on the server.
Lastly, a PHP script was used to iterate the library. It picked one song at a time, converted it into 1 minute version and then uploaded it to the shortened Amazon S3 instance.
In this way, the shortened versions of the whole music library songs were managed.
Although this approach was a bit time taking, but it only required one time processing. Once all the songs of this portal’s music library were converted into their preview versions, nothing else was required to process them. As a result, a more efficient way to manage it on the client side was achieved.