Contact us +32 498 138 661

info@rambla.be

news

Kia press conference with lie detectorThe one hour long press conference is part of an online campaign for automobile manufacturer KIA. During the live event, viewers can ask questions to the CEO of KIA Motors Belgium while he is strapped to a lie detector. A second livestream shows the results of the polygraph test. Both streams are simultaneously broadcasted using our Rambla Broadcaster and streamed via the Rambla CDN.

By the way: we would love to see this practice becoming the newest trend at press conferences. ;)

Livestream

This is the first of a series of tutorials that will help you get to grips with Rambla Web Services. In this tutorial, we will use the cURL command-line tool to communicate with Rambla Storage Service (RASS). We will demonstrate how to use RASS for file- and directory management on our CDN and, in the meantime, show the basic mechanics of a REST API and the Atom Publishing Protocol.

If you are not familiar with the concept of REST or the Atom Publishing protocol (= atompub), you can find a detailed explanation on our wiki as well as some examples. The atompub specification (= rfc 5023) itself is also a very readable introduction to both REST and atompub. Or you could watch these videos by Google's Joe Gregorio: 'Intro to the Atom Publishing Protocol' and 'Intro to REST'.

In this tutorial, you will learn how to create a directory, upload files, and delete files and directories using the RASS API. For these purposes, RASS exposes the "dir" and "item" resources. Additionally, RASS also exposes a "meta" resource that allows you to retrieve, manage or search for metadata. We will look at these metadata features in another tutorial.

Create Directory

So let's get started. First, we'll create a new directory named "tutorial1" inside the account of a user named "monty" on CDN03. We can do this by sending an HTTP POST request to the "dir" resource and passing the name for our new directory in the URL path: "http://rass.cdn03.rambla.be/dir/tutorial1/".

In cURL syntax, this translates to: "curl --url http://rass.cdn03.rambla.be/dir/tutorial1/ --request POST --user monty:mypwd", which produces the following output (only relevant lines are included here):

curl --url http://rass.cdn01.rambla.be/dir/tutorial1/ --request POST --user monty:mypwd --verbose

> POST /dir/tutorial1/ HTTP/1.1
> Authorization: Basic bW9udHk6bXlwd2Q=
> Host: rass.cdn03.rambla.be

< HTTP/1.1 201 Created
< Content-Length: 923
< Location: http://rass.cdn03.rambla.be/dir/tutorial1/
< Content-Type: application/atom+xml;type=entry

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:raws="http://rambla.be/raws/ns-metadata/1.0" raws:kind="dir"
raws:path="/tutorial1">
<id>http://rass.cdn03.rambla.be/dir/tutorial1/</id>
<title>/tutorial1</title>
<updated>2010-06-18T13:21:44+02:00</updated>
<author>
<name>monty</name>
</author>
<link href="http://rass.cdn03.rambla.be/dir/tutorial1/?;kind=root,file,dir" rel="self" type="application/atom+xml"/>
<link href="http://rass.cdn03.rambla.be/dir/tutorial1/" rel="edit" type="application/atom+xml"/>
<link href="http://rass.cdn03.rambla.be/dir/tutorial1/?alt=html;;kind=root,file,dir" rel="alternate"
type="application/atom+xml"/>
<summary>4096 bytes, updated on 2010-06-18 13:21:44</summary>
<content type="application/xml">
<params xmlns="http://rambla.be/raws/ns-metadata/1.0">
<name>tutorial1</name>
<size>4096</size>
<updated>2010-06-18 13:21:44</updated>
</params>
</content>
</entry>

In the HTTP response body, RASS returns an ATOM entry which contains all information about the directory that has just been created. The entry element's "raws:path" attribute contains the directory's relative path on the CDN. The entry's "atom:content" element contains the RAWS-specific information in the form of an xml structure which is contained inside the "raws:params" element. The actual parameters for each resource are defined in the Rambla wiki.

Upload File

To upload a file to the CDN, you insert its contents as the binary body of a HTTP POST request to the RASS item resource. The URL path (= "/tutorial1/") should point to the directory in which RASS needs to store the uploaded file. The SLUG HTTP header (= defined by the atompub protocol) must be present to suggest a filename to RASS.

curl --url http://rass.cdn03.rambla.be/item/tutorial1/ --user monty:mypwd --data-binary @./recordings/taste.mp4 
-H "SLUG: cookbook.mp4" --verbose

> POST /item/tutorial1/ HTTP/1.1
> Authorization: Basic bW9udHk6bXlwd2Q=
> Host: rass.cdn03.rambla.be
> SLUG: cookbook.mp4
> Content-Length: 239136

