Streaming

From BC$ MobileTV Wiki
Jump to: navigation, search

As the name describes, streaming is the process of opening a connection between a (typically thin) client and a (typically thick) server for passing a constant flow of communication data. It is called streaming because it shares similarities in a high-level view, to a streaming river which flows (message stream) from a larger body of water such as an ocean or lake (server) down to an end user such as a person collecting fresh water or panning for gold (client).


Formats

Progressive Download

Progressive Download is a feature by which metadata encoded into a given media file (image/audio/video) specifies how much of that file should be downloaded from the server, before any rendering shuld proceed. It is up to the client media player to adhere to and enforce the encoded "minimum download prior to playback" settings.

HTTP Streaming

Also known as HLS, HTTP Live Streaming is an Apple standard for reaching a wide array of web-enabled devices with live video streams.


Adaptive Streaming

Adaptive Streaming is a technique for streaming media by varying the quality of the stream based on the available network bandwidth. This allows the user to experience the best quality media that their bandwidth will allow. The standard method to provide this feature is splitting of media content into multiple separate "tracks" with different qualities (bit rates & resolutions). The player chooses a track based on the available network bandwidth (which especially on Mobile, can fluctuate at various points in time as signals get stronger or weaker, so different tracks can be chosen and media quality increased or decreased as needed).

Each track is split into chunks of a given duration, typically between 2-10 seconds. This allows the player to quickly switch between tracks as available bandwidth changes. The Media Player is responsible for stitching these chunks together for seamless playback, so the end-user won't notice or get their media playback halted/stuck as frequently happened in earlier days of Online Video & Mobile Video especially (where the file sizes can be much larger, but this can even be an issue with much smaller and lower bit-rate audio formats such as Internet Radio, Podcasts/Audiobooks, Music streaming, etc.

Selecting the most appropriate track for the current environment (Device/OS/Browser/Scren-Resolution/Connection-Type/Connection-Strength/Connection-Speed) is the core challenge of the "adaptive" part of Adaptive Streaming.

[1]

Secure Streaming

