WO2014072739A1

WO2014072739A1 - Video distribution

Info

Publication number: WO2014072739A1
Application number: PCT/GB2013/052963
Authority: WO
Inventors: Nick BRADLEY; Paul Hodgson; Ian ROBSON
Original assignee: Bradley Media Ltd
Priority date: 2012-11-09
Filing date: 2013-11-11
Publication date: 2014-05-15
Also published as: GB201220245D0; GB2508138A

Abstract

Systems, methods, apparatus and computer programs for distributing and delivering video content to computing devices are described. A plurality of items of video content are received over a data network and stored. A direct link is associated with each of the plurality of items of video content, each respective direct link being to a different location. Each of the plurality of items of video content is converted into a plurality of different formats and a plurality of files of video data are stored in the plurality of different formats. For each of the members of a set of the plurality of video items, video information and the direct link are sent to a browser over the data network. At least one of the direct links and a mobile phone number is received from the browser. A message including the at least one direct link and the mobile phone number is sent to an SMS gateway to send the message as an SMS message to the mobile phone number.

Description

Video Distribution

The present invention relates to video distribution and in particular methods, apparatus, systems and computer program products for distributing video content to users.

A number of service exist which allow people to upload a file of video data which can then be viewed by other people. For example, the YouTube (which is a registered trade mark in some countries) website allows a first person to upload a file of video data which can then be viewed by people browsing the website. However, there is limited

functionality for people who might want to manage and distribute their video content more professionally or commercially.

As well as allowing people to browse and view the video content that has been uploaded to YouTube, it is possible for a first person to send a second person an email including a shortened url provided by a url redirection service (such as bitly). URL shortening is a technique used on the World Wide Web in which a Uniform Resource Locator (URL) may be made shorter in length and still direct to the required page. This is achieved by using an HTTP Redirect on a domain name that is short, which links to the web page that has a long URL. Hence, the YouTube approach allows a user to send an email, with an indirect link to a video, to an email address associated with an intended recipient of the email.

However, there are a number of deficiencies with this approach. Firstly, it is not a reliable method for distributing video content at the commercial or enterprise level. It can only be used to send video content to people with an email account. Also, some people may have multiple email accounts with different email addresses and may only access some of their email accounts periodically. Therefore, there is a risk that there would be a significant delay before an intended recipient actually saw the email. Further, it would require the email for one recipient to be sent multiple times.

Even if an intended recipient only has one email account and address, then there are a large number of reasons why the recipient may never receive the email. Firstly, the SMTP email protocol is a 'store and forward' protocol which does not guarantee delivery. An intended recipient's email account may be behind a fire wall or a spam filter or some other network entity which prevents delivery of the email. Delivery also depends on the physical network being reliable. If the network includes a wireless part and the end user has no connection, then again delivery might fail.

Also, it would be preferable to reduce or avoid any intermediate steps in delivering video content, for example not having to rely on a URL shortening service, in order to help improve the reliability of video content distribution. On the other hand email can be seen as a preferred way of distributing video content owing to the ability to attach files to emails. While this approach may be suitable for short videos, for more professional or enterprise users, even short videos can often have sizes of several 10s of Megabytes and video files of size several Gigabytes are not uncommon. Most email services have filters which block emails having files much larger than a few Megabytes, and email services may simply not be able to handle files of several Gigabytes.

An alternative to using emails is to use some form of data transfer service, such as using ftp. However, that requires a reasonable amount of technical sophistication and is not practicable for an entity needing to distribute many different video files to many different recipients, for example by manually sending many different videos to many hundreds of different destinations.

There are also network based services allowing the storage and retrieval of large files, such as dropbox (DROPBOX is a trade mark that may be registered in some

jurisdictions), but again such services are not practicable for an entity needing to distribute many different video files to possibly hundreds or thousands of different recipients. There is therefore a need for a more reliable method for distributing video content which is suitable for commercial and enterprise users. The present invention provides a video distribution system with improved delivery reliability and which uses a messaging system different to email, for example SMS messaging. Even though SMS messaging is also a store and forward messaging protocol without guaranteed delivery, the inventors have found that with care it can be used as the basis for a video distribution system which can more reliably deliver video content to intended recipients.

Various aspects of the invention relate to the distribution and/or delivery of video content to a plurality of electronic devices which can receive SMS messages, such as mobile phones and other communications devices having a wireless telephony capability.

Aspects of the invention reside in the overall system itself, various sub-systems and parts of the system, data processing methods thereof and computer readable media storing computer program instructions which can be executed to carry out the methods. According to a first aspect of the invention, there is provided a method for delivering video content to a device. The method can include receiving a video request for an item of video content over a data network from a device. The video request can include a link to a location, and the link can be associated with the item of video content. The video request can also include at least one attribute relating to at least one item of software resident on the device. The method can also include determining from a plurality of available formats a compatible format for the item of video content which is compatible with the device using the at least one attribute. A file of video data can be identified in the compatible format for the item of video content and which is at the location specified by the link. The transfer of video data can then be initiated from the identified file of video data to the device via the data network by sending the link to the device over the data network.

At least one attribute of software resident on the device can be used to help determine which of a plurality of file formats will be compatible with the device thereby improving the reliability with which the item of video content can be delivered to the device, even though the nature of the device is not known or predictable beforehand. Preferably the link is a direct link. That is the direct link allows the storage location of the item of video content to be determined directly, rather than having to rely on some ancillary or third party service. Hence, this also improves the reliability with which video content can be delivered as the method is not reliant on an ancillary or third party service 5 to be available or operable.

The link can be to a location on a remote storage device or devices, and in particular a network accessible remote storage device or devices.

10 The at least one item of software resident on the device can include an operating system or a browser. There can be a plurality of attributes, and each attribute can relate to a different item of software resident on the device. The items of software can be the operating system and the browser. The attributes can include the type of the software and the version of the software.

15

The method can further comprise selecting a data transfer rate at which to transfer the video data to the device. The method can further comprise identifying the file including identifying a file of video data having the selected data transfer rate. Hence, the file to be transferred can be selected to be compatible or appropriate to the data transfer rate or 20 bandwidth of the available network connection to the device. Again, this helps to

improve the reliability with which the video content can be delivered to and/or viewed on the device.

The data transfer rate can be selected from 1024kbit/s, 512kbit/s, 384kbit/s, 256kbit/s and 25 192kbit/s. A high data transfer rate can be 1024kbit/s, a standard or default data transfer rate can be 512kbit/s and a low data transfer rate can be 192kbit/s. These values have been found to provide reliable transmission to a wide range of devices from the most current devices through to older legacy devices which otherwise have sufficient functionality to be used with the method.

30

Selecting a data transfer rate can include determining whether an IP address for the device has been received and selecting a data transfer rate higher than a default data transfer rate if the IP address has been received. A default data transfer rate can be selected if the IP address has not been received. The higher data rate can be, for example, 1024kbit/s.