< HTTP/1.1 201 Created
< Date: Fri, 18 Jun 2010 12:06:37 GMT
< Content-Length: 1102
< Location: http://rass.cdn03.rambla.be/item/tutorial1/cookbook.mp4/
< Content-Type: application/atom+xml;type=entry

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:raws="http://rambla.be/raws/ns-metadata/1.0"
raws:kind="file" raws:path="/tutorial1/cookbook.mp4">
<id>http://rass.cdn03.rambla.be/item/tutorial1/cookbook.mp4/</id>
<title>/tutorial1/cookbook.mp4</title>
<updated>2010-06-18T14:06:39+02:00</updated>
<author>
<name>monty</name>
</author>
<link href="http://rass.cdn03.rambla.be/meta/monty/tutorial1/cookbook.mp4/" rel="self"
type="application/atom+xml"/>
<link href="http://rass.cdn03.rambla.be/item/tutorial1/cookbook.mp4/" rel="edit" type="video/mp4"/>
<link href="http://monty.cdn03.rambla.be/tutorial1/cookbook.mp4" rel="enclosure" type="video/mp4"/>
<summary>239136 bytes, updated on 2010-06-18 14:06:39</summary>
<content type="application/xml">
<params xmlns="http://rambla.be/raws/ns-metadata/1.0">
<name>cookbook.mp4</name>
<size>239136</size>
<updated>2010-06-18 14:06:39</updated>
<mimetype>video/mp4</mimetype>
</params>
</content>
</entry>