There is no magic bullet when it comes to protecting your content online. You have to use a layered security approach to prevent content to be downloaded without permission. As you may have already guessed, none of this comes cheap. Unless you use a CDN or can run your own infrastructure, you won't be able to completely protect your content. Here are some techniques from less to more security of the content and users' privacy offered:

  1. Obfuscation: Make it difficult to find the source of the video by removing any reference to it from the client-side code (HTML, CSS, JavaScript) that can easily be viewed when Right-Clicking and "Viewing the Source Code". Further obfuscating and/or minifying the client source code may also be a deterrent for many, and may waste their time digging through for something that doesn't exist.
  2. Disabling direct-access via URL: On the server-side, you can use role-based authentication and allow only System Administrators or others who are authenticated to the network to access a file. For example, in Apache, you could use htpasswd[2] and also disable hotlinking[3].
  3. Put videos behind URL's that are not indexed, shared or searchable: Not knowing a video exists in the first place makes it alot more difficult to steal it. Use tools like robots.txt, Search Engine Webmaster Tools, along side strong Server configurations and privacy settings to hide content from the public web, thereby placing into the Deep Web where the address is only known by a relative small few. Of course, if any of those "in the known" intentionally or accidentally pass out the URL, the effectiveness of this technique is minimized.
  4. Login & HTTPS: As your first practical line of defense, make sure that you are requiring your users to log in to a site and have all communication between the server and client be encrypted. While that doesn't ensure that user's don't steal your content, they have to have an account before they can do so. You can then track who accessed content and even use credentials to use different watermarks for each video and each user viewing it.
  5. Private Networks and Intranets: If practical, you could require that users be authenticated within a specific local intranet (LAN) to even have access to your content. This would be for use-cases such as keeping a video only within a company, government department or other organization. By only allowing internal traffic to access the physical server where the content is stored, there is a much higher degree of network-level security available (for example Firewalls, Intrusion Detection Systems and other various Intrusion Prevention Systems).
  6. RTMPE vs. Progressive: Streaming files over progressive download means files don't get cached in the browser, making it somewhat more difficult to retrieve them. RTMPE is Adobe's real-time encrypted streaming technology and is available in Flash Media Server (FMS) or via CDN's like Akamai. I have found this to eliminate many of the off-the-shelf rippers. It doesn't prevent all of them, but it's an extra barrier that limits the software packages that can access these streams.
  7. Chunking and Encoding: By splitting up long-form content such as TV shows, Movies or Live content (i.e. concerts, sports, etc) into many significantly smaller segments, it can make it somewhat more difficult to capture the video or archive it. This is akin to taking 10 minutes of video and breaking it into 100 clips of 6 seconds, or 100,000 clips of 6 milliseconds in length. The problem with chunking is that if an attacker can use hacking tools such as packet-sniffers or network monitors to determine the exact timing of the chunking[4] and/or rate of encoding[5], then decoding and muxing software can be configured to decode and merge the small segments; however this can be again prevented by varying the rates of Chunking and Encoding[6].
  8. Filename and Path Encryption: Use an MD5 hash to encrypt the name of the video file and then decrypt the hash code in the player (as an AS3 plugin, for example). Users who look at your source will see a url that they can't make any sense of and often give up.
  9. SWF Verification: Another FMS-only feature that is supported by some CDN's like Akamai. It essentially does a checksum test on the SWF player to make sure it is identical to the one you you cleared for use. So if someone uses their video player to plug your link in, it won't play back on their site or device.
  10. Token-based Authentication: In this scenario every file request is accompanied by a token that is valid for a specific amount of time. If you limit that to 5 or 10 seconds (as long as it takes to load the initial video), a third party capture tool may not have enough time to grab the link. It also means that if someone forward the page or player the video won't work because the token has expired. This is very effective in my experience.
  11. Watermarking: If you require authentication on your website, you could add watermarks to your video. There are two options for this: a simple overlay using JW's logo feature or a server-side approach that actually changes the video. Option 1 would have you generate a transparent IMG in PHP or another web language and overlay that during playback (or maybe just for the first 20 seconds). If someone uses a screen-grabber this is an excellent deterrent as it's tough to get that out of the video if placed somewhere in the middle of the player. Option 2 is much more involved and less scalable. By using a combination of meconder and ffmpeg, you can read a file from source and stream it out at the same time while adding a video overlay. This actually changes the file itself as it gets delivered.
  12. Digital Rights Management (DRM): Last but certainly not least is the ugly elephant in the room, DRM. It is commonly viewed as a bad thing by users, as it limits their freedom to watch content when/where they want to watch it, especially when they are paying for the content. Despite the most advanced encryption techniques being applied to DRM, virtually every existing solution has been (or can theoretically) be cracked by reversing the algorithm (decrypting it) to allow playback anywhere by anyone. The best DRM allows users to watch on any device of their's but requires a proprietary player to playback, which can use several of the techniques above to enhance security further. The worst DRM self-destructs or attacks a sharer's device, and such technologies have caused serious retributions or boycotts by users.

Cite error: Closing </ref> missing for <ref> tag


Tutorials

External Links

References

  1. Performance comparison of video coding standards: an adaptive streaming perspective: https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95
  2. Apache Web Server - htpsswd: http://httpd.apache.org/docs/2.2/programs/htpasswd.html
  3. Tutorial on Hotlink Disabling in Apache: http://www.vbseo.com/f34/hotlink-protection-tutorial-apache-server-htaccess-files-6456/
  4. HTTP Chunking of data: http://developers.sun.com/mobility/midp/questions/chunking/
  5. Security Considerations for Data: http://msdn.microsoft.com/en-us/library/ms733135.aspx
  6. wikipedia: Chunked transfer encoding

See Also

Media Streaming Server | Mobile Streaming | Live Streaming | P2P | Online Video | Mobile Video | MobileTV