Selecting a data transfer rate can include measuring the data transfer rate on a connection to the device over the data network. Measuring the data transfer rate can include sending a message to the device and determining the time taken for the message to be received by the device. The message can include an image file. The image file can be of an image related to or taken from the item of video content. The data transfer rate can be changed or varied during transmission of video data to the device. The data transfer rate can be adaptive, based on the data transfer rate of the connection to the device. The data transfer rate can be increased from a lower initial value to a higher later value. The plurality of available formats can include one or more of the following: video file format; audio encoding format; video encoding format; display resolution; display aspect ratio; and video bitrate. Each format can be defined by a plurality of different video properties, for example two, three or preferably four. The properties can be video file format, audio encoding format, display resolution in pixels or video bitrate. The video file format can be selected from one or more or all of: mp4, ogg, mov, webm, wmv, 3gp. The audio encoding format can be selected from one or more or all of: aac, vorbis, wmav. The display resolution can be selected from one or more or all of (width x height in pixels): 320 x 180, 480 x 270, 640 x 360, 730 x 410, 176 x 144, 320 x 240, 480 x 320, 480 x 360, 640 x 480, 800 x 480, 128 x 96, 352 x 288, 704 x 576, 1408 x 1152. The bit rate can be selected from one or more or all of: 512kbit/s, 1024kbit/s, 192kbit/s,

256kbit/s, 384kbit/s.

Initiating the transfer of video data can further comprise serving a web page to the device. The web page can include a video player, for example an embedded video player to the device. The web page can be a HTML web page.

Initiating the transfer of video data can further comprise sending a command to re-direct a browser on the device to the location to the device. Determining the compatible format for the item of video content can include querying a database using the at least one attribute or a plurality of attributes. Identifying the file of video data in the compatible format can includes querying a database using the compatible format.

The device can be a computing device having a mobile or wireless telephony

functionality or capability. The device can be a mobile phone. The device can be a smart phone. The mobile phone can be at least a 2.5 G smart phone or higher.

The device can be a computing device having a messaging application which can synchronise with SMS messages received by a mobile phone. The computing device can be a personal computer. The personal computer can have various forms, e.g. a desk top, a lap top, a note book, a netbook, a tablet.

A further aspect of the invention provides a server or servers in communication with a data network and configured to carry out the first method aspect of the invention and any preferred features thereof. The server or servers can be a web server and/or an application server.

A further aspect of the invention provides a computer readable medium or media storing computer program code executable by a data processing device or devices to carry out the first method aspect of the invention and any preferred features thereof.

A second aspect of the invention provides a method for delivering video content to a device. The method can comprise receiving on a mobile phone via an SMS service an SMS message including a link to a location, the link being associated with an item of video content. A request to display the item of video including at least one attribute relating to at least one item of software resident on a device can be transmitted over a data connection from the device. The item of video content can be received over the data connection in a format compatible with the device and based on the at least one attribute. The item of video content can be displayed on a display of the device. This aspect of the invention relates to the client side operation of the invention and how the receiving device or devices interact with the server side aspects of the invention. The link may be a direct link as discussed above.

The attribute can indicate the current operating system of the device. The attribute can be the current browser of the mobile phone. A plurality of attributes can be provided and one can be the current operating system of the device and another can be the current browser of the device. Further attributes can include the version of the operating system and/or browser. These attributes have been found to be suitable for reliably determining the identity of the device.

Receiving the item of video content can include receiving a web page including a video player. Receiving the item of video content can further include receiving a stream of video data for the item of video content and displaying the item of video content using the player. The web page can be a HTML web page. The video player can be embedded in the web page. Receiving the item of video content can include receiving a stream of video data for the item of video content. The method can further comprise displaying the item of video content using a video player resident on the device.

The item of video content can be automatically displayed when video data for the item of video content is received at the device. The item of video player can be automatically displayed on the device without user interaction to start playing the video.

The device can be the mobile phone, that is the device and the mobile phone can be the same entity.

The device and the mobile phone can be different entities. The device can be a computing device having a messaging application which can synchronise SMS messages received by the mobile phone. A further aspect of the invention provides a mobile phone which can communicate with a data network and being configured to carry out the second method aspect of the invention and any preferred features thereof.

A further aspect of the invention provides a mobile phone and computing device being configured to carry out the second method aspect of the invention and any preferred features thereof. A further aspect of the invention provides a computer readable medium or media storing computer program code executable by one or more data processing devices to carry out the second method aspect of the invention and any preferred features thereof.

A third aspect of the invention provides a method for distributing video content to a plurality of devices. The method can comprise receiving one or a plurality of items of video content over a data network. The or each of the plurality of items of video content can be stored. A link can be assigned to the or each of the plurality of items of video content. Each respective link can be to a different storage location. The or each of the plurality of items of video content can be converted into a plurality of different formats. The plurality of files of video data in the plurality of different formats can be stored. For each of the members of a set of the plurality of video items, video information and the link can be sent to a browser over the data network. The members of the set can be one or, a plurality of, or all of the plurality of video items. At least one of the links and a mobile phone number can be received from the browser. A message including the at least one link and the mobile phone number can be sent to an SMS gateway to send the message as an SMS message to the mobile phone number.

The method can be an enterprise or professional method for distributing video content. Each of the items of video content can have a file size of greater than 10 Megabytes, 100 Megabytes or 1 Gigabyte.

Converting each of the plurality of items of video content can include transcoding from an original video encoding format to a different video encoding format. The different video encoding format can be selected from one or a plurality or all of: mp4, ogg, mov, webm, 3gp.

Converting each of the plurality of items of video content can include changing at least one or a plurality of the following: video file format; video encoding format; audio encoding format; display resolution; display aspect ratio; and bitrate.

The video information can includes at least one or a plurality of: a video name; a link to a thumb nail image; a unique identifier for the item of video content; and a standard message text string.

The method can further comprise receiving from the browser a message string including at least one of the links and sending the message string including the at least one link to the SMS gateway.

Converting an item of video content into a plurality of different formats can include instantiating a plurality of instances of an encoder. The encoder can be FFmpeg.

The plurality of instances of the encoder can be instantiated over a network connection on a remote server or servers.

Converting an item of video content into a plurality of different formats can include maintaining a job queue. Each of the plurality of items of video content can be stored on a remote network storage device or devices. Each of the plurality of files of video data in different formats can be stored on the remote network storage device or devices. The remote network storage device or devices can be cloud storage. Each of the plurality of the items of video content can be sent in separate segments to a remote network storage device for storage. Each segment can be approximately the same size. Each segment can be approximately 5 Megabytes in size. The method can further comprise extracting and storing a plurality of items of metadata for each of the plurality of items of video received over the data network.

Each link can include a unique address having not more than ten alphanumeric characters. Preferably each link is not more than eight and most preferably not more than six characters. The address can be a padded base 36 encoding of a location. The link can include a domain as well as the address. Preferably the link is a direct link, such as a url.