The "Location" header (= see also the entry's editable "link" element) points to the item resource that RASS has just created. In doing this, RASS has made your file publicly available on the CDN at "http://monty.cdn03.rambla.be/tutorial1/cookbook.mp4", as specified by the enclosure URL. Finally, the entry's self "link" element points to a URL that you can use to retrieve or attach metadata for/to this new resource.

Unless you are using globally unique filenames, you should always check the HTTP response to get the actual filename given by RASS. For instance, when you issue the same command for a second time, RASS will respond with the following "Location" header and ATOM entry.

< Location: http://rass.cdn03.rambla.be/item/tutorial1/cookbook000.mp4/

<entry raws:kind="file" raws:path="/tutorial1/cookbook000.mp4" xmlns="http://www.w3.org/2005/Atom"
xmlns:raws="http://rambla.be/raws/ns-metadata/1.0">
<link href="http://monty.cdn03.rambla.be/tutorial1/cookbook000.mp4" rel="enclosure" type="video/mp4" />
...
</entry>

Since a file named "cookbook.mp4" already exists, RASS adds a numerical suffix to the filename suggested in the SLUG header.

Delete File

To delete the file we've just created, we can send an HTTP DELETE request to the "item" resource, passing the relative path (= "tutorial1/cookbook000.mp4") to the file that needs to be deleted.

curl --url http://rass.cdn03.rambla.be/item/tutorial1/cookbook000.mp4 --request DELETE 
--user monty:mypwd --verbose

> DELETE /item/tutorial1/cookbook000.mp4 HTTP/1.1
> Authorization: Basic bW9udHk6bXlwd2Q=
> Host: rass.cdn03.rambla.be

< HTTP/1.1 204 No Content
< Content-Length: 0

To confirm that the file has been deleted, RASS sends back a response with status code "204 No Content" and an empty body.

Delete Directory

In the same way, a directory can be deleted by sending an HTTP DELETE request to the "dir" resource, and passing the directory's relative path in the URL. But since our "tutorial1" directory still contains a file, a non-recursive delete attempt will fail.

curl --url http://rass.cdn03.rambla.be/dir/tutorial1/ --request DELETE --user monty:mypwd --verbose

> DELETE /dir/tutorial1/ HTTP/1.1
> Authorization: Basic bW9udHk6bXlwd2Q=
> Host: rass.cdn03.rambla.be

< HTTP/1.1 403 Forbidden
< Content-Length: 283
< Content-Type: application/xml

<?xml version="1.0" encoding="utf-8"?>
<error xmlns="http://rambla.be/raws/ns-metadata/1.0">
<code>ResourceCanNotBeDeleted</code>
<message>You are not allowed to delete this resource.</message>
<reason>The directory you tried to delete (path = /tutorial1) is not empty.</reason>
</error>

RASS returns a response with status code "403 Forbidden" and an XML-formatted error message in the body. However, we can recursively delete the directory by passing "recursive=1" as part of the URL's query-string arguments.

curl --url http://rass.cdn03.rambla.be/dir/tutorial1/?recursive=1 --request DELETE --user monty:mypwd --verbose

> DELETE /dir/tutorial1/?recursive=1 HTTP/1.1
> Authorization: Basic bW9udHk6bXlwd2Q=
> Host: rass.cdn03.rambla.be

< HTTP/1.1 204 No Content
< Content-Length: 0

In this case, RASS responds with status code "204 No Content" to confirm that the directory has indeed been deleted.

APIs

Rambla Storage Service (RASS) version 3.0 includes the ability to instantly synchronize changes to the CDN file-system to all nodes on the CDN. This new feature may be useful for real-time workflows or websites with user-generated content. It helps them avoid the so called "CDN sync-delay" (= few minutes before changes are reflected on all CDN nodes), which may occur if you use FTP to upload files to your CDN account.

With instant syncing, an uploaded file will be available for download or streaming as soon as you receive the HTTP response from RASS, which also contains the location of the file on the CDN. In the same way, when you use RATS to encode a file and publish the result to your Rambla account, the encoded file will be available on the CDN when RATS has finished processing the job request.

Currently, RASS instant syncing is still deployed as an optional feature. If you want it to be enabled for your account, please contact us. In a later phase, we will set instant syncing as the default option for all RASS access.

We recommend that, when possible, you avoid mixing FTP access and RASS instant syncing. For example, if you create a directory on the CDN using FTP and immediately afterwards upload a file to it using RASS, the instant syncing may fail if the directory does not yet exist on all CDN nodes (because of the CDN sync-delay that comes with FTP access). In such case, you should also use RASS to create the directory.

APIs

Laila, the littlest snow leopard

Laila came into this world on April 4th in animal park Planckendael. She is the first snow leopard to be born in Belgium. And the cub definitely has some star-quality! You can see for yourself at the Planckendael site.

 

 

 

Livestream

As you may know, Rambla is currently involved in a research project - funded by the Flemish government agency for Innovation by Science and Technology (= IWT) - regarding support for metadata through our CDN. The goal of this project is to find a way in which our customers can benefit from having a context-aware CDN. This post will try to explain what we mean by metadata support and how this could benefit you.

Kinds of metadata

Metadata is simply data about data. For multimedia purposes, we can divide metadata into a number of basic categories :

  • Content Attributes : Describes the basic form of the actual multimedia file or stream, including things like the length and format of a video.
  • Content Description : Covers all information about the actual content, like title, genre, date and location at which the content was created. This information can either be generated by your production software or it can be human-authored (e.g. summaries for playlist or program guides).
  • Timed Metadata : This is information that applies to a subset of the content. At a basic level this is content such as closed captioning or even lyrics for music, but it can be much more sophisticated including listings of who or what appears in a scene or geospatial information such as where a scene was shot.
  • Hotspots : This is a more detailed level of information than timed metadata, allowing identification of exactly which portion of a frame or sequence of frames an object, person or user interface element exists on.
  • Context Information : This provides a context in which the multimedia may be consumed, such as an allowed platform, access restrictions or monetization related data.

Value of metadata

The availability of metadata allows you to improve your multimedia management and can drive growth in viewership, discovery and monetization opportunities. These opportunities range from contextual advertising, interactive playlists and content recommendations to advanced use cases such as personalization and targeting, social networking, video syndication and dynamic packaging.

The integration of metadata at CDN level offers customers a direct way to harness this potential, without them having to deploy a software solution to store, manage and disseminate their metadata. Moreover, keeping the metadata on the CDN together with the multimedia files will unlock a number of extra benefits. Here are some examples:

Metadata Capturing

  • Automatically capture and store content attributes for multimedia files that are uploaded and/or encoded using our services. For instance, if a source file has been transcoded into different formats, you will be able to distinguish the transcoded files by looking at their metadata.
  • Create or update metadata programmatically, from multiple sites or applications. Create your own vocabularies or use existing ones. Allow third parties or end users to collaborate in generating metadata (e.g. ratings).
  • Future development of advanced metadata processing services is also possible, like converting speech to text or tracking timed metadata or hotspots. This could lead to related services being deployed at CDN level: e.g. video-level or scene-level searching based on metadata indexing.

Media Accessibility

  • Easily identify your files from any location on the web, using content description data (e.g. title, description, date). Don't be tied to a particular CMS or application.
  • Let your applications retrieve dynamic file listings (feeds, playlists, ...) or provide such listings yourself for end-user consumption or video syndication (e.g. based on genre, container format).
  • Export metadata in different formats. This should also make it possible to re-encode multimedia files, while storing existing metadata in a container-specific format.

Content Monetization

  • Dynamically serve ads or content suggestions, or let others ingest preferred content from your account.
  • Get and compare statistics based on metadata queries (e.g. get all multimedia traffic for a certain event or genre).
  • Future development of an API for context information is possible and would allow you to control who can receive your (live-)streams, based on user credentials or credits.

Your Opinion matters

Since this is a research project, we are very much interested in your opinion. Would you consider storing your metadata at the CDN level? What benefits or features would you be interested in? Which kinds of metadata are important to your company or organization? Do you see any problems concerning your current workflow or infrastructure? Just leave a comment, or send us an email.

APIs
Syndicate content