Does anyone have any experience to share regarding running an ffmpeg process on an EC2 instance to take an HQ bitrate stream from a local broadcast server (which is severely bottlenecked when it comes to out-bandwidth) and have it transcode the incoming (or more than one) RTSP/RTMP stream with different bitrates on EC2 ?
So that’s taking the incoming HQ bitrate stream from ffmpeg at the local server (say 1800kbps), publish that on EC2 as a live application for desktop clients while listen to the EC2 as client and re-transcode that and publish it as another it live application.
I can’t duplicate output where the broadcast server is, so is this theoretically and practically possible ? Is there a neater way to do it from with Wowza EC2 ? (while maintaining as little instances as possible ?)
You can do it with ffmpeg, although it’s a little clunky and you’ll require a decent amount of CPU horsepower on the instance.
The other option if you’ve got the luxury of a little time before taking it into production is to use the built-in transcoding functionality in V3 (currently in preview).
-Ian
There are Amazon EC2 instances with CUDA resources but at this time I do not believe they support Windows which is required for the Wowza Server 3 Transcoder. We hope at some time in the near future to add support for CUDA on Linux. No definitive timeframe for this.
That being said we do think the non-accelerated software encoder will work on x-large instance quite well. We plan on doing testing in the coming weeks. We will publish performance numbers when we have them.
I hope this helps.
Charlie
Again, we need to run performance tests. At this time we just do not know how the performance will be.
The software encoder is not x264/ffmpeg. It is based on MainConcept encoder SDK.
Charlie
V3 sounds great, and that’s ultimately the final destination in the deployment, but the WowzaV3 forum folk have been a little quiet about the compatibility of the full V3 feature set on EC2 servers, namely whether the Wowza EC2 instances rely on Cuda or QuickSync or have an adequate replacement for them that will be compatible with the V3 transcoding requirements.
Anyone care to shed any light ?
Thanks for your responses Charlie & Ian.
“in the coming weeks” …
Is this testing pre-release or after it ?
And the software encoder. Is this using ffmpeg as described in this thread or the fallback feature to the V3 Transcoder ?
Went back to the V3 forum and it’s clear that this is not the case.
Assuming the principal stream is at a much lower quality than originallly desired (480p instead of 720p), would a small instance be able to handle two ffmpeg at 360p and another bitrate for mobile (or even just one of them ?) or would even that be too processing intensive ?
Do the core Wowza server components require a lot of processing power on their own (the maximum concurrent viewers at the instance’s full bandwidth allowance/load balancing modules/recording modules) or should I expect the transcoder to eat up the majority of available CPU power ?