A further aspect of the invention provides a system for distributing video content to devices, comprising: one or more servers; a network accessible storage device or devices; and a data network, wherein the system is configured to carry out the third method aspect of the invention and any preferred features thereof.

A further aspect of the invention provides a computer readable medium or media storing computer program code executable by one or more data processing devices to carry out the third method aspect of the invention and any preferred features thereof.

Other aspects of the invention also include a computer readable medium or media bearing computer program code or instructions executable by one or more data processing devices to carry out any of the method aspects of the invention and any of their preferred features.

Other aspects of the invention also include data processing apparatus configured to carry out any of the method aspects of the invention and any of their preferred features. In different aspects, the data processing apparatus may be a computer system, one or more servers or a mobile phone.

An embodiment of the invention will now be described in detail, by way of example only, and with reference to the accompanying drawings, in which:

Figure 1 shows a schematic diagram of a video distribution system according to the invention and including various apparatus according to the invention;

Figure 2 shows a flow chart illustrating different stages of operation of the video distribution system;

Figure 3 shows a data processing flow chart illustrating a video upload method; Figure 4 shows a data processing flow chart illustrating a video format conversion method;

Figure 5 shows a schematic representation of a data structure for storing the different video file formats;

Figure 6 shows a data processing flow chart illustrating a part of a video distribution method according to the invention;

Figure 7 shows a data processing flow chart illustrating a video delivery method according to the invention; and

Figure 8 shows a schematic block diagram of a data processing device according to the invention.

Similar items in the different Figures share common reference signs unless indicated otherwise. With reference to Figure 1 , there is shown a schematic block diagram of a video distribution system 100. The system, combinations of parts of the system, individual parts of the system and data processing methods of operation of the foregoing are all aspects of the invention. The video distribution system includes a client computer 102 associated with a first user 104 who wants to distribute one or more items of video content, i.e. one or more files of video data. The client computer 102 is in communication with a wide area network 106 such as the internet. A video distribution and delivery service 108 is also in

communication with the network 106 and includes at least one server 110 in

communication with a database 112. Sever 110 and database 112 are merely

representative of the video distribution and delivery service 108 which may in practice include multiple servers over which the functionality describe below may be distributed. However, for ease of explanation server 110 will be used to represent the video distribution and delivery service 108 Server 110 can be considered a web server in that it hosts a service accessible over the network 106 and also an application server as it hosts the distribution and delivery service application. However, separate web and application servers can also be used. A video formatting service 114 is also in communication with the network 106 and includes at least one server 116. Sever 116 is merely representative of the video formatting service 114 which may in practice include multiple servers over which the functionality describe below may be distributed. However, for ease of explanation server 5 114 will be used to represent the video formatting service. Server 116 hosts a video formatting service accessible over the network 106. In particular server 116 hosts software to convert video between different formats and includes a library of video codecs. For example, the FFmpeg tool can be used to provide the video format conversion for video files as described in greater detail below.

0

A network accessible storage service 118 is also in communication with the network and is represented by database 120. Database 120 is merely representative of the network storage service 114 which may in practice include multiple servers and storage devices which provide cloud storage of video files in various formats as will be described in5 greater detail below.

System 100 also includes a first mobile phone 122 associated with a first recipient user 124 and a second mobile phone 126 associated with a second recipient user. The first and second mobile phones are different in at least one respect. For example, they may be0 from different generations, have different hardware (such as display screen size,

resolution or aspect ratio), be provided by different manufacturers, use different operating systems (e.g. Android, iOS, Windows), use different versions of an operating systems, have different browsers (e.g. Chrome, Safari, Internet Explorer) or different versions of a browser. Furthermore, some devices have built in video players.

5

As will be appreciated there are a vast number of permutations of mobile phone hardware and software configurations that any one user may have. Also, these do not stay fixed, for example as users upgrade their software or change phones but retain their previous mobile phone number. Therefore, even if a user's phone configuration was known it may change0 in future while the user retains the same mobile phone number in an unpredictable way. It will also be appreciated that there are a plurality of different video encoding schemes and video file formats and that these are not all universally compatible with all mobile phones. Therefore, it can be very hard to ensure that a video will be viewable by a user in advance as the user's mobile phone cannot reliably be known in advance.

Each mobile phone 122, 126 provides a wireless telephony function (which inherently includes a short message service (SMS) or colloquially 'text messaging') and can also support a data connection to the network 106. Figure 1 illustrates the data connection being initially via a base station 130 of the mobile telephone network and then on via communication link 132 to the network 106. However, additionally or alternatively, the mobile phones 122, 126 may be able to connect via a Wi-Fi hub or some other wireless connection to the network 106 to provide the data connection 132 to the network. Hence, the actual nature of the data connection is not vital and any mobile phone from 2.5G onward should have a sufficient data connection capability. Each mobile phone 122, 126 also has some form of browser by which it can interact with the network 106 to make and receive requests. Each mobile phone may or may not have one or more video players resident on it. The expression 'mobile phone' is intended to be construed broadly to include any wireless communications device which has both a mobile telephone functionality such that it can receive an SMS message over a mobile phone network and also a data connection. Therefore, 'mobile phone' should be construed broadly to include smart phones, PDAs, tablet computers (which have a SIM card and hence mobile phone capability), and similar, for example.

Finally, Figure 1 also schematically illustrates a mobile terminated (MT) part 140 of a typical mobile phone network architecture. This includes base station 130, a terminating Mobile Switching Center (MSC) 142 for the phones 122, 126, assisted by a Visitor Location Registrar (VLR) database 144, and a centralized store-and- forward server known as an SMS Center (SMSC) 146, assisted by a Home Location Registrar (HLR) database 148. SMSC is also in communication with other parts of the mobile phone network (not shown) and also in communication with the network 106 from which it can receive SMS messages for distribution over the mobile phone network, e.g. from an SMS gateway server (not shown) on network 106.

The overall function of the system 100 will be described at a high level with reference to Figure 2, before being described in greater detail. As illustrated in Figure 2, the video content distribution and delivery system 100 has two different modes of operation: a video formatting mode 202 and a video delivery mode 204. As illustrated in Figure 2, the video formatting mode 202 generally occurs before video delivery 204 for a particular item of video content. However, the overall system 100 can be operating in video formatting and video delivery modes in parallel for different items of video content.

In the video formatting mode, a video distribution user 104 can upload a video file in an original format over the network using distribution service 108 and the video file is stored by the video distribution service 108 on the network storage 120. The video formatting service then converts the video file in its original format into a plurality of different formats (to be described in greater detail below) but which are generally sufficient to allow the video to be displayed on the large majority of currently existing mobile phone configurations (i.e. hardware and software). Once the original video file for the item of video content has been converted into the plurality of different formats but all for the same item of video content, then the item of video content is ready for distribution to users for viewing on their mobile phones. Also, as new mobile phones and/or new video formats are introduced, the video conversion engine can be updated to ensure future compatibility and universality of the system. The system 100 can then operate in a video delivery mode 204 in which the item of video content can be made available and delivered to recipients 124, 128. The distribution user 104 can communicate with distribution and delivery service 108 to select an item of video content to be distributed to one or more mobile phones. The distribution user notifies the distribution and delivery service of the mobile phone numbers of the or each mobile phone and the distribution and delivery service causes an SMS message to be sent to each mobile phone number and which includes a short direct link to the location of the item of video content on the network storage device 120.

