Clever Geek Handbook

Features of testing a web application for video service





On-demand streaming (VOD) services have become an integral part of our daily lives. Video on Demand is a video content delivery system that allows viewers to select content (video) and watch it at a convenient time (on request) on any device designed to play video (web, tablets, smartphones, game consoles, etc.) .



Currently, a significant proportion of Internet traffic spends its data on viewing audio and video content. With the growth of data transfer speed, multimedia streaming has become the main way of disseminating information among users.



Keeping your media content up and running is crucial. Video playback quality is an essential factor in the overall user experience of smart devices.



In this article we will talk about the features of testing web applications for video services, in particular, we will focus on the features of testing the player.



Why is video service testing so important?



Testing is nothing new to anyone, but video services have their own specific characteristics and their own tasks.



The main objectives of the video service site are to provide users with quality content and organize the process of interacting with the service as comfortably as possible. Also, the site is often used as a marketing tool.



Thus, testing a web application for video service is necessary for you to deliver to your potential users an application that:





However, all these characteristics can only be verified by running the appropriate test scripts, which verify all the necessary conditions. That is why all types of testing streaming applications are required.



How does the video get to us?







Before moving on to the specifics of testing such applications, we answer the question: how does the video get to users?



Licensors have a digital distribution department, from which we receive sources in a special format with a set of technical metadata for sound / video settings - all source materials require some processing. The sources go to the department that prepares the video, where it is checked that everything works correctly and correctly. It is also important to check what the copyright holder sent, whether it is suitable for viewing: adjust the bitrate, display the sound level and make color correction. After that, the sources are sent to the encoding system, and then all content files are laid out on servers.

And only after all these manipulations is it sent to the end user. All our video needs protection, so we encrypt it.



What about Internet piracy?







With such a rapid growth of VOD, the issue of protecting legal digital content becomes extremely relevant.



After the video has undergone special processing, DRM comes into play, developed in response to the rapid growth of Internet piracy.



Digital Rights Management is a system that protects content from unauthorized copying; a kind of "lock", the key to which the user receives through DRM systems of well-known vendors.



It's hard to crack such a key, and you can only get it after purchasing a product with a license. If the video is encrypted using the DRM solution, then during playback the player will detect the encrypted data and ask the license manager for authentication and decryption key.



All DRM solutions are certified. We use literally all DRM, as vendors support each of their own, and in the legal form, the sale of content is possible exclusively through DRM.



Each vendor has its own encryption scheme and its own transport (container), but after the appearance of CENC and its adoption by all major market players, a common CENC container appeared, which includes several DRMs.



DRM solutions:





Features of testing a web application for video service



Obviously, there is no single DRM solution. DRM in various browsers is different, and this is not a whim, but a necessary necessity, because Google does not play FairPlay, and Safari does not support Widevine, so cross-browser testing of the player is inevitable.



Testing a player requires many factors to consider. In addition to the device, browser, and hardware, the tester must also take into account external conditions, such as channel bandwidth. Let's look at the general problems that the tester encounters when testing the player.



Player Testing:



The main feature of testing the player is support for two players at once: for Safari and IE - a native player based on FairPlay; for other browsers - HTML5 player based on CENC.



Difficulties:



  1. Testing cross-browser compatibility of VOD applications.

    • the need to support all browsers: Google Chrome, Mozilla Firefox, Opera, Yandex. Browser - HTML5 player based on CENC, separately - Safari.
    • browser compatibility testing: you need to have a full combination of all browsers, operating systems and their versions.
    • You can use virtual windows and emulators, but when the application runs in real time, an unexpected error may occur that the emulator cannot detect.


  2. Repeated playback of content on other platforms is multiservice: it is important to ensure stability on all devices so that the resolution of streaming multimedia and application performance do not affect different devices.
  3. Adaptation of the video stream to the network bandwidth: it is necessary to check the influence of the network on the application response time.

  4. Stress Testing. No matter how well you develop your application, there is a limit to the traffic that it can handle; testing VOD applications for load and performance is vital.

  5. Automation. The main problem with automated testing of a web player is that all automation tools are better suited for ordinary web applications, such as e-commerce sites, single-page applications or social networks, there is no single solution for video service.



What's inside?



How does the player work:







We figured out the delivery of content and its protection, but what happens next? What happens when a user starts watching a movie or series?



After the content is purchased and a license to play is obtained, the user can view it.



When asked to play, the player asks the server for a manifest from the server and downloads it. A manifest is an ordinary XML rule of how the player will “pump out” a playlist in a specific format (taking into account DRM).



Almost simultaneously, the DRM manager of the player itself is connected and requests a license for playing from the server, because all the necessary data (what and in what format to play) is already received from the manifest.



In turn, the same session key comes from the server, upon receipt of which, the player decrypts the stream, and we can enjoy viewing the purchased content.



At each stage of the player, problems may arise. Each request is a potential failure, and it is important to test all of these points, for example:





A license request to a DRM server also generates several test scenarios, because the content is distributed under different rights, which requires additional attention:





Conclusion



Testing a web application for video service is different from traditional testing of various websites (whether it is a store or a website of currency quotes). All these nuances complicate automation and increase the number of scenarios that need to be covered by tests, require more expertise and labor from the tester.


More articles:


All Articles