Sochi.Camera: features of creating a project in general, completely, completely from scratch, without standards and already implemented examples

Sochi.Kamera is a site that broadcasts streams from over 300 webcams installed in Sochi and its surroundings. The site and the entire service is non-commercial; it has been created and maintained at its own expense by the local Internet provider , Business Communication , for almost 10 years. In this post we will tell you how to code from absolute zero; about the battle with YouTube (we won); why free software is bad and free video streaming service is good. Perhaps, in the future, when they turn to us with another offer - write for 100-200 thousand rubles. the same service as Sochi.Kamera, instead of a thousand words, we ’ll give Rafaella a link to this post so that everyone can understand everything at once.

First version: flayed design with pieces of someone else's code

Our project was made almost from scratch, there were no similar services, role models or templates. Everything that we did, we had to do ourselves: from rewriting buggy modules from open source libraries to inventing new ways to mount cameras. There were no ready-made solutions, and when we started the project, and now there are none, in the form of templates, anyway, rather decent programming skills are required.

We started ourselves, with our staff network administrators who knew how to code a little. Almost from the first steps of the project, we would like to make our lives easier. But the only "ripped off" version of the site was the very first. The design was borrowed from a desktop program for viewing photos and videos, the name of which no one now remembers. Actually, the original idea of ​​the site was an online cinema with many halls, with a dark background and a large screen with a high-quality picture. The design of this program with a forgotten name was the same - a dark background, a bunch of previews, with a click on which the big screen opened.



The code was taken from a Linux DVR, an open source simplest DVR on Linux. It worked as a website, it was possible to access it through a browser and watch streams from cameras. On a piece of code from a Linux DVR, where motion jpeg was used, we pulled the design from the photo viewer and the first version of Sochi came out. The camera is clumsy but working.

Now the fifth version of Sochi.Camera is working. Site design has changed a lot. The main idea of ​​the “dark room of the cinema”, however, did not go anywhere, but now the design is more like a Yandex video than a desktop photo-video library. However, this is only a distant reminder, not a flayed appearance. On the new version of the site an online competition was announced, the overall design and icons created by the winners were used on the current version of the site.

image

Of course, not all users of the site favorably adopted a new look, for the strongly dissatisfied the old version was also left, however, now almost no one enters it.

As for the code, the second and further versions were made more independently, and they turned out to be less artisan. Now the service is made on Java script, the server part is on Node.js, the client part is on Angular.js. We have only one person involved in the development of a server application, but this is a professional developer and today's high level of our service is largely his merit. By the way, our entire team is listed in the section on the project on Sochi.Camera.

Turbulence in the transition from Flash to HTML5

When Steve Jobs declared war on Flash, our site just worked on it. All browser manufacturers began to gradually go to HTML5, where the demonstration of video streams was not yet standardized, and we got a big problem. Sochi. The camera could have been working on Flash for several more years, but in new versions of browsers everything was unstable, we lost a lot of users, because instead of video from cameras they got a dark window.



It was necessary to rewrite the site for new versions of browsers, and not only did you have to write a piece of code for each version separately, it was also necessary to determine a bunch of browser-player on the fly. Here is our developer and wrote a design that did it quite successfully. Of course, it was very stressful to the system and complicated the code. So, when the standardization situation is settled, we once again reworked the service, eliminating these additional crutches.

One of the strengths of our developer is that he is constantly engaged in refactoring - optimizes the code, reduces the load on the server and communication channels, constantly monitors the capabilities of new versions of programming languages.

By the way, at the same time, when we struggled with different browser formats, YouTube solved a similar problem, with two minor differences: YouTube showed files, not streams, which made it much easier for programmers to do it; and this is YouTube, with a huge staff of programmers, and not a small company with one, albeit a very good and even brilliant programmer. Looking now at these past cases, we can say that the turbulence passed no worse.