If a recipient user views the SMS message on their mobile phone and selects or otherwise activates the short direct link, then the mobile phone's browser sends a request over the mobile phone's data connection to the distribution and delivery service which includes the short direct link and also one or more attributes relating to the software resident on the mobile phone, such as the type of operating system, the version of the operating system, the type of browser and the version of the browser. Using the received mobile phone attributes, the distribution and delivery service 108 can determine with reasonable reliability what the mobile phone is likely to be and from that determine exactly which video file format or formats will be compatible with that mobile phone and its current configuration.

The distribution and delivery service 108 can then initiate the transfer of video data for the item of video content from the network storage 120 to the mobile phone using the short direct link (which identifies the item of video content) and the determined compatible video file format. Hence, the video data for the item of video content can be streamed over the network to the mobile phone using the mobile phones data connection 132 and can reliably be displayed on the mobile phone as it is being delivered in a compatible format. Hence, video can be reliably delivered to the mobile phone, notwithstanding the potential incompatibility between the various video formats and mobile phone configurations that are in existence at any point in time.

In greater detail, Figure 3 shows a data processing flow chart illustrating a part of the video distribution method 300 of the invention which is implemented in software and is carried out by the video distribution and delivery service 108 and in particular server 110. Initially, at step 302, the method can create a new user account if the user 104 wishing to distribute an item of video content is a new user. However, if the user 104 is an existing user who already has a user account with the system, then step 320 is omitted and the user can simply be logged on by supplying a user name and a password. The distribution and delivery service 108 maintains a user accounts for each of a plurality of users of the system and database 112 stores various items of user account data for each different user. When the service 108 receives a request to upload a new item of video content, then at step 304, server 110 creates a new database record for the new item of video content. The item of video content record can include various data items relating to the item of video content such as a file name and a unique identifier for the item of video content which is unique throughout the system. An association between the record for the item of video data and the user account of the user who uploaded the video is maintained in the database 112. At step 306, the server 110 receives the up loaded file 308 of video data in an original format over the network 106 from remote computer 102. The original or master file of video data can be uploaded in whatever format the user wants and may be the format in which the video was created or a converted file format. As the original video file is available at the server 110, at step 312, the server 110 segments the video data into fixed sized segments, e.g. 5 Megabytes, and starts to transmit the file of video data in its original format in a sequence of 5 megabyte segments over network 106 to storage service 118 which receives the segments of the video file and stores them in storage device 120. As illustrated by process flow loop 312, the server 110 continues to send the 5 megabyte segments of the video file to the storage service 118 until the entire video file has been received and stored in storage device 120. Once the transfer of the original video file to storage service 118 has been started, method 300 can continue with the video file transfer continuing to occur as a back ground process. This helps to avoid delays in the uploading of video as the user does not need to wait for the entire file to be transferred to storage 120 before method 300 can continue. Sending the video file in segments also helps to avoid drop outs from causing the entire file transfer process to be restarted, rather than just having to send the relevant segment. This is particularly relevant for large video files. At step 314, server 110 extracts various items of metadata for the original video file, such as the size of the file in bytes, the image resolution (in pixels), the image aspect ratio, the ran time of the video (in seconds) and a screen shot from the video (as an image file, such as a .jpg). The extracted metadata 316 is then stored in database 112 either as part of or associated with the record for the current item of video content. Once the metadata has been extracted and written to the database and the original video file transferred to the network storage then at step 318 a report is sent to the client computer 102 of the uploading user 104 confirming that the video file has been successfully uploaded.

At step 320, server 110 sends a request to the format converting service 114 to instantiate one or more instances of a video format converter such as FFmpeg. The greater the number of instances, the more quickly a plurality of video file conversions can be carried out. But this needs to be balanced with the bandwidth of the network being able to deliver sufficient data and the currently available computing resources of server(s) 116. At step 322, server 110 creates a format conversion job queue which specifies a plurality of different format conversions to be carried out for the current item of video content.

There are a number of properties of the video that may need to be converted in order to be compatible with a specific phone and its current software. These include the video file or container format (e.g. mp4, ogg, mov, webm, wmv, 3gp, avi, flash, ProRes), the audio data format (e.g. aac, vorbis, wmav), the display size in pixels (e.g. 320 x 180, 480 x 270, 640 x 360, 730 x 410, 176 x 144, 320 x 240, 480 x 320, 480 x 360, 640 x 480, 800 x 480, 128 x 96, 352 x 288, 704 x 576, 1408 x 152). The system can also convert the bitrate of the file to accommodate variations in data connection bandwidth (e.g. 512k, 1024k, 192k, 256k, 384k).

It has been found that only a reasonably small subset of all possible combinations of these properties need to be generated in order to create at least one video format which will be compatible with the majority of currently existing mobile phone configurations. Server 110 maintains a list of approximately 30 different combinations of video properties which thus define approximately 30 different format conversion jobs for the conversion service 114 to carry out for the current item of video content. Each conversion job definition in the job queue includes a number of arguments or parameters which define each unique conversion job. Some conversion jobs may be quite simple, such as simply changing a single video property, such as the aspect ratio. Other conversion jobs may be more complex and may include changing the encoding format (or more accurately transcoding the video data if it is already encoded) and changing the video resolution and changing the aspect ratio. In the current example, each conversion job can be defined by the video file format or container, the audio encoding format, the display resolution (in terms of pixel width x pixel height) and, optionally, a bitrate.

Figure 4 shows a process flow chart illustrating an file format conversion method 400 carried out by server(s) 116 of the conversion service 114 in parallel with the operations of the server 110. Method 400 starts at step 402 with the receipt of a request to instantiate one or more instances of the video conversion program FFmpeg in response to step 320 of Figure 3. At step 404, the method requests a next file conversion job from the job queue maintained by server 110. In response to this request, server 324 notifies service 114 of the details of the next conversion job (in this example the first) and forwards whatever arguments or parameters are needed by the format conversion program to carry out the specific file conversion required. At step 406, method 400 determines that the job queue is not empty as it has received a next job and so proceeds to step 408 and downloads the video file in its original format 410 from network storage device 120. At step 410 a currently available one of the instances of FFmpeg converts the video file from its original format into a converted format according to the conversion specification provided by the job queue. The converted or re-formatted video file 414 is then sent back over the network at step 412 for storage on the network storage device 120.

Processing then returns to step 404 at which the method requests a next job from the job queue. If the job queue is determined not to be empty at step 326 of method 300, then server 110 sends the next conversion job specification over the network 106 and so at step 406 processing proceeds to step 408. If the next job is to convert or reformat the same item of video data as for the previous job then it is not necessary to download the original video file as it may be kept in local memory or storage by conversion service 114.

