How-To: Converting Recorded Files to MP4 for Seamless Playback via Red5 Pro

December 18th, 2015 by Chris Allen

A lot of developers have been asking us detailed questions about recording streams using Red5 Pro. The one thing that comes up most frequently is how to create an MP4 file for easy playback on mobile devices. While you can use our SDK to playback the recorded file as is (Red5 records in FLV format), this requires that the user always use your native app, and sometimes it would just be nice to provide a link to an MP4 for progressive download.

So with that, here’s a quick guide to get you up and running with a custom Red5 application that converts recorded files to MP4 for easy playback. You can find the source for this example on GitHub.

Install ffmpeg

The first step is to install ffmpeg on your server. ffmpeg is a great command line utility to manipulate video files, such as converting between formats like we want to do for this example.

You can find precompiled packages for your platform from ffmpeg’s website, although if you need to convert your recordings to formats that need an extra module on top of ffmpeg, you might need to compile those from scratch. Once you have ffmpeg on your server, just issue a simple command to make sure it’s working. The simplest thing you could do is just called ffmpeg with no params like this: ./ffmpeg . That should output something like this:

FFMPEG_output.png

If you see it output the version number and other info, it means you have a working version installed on your machine. Note that I’m running on my local Mac, but the same concept applies to putting it on any other OS. Also note, for production use, you would want to put the binary in a better place than ~/Downloads , and you would want to update your PATH  to point to the ffmpeg application from anywhere.

 

Start Your Own Red5 Application

Now that you have ffmpeg on your server, the next step is to build your own custom server side application for Red5, extending the live example here. You will use this as the beginning of your custom app that will convert your recorded files to MP4.

 

Overwrite MultithreadedApplicationAdapter.streamBroadcastClose()

Now on to calling ffmpeg from your custom Red5 Application.

In your MultiThreadedApplicationAdapter  class you will now need to override the streamBroadcastClose()  method. As is pretty obvious from the name, this method is called automatically by Red5 Pro once a stream broadcast has finished and closed. Even though the Broadcast is finished, it doesn’t mean that the file has finished being written. So, in order to handle that, we need to create a thread to wait and allow the file writer to finish the flv write-out. Then, we access the file and convert it to an MP4 using ffmpeg.

 

Let’s see what that looks like in code:

1. Overwrite the method.

 

2. Check to make sure there is a file that was recorded.

 

3. Setup some variables to hold the data about the recorded file.

 

4. Create a thread to wait for the FLV file to be written. Five seconds should be plenty of time.

 

5. Next we need to get a reference to the FLV file.

 

6. Make sure that there is a file before continuing.

7.  Get the path to the file on the file system and the path to where you want the MP4 version saved.

 

8. Delete any previous file created, otherwise FFMPEG  will fail to write the file.

 

9. Tell your application where to find FFMPEG . Note in this case we’ve added the app to our PATH so we can call it from anywhere.

10. Create the FFMPEG  command.

 

11. Run the process.

 

12. Read the output from FFMPEG  for errors and other info.

 

13. Create threads for each of these and wait for the process to finish.

 

14. Make sure that the process created the file and that it didn’t log any errors.

 

15. Finally catch any potential exceptions and close out the thread you created.

 

That’s it! You’ve now created an MP4 file from the recording. Rather than typing that out line by line we’ve provided the example project here:

https://github.com/red5pro/red5pro-server-examples/tree/develop/FileConversion

Now that you know how to intercept one of the methods of the MultiThreadedApplicationAdapter  in Red5 Pro you can start to look at other ones you could implement to do custom behavior for your app. Many people who are recording their files want to move them to an Amazon S3 bucket for storage. Adding in a few lines using Amazon’s API to do that wouldn’t be too challenging.

What other things would you want to do with a custom Red5 application? We would love to hear from you.

-Chris

 

New Red5 Pro Server 0.2 Release Featuring Clustering and HLS

December 11th, 2015 by Jamie Maynard

R5P_HLSrelease

We have been working hard on a number of features that we are super excited about including clustering and HLS support. You can get the new release here. Make sure to be signed in with your account first. Also, expect new SDKs to follow soon as well. Cheers!

RED5 PRO SERVER 0.2 RELEASE NOTES

This release has two new features our customers have been requesting.

CLUSTERING
This version of the server allows for configuring servers together to achieve infinite scale. This is the first version of the feature, and is limited to round robin style load balancing of Edge servers to an Origin server. There are many configurations possible with this setup including support for multiple origins, and Edges being able to connect across Origins. If there’s a setup you are looking for but our solution doesn’t seem to support it, please let us know.

