Skip to content

Commit cf1b573

Browse files
thassothasso
committed
Cleanup merge issue on section 2.2
1 parent 61b9d8f commit cf1b573

File tree

1 file changed

+75
-31
lines changed

1 file changed

+75
-31
lines changed

‎index.html‎

Lines changed: 75 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -626,16 +626,81 @@ <h4>Client-side ad insertion</h4>
626626
connection. An event is pushed to the listening clients
627627
simultaneously, this event is then used to trigger the same
628628
set of events discussed above. </p>
629-
<h4>Other possible VOD use cases</h4>
630-
<ul>
631-
<li>Buffer manipulation (device / storage dependent)</li>
632-
<li>HTTP byte range requests</li>
633-
<li>HTTPs support</li>
634-
<li>Player event exposure</li>
635-
<li>HDCP security requirement for HDMI</li>
636-
<li>Watermarking</li>
637-
<li>Hardware acceleration support</li>
638-
</ul>
629+
<h3>VOD – further considerations</h3>
630+
631+
<h4>Byte range requests in context of web video application</h4>
632+
633+
<p>
634+
An HTTP range request allows a client to request a portion of a larger
635+
file. This is helpful in a few scenarios. In the vod scenario the user
636+
may want to access a specific location in a file, a range request
637+
allows you to access content at a specific location without downloading
638+
the entire transport chunk.
639+
</p>
640+
<p>
641+
Both the player and the server need to support range requests. The
642+
player needs to be able to playback a source buffer and server must be
643+
configured to serve ranges. The exchange begins when a client makes an
644+
HTTP HEAD request, the server will then respond with a header that
645+
includes Accept-Ranges: bytes. If this is the case then the client can
646+
issue subsequent requests for partial content. The returned bytes are
647+
added to an Array Buffer and then appended to the sourceBuffer which in
648+
turn is used as the src parameter of the of the video element.
649+
</p>
650+
<h4>HDCP security requirement for HDMI</h4>
651+
<p>
652+
Most content has some limitation placed on its distribution by the
653+
owners. There are different ways of protecting the owner’s rights. The
654+
most common is DRM (digital rights management) this prevents the
655+
content being watched on a client device if the user cannot ‘unlock’ it
656+
with a key. However, once the content is unlocked the service provider
657+
should make every effort to prevent the user from re-distributing this
658+
content.
659+
</p>
660+
<p>
661+
There is an illicit market for high value content such as live sports
662+
and premium vod and attempts are made to re-distribute it. The
663+
potential pirate may attempt to re-broadcast a stream. It could be
664+
taken into the pirate’s home system and re-encoded once the source has
665+
been decrypted. Alternatively, a stream could be output to a projector
666+
or split and taken off to multiple local locations.
667+
</p>
668+
<p>
669+
A technical solution to prevent interception as a signal travels from a device
670+
to a television or projector is termed High Bandwidth Content Protection
671+
(HDCP). If implemented by a device manufacturer it takes the form of a key
672+
exchange between devices. If the exchange fails the signal is stopped and the
673+
client is notified. The client can then use this notification to present the
674+
user with a message altering them.
675+
</p>
676+
677+
<h4>Watermarking</h4>
678+
<p>
679+
Support for real-time watermarking is becoming an important consideration
680+
for distributors of high-value content. A service provider’s right to
681+
distribute content is linked to their ability to protect it with studios and
682+
sports channels insisting on the capacity for a service provider to detect a
683+
breach of copyright on a stream by stream basis. A service provider can
684+
include a vendors sdk in the client that can add a watermark at run-time.
685+
Normally, the watermark is invisible to the consumer and takes the form of a
686+
digital signal, this is referred to as forensic water marking. Part of the
687+
service provided by the vendor of this technology if to monitor the black
688+
market for re-distributed material. Ilicit streams or files are intercepted
689+
screened for the digital fingerprint inserted on the client. If a suspect
690+
stream is found they then direct the service providers to the location where
691+
the streams have been misappropriated.
692+
</p>
693+
694+
<p>
695+
Whilst this is not an issue that developers will often be faced with,
696+
this requirement can dictate the choice of platform for the content
697+
distribution. This type of process in itself requires processing power
698+
and platforms such as Android, iOS or Roku provide developers with an
699+
interface to low-level functionality in situations where the resources
700+
can be effectively ring-fenced. The options for watermarking in the
701+
browser are limited to overlays and this limitation is then reflected
702+
in a distributor’s choice of platform for their web video application.
703+
</p>
639704
</section>
640705
<section>
641706
<h3>Live Streaming</h3>
@@ -746,27 +811,6 @@ <h3>Live Streaming with Server Side Ad Insertion</h3>
746811
player to potentially reset the decoder.
747812
</p>
748813