However, if the next job in the job queue is for a different item of video content to the previous job, then at step 410 the original video file for a different item of video content can be downloaded.

Hence, processing continues to loop until it is determined at step 326 that there are no jobs remaining in the job queue and hence at step 406 of method 400 processing proceeds to step 416 and format conversion service 114 reports at step 416 completion of the format conversion for the current item of video content to server 110. Then, the instances of FFmpeg are terminated and memory cleared at step 116 and method 400 ends until it is called again by server 110 when a new file conversion job queue has been established.

In the above described embodiment, the original video file is converted into a plurality of different formats but all having the same data rate. Hence, a default or standard data rate is specified in the job specifications in the job queue, such as 512kbit/s. This data rate is chosen so as to provide a reasonable quality of video over a widely available range of data connection bandwidths. However, in other embodiments, the 30 different file format conversions can be carried out for a plurality of different bit rates. Hence, after the file format conversion has been carried out initially for the standard data rate, the same group of file format conversions can be carried out at a higher data rate, such as 1024kbit/s (for use in cases where the mobile device has a broadband data connection) and/or at a lower data rate such as 192kbit/s (for use in cases where the mobile device has either a low data connection bandwidth or to avoid lengthy buffering before displaying video). The bit rate can be set as an argument in the job queue definitions such that there are effectively three job queues (a standard bit rate, a high bit rate and a low bit rate). However, as the data rate can be set on a job-by-job basis, the system can select which individual jobs to complete first at which data rate. Alternatively, steps 410 and 412 may simply be repeated three times, once for each different data rate.

Figure 5 shows a diagramatic representation of a data structure 500 used by network storage device 120 to store the various video data files for the various items of video content. The overall data structure 502 used by the system for storing the video data comprises a plurality of different addressable locations 504, 506, 508. Although three are shown in Figure 5 it will be appreciated that a greater or lesser number of locations can be provided as indicated by dots 510 and location 510 being represented in dashed lines. Each different location corresponds to a different one of a plurality of items of video data content. Hence location 504 corresponds to a first item of video content (e.g. a film), location 506 corresponds to a second item of video content (e.g. an advert) and location 508 to a third item of video content (e.g. a music video). Each location 504, 506, 508 includes a plurality of video data files in the approximately 30 different formats. For example the location 504 for the first item of video content stores files 520 to 534 each having a different format. For example all of files 520 to 528 may have video data encoded in the same way, but be formatted for different aspect ratios, or screen resolutions or combinations thereof. Similarly, all of files 530 to 534 may have video data encoded in the same way, but using a different encoding scheme to files 520 to 528, and be formatted for different aspect ratios, or screen resolutions or combinations thereof some of which may be the same as for files 520 to 528 and some of which may be different. As explained above, not all possible different combinations of video display properties need to be supported, only those which are required for the majority of currently available mobile phones. Hence, storage location 504 includes a plurality of video data files each having a different format, but all for the same item of video content. Similarly, storage location 506 includes a plurality of video data files 520' to 534' each having a different format to each other, but having the same formats as files 520 to 534, and all for the same item of video content (which is a different item of video content to 5 that offiles 520 to 534).

Hence, data structure 500 has a plurality of different locations each associated with a different one of a plurality of items of video content, and each location storing a plurality of files of video data each having a different format. In alternate embodiments in which 10 multiple different data rates are provided for either each location can be split into three sub-locations each storing files at a corresponding one of the different data rates, or the number of files in each location is simply multiplied by the number of different data rates.

As described above, on completion of the file conversion process 400 for a particular item

15 of video content, the process 400 reports back to the server 110 at step 416 and when doing so notifies server 110 of the address or location on the network storage device of the storage area, e.g. storage area 504, for the item of video content. At step 328, server 110 reports back to the client computer 102 of the uploading user 104 that the file conversion process has completed for the current item of video content. Finally at step

20 330 a short form direct link or address for the storage area is created by the server at step 330. The address needs to be short in order to ensure that it can be accommodated within an SMS message which is typically limited to 160 characters (although 140 in Canada). Also, the address is direct in the sense that it points directly at the location on the storage device at which the plurality of video data files are stored, rather than requiring some king

25 of re-direction service such as that provided by url shortening services. Hence, the

present invention is more reliable as it does not depend on the availability of an ancillary third party service. Rather, the short form address associated with an item of video data directly specifies the location on the network storage device at which the plurality of video data files in different formats are located. For example, the direct link or address

30 can be a six character alpha numeric string including upper and lower case characters, e.g.

33uTet. The direct link is then stored in the database record for the current item of video content in database 112. The six character string is a padded base 36 encoding of an integer which specifies the address on the storage device. Method 300 then ends for the current item of video content. If video uploading user 104 wants to distribute another item of video content then he can select to do so and method 300 begins again at step 304.

Hence, at this stage at least one item of video content is now available for distribution by the system 100. The distribution of video content proceeds by providing potential viewers of the item of video content with the mechanism to do so. Figure 6 shows process flow charts illustrating a further part 600 of the video distribution method of the invention in terms of corresponding client side 610 and server side 650 data processing operations.

At step 612, a browser application running on client computer 104 is pointed at the video distribution website hosted by server 110 and a request is sent from client computer 012 over network 106 to server 110 which services the request by serving at step 652 a home page of the website including a log on function back to client computer 102. The browser renders and displays the home page and the user 104 can enter their user name and password to log on to the website at step 614. The log on details are received by server 110 at step 654 and the user is authenticated nu accessing the user account details on database 112. The process can terminate if the authentication fails or a limited number of re-tries can be allowed. At step 656 user credentials are sent to the browser and stored on the client machine in a cookie as is well known in the art. Method 650 queries database 120 to identify all of the different items of video content associated with the user's account and retrieves a number of data items for each item of video content which are then served 658 to the client computer as a webpage 670 for the current user. The webpage and associated data includes, for each item of video content, the video name, a url for a thumb nail image, the unique ID for the item of video content and a url including the domain of the network storage device and the six character direct link or address, e.g. http://domain_name.tv/33uTet. A standard message text string, denoted Message$, such as "Please_watch_the_video_here:" is also sent with the webpage.

The web page and associated data 670 are received by the client computer 102 at step 616 and the webpage is rendered and displayed to the user 104 by the browser. The webpage can include a plurality of thumb nail images and associated video names, one for each different item of video content, arranged in a matrix. The user can select a one of the items of video content by clicking on one of the displayed the thumbnail images or video names which generates a video selection command at step 620. At step 622, the browser

5 can display a pre-formatted message composed of the standard message text string

Message$ and also the direct url corresponding to the selected item of video content, e.g. "Please watch the video here: http://domain name.tv/33uTet". At step 624, the user can optionally edit the message text if required and can then enter one or more mobile phone telephone numbers. For example a dialog box can be used to allow the user 104 to

