We Don't Make It Easy, We Make It WorkPosted Feb. 15, 2012 by Stefan Caunter
You know how every marketing page tells you that it makes things "easy"? If it's so easy, how come I need you guys then? You're probably making it easy to take my money, not let me get what I need. I just have to say this.
We don't make things easy, we make them work.
Saying it's easy doesn't make it so. It sure doesn't make it work, and it sure doesn't get you the support and communication that comes from having knowledgeable video streamers at your disposal. This is another reason why we don't send automated email replies. You already get those, and know that they don't mean anything. The important thing is that you get a reply from a real guy.
Complex video integrations require patience, time, expertise, care and testing. They aren't easy, but they work beautifully when they are done.
Video CDN: Amsterdam, Toronto, Dallas Node additionsPosted Feb. 9, 2012 by Stefan Caunter
We've added gigabit nodes in Europe and North America as business has doubled since last October. The control panel will be getting an update this month as well.
The Story of the Helsinki Car Crash VideoPosted Feb 5, 2011 by Stefan Caunter
It's been over 48 hours since we were pulled out of the pile-up on the highway from Lahti to Helsinki. I've been largely unaware of the impact of this video, although with over half a million views in two days, I have some idea. I'm sure it has been on the news media here. I know a version was on a news website, but that's about it.
The youtube comments have been interesting. Obviously they come from a place where there is limited context. You either see it from someone's email to you sharing it, with their set up of it, or you see it on the news; either way, you have your own ideas about what you are seeing, and very little idea about how this happened.
First of all, the snow started very suddenly. It was clear and dry when we left Lahti. We got more than halfway before it started snowing. The whiteout at the beginning of the video was only the second one. We noticed we couldn't see at one point, and then it got better. We passed police trying to get people off the road, at a major interchange. Many commenters wonder why that had not happened. They already knew conditions were bad, but we had no sense of it, and were able to continue. Again, there had been no cars off to the side. Yet. We were in the first set of collisions.
My friend in the back, Sheldon Monderoy of LiveStream Finland, said, "You should take a picture". So, I started the camera. It was set to movie, not picture. And yes, I was holding it wrong. I turned it on, and the second whiteout came almost immediately. I remember, we had been passed by a black car previously. As the camera goes down to my leg, I forget about it completely, because there is the black car just to our left, stopped. It has hit a white van, directly in front of us. Our driver, Jani, goes to the left, toward the black car, and I am sure we are going to hit. The camera goes down as I brace for impact, and close my eyes. Amazingly, we don't hit the black car. We land softly in the ditch, in four feet of soft snow. Airbags did not deploy. Doors were not that buried, so we could open them with moderate force. It's important to understand how critical it was that we got to the ditch. The car had Nokian tires, the best, studded ones. This, and Jani's driving skill, practised in the Finnish military, allowed us to get out of the centre of the road, where we would surely have gotten smashed.
It is at this point that we realize we are sitting ducks. With the doors open, Monderoy is the first out, and we are hit for the first time. He considers getting back in, but Jani and I realize we are in terrible danger. We go out the driver side front door. I see a man, dazed, on his knees, his face bleeding from hitting his airbag, in the ditch. We run up across the median in three feet of snow, up to the side of the northbound highway. I realize now that the movie is still recording, and that I have the camera in my hand. I start to show my friends, first Sheldon, then Jani, but the crashes start, and I swing around to see what the noise is.
At this point I realize I can document some of what is happening. Cars keep coming, in the whiteout, with no idea of what is in front of them. The only reason there were no fatalities is that there were no trucks. I shudder at the thought. Nevertheless, the sounds of the impacts are terrible to witness. I turn off the camera because I cannot watch any more, and put it in my pocket. After a couple of more minutes, traffic stops, and we start to go back to the scene to see who needs help, and to see if we can use the car to stay warm in the -20C weather.
Many people have commented on speed. These cars were not going that fast. In Canada, where I am from, it would have been much worse. The Finnish drivers were amazing. I still have no idea why there were no trucks behind us, or why we didn't take harder hits before we got out. Four of us were lined up bashed into each other in that ditch. Each car behind got it worse and worse.
So, I wanted to have the chance to put some context into the video. It's a terrifying snapshot of something that I hope no one ever has to go through. Thirty eight people were injured. Anyone of us could have been killed by a truck, or by a car as we ran for our lives. You can see just one example of that on the video. Part of me feels guilty for escaping unhurt, and part of me feels guilty for making the movie, if only because of the suffering and misery it documents, as well as resurrecting how terrifying an experience it was; I'm reminded however, that it was only by purest chance that the camera was on at that moment. It was the thought that in the beautiful Finnish countryside, an amazing snowstorm was happening, and here I am, visiting, on my way to Helsinki. To end up in the ditch, at the front of the biggest car crash in 100 years in Finland? Well you could not ever think that the camera would be on. Even held the wrong way...
We got on our way, three and a half hours later, the car remarkably unscathed, and drove through five kilometres of wrecked cars off to the side. The Finnish emergency workers were incredibly efficient, well-equipped, and organized. It seems that as the storm intensified, it caused everyone to crash. Our crash was the worst, and most concentrated, but that was a very rare event indeed, and very surely no one's fault. No one could have kept control of a small car in such a freakishly intense whiteout, that came so suddenly.
I'll post the full HD version of the video on ScaleEngine later. YouTube is fine, but I run a video streaming company, don't I?
More upgrades in EuropePosted Feb 2, 2011 by Stefan
We are adding Netherlands to our European zone.
I'm in Finland, with the NetMovies24 team for their launch, in the middle of the European cold snap. This is transaction VOD for the specific region; we are securing access with SEVU to the Scanbox and Nordisk catalogues for Scandinavia.
Live Viewer CountsPosted Jan 24, 2011
We have been hard at work on our ticketing system. The ability to access a real time count of viewers has been added and documented, with example php code and a sample jquery for the live stats. You need to pass in your api key and the name of your stream. You will also be able to see a real-time graph of viewer counts in the control panel.
Further upgrades to our capacity are forthcoming. VSN users will see a second Gigabit of capacity available in the Southern US. We will be approaching 10Gbit concurrent capacity in Europe in February, to support a major VOD launch. I will be blogging from Scandinavia as this goes live.
We've also added more debugging to SEVU for implementers, so you can receive error messages and display them to clients in your player, as well as query the log for specific errors relating to invalid tickets, play attempts from non-authorized IP addresses or non-paying clients attempting to view a locked stream.
Finally, we have added status, search and revoke methods to SEVU, allowing implementers to check tickets associated with a password, IP address, or video. You can also now revoke a ticket. We have example php and json code available on the SEVU Managing a Ticket page.
Affilate Summit WestPosted Jan 6, 2012 by Stefan Caunter
I'm going to be at Affiliate Summit West this weekend. Say hello and talk to me about ad network hosting, video streaming, or your high traffic issues.
Lot of folks are running Scale Engine demo accounts, mostly because we've made it easier to sign up.
Demo accounts let you run any type of VSN (video streaming network) application. You can get a live streaming application up quickly to demonstrate to clients our global reach. Stream from anywhere to a US or EU origin, and show to the world. We've had inquiries about limits on the 275GB demo. We absolutely won't shut you down, and we don't have concurrency limits. Go ahead and stress test us. This is a big differentiation between us and DaCast. Also, note that you get access to our fully redundant premium storage for your VOD demo, which can be streamed worldwide.
Storage, Capacity, Investors and CustomersPosted Dec. 1, 2011 by Stefan Caunter
Storage capacity for OWC and Video on Demand has more than doubled. We found hard drive availability a few weeks ago and took advantage before they all disappeared. We've got a cold spare sitting on-site in a cardboard box, and a double redundant ZFS array that is screaming fast. If you need redundant storage at $0.15 per GB per month please get in touch.
For Europe, additional network capacity is online. This expansion doubles our network throughput in Europe for VideoCDN, and keeps our streaming price for VOD or livestream hosting at $0.09 per Gb transferred. Is anyone paying $0.25 per Gb of video transferred?
Just finished researching Dacast and Wistia pricing to update our price comparison tables. I had not heard of Wistia until someone asked us about them. Still don't know much about them. Anyway, Dacast resells for Edgecast, which is fine. Edgecast requires a major contract, but Dacast must get a deal on bandwidth, and they are more expensive than Edgecast. I also noticed that Edgecast is funded by Disney. There is a venture capital arm of the Walt Disney company that invested in Edgecast. I think that's funny. Edgecast has this awesome, black, aggressive website, and they got their money from Mickey Mouse! We don't have investors here at ScaleEngine, we have customers, which I think is better for everyone. When you have investors, they come first, folks. You want to know that customers are a priority, not investors. We run our business, every day, like we need customers, not investors.
High Quality Hosting and Page Speed Posted Nov 27, 2011 by Stefan Caunter
Allan has written some slides on Accelerating Wordpress, which we'll post here after he presents them at the Toronto Affiliate Summit Meetup on November 29th 2011. We usually edit each other's stuff, and I started in on the shared vs. dedicated hosting slide. Since we do Scalable Hosting, with our Origin Web Cluster, I thought I'd publish the overview here.
On shared, virtual hosting environments, those cheap, $5 hosting plans, someone else's busy site will, by definition, adversely affect your site. Overloaded virtual servers with hundreds of sites cannot sustain bursts of valuable traffic, or even get pages built and sent out in a reasonable amount of time.
Network and disk throughput are often poor to terrible with shared hosting, failing to reach even the basic 5Mbps download speed for the average US internet user. Top download averages are now at 30Mbps for Japan, Korea and Hong Kong. High speed internet is legislatively mandated in Scandinavia. Your hosting and CDN needs to be on a 1Gbps line for your target market of well provisioned end users.
You need to distribute and optimize your site's "objects", from the base html, to the scripts and css, to the images and video. Insist on redundant Tier1 high quality network transit. Find a hosting company with properly tuned memory, disks, storage, servers, databases, and web servers. You don't get what you pay for, you get what you get. Find out what you are getting with your hosting! Clustering and pooling of server resources can dramatically expand capacity and throughput. Is the PHP engine distributed on multiple servers for maximum horsepower? Are PHP processes isolated from web server processes? Are web server processes optimized for concurrency and maximum throughput? Can your host proxy intelligently to maximize efficient delivery of content and leverage existing site logic?
Flowplayer rtmp integration with smil playlists Posted Nov 24, 2011 by Stefan Caunter
Here is how to integrate a commercial flowplayer licensed version into rtmp streaming with ScaleEngine CDN.
The example assumes you are using a .smil file stream named yourplaylist on ScaleEngine, and that the smil file knows about three different streams, configured to be a variable in php (in this case, ICL_LANGUAGE_CODE).
Set up your div and call the scripts you need. You want to be using the commercial 3.2.7 flowplayer, with the 3.2.3 rtmp plugin.
Provider "scaleengine" is not especially important, but we like our vanity, sometimes.
I created a stripped down flash window, with no controls, that just plays a continuous loop, like a tv station.
This embed code will detect the page language, and assuming your smil file has paths to the proper language videos, the viewer gets the correct language playback stream from the named playlist.
RTMP code exampleDNS packet size and Cisco ASA Posted Nov 18, 2011 by Stefan Caunter
For some time, we've managed DNS with a combination of geographic locations, using zones, and A records, that can give a round robin result for an area, to get the closest result for an HTTP request on the CDN. We recently exceeded the 512 byte limit on DNS answers that is imposed by default on Cisco ASA firewalls, with the result being a brief CDN outage. When you consider that DNSSEC has been sending large answers for eight years, and eDNS timeouts should be handled by lookup servers gracefully, with fallback to 512 octet DNS udp size, it's strange that Cisco still ships with this default setting.
So what have we learned? We can't fix bind9 timeout handling at ISPs, nor can we request that Cisco change their ASA stock setting to not switch to tcp for larger DNS responses. Well we could, but Cisco is the Maytag of network appliance companies. Yeah, the bored service counter guy works there. So for now, we better keep our DNS packets not one byte larger than 512 (it was one byte too big).
We think a full anycast DNS setup will solve this once and for all and will keep you posted on progress on this front. We are also excited about a large ZFS storage system we will be bringing online at Pullman, our recent upgrades in the US for the CDN, and major upgrades that are coming in Europe in January for VOD and streaming customers.
Vodo.net launches Pay Per View with SE-VUPosted Oct 11, 2011 by Allan Jude
Vodo.net has started implementation of the SE-VU Virtual Usher ticketing system, allowing instant pay per view access to their content for those who don't want to torrent (and wait) for episodes of Pioneer One and other premium content.
API release 0.8 AnnouncementPosted August 11, 2011
SeeView (SE-VU) Virtual UsherVideo CDN customers can now access the Scale Engine API to build a pay per view theatre for Transaction Video on Demand. Developers should refer to the documentation. We have also posted example php code for creating a SE-VU Ticket (See View), our virtual usher system allowing content owners to manage pay per view video on demand for subscription VOD and transaction VOD.
Scale Engine API is comingPosted August 9, 2011
We are working on an API for securing video on demand, which we will announce in the next couple of days. You will be able to secure Transaction Video on Demand (TVOD), as well as Subscription Video on Demand (SVOD). Additionally, you will be able to integrate your existing payment system into your movie access rules, to authorize viewing, should you be running pay per view or time-based subscription viewing. Membership based sites can now offer pay per view for events with secure streaming to only authorized clients. Pay per view website integration for independent film, documentary and other specialty content owners will be offered over this API, as well as secure subscription based access to your unique content streams and channels such as content from owners with specialty language content, who wish to reach their expatriate linguistic base.
There is no request we get more frequently than for an easy way to integrate payment for video streaming and we are looking forward to rolling it out.
IP cameras that just send HTTP streamsPosted June 8, 2011
How to fake an rtsp stream from http cameras
We've all seen them. Inexpensive IP cameras that promise to send h264 streams in their specifications. Panasonic and Planet cameras have okay web based viewers, and claim to send h264 out, but the reality is that they don't. You can view through the camera's web interface, and that's it. The thing works, but doesn't shoot h264. How to actually restream HTTP mjpeg, like the example below; this is from a Planet camera that only puts out HTTP.
Having done it a couple of times, let me start by saying it's got to be done with a specific way to keep the stream going, all the time (I use Proc::Daemon with perl), and you have to be able to get to the HTTP source reliably (I use lynx), and you have to transcode the stream and send it to rtsp on a wowza server using ffmpeg.
I'll deal with the perl daemon wrapper after I talk about getting the stream, and transcoding it. I choose lynx, instead of curl or libwww, because I can build the appropriate url with "?" url parameters, and I can pass username and password, and optionally install a certificate. I also wrote all the SSL documentation for lynx, so I'm declaring my bias.
In perl you need the ip address of your camera. I have a nice hack if you are behind a dynamic dns service, which I'll write about when I talk about the Panasonic cameras. This works with a Planet:
my $location = 'http://1.2.3.4';We can print out this command to our screen and see if it will work. Run it and see if you get a big ugly video stream on your command prompt screen. In case you're wondering, lynx works just fine in windows too. If I run the command without -dump -source, I see the lynx prompt:
# this uri pulls the Planet mjpeg stream over http
# 'http://1.2.3.4/video.cgi?resolution=4cif&random=0.07799162343144417'
my $uri = "/" . "video.cgi" . '?' . "resolution" . '=' . "4cif";
# build url
my $url = "$location" . "$uri";
my $lynx_string="lynx -nopause -dump -source ";
# got all the bits, assemble it
my $lynxcmd="$lynx_string" . "$url";
which is okay. I can transcode that. Panasonics declare mjpeg.
If we run with -dump -source, we get a stream. Now to transcode with ffmeg.
Pipe $lynxcmd into ffmpeg, tell ffmpeg what it's getting, and send it to wowza as rtsp. Simple to say, hard to do, and different for every camera. Fun.
We need in perl:
system("$lynxcmd | /usr/local/bin/ffmpeg "); What arguments do we need for ffmpeg? Different for every camera. ICA-H312 worked with this:
ffmpeg -r 3 -f mjpeg -an -force_key_frames 0.2 5 -s 4cif -b 1024k -g 30 -vb 150000 -strict experimental -i - -ac 1 -vcodec libx 264 -vpre medium -r 3 -g 30 -b 150000 -f rtsp -muxdelay 0.5 rtsp://127.0.0.1:1935/train/_definst_/camera.sdp
Which means, pipe the continuous HTTP stream from lynx, into ffmpeg. In ffmpeg, say that rate is 3, force the format to be interpreted as mjpeg, ignore audio (-an), use 4cif size, a 1024k buffer, (and a couple more options), and with this input from STDIN, transcode it to h264, again at rate 3, formatted for rtsp, to the listening rtsp application we have created on our wowza server.
Which will work, as long as the camera keeps sending. We keep it running forever with Proc::Daemon. Wrap the few lines of perl in this:
use Proc::Daemon;
Proc::Daemon::Init;
my $continue = 1;
$SIG{TERM} = sub { $continue = 0 };
while ($continue) {
# all our perl is here...
}
This will now pull your Planet camera's lousy 4cif HTTP stream, that you thought would only ever work on their camera web page, into wowza, so you can send it to your iPhone or desktop, limited only by the number of streams your wowza servers can support.
Summarizing FeaturesPosted June 4, 2011
Working through a submission to VidCompare.com. Here's what I've come up with so far, and it takes a while to remember everything you are doing. We take most of these features for granted, not sure how people get along without them. All the while watching a traffic spike to LiveStream Finland.
Here's what I've got so far:
- No contract, pay as you go streaming
- RTMP live and Video On Demand streams
- RTMPe (Encrypted/DRM) streaming with free secure token players
- iPhone, Android and mobile streaming
- Anti-hotlinking domain locking (Don't let other people run up your bill)
- HTTP origin pull (You don't have to upload all of your videos to us)
- geo-DNS system for US/EU zones (We automatically route your viewers to the best server)
- Daily usage graphs broken down by stream
- Updated monthly billing estimates