749-
<h3>VOD – further considerations</h3>
750-
751-
<h4>Byte range requests in context of web video application</h4>
752-
753-
<p>An HTTP range request allows a client to request a portion of a larger file. This is helpful in a few scenarios. In the vod scenario the user may want to access a specific location in a file, a range request allows you to access content at a specific location without downloading the entire transport chunk.</p>
754-
755-
<p>Both the player and the server need to support range requests. The player needs to be able to playback a source buffer and server must be configured to serve ranges. The exchange begins when a client makes an HTTP HEAD request, the server will then respond with a header that includes Accept-Ranges: bytes. If this is the case then the client can issue subsequent requests for partial content. The returned bytes are added to an Array Buffer and then appended to the sourceBuffer which in turn is used as the src parameter of the of the video element.</p>
756-
757-
758-
<h4>HDCP security requirement for HDMI</h4>
759-
<p>Most content has some limitation placed on its distribution by the owners. There are different ways of protecting the owner’s rights. The most common is DRM (digital rights management) this prevents the content being watched on a client device if the user cannot ‘unlock’ it with a key. However, once the content is unlocked the service provider should make every effort to prevent the user from re-distributing this content.
760-
There is an illicit market for high value content such as live sports and premium vod and attempts are made to re-distribute it. The potential pirate may attempt to re-broadcast a stream. It could be taken into the pirate’s home system and re-encoded once the source has been decrypted. Alternatively, a stream could be output to a projector or split and taken off to multiple local locations.
761-
A technical solution to prevent interception as a signal travels from a device to a television or projector is termed High Bandwidth Content Protection (HDCP). If implemented by a device manufacturer it takes the form of a key exchange between devices. If the exchange fails the signal is stopped and the client is notified. The client can then use this notification to present the user with a message altering them. </p>
762-
763-
<h4>Watermarking</h4>
764-
<p>Support for real-time watermarking is becoming an important consideration for distributors of high-value content. A service provider’s right to distribute content is linked to their ability to protect it with studios and sports channels insisting on the capacity for a service provider to detect a breach of copyright on a stream by stream basis.
765-
A service provider can include a vendors sdk in the client that can add a watermark at run-time. Normally, the watermark is invisible to the consumer and takes the form of a digital signal, this is referred to as forensic water marking. Part of the service provided by the vendor of this technology if to monitor the black market for re-distributed material. Ilicit streams or files are intercepted screened for the digital fingerprint inserted on the client. If a suspect stream is found they then direct the service providers to the location where the streams have been misappropriated. </p>
766-
767-
<p>Whilst this is not an issue that developers will often be faced with, this requirement can dictate the choice of platform for the content distribution. This type of process in itself requires processing power and platforms such as Android, iOS or Roku provide developers with an interface to low-level functionality in situations where the resources can be effectively ring-fenced. The options for watermarking in the browser are limited to overlays and this limitation is then reflected in a distributor’s choice of platform for their web video application.</p>
768-
769-
770814
</section>
771815
<section>
772816
<h3>Live Streaming with Client Side Ad Insertion</h3>

0 commit comments

Comments
 (0)