10 manually type or cut and paste one or more mobile phone numbers. Alternatively or additionally, a user can import or select mobile phone numbers from a contact directory or attach a file of mobile phone numbers. In this example, it is assumed that the user somehow enters a first mobile phone number and a second mobile phone number associated with the first 124 and second 128 intended recipients respectively. At step

15 628, the browser sends a request 630 to the web server 110 which includes the message text and also the two mobile phone numbers. At step 660, web server receives the request 630 and extracts the message text, Message$, and the two mobile phone numbers, Mobile_#s, and marshals and sends a request to an SMS gateway server to send a first SMS message including Message$ to the first mobile phone number and a second SMS 0 message also including Message$ to the second mobile phone number.

The video distribution process is now effectively completed as the item of video content has been made available to potential viewers (analogous to broadcasting a TV signal) who now only need to select to view the item of video content (analogous to turning a TV on). 5 Hence, the item of video content can be considered effectively to have been distributed. The item of video content has been more reliably distributed than other approaches as there are typically fewer mechanisms preventing reception of the SMS message compared to other messaging formats (such as fire walls or spam filters). Also, many people tend to have only a single mobile phone number, rather than multiple email addresses, and also0 tend to keep their mobile phone number, rather than changing their email address, for example when moving jobs. Also, people tend to always read SMS messages as they are so short. However, many people delete mails merely form their subject line without ever reading the actual message body. Also, SMS messaging is a simple default functionality on mobile phones, and does not require the user to set up or configure an email account. Hence, the distribution method of the invention helps to ensure the availability of items of media content to a wider range of users for instance people with lower levels of technical knowledge or understanding.

Figure 7 shows a process flow charts illustrating a video delivery method 700 of the invention in terms of corresponding phone side 710 and server side 750 data processing operations. At step 712 a mobile phone, e.g. first phone 122 associated with first user 124, receives the SMS message including Message$ sent via the SMS service 140. At step 714, responsive to user input the phone 714 displays the SMS message on the phone's display, e.g. "Please watch the video here: http://domain name.tv/33uTet". As can be seen, the message is sufficiently short (preferably not more than 140 characters) to be fully received by SMS and displayed. Also, the displayed message includes a direct link to the location of the item of video content as the url includes the actual location or address of the video files at the network storage service 118. Hence, no re-direction or other ancillary service provided by some third party, such as a url re-direction service, is needed in or to access the video content. If the user decides not to activate or select the link, for example by simply closing or deleting the message, then the url is determined not to have been selected at step 716. Even if a user decides not to select the link, the invention still provides a more reliable way of distributing video content as the opportunity to access the video content has been provided to the user in a more reliable fashion than other communication mechanisms, such as, for example, email. Also, no internet connection to the mobile phone is needed in order to deliver the SMS message and therefore the video is more reliably distributed to potential viewers.

If the mobile phone 122 determines at step 716 that the link has been selected, for example by a user clicking on or touching the link, or via some other user interaction o input method, then at step 720 the browser application currently resident on the mobile phone prepares and sends a video request 730 over the data connection 132 to the distribution and delivery service 110 which is at the domain "domain name.tv". The video request 730 includes a number of data items including the short location of the item of video content, 33uTet, and has a HTML header which includes a plurality of data items which describe the mobile phone. For example, the data items can be attributes relating to the software currently resident on the mobile phone. These phone software attributes include, the type of operating system, the version of the operating system, the type of browser, and the version of the browser. The operating system, and its version, the browser, and its version, are identified in product tokens in the user-agent request-header field. Other product tokens can also be present in the user agent request-header field and used if needed in order to help identify the mobile phone. The video request 730 can also include any available data which indicates the nature of the data connection that the phone has. For example, this might be an IP address for the phone if the phone's data connection is via a broad band connection, e.g. Wi-Fi.

At step 752, the video distribution and delivery service server 110 receives the video request message 730. The service then determines at steps 754 and 756 which of the plurality of different formats for the item of video content is compatible with the requesting mobile phone. As discussed above, there is no way in advance to reliably know what the configuration of the requesting device and what format of video data file will be compatible with it. Hence, in order to reliably deliver the video content quickly, the service tries to reliably identify the requesting device and which video file format will be compatible with the requesting device. This is generally carried out using database look ups or queries and tables or other data structures which define or specify the relationship between the received software attributes and the types of phone and the video file formats supported by each type of phone. Database 112 maintains a table listing every, or at least the large majority of, currently available mobile phone having a suitable data connection (e.g. at least 2.5G compatible) and the combination of software attributes for each different phone. The combination of attributes does not necessarily need to be able to uniquely identify each different phone, as some groups of phones will all be able to support the same video file format. Hence, some of the different phones may have the same specific combination of attributes (e.g. the same operating system, the same browser, and the same display). The table can also include a data item for each phone which indicates whether the phone supports direct play or auto-play of streamed video. This can be a data field which is set to true (1) if the phone does support direct play and false (0) if it does not. Hence, once the phone, or group of phones, has been identified a further database look up or query is carried out to determine which video file format or formats are supported by the identified phone or group of phones. Database 112 also maintains a table listing each of the 30 or so different video file formats and a mapping or other association to all of the phones with which each format is compatible. Some of these mappings may be one-to- one, while many of the mappings may be one to many for example is a particular video file format is supported by or compatible with a multiple phones. The table also includes some indication of, or association, between each different video file format and the actual video data files, e.g. 520- 534, on the network storage device. This pre-configured, and, for example, may be a simple correlation, e.g. that the 15^th video file has the 15^th file format.

Optionally, the method 750 can also include determining what data transfer rate to use. For example, if an IP address is received in the video request form the phone, then the phone may be connected via a broad band connection and therefore a higher data transfer rate is likely to be possible. Hence, as well as determining the video file format, the method can also determine to use a video file format having a higher data transfer rate so as to supply a higher quality video image. Otherwise, a standard data transfer rate can be used which is lower but which is likely to guarantee delivery of the video data.

Additionally, or alternatively, the method 750 can include carrying out a speed test of the data connection to the mobile phone and then determining what data transfer rate to use based on the result of the speed test. For example, the method can send a thumb nail image data file of known size to the mobile phone for display prior to display of the video. The size of the image file is known and by measuring the time taken for the image file to be received by the mobile phone, then the server can determine the bit rate of the data connection. The server can then determine what data transfer rate for the video data file is appropriate based on the measured connection speed, e.g. a low, medium or high data transfer rate. This further helps to ensure that video is reliably delivered as the system can vary the data transmission rate based on the actual bandwidth of the data currently available. Hence, the sever 110 has now determined at least one of the plurality of video data files which has a format compatible with the mobile phone, and optionally also has the appropriate data transfer rate. At step 758, server 110 determines whether the mobile phone supports direct or auto-play or not. If not, then at step 760, the sever creates an html webpage in which a video player is embedded and which is served to the mobile phone and which includes the address of the network storage device, the location of the item of video content on the network storage device and the compatible video data file name, e.g. http://net_storage.com/33uTet/File_15.mov. If it is determined that the mobile phone does support direct or auto-play at 758, then the server 110 sends a re-direction command to point the mobile phones browser at the network storage device and at the compatible video data file. Hence, the video delivery service 108 has now initiated the transfer of video data in a compatible format to the mobile phone 122.