In addition to the correct approach of our main programmer to the efficiency of software, another very important point was the choice of a new streaming platform. Although we left Wowza not for a “technical reason”, but because of their immodest tariff policy, technically we also won in the future. We started working with Flussonic from the company Erlivideo on our fourth version, about 4 years ago, when they were not yet heard. Then this product went from semi-handicraft to normal paid commercial.

The history of this product very well confirms the fact that software products develop better not along the path of open source software with free (or conditionally free) distribution, but along a commercial path.

Flussonic himself by the time when we gathered to move to it, already existed for three years. At first, he had open source code, distributed free of charge, and programmers earned only from its support. Its development was unstable, because users did not report bugs, third-party developers were not interested in participating in the development of the project, there was little money from support. Then it was decided to close the code, to create the company Erlivideo and start developing a commercial product. And about a year after the creation of the company, we began to work with them.

We were a training ground for them, an experimental base, shared problems with them, offered features. One of the important things we got from them is the player, written specifically for their engine. The important point is that both of these parts - the kernel and the client - are written by one developer, even if problems arise, they are quickly eliminated. Erlivideo has grown a lot over this time, has become well known in the iptv industry, and now, on our fifth version, everything has been working steadily for over a year without any particular disruptions.

Money: what to spend and how to make money

After many years of operation, the site has become very famous, popular, and has itself become a model for such resources. People periodically contact us to buy a complete solution. We figured out how much this decision would cost us today, taking into account our experience and the mistakes made. In general, the server part is about 1,000,000 rubles, each mobile application is between 500,000 and 600,000 rubles. These amounts of potential buyers are scared, they count on a maximum of 100,000 - 200,000 rubles for everything. When we start to paint the component parts of the software, the cost of certain solutions, people are perplexed: for example, why spend money on writing modules for which there are free analogues in open source libraries. Just to make them work better!

image

Here is an example, a simple task - to take the stream from the camera and distribute it to a large number of subscribers, just multiply it without changing it. In the free solution from the open source ffmpeg library, if the flow from the source is interrupted, the whole process stops and must be restarted manually. Imagine if there are more than three hundred cameras on the network, a rather large network, something constantly happens - somewhere on the camera the power fails, somewhere between the server and the camera the communication break happens and the service just stops. It is easier to pay money for a paid solution that can monitor the state and restart if necessary, than use a free solution, but monitor and restart manually.

In general, according to our estimates, the cost of developing software has amounted to about 40% of all project costs. The remaining 60% is all hardware, including cameras and servers, as well as licenses for used third-party applications.

We spent a lot of money on this our project, and in general, now would not refuse to somehow make money on it. But this is definitely not a direct, “head on” way of monetization. After studying the majority of monetization models, it became clear that those of them, where the service earns directly, require additional troubles and generally do not pay off. Now there are technical solutions that can quite easily integrate advertising directly into the video stream. Technically, this is a very good solution, the load on the servers is low, it is impossible to bypass advertising blockers, with our attendance of 500,000 - 600,000 people every month this video ad will be watched by a very large audience, but building a sales system around this, administering cash flows is very expensive, and we do not plan such monetization.

So we use indirect models, mainly to promote our main carrier business. For example, at the entrance to the site we analyze the IP-address of the visitor, and the local, but not our client, we show advertising our own services. We give streams for display on third-party web resources in exchange for our advertising with them. On local TV channels, they gladly use video from our cameras in the news blocks at prime time with mention of the name of our company. Our clients hotel chains broadcast video streams from our cameras on their televisions, receiving them as TV channels, for them this is an additional free service, a chip for guests.

The site itself, with its nearly 5 million views per month, we use as an advertising platform, but we do not sell advertising - we place only our own, or our corporate customers, for free, just increase loyalty.

In the future we plan to adhere to the same strategic line - indirect ways of monetization, free service for visitors.

We are waiting for your questions, comments, comments, and suggestions about the next article.

Source: https://habr.com/ru/post/413929/


All Articles