OUT OF THE BOX HLS SUPPORT
In addition to clustering, the new server now supports HLS. Where as before you had to install the open source Red5 HLS plugin, Red5 Pro now comes with the feature out of the box. With the feature we also have created an HTML5 example using Video.js that connects to our server via HLS.

Let us know if you have any questions. We look forward to seeing what you do with this!

Video Tutorial–How to Create an iOS Streaming Example in Minutes

December 9th, 2015 by Jamie Maynard

Interested in getting up and running with our client-side SDKs?

Our CTO Dominick Accattato just finished a great video tutorial on how to set up iOS streaming with the Red5 Pro server in six easy steps, all within a matter of minutes. In this example Dominick demonstrates how to stream from iOS to the web and then from the web back down to iOS.

 

Was this video useful? We’d love to hear your feedback on how we can continue to enhance our user support!

Do You Actually Need WebRTC?

December 3rd, 2015 by Chris Allen

webrtc

Don’t take this the wrong way; while we are thrilled about WebRTC and its potential to open up live streaming and communication within browsers, we want to pose the following question: do you actually need WebRTC for your use case? After much analysis, what we’ve found based on talking to our customers is that the answer nine times out of ten is no.

Adobe Flash
I know what you are thinking. Flash is dead: it’s a memory hog, it has terrible security flaws, and it’s an antiquated relic that should be banished from every browser on the planet. Yes, yes, much of this is undoubtedly true. Regardless of its obvious weaknesses, Flash is still a strong solution, and it can do the job that WebRTC does pretty much universally on desktops and laptops today. We originally built Red5 to integrate with Flash, and one of the most logical reasons we didn’t just start from scratch with Red5 Pro is that it still works great in this scenario. There’s a reason that solutions like video.js have a Flash fallback feature. Flash exists on these older browsers, it’s consistent, and it still works remarkably well considering its age.

Native Apps
Mobile publishing (meaning accessing the camera, encoding to a video format, and live streaming out) typically has to be done via native apps. This is especially true on iOS, as the Safari browser doesn’t support WebRTC today. The latest versions of Chrome on Android support WebRTC, and in a lot of cases it’s a viable way to implement live streaming. However, the most successful apps out there today are all native, such as Skype, Periscope and WhatsApp. In this regard, most of our customers feel it’s important to make a native app, and WebRTC doesn’t buy you anything if you have to implement it natively.

If you have the time and patience you can get the WebRTC project to compile and integrate on your mobile app, but most developers don’t want to be bothered with the complexities of integrating protocols at this level–they prefer a nice layer of abstraction using an easy-to -implement SDK. While there are excellent WebRTC based SDKs like TokBox, most developers don’t actually care what the underlying protocol is. In the end, they just want it to work.

We chose RTSP/RTP for our protocol within the Red5 Pro mobile SDKs as it’s both extremely fast and efficient. In addition, even after we’ve finished our current WebRTC implementation, which will be released in the Spring of 2016, we won’t be switching the protocol for the mobile endpoints. As an aside, if you study the WebRTC standard you will see that they actually use RTP as the base level protocol for the transport anyway.

What do you think? Do you really care what protocol your preferred streaming SDK is using under the covers, or do you just want it to work flawlessly? We would love to hear your feedback on this.

HLS
It also turns out that if you want to build an app that simply views live streams in a browser, then there are other ways to to do it. HLS, or HTTP Live Streaming has already become the standard streaming protocol on iOS devices, and there’s support for it on newer Android devices. I mentioned the video.js player, and there’s commercial ones like JWPlayer which support HLS as well.

On many Android devices, RTSP is a standard that can be relied upon as a way to consume live streams. With Red5 Pro we support both HLS and RTSP.

Not to Discount WebRTC
Clearly there’s a future in WebRTC, and as more browsers begin to support the standard and the protocols begin to be unified, we will see it become the go-to strategy for live streaming and live communication apps. We strongly believe in the future of WebRTC, and this is why we are working diligently on implementing WebRTC support in Red5 Pro. In the meantime though, there are many alternatives which work well, and for the foreseeable future we will still need these other protocols and platforms to work as fallbacks. Red5 Pro supports what you need today to get live streaming apps up and running for 90% of the use cases.

Let us know what you think. Are you currently using alternatives to WebRTC in your apps today? How much longer do you think solutions like Flash will stay relevant?