If the mobile phone 122 does not support direct or auto-play, then the mobile phone received the html page and embedded video player which is displayed by the mobile phone's browser. The user 124 can the enter a command to start the embedded video player and the browser contacts the network storage service 118 and requests the compatible video file format form storage device 120 and the video data 724 is streamed over network 106 and data connection 132 to the mobile phone and displayed 722 by the video player on the mobile phone's display device. Hence, only a second user interaction is required in order to display the item of video content. Alternatively, if the mobile phone supports direct or auto-play, then the mobile phone's browser automatically redirects form server 110 to network storage device 120 and video data 724 from the compatible file format is streamed to the mobile phone and automatically displayed 722 without requiring any further user interaction. The item of video content can continue to be displayed 728, until the mobile phone determines 726 that the video has finished or that the user has stopped the display of video, for example by entering a command or closing the browser or video player. Alternatively, or additionally, some mobile phones support a number of different messaging services, including SMS messaging, such that messages received via SMS, can be aggregated into a different or single messaging application. For example, on an iPhone 4 it is possible to merge SMS messages into the iMessage application. In that case, the user may select the direct link to the video content through the iMessage application. There is also the possibility to synchronise messages between different physical devices using iMessage in which case the Message application on any one of the different physical devices can be used to view the content of the SMS message, display the link and then the link be activated to cause the video to be downloaded to the particular device on which the link was activated, rather than the phone to which the SMS message was originally received.

Hence, the invention allows an item of video content to be uploaded in a first format and then allows that item of video content to be displayed on any mobile phone without knowing in advance what phone the video content may need to be delivered to. So, for example, an amateur film maker 104 may create a film using a professional camera and then upload the film in a first format using the video distribution and delivery service. In a private system, the film maker may then decide to distribute the film to a number of individuals 124, 128, for example contacts in the film industry whose mobile phone numbers are known. If the first individual 124 has, e.g., an iPhone 4 122 (iPhone is a trade mark which is registered in some countries) and the second individual 128 has a Galaxy III 126 (Galaxy is a trade mark which is registered in some countries) then both individuals will be able to view the video content irrespective of any incompatibility in screen size, resolution, video encoding formats, etc between the mobile phones and also the original video file.

As mentioned above, the first individual 124 may also have a second network connected device, such as an iPad (iPad is a trade mark of Apple Inc. which is registered in some jurisdictions) with which SMS messages can be synchronised via a messaging

application, such as iMessage. Then although the SMS message is originally sent to the mobile phone 122, the message and direct link may be synchronised with the first individual's iPad. The first individual can then display the message on their iPad, and activate the link on their iPad, in which case the iPad's software attributes are sent over the network connection at step 720 and hence a different video file is selected (at least because the iPad screen is larger than an iPhone screen) and streamed to the iPad. Hence, although the video content is distributed via SMS, the actual video content may be displayed on a different device to that to which the message was initially sent or addressed (by the mobile phone number).

Hence, the invention provides a reliable video content distribution and delivery mechanism for video content suitable for commercial or enterprise use.

In an open system, a person other than the uploader, can browse multiple items of video content and select to send one to one or more contacts whose mobile phone numbers are known. Hence, the invention can also provide a reliable video distribution and delivery mechanism for social use.

The inventors have found that even though SMS messaging appears not to be a suitable mechanism for distributing video content (as SMS messaging is limited to text messages of not more than 160 characters) and there is no universally compatible video standard for mobile phones, with care SMS messaging can provide a more reliable video distribution and delivery system than other communication mechanisms, such as email. Even though SMS and email are both store and forward messaging protocols, there tend to be more barriers to delivery of emails (e.g. spam filters, fire walls, etc) than SMS. Also, people tend to retain their mobile phone numbers and they are current whereas people can have multiple email addresses and they can change and become obsolete. Also, many less technically skilled people cannot set up email accounts but inherently will have SMS if they have mobile phone, for example some more elderly people. Further, in some developing countries, the personal computing platform stage has been jumped and people have moved straight to mobile phone platforms instead. Therefore adoption and use of email may be very low whereas SMS messaging is pervasive. Yet further, delivery of video by text messaging can be effectively instantaneous as the video can be delivered almost immediately that the user selects the link. This is because there is no need to open an attachment to an email, or any other significant ancillary steps that may be needed in other approaches. Hence, although there are significant technical difficulties in using SMS to reliably deliver video content, SMS turns out to be a better way of distributing video more reliably to more people, than easier to use distribution channels, such as email. Generally, embodiments of the present invention, and in particular the processes carried out by the various servers involved in the video distribution and delivery system, employ various processes involving data stored in or transferred through one or more computer systems. Embodiments of the present invention also relate to various apparatus for performing these operations. This apparatus may be specially constructed for the required purposes, or it may be a general-purpose computer selectively activated or reconfigured by a computer program and/or data structure stored in the computer. The processes presented herein are not inherently related to any particular computer or other apparatus. In particular, various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required method steps. A particular structure for a variety of these machines will appear from the description given below.

In addition, embodiments of the present invention relate to computer readable media or computer program products that include program instructions and/or data (including data structures) for performing various computer-implemented operations. Examples of computer-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto- optical media; semiconductor memory devices, and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The data and program instructions of this invention may also be embodied on a carrier wave or other transport medium. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

Figure 8 illustrates a typical computer system that, when appropriately configured or designed, can serve as a server part of the invention. It will be appreciated that a mobile phone also includes data processing apparatus similar to that shown in Figure 8, but omitting some parts shown in Figure 8 while also including mobile phone telephony components. The computer system 800 includes any number of processors 802 (also referred to as central processing units, or CPUs) that are coupled to storage devices including primary storage 806 (typically a random access memory, or RAM), primary storage 804 (typically a read only memory, or ROM). CPU 802 may be of various types including microcontrollers and microprocessors such as programmable devices (e.g., CPLDs and FPGAs) and unprogrammable devices such as gate array ASICs or general purpose microprocessors. As is well known in the art, primary storage 804 acts to transfer data and instructions uni-directionally to the CPU and primary storage 806 is used typically to transfer data and instructions in a bi-directional manner. Both of these primary storage devices may include any suitable computer-readable media such as those described above. A mass storage device 808 is also coupled bi-directionally to CPU 802 and provides additional data storage capacity and may include any of the computer- readable media described above. Mass storage device 808 may be used to store programs, data and the like and is typically a secondary storage medium such as a hard disk. It will be appreciated that the information retained within the mass storage device 808, may, in appropriate cases, be incorporated in standard fashion as part of primary storage 806 as virtual memory. A specific mass storage device such as a CD-ROM 814 may also pass data uni-directionally to the CPU.

CPU 802 is also coupled to an interface 810 that connects to one or more input/output devices such as such as video monitors, track balls, mice, keyboards, microphones, touch- sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU 802 optionally may be coupled to an external device such as a database or a computer or telecommunications network using an external connection as shown generally at 812. With such a connection, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the method steps described herein.

Although the above has generally described the present invention according to specific processes and apparatus, the present invention has a broader range of applicability. One of ordinary skill in the art would recognize other variants, modifications and alternatives in light of the foregoing discussion.

Claims

CLAIMS:

1. A method for delivering video content to a device, comprising:

receiving on a mobile phone via an SMS service an SMS message including a direct link to a location, the direct link being associated with an item of video content; transmitting a request to display the item of video including at least one attribute relating to at least one item of software resident on a device over a data connection from the device;

receiving the item of video content over the data connection in a format compatible with the device and based on the at least one attribute; and

displaying the item of video content on a display of the device.

2. The method of claim 1 , wherein the attribute indicates the current operating system of the device.

3. The method of claim 1 or 2, wherein the attribute is the current browser of the mobile phone.

4. The method of any of claims 1 to 3, wherein receiving the item of video content includes:

receiving an HTML page including an embedded video player; and

receiving a stream of video data for the item of video content and displaying the item of video content using the embedded player.

5. The method of any of claims 1 to 4, wherein receiving the item of video content includes:

receiving a stream of video data for the item of video content and displaying the item of video content using a video player resident on the device.

6. The method of any of claims 1 to 5, wherein the item of video content is automatically displayed when video data for the item of video content is received at the device.

7. The method of any of claims 1 to 6, wherein the device is the mobile phone.

8. The method of any of claims 1 to 6, wherein the device is a computing device having a messaging application which can synchronise SMS messages received by the

5 mobile phone.

9. A mobile phone which can communicate with a data network and being configured to carry out the method of any of claims 1 to 7.

10 10. A mobile phone and computing device being configured to carry out the method of any of claims 1 to 6 or 8.

11. A computer readable medium or media storing computer program code executable by one or more data processing devices to carry out the method of any of claims 1 to 8.

15

12. A method for delivering video content to a device, comprising:

receiving a video request for an item of video content over a data network from a device, the video request including a direct link to a location, the direct link being associated with the item of video content, and at least one attribute relating to at least one 0 item of software resident on the device;

determining from a plurality of available formats a compatible format for the item of video content which is compatible with the device using the at least one attribute; identifying a file of video data in the compatible format for the item of video content and being at the location; and

5 initiating the transfer of video data from the identified file of video data to the device via the data network by sending the direct link to the device over the data network.

13. The method of claim 12, wherein the at least one item of software resident on the device includes an operating system or a browser.

0

14. The method as claimed in any of claims 12 to 13 and further comprising: selecting a data transfer rate at which to transfer the video data to the device, and wherein identifying the file includes identifying a file of video data having the selected data transfer rate.

5 15. The method as claimed in claim 14, wherein selecting a data transfer rate includes:

determining whether an IP address for the device has been received; and selecting a data transfer rate higher than a default data transfer rate if the IP address has been received or selecting the default data transfer rate if the IP address has not been received.

10

16. The method as claimed in claim 14, wherein selecting a data transfer rate includes measuring the data transfer on a connection to the device over the data network.

17. The method of any of claims 12 to 16, wherein the plurality of available formats 15 includes one or more of the following: video file format; audio encoding format; video encoding format; display resolution; display aspect ratio; and video bitrate.

18. The method of any of claims 12 to 17, wherein initiating the transfer of video data further comprises serving a web page with an embedded video player to the device.

20

19. The method of any of claims 12 to 17, wherein initiating the transfer of video data further comprises sending a command to re-direct a browser to the location to the device.

20. The method of any of claims 12 to 19, wherein determining the compatible format 25 for the item of video content includes querying a database using the at least one attribute.

21. The method of any of claims 12 to 20, wherein identifying the file of video data in the compatible format includes querying a database using the compatible format.

30 22. The method of any of claims 12 to 21, wherein the device is a mobile phone.

23. The method of any of claims 12 to 21, wherein the device is a computing device having a messaging application which can synchronise with SMS messages received by a mobile phone.

24. A server or servers in communication with a data network and configured to carry out the method of any of claims 12 to 23.

25. A computer readable medium storing computer program code executable by a data processing device to carry out the method of any of claims 12 to 23.

26. A method for distributing video content to devices, comprising:

receiving a plurality of items of video content over a data network;

storing each of the plurality of items of video content;

assigning a direct link to each of the plurality of items of video content, each respective direct link being to a different location;

converting each of the plurality of items of video content into a plurality of different formats and storing a plurality of files of video data in the plurality of different formats;

for each of the members of a set of the plurality of video items, sending video information and the direct link to a browser over the data network;

receiving from the browser at least one of the direct links and a mobile phone number; and

sending a message including the at least one direct link and the mobile phone number to an SMS gateway to send the message as an SMS message to the mobile phone number.

27. The method as claimed in claim 26, wherein converting each of the plurality of items of video content includes transcoding from an original video encoding format to a different video encoding format.

28. The method as claimed in claim 26 or 27, wherein converting each of the plurality of items of video content includes changing at least one of the following: video file format; video encoding format; audio encoding format; display resolution; display aspect ratio; and bitrate.

29. The method as claimed in any of claims 26 to 28, wherein the video information includes at least one of: a video name; a link to a thumb nail image; a unique identifier for the item of video content; and a standard message text string.

30. The method as claimed in any of claims 26 to 29, further comprising:

receiving from the browser a message string including at least one of the direct links; and

sending the message string including the at least one direct link to the SMS gateway.

31. The method as claimed in any of claims 26 to 30, wherein converting an item of video content into a plurality of different formats includes instantiating a plurality of instances of an encoder.

32. The method as claimed in claim 31 , wherein the plurality of instances of the encoder are instantiated over a network connection on a remote server or servers.

33. The method as claimed in any of claims 26 to 32, wherein converting an item of video content into a plurality of different formats includes maintaining a job queue.

34. The method as claimed in any of claims 26 to 33, wherein each of the plurality of items of video content is stored on a remote network storage device and wherein each of the plurality of files of video data in different formats is stored on the remote network storage device.

35. The method as claimed in any of claims 26 to 34, wherein each of the plurality of the items of video content is sent in separate segments to a remote network storage device for storage.

The method as claimed in any of claims 26 to 35 and further comprising: extracting and storing a plurality of items of metadata for each of the plurality of items of video received over the data network.

37. The method as claimed in any of claims 26 to 36, wherein each direct link includes a unique address having not more than ten alphanumeric characters.

38. A system for distributing video content to devices, comprising:

a server;

a network accessible storage device; and

a data network, wherein the system is configured to carry out the method of any of claims 26 to 37.

39. A computer readable medium or media storing computer program code executable by one or more data processing devices to carry out the method of any of claims 26 to 37.