Video content playback

Abstract

A video content playback device (1410) comprising the following: a first video content player that is operable to start playing video content comprising several images to be displayed at appropriate times; a processing unit designed to load a second video content player in response to the first video content player initiating video content playback; A content control transmission unit designed to transmit control of the playback of video content from the first video content player to the second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content; characterized in that: the processing unit is designed to detect a data entry associated with the video content that identifies the second video content player; and The second video content player is located in an application environment, with the processing unit designed to start the application environment in response to a detection of the data item associated with the video content.

Description

BACKGROUND Technical area

[0001] This disclosure concerns video content playback. Description of the state of the art

[0002] The background information provided here serves the purpose of a general presentation of the context of this disclosure. Work by the inventor named herein, to the extent described in this background section, as well as aspects of the description that could not otherwise be considered prior art at the time of filing, are neither expressly nor implicitly incorporated as prior art in relation to the present disclosure.

[0003] It is known that viewers are able to access video content provided, for example, by a third party via a set-top box (STB) or directly through a television set. Arrangements like these can be used in the context of a television channel providing, for example, media library services for its programs or an on-demand service for video content. These services may be provided by the content provider free of charge (often with a lot of advertising to generate revenue for the content provider) or on a subscription or paid basis.

[0004] In this context, delivering video content can be achieved by launching an application associated with the content provider. This allows the viewer to browse a selection of available programs or other video content, choose a preferred item, and then start playback. Alternatively, a list of available content can be delivered to the set-top box (or other device), and the viewer can use this list to make a selection within a native application without first launching the application. Once a selection has been made, the appropriate application corresponding to the video content is then launched, and playback can begin.

[0005] Each of these approaches results in an associated delay in the start of the video content playback process, which may be undesirable for a viewer. This is usually attributed to the initial loading of the application to view the content or the loading of the application to play the content once a selection has been made. The present disclosure provides an arrangement for reducing this delay.

[0006] WO 2015 / 191 180 A1 describes a display mode-based change of a media player.

[0007] US Patent 2013 / 0074131A1 discloses a system and a method for integrating and controlling web-based HTML players in a native context.

[0008] The document US 2007 / 0162852A1, chosen for the preambles of independent claims 1, 11 and 14, describes a method and an apparatus for changing the codec for playing back video and / or audio file streams encoded by different codecs within a channel.

[0009] From CN 1 02 647 634 A a method and a device for playing videos with multiple fragments based on HTML 5 are known.

[0010] CN 1 03 945 240 A discloses a method and a device for video playback based on video aggregation.

[0011] A method and a device for selecting a video player are known from CN 1 03 702 215 A.

[0012] US 2009 / 0328124A1 reveals an adaptive video switching system for variable network conditions.

[0013] US patent 2014 / 0096166A1 discloses techniques for interrupting the playback of recorded multimedia content or live television on a multimedia player and resuming playback from the point of interruption on the same or a different multimedia player. SUMMARY

[0014] The present disclosure addresses and mitigates the problems that arise from this processing.

[0015] Respective aspects and features of the present disclosure are defined in the attached claims.

[0016] It is understood that both the preceding general description and the following detailed description are exemplary, but not limiting, for the technology at hand.

[0017] According to a first aspect, the present invention provides a video content playback device according to claim 1. According to a second aspect, the present invention provides a method for playing back video content according to claim 11. According to a third aspect, the present invention provides computer software according to claim 12. According to a fourth aspect, the present invention provides a non-transient, machine-readable storage medium according to claim 13. According to a fifth aspect, the present invention provides a data structure used in the video content according to claim 14. Further aspects of the present invention are described in the dependent claims, the drawings, and the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] A more complete understanding of the revelation and many of its associated benefits is easily grasped when they become clear with reference to the following detailed description, when viewed together with the accompanying drawings, in which: Fig. 1 schematically illustrates the time sequence of a video playback process; Fig. 2 schematically illustrates an exemplary native user interface for video selection; Fig. 3 schematically illustrates a control transmission process; Fig. 4 schematically illustrates a control transfer process with a buffer step; Fig. 5 schematically illustrates an exemplary data structure; Fig. 6 schematically illustrates a series of images at a GOP boundary; Fig. 7 schematically illustrates a control transmission process; Fig. 8 schematically illustrates a time sequence of a control transmission process; Fig. Figure 9 schematically illustrates a control transfer process in which the content is paused; Fig. Figure 10 schematically illustrates a time sequence of a control transmission process in which the content is paused; Fig. Figure 11 schematically illustrates a control transfer process in which a search operation is performed; Fig. Figure 12 schematically illustrates a control transfer process using a UI; Fig. Figure 13 schematically illustrates a control transfer process in which the content is DRM-protected; Fig. Figure 14 schematically illustrates a hardware arrangement for implementing a control transmission process; Fig. 15 is a schematic flowchart illustrating a sequence of processing steps performed by a server and a sequence of processing steps performed by a client; and Fig. Figure 16 schematically illustrates a server and a client. DESCRIPTION OF THE EXECUTION FORMS

[0019] Fig. Figure 1 is a schematic illustration outlining a video playback method according to the present disclosure. It is described in the following section. Fig. 1. It will become apparent that there are many different variations within this procedure, and the relative durations of various events as shown are not intended to be scaled, and therefore the passage of time should not be considered limiting. With reference to Fig. The features discussed above are described in more detail below with reference to further figures.

[0020] The process shown in chronological order begins in stage 10 with the selection of an item to be played. This could be a selection from a number of programs offered by a source, such as a television media library service provider or a local storage device, or it can be omitted entirely if the video content is to be started without a selection (for example, an autoplay video). In response to the initiation of video content playback, a first, or native, video player is loaded in stage 20. This is a video player associated with the host device rather than the video content being played.

[0021] The players can be executed in software code and stored on or provided by a non-transitory machine-readable medium.

[0022] For example, the video content can be downloadable or streamed content, such as from a server and / or over a network or internet connection, or it can be content obtained through a peer-to-peer system, or it can be locally stored content, such as on a removable storage device. The video content can include one or more associated audio tracks or other audio content and, optionally, one or more types of selectable subtitles. The video content can comprise multiple video content items rather than a single piece of content. For example, the video content could comprise a playlist of short video fragments, each residing on a server, with each fragment identified by a Universal Resource Indicator (URI).A first video player can be designed to receive data for video content in response to the initiation of video content playback.

[0023] Once the native player is loaded, video playback begins in stage 30. The video's runtime is represented by line 31, with a scale factor of 90, which is used schematically to show that the video can run for a longer period than would be appropriate to display on any reasonable scale. It is understood that a buffering period can be performed before playback begins, and that buffering can be implemented in any number of ways, some of which are discussed below.

[0024] In stage 40, an 'aitx' box is detected in the associated metadata for the video content, a data structure corresponding to an application information table. This contains information about an associated video playback application, which is the preferred client for managing the video, as determined by the content provider. Other methods for providing this information might be implemented, such as using a different box in the header or identifying the video's source during selection. The 'aitx' box is described in more detail below. Stage 40 provides an example of how a processing unit is designed to detect a data entry associated with the video content that identifies the second video content player.

[0025] Upon reading the 'aitx' box at stage 40, or in other words, in response to the first player initiating playback, a suitable application environment is booted at stage 50. This environment might be a processing unit designed to load a second video content player in response to the first video content player playing the video content. This application environment could be, for example, a web browser and is capable of loading an application at stage 60, such as an HTML5 player intended to control playback and function as a second video content player. (HTML5 stands for HyperText Markup Language version 5 and represents, for example, a markup language used to structure and present internet content.)This application may, relative to the native player, have additional functionality as well as a different user interface (UI) and branding related to the video content provider. Therefore, this provides an example of a second video content player located within an application environment, where a processing unit is designed to launch the application environment in response to the detection of the data item associated with the video content.

[0026] The application loaded in level 60 provides an example of a second video content player.

[0027] Control of video content playback is inherited in stage 70 from the application loaded in stage 60, so that the UI (user interface, for example, one or more controls have a screen display) is associated with this application and any additional features are now accessible to the viewer.

[0028] In the context of this disclosure, 'inherited' means that control of video content playback is transferred from one player to another. This can be accomplished in a number of ways and should not be seen as limited to a process in which one player hands over control to another. For example, this term should also be understood to represent a transfer or reassignment of control. A transfer in this context could mean that the first and second video content players each play an active role in either relinquishing or receiving control of the video content.In this context, a reassignment of control could refer to the operation of a third-party application capable of transferring control from one player to another without either player necessarily playing an active role in the transfer. Alternatively, the video content player assuming control could actively take over control of playback from the other player. The use of the word "transfer" in any of the described embodiments can be understood to mean any of these options or any other related process in which control of playback is transferred from one player to another.

[0029] Although shown at a point where the application finishes loading, control transfer can be implemented before the application is fully loaded; for example, control of the application's content could be transferred once sufficient resources to handle playback have been loaded. Once playback control has been transferred at level 70, the native player can be unloaded at level 80, as it is no longer needed for playback. However, it can be reloaded at a later point (such as at level 100), for example, towards the end of video playback, to control the transition from the video content to the native UI (such as menus associated with the display device rather than the video content provider).

[0030] A content control transmission unit (discussed below) can be designed to transmit the control of the playback of the video content from the first video content player to a second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content.

[0031] Fig. Figure 2 shows a schematic example of a video content selection screen as an example of a user interface by which a viewer can select video content to display. The display 200 shows a number of options 210 (with icons representing currently displayed options AE, and any icons corresponding to further options hidden), all of which may come from the same video content provider or from multiple providers. The vertical arrows 220 may be provided, which typically allow a user to navigate (for example) between different providers or content categories, while the horizontal arrows 230 allow users to navigate between icons representing a content list from the same provider or category.These icons could be displayed in a carousel format, allowing a user to continuously cycle through them to make a selection, either using the horizontal arrows 230, or they could be grouped together so that, for example, selecting one of the horizontal arrows 230 would present a completely new set of icons. The use of this interface has been described in the context of using a cursor to navigate through the options; however, alternatively, the icons themselves could be moved, and whichever icon is in the center slot (C in the figure) is the one to be selected if and when the user presses an "Enter" key, for example, on a remote control device—the center slot could be highlighted in some way (such as with a border) to communicate this to the user.In this embodiment, arrows 220 and 230 are not selectable, but instead indicate to the user that further options are available for selection that are not currently displayed.

[0032] Similarly, this type of user interface can be used for playing content stored locally on a hard drive or removable medium - for example, arrows 220 could correspond to changing a storage medium (such as from an internal hard drive to a USB flash drive) and arrows 230 could correspond to navigation icons representing the respective media files stored on the currently selected medium.

[0033] When receiving content, it may be desirable to buffer it. This means that a portion of the video content is downloaded and stored locally before playback begins. This video buffering is performed to provide viewers with a virtually uninterrupted viewing experience, as data is stored for a set duration or amount of time before playback. Furthermore, playing back video content represented by this data means that varying network conditions have less of an impact on video playback.

[0034] Video buffering can be initiated while the viewer scrolls through the screen to reduce the delay in displaying the content once it has been selected. This buffering is implemented as a predictive feature and could therefore, in preparation for a selection, take the form of buffering the content associated with the icon C in the screen. Fig. 2 (corresponding to the center icon). It is also possible to buffer more than one video, for example, the content corresponding to center icon C, and the content represented by options on either side of it (B and D, so that 3 videos are buffered at any given time), or all of the options currently available for selection on the screen. In other implementations, the content corresponds to a predetermined number of icons that immediately previously occupied the center slot. The latter options provide a more robust buffering implementation than the first option, as they allow a user to move between options without necessarily discarding the content already buffered for a previous option, should they then choose to continue selecting.Alternatively, buffering could be performed for content determined by other means, such as a prediction based on a viewer's previous viewing statistics. A less recently written file could be flushed from the buffer or deleted in response to a different icon being selected.

[0035] This arrangement therefore provides an example of using a video buffer associated with the first video content player, in which video content is pre-buffered by the video buffer before a playback operation is requested, and an example of an arrangement in which a second video content player is designed to use a buffer associated with the first video content player to continue playing the video content.

[0036] Once buffering is complete and the content selection has been made, the native player associated with the system is started and begins playing the video.

[0037] Fig. Figure 3 schematically illustrates the in Fig. The process described in section 1 is a sequence of steps rather than a chronological sequence. In the first step, content to view is selected (300), and playback is started in the native player (310). An application environment is then loaded (320) (in accordance with the information contained in the AIT), and an application is loaded within that environment (330). Control of playback is then transferred from the native player to the loaded application (340), and playback continues seamlessly (350). Optionally, the native player (360) is reloaded at a later point during playback.

[0038] In the context of player control transfer, "seamless" means there is no pause in the display of frames. Frames intended to be presented to the viewer at a predetermined time (a corresponding display time for each frame) continue to be presented at that time despite the player control transfer, so the viewer remains unaware of the transition, except for any UI changes or similar. An example of how to implement this is to use an invisible, full-screen window that appears when the application environment starts. This invisible window allows the viewer to see the content displayed by the native player, but once the application is fully loaded, the invisible window is used to display the content instead.Since the window is already loaded and present on the screen, the disruption caused by the transition between video content players is reduced.

[0039] Fig. Figure 4 schematically illustrates a similar procedure in which there is a buffer step 400 for the content. In the figure, buffering 400 takes place in the first step before the selection of the content to be viewed (as previously with reference to Fig. 2 was discussed) instead (or at least is started), although it is understood that this step could take place after the selection 410 of the content to be viewed. After the content to be viewed has been selected 410, playback is started in the native player 420. An application environment is then loaded 430 (in accordance with the information contained in the AIT) and an application is loaded within that environment 440. Control of playback is then transferred from the native player to the loaded application 450 and playback continues seamlessly 460.

[0040] Fig. Figure 5 shows an exemplary data structure 500 used for video content, comprising a header 510 and audio and video information, or A / V information, 520. In this arrangement, information is added to or otherwise enclosed with the header 510 to indicate the details of an application that should be launched to control video content playback. In one embodiment, this is in the form of an Application Information Table (AIT), which, depending on the desired format, is represented by an 'aitx' or 'aitb' box (XML or binary XML expression). A box is an object defined in the MP4 / ISOBMFF standards (ISO Base Media File Format (ISO - International Organization for Standardization)), and boxes are used as containers to hold all the data in such a file.Boxes are specified by a four-character code identifier (for example, 'ftyp') to ensure that the correct box is read to locate the desired data. The 'aitx' / 'aitb' box is now discussed in the context of an MP4 / ISOBMFF file as an example of an implementation procedure and provides an example of a data structure used in video content. This data structure is read during playback by a first video content player to indicate that a second video content player should be started to take over control of video playback.

[0041] The 'aitx' box could be provided as part of a film atom (moov) or could be fragmented and distributed as accompanying metadata. Further examples of 'aitx' boxes could be placed at various points within the video content.

[0042] A schematic example of an 'aitx' box (in this example contained in a container 'meta' instead of a 'moov') is as follows: Box Type: 'aitx' Container: Meta box ('meta') Mandatory: No Quantity: Zero or one (Note: More than one, there should be a larger XMLAIT with more XML in it...). aligned(8) class XMLAITBox extends FullBox('aitx', version = 0, 0) { string xml;

[0043] An ISOBMFF file consists of several boxes that act as containers to hold data such as video content and metadata. Each of these boxes is identified by a four-character code and can contain other boxes. For example, the first box in the file is `ftyp`, which defines the file type and compatibility information and does not contain any other boxes within it. There are several places in the file where a box can be used that does not have a pre-specified function. In one implementation, the `meta` box is selected, and a box is created within this highest-level box, called `aitx` or `aitb`, depending on whether it is in XML or binary XML format. This box contains information about the application that should be launched to control video playback, such as an application information table.It is understood that this procedure can be applied to a number of different file types that include support for new data to be inserted into the header.

[0044] HbbTV (Hybrid Broadcast Television) features a concept of bi and br application launch modes, where br denotes broadcast-related operation and bi denotes broadcast-independent operation. These indicate the respective modes in which an HbbTV application can launch. If launched from the broadcaster, the application starts in br mode (and broadcast AV can be controlled). If launched from a portal or application, it starts in bi mode (no access to broadcast AV unless certain other measures are taken). Furthermore, the native application interface can specify / override which type of launch occurs. The native app would also decide whether to parse, interpret, and auction signaling data in the stream. For a bi-start

[0045] One technique for making this transition seamless is as follows: The video object must be present in the Document Object Model (DOM) JavaScript tree at page load time; this means that a video object will be created and correctly configured with the correct @src if either one or more of the following conditions are met: body.onload() has finished; or A script triggered by "@run-at document-start" was executed. the @src="rec: / / current-media-player" (a command that sets the video source to be played as the current media player of the TV receiver). Alternatively, a child <source> The element can also be used instead of the @src attribute.

[0046] For a BR start, media playback would continue while the application boots and loads. The application is not visible until `application.show()` is called, where `application` is an instance of an `application` object, as defined in HbbTV. Inheritance or transmission therefore occurs before `show()` is called. There is no video / broadcast object while it is loading—even if there were, it wouldn't display anything after `application.show()` because no broadcast is taking place.

[0047] The <video>< / video> indicates a written src attribute (or child) <source> element) which is, for example, rec: / / current-media-player. The currentSrc, when read, is the media URL belonging to the media asset that the native application used.

[0048] Once inherited, all other video attributes and state variables are set to what they would otherwise be if the video content playback had reached its current state had it initially been loaded from an HTML environment. Events from 4.7.10.16 of [HTML5] would fire, but possibly directly, bypassing some of the state machine's states to reach its actual current state.

[0049] Once the application environment and the application have loaded, playback control is transferred from the native application to the new application. This can be handled in any number of ways, as will now be described with reference to Fig. 6-12 is described.

[0050] Fig. Figure 6 shows a set of frames 600 that constitute part of the video content. Frames 610 belong to a first group and frames 640 to a second, with each group of frames potentially corresponding to a portion of a group of images (GOP) as used in video encoding methods. It may be desirable to perform the playback control transfer at a boundary between two GOPs, as this is a natural breakpoint during playback. Performing the transfer at any time other than a GOP boundary would require both content players to process the same GOP due to the dependencies of the images contained within it. This can be undesirable because of the additional processing required to prepare the same set of images for display twice.

[0051] In the context of Fig. 6. Control can be transferred to the loaded application at the boundary between frames 620 and 630, either during the display of frame 620 or at any other time before it, with appropriate timing information (for example, transferring playback control at the next GOP boundary). This transfer would not necessarily have to occur during the display of the GOP marked with the A's; it could equally be implemented in any GOP before it, with the playback control transfer being delayed until the boundary between frames 620 and 630. It should be noted that frames 620 and 630 do not necessarily have to differ in their aesthetic content; for example, operational control could continue to be transferred during looped content or if the same frame is continuously output during a pause.

[0052] Accordingly, the content control transmission unit in examples is designed to transmit control of the video content at a GOP boundary in the video content.

[0053] Fig. Figure 7 schematically illustrates a playback control transfer process according to the present embodiments. In this process, the application is loaded at 700, and then at 710 a determination is made that the content is displayed in a standard playback mode, which means that no operations affecting playback, such as pausing or searching, are performed.

[0054] The control is then transferred to application 720. Fig. Figure 8 schematically illustrates the time sequence of a transfer according to this process.

[0055] Fig. At 800, time 810 indicates the start of playback, with the application environment and application loading at that time. Time 810 does not necessarily have to correspond exactly to the time required to load the application. If the application loads before the end of time 810, it can wait for a signal to take control of content playback at a later time or to initiate the transmission process earlier. In this figure, transmission at time 820 is signaled by a flag. However, transmission could also be handled by performing it after a predetermined time has elapsed for the video content (thus allowing sufficient time for loading and preparing the application) or, for example, after a set duration during or after the application has loaded. Following this, at period 830, the application controls content playback.

[0056] Fig. Figure 9 schematically illustrates a corresponding process when the content is paused during the period in which the control transfer is performed. The application loads (900) and a pause in the video content is detected (910). Transfer (920) of the video content continues in this embodiment, and the first UI switches to the second in a crossfade operation (930). It is understood that these steps can be performed in any order or substantially simultaneously—for example, the UI could be switched before the application is fully loaded, temporarily blocking any unloaded functionality, whether a pause is detected or not.In these examples, the content control transmission unit is designed to transmit playback state information (such as a pause state) of the video content to the second video content player; and the second video content player is designed to begin playing the video content according to the playback state information.

[0057] Fig. 10 is a time sequence that schematically illustrates an alternative embodiment in which a control transfer is carried out during a pause, although it could be equally applicable to other operations such as searching, as with reference to Fig. As described in section 11, playback continues from period 1000 until pause 1020, during which the application is loaded in period 1010 and prepared for control transmission during pause 1020. However, the transmission is delayed until period 1030, after pause 1020 has ended. The transmission is performed when playback resumes at period 1000 and is implemented in a standard manner equivalent to immediate playback of the content.

[0058] With Fig. 10. For example, the content control transmission unit can be designed more generally to delay the control transmission of the video content during one or more of the following: (i) Playback-modifying operations performed on the video content (such as pause, shuttle, skip and the like); or (ii) Using a user interface associated with the first video content player.

[0059] Fig. Figure 11 schematically illustrates a Fig. 10. The corresponding process relates to a search operation. The application loads at 1100, and a detection that a search operation is being performed is made at 1110. The control transfer is then delayed at 1120 until the search operation is complete and normal playback resumes, at which point the transfer is performed at 1130. A delay in the transfer can be implemented in several ways; for example, loading could be paused in response to an operation being performed related to video content playback. Alternatively, the application loading could be aborted during the operation, with the application loading restarting when normal playback resumes. Both in Fig. 10 as well as in Fig. 11. The transfer can be further delayed once the pause / search operation has been completed; it does not necessarily have to be performed immediately.

[0060] Fig. Figure 12 schematically illustrates a process where control transfer is delayed when the UI is in use. An application is loaded (1200), and a detection is made (1210) that the UI is either in use or simply displayed to a viewer. Transferring control of playback while the UI is in use could be inconvenient for the user if it caused the UI to switch from the native player to the loaded application, as this would require the user to leave the native UI. Therefore, it may be desirable to delay the transfer (1220) until the UI is no longer in use or displayed, switching at a point after which normal playback resumes in a manner similar to that described in Figure 12. Fig. 10 and Fig. 11 was resumed. Alternatively, control transfer could be implemented such that the loaded application controls playback and only the UI of the new player is in use until a point when the native UI is no longer in use or displayed.

[0061] Although many of the above embodiments were described with reference to a transfer process at the beginning of content viewing, they can be applied equally to other points in time. For example, a transfer could be performed toward the end of the content such that the native player controls playback for most of the viewing time. This could be used to provide the viewer with additional content options to choose from (for example, a message of the type "related programs") that are associated with the provider of the loaded application.Another alternative is to allow switching of control for the purpose of displaying advertisements during content playback, with the native player or a loaded application (either one associated with the content being shown or another application specifically designed to deliver advertisements) handling most of the content playback, while the other is used to deliver advertisements to the viewer. In this embodiment, the control transfer can be handled in the same way as described above, but with a higher frequency and by signaling when the advertisement should be displayed; for example, the native player can interrupt the display via the loaded application, or both could be provided with timing information signaling the times at which the transfer should be initiated.

[0062] Fig. Figure 13 schematically illustrates another application of the transmission method described above. In this embodiment, the content selected for viewing (1300) is protected by DRM (Digital Rights Management). This content could have been obtained from a variety of sources, such as those discussed previously, as long as the associated application, which is intended to be used for playback, can identify the content as protected. This could be done, for example, by reading associated metadata or watermark detection. Playback is initiated in a native player (1310), and the application environment is loaded in response to the AIT (1320). An application is then loaded (1330), and control of the player is transferred (1340).Once the transmission is complete (1340), the application is able to read metadata associated with the content and determine that it is protected by DRM. At this point, the viewer is prevented from viewing further content and is optionally presented with payment options for access (1360).

[0063] In some implementations, the viewer is instead given a warning, but is allowed to view the content for a predetermined period; for example, the viewer may be allowed to watch the first 10 minutes of a program or film as a sample to generate interest, increasing the chances that the viewer will continue to purchase access to the content.

[0064] Control can be transferred back to the first video content player, either at the end of video playback or during video playback (for example, to isolate each commercial break). In examples, the content control transfer unit is designed to transfer control of the video content back to the first video content player at the end of video playback or in response to the detection of another data item associated with the video content, where the additional data items indicate a transfer back to the first video content player.

[0065] Fig. Figure 14 schematically illustrates a hardware arrangement used to implement a procedure as described above. A content source 1440 is provided, which may be, for example, a set-top box, an internet connection, optical media, or a USB flash drive. The content is fed to a processing unit or circuit arrangement 1410, which includes a content processing unit or circuit arrangement 1420, a buffer or buffer circuit arrangement 1430, and a control transmission unit or circuit arrangement 1440. Output video content is fed to the display 1450 for display.

[0066] The content processing unit 1420 receives content from the content source 1400 and performs any necessary decoding operations to prepare the content for display. The content processing unit 1420 thus provides an example of a first video content player that can begin playing video content comprising multiple images to be displayed at appropriate times. Information about the transmission process (such as the A / V time) is passed to the control transmission unit 1440, while A / V content is prepared for display and stored in a buffer 1430, ready to be fed to the display 1450. Alternatively, the buffer 1430 can store undeciphered content data.

[0067] The control transmission unit 1440 receives information about the transmission, such as which application should be launched, when the transmission should take place, and any other information, such as details of any DRM protection of the content. The control transmission unit 1440 is then operational to launch the appropriate application environment and application and to implement the transmission of playback control in a manner corresponding to any of the embodiments described above. In examples, the video content is protected by Digital Rights Management, and the second video content player is designed to, in response to a control transmission to the second video content player, offer the viewer an option to purchase access to the video content.

[0068] The content transfer unit thus provides an example of a processing unit designed to load a second video content player (for example, as an application to be executed by the content processing unit that is separate from an application providing the first video content player) in response to the first video content player initiating playback of the video content;and a content control transmission unit designed to transmit control of the playback of the video content from the first video content player to a second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content.

[0069] Buffer 1430 stores data for multiple images to be displayed on screen 1450. Buffer 1430 is designed to be used by both the native player and the loaded application during transmission, rather than each application necessarily having its own separate buffer.

[0070] Fig. 15 and Fig. 16 concern the techniques discussed above, which are executed in an exemplary server-client context.

[0071] Fig. Figure 15 is a schematic flowchart illustrating a sequence of processing steps performed by a server (a set of steps delimited by a dashed rectangle 1500) and a sequence of processing steps performed by a client associated with (for example, having a data connection with) the server (a set of steps delimited by a dashed rectangle 1510). As far as the server is concerned, it performs the steps shown within rectangle 1500, and as far as the client is concerned, it performs the steps within rectangle 1510. Therefore, the steps within rectangle 1500 can be viewed as a process with respect to a server, and the steps within rectangle 1510 can be viewed separately as a process with respect to a client.Apart from that, dashed lines are provided between the two to indicate how the two procedures are related to each other.

[0072] The terms "client" and "server" refer to the relationship between the two systems, in that the "server" performs some of the functionality discussed below. No other limitations are intended by the terms "client" and "server".

[0073] The procedure concerning the server includes: • Detecting (in one step 1520) the playback of video content using a first video content player that includes multiple images to be played at corresponding display times; • Sending (in one step 1530), via an interface (which may include an interface 1650, see below), payment option data relating to the video content; • Receiving (in one step 1540) a statement of purchase data; • in response to the provision of purchase data, sending (in one step 1550) instructions which, when executed, in response to the first video content player initiating playback of the video content, load a second video content player from electronic storage; and • Sending (in one step 1560) data that allows the transfer of control of the playback of the video content from the first video content player to a second video content player, such that the multiple images instructed to be displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images instructed to be displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content.

[0074] The procedure concerning the client includes: • Executing playbacks using a first player in one step 1570; • Displaying received payment option data and capturing a user response to the payment option data; transmitting data indicative of the user response to the server (in one step 1580); • Loading a second player (in one step 1590); and • Transferring control to the second player (in one step 1595).

[0075] In an example system, the control flow between these two methods can proceed as follows: • Step 1520 reacts to step 1570; • Step 1580 responds to step 1530; • Step 1540 responds to step 1580; • Step 1590 responds to step 1550; • (Optional) Step 1560 responds to step 1590 (or in other examples, the server can simply impose a suitable delay between steps 1550 and 1560 to allow step 1590 to be executed); and • Step 1595 responds to step 1560.

[0076] Fig. Figure 16 schematically illustrates a server 1600 and a client 1610 (which may be one of several clients associated with the server 1600).

[0077] The server includes the following: a detector 1620 designed to detect the playback of video content using a first video content player comprising several images to be displayed at corresponding display times; a receiver 1630 designed to receive a statement of purchase data; and a transmitter 1640 designed to transmit, via an interface, payment option data relating to the video content and, in response to the specification of purchase data, to send instructions which, when executed, load a second video content player from an electronic memory in response to the first video content player initiating playback of the video content, and to send data which allows the transfer of control of the playback of the video content from the first video content player to a second video content player, such that the multiple images instructed to be displayed by the second video content player are each displayed at their respective display times, as if they had been displayed by the first video content player.and the first of the several images instructed to be displayed by the second video content player and the last of the several images displayed by the first video content player in the video content are subsequent images.

[0078] The client 1610, connected to the server via a data connection 1650, comprises a first player 1660, an interface and a controller 1670 (for receiving information from the server, sending information to the server and controlling the operation of and the transmission of control between the first player and the second player) and a second player 1680.

[0079] In summary, embodiments of the present disclosure relate to the playback of a video stream in a native application / interface. The video stream contains application signaling that can be used to boot a non-native application / interface. This application would then boot and seamlessly inherit control of the video playback. Three features are (a) signaling of the non-native application / interface; (b) rules for seamless inheritance; and (c) initial timing constraints for the first few milliseconds when the non-native application / interface takes control of the video.

[0080] Insofar as embodiments of the disclosure have been described, at least in part, as being implemented in a software-controlled processing device, it is understood that a non-transitory machine-readable medium carrying such software, such as an optical disk, a magnetic disk, a semiconductor memory or the like, is also considered to represent an embodiment of the present disclosure.

[0081] It is understood that the above description, for the sake of clarity, has described embodiments with regard to different functional units, circuit arrangements, and / or processors. However, it is obvious that any distribution of functionality between different functional units, circuit arrangements, and / or processors can be used without deviating from the embodiments.

[0082] The described embodiments can be implemented in any suitable form, including hardware, software, firmware, or any combination thereof. Optionally, the described embodiments can be implemented, at least partially, as computer software running on one or more data processors and / or digital signal processors. The elements and components of any embodiment can be implemented physically, functionally, and logically in any suitable manner.

[0083] In fact, the functionality can be implemented in a single unit, in multiple units, or as part of other functional units. Therefore, the disclosed embodiments can be implemented in a single unit or can be physically and functionally distributed between different units, circuit arrangements, and / or processors.

[0084] Although the present disclosure has been described in connection with some embodiments, it is not intended that it be limited by the specific form set forth herein. Although a feature may appear to be described in connection with certain embodiments, a person skilled in the art would additionally recognize that various features of the described embodiments can be combined in any suitable way to implement the technology.

[0085] It is evident that, in light of the above teachings, numerous modifications and variations of the present disclosure are possible. It is therefore understood that the technology, within the scope of protection of the attached claims, can be exercised in ways other than those specifically described herein.

[0086] The respective embodiments are defined by the following numbered sections: 1. A video content playback device comprising the following: a first video content player that is operable to start playing video content comprising several images to be displayed at appropriate times; a processing unit designed to load a second video content player in response to the first video content player initiating video content playback; and A content control transmission unit designed to transmit control of the playback of video content from the first video content player to a second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content. 2. Device according to Section 1, wherein the processing unit is designed to detect a data item associated with the video content that identifies the second video content player. 3. Device according to Section 2, wherein the second video content player is located in an application environment, wherein a processing unit is designed to start the application environment in response to detection of the data item associated with the video content. 4. Device according to any of the preceding sections, wherein the first video player is designed to receive data for video content in response to the initiation of playback of the video content. 5. Device according to section 4, comprising a user interface by means of which a viewer can select video content for display. 6. Device according to any of the preceding sections, wherein the content control transmission unit is designed to transmit control of the video content at a GOP boundary in the video content. 7. Device according to one of the preceding sections, wherein: The control transmission unit is designed to transmit playback status information of the video content to the second video content player; and The second video content player is designed to begin playing the video content according to the transmitted playback state information. 8. Device according to any of the preceding sections, wherein the content control transmission unit is designed to delay the transmission of control of the video content during one or more of the following: (i) playback-modifying operations performed on the video content; or (ii) Using a user interface associated with the first video content player. 9. Device according to any of the preceding sections, wherein the content control transmission unit is designed to transmit control of video content back to the first video content player at the end of video content playback or in response to detection of another data item associated with the video content, wherein the other data items specify a transmission back to the first video content player. 10. Device according to any of the preceding sections, wherein: the video content is protected by Digital Rights Management and the second video content player is designed, in response to a control transmission to the second video content player, to give the viewer an option to purchase access to the video content. 11. Device according to any of the preceding sections, comprising a video buffer associated with the first video content player, and in which video content is pre-buffered by the video buffer before a playback operation is requested. 12. Device according to Section 11, wherein the second video content player is designed to use a buffer associated with the video content player to continue playing the video content. 13. A method for playing back video content, wherein the method comprises the following steps: Starting to play video content using an initial video content player that includes multiple images to be played at corresponding display times; Loading a second video content player in response to the first video content player initiating video content playback; and Transferring control of video content playback from the first video content player to a second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content. 14. Computer software which, when executed by a computer, causes the computer to perform the procedure described in Section 13. 15. A non-transitory machine-readable storage medium that stores computer software in accordance with Section 14. 16. A data structure embedded in the video content, which is read by a first video content player during playback of the video content to indicate that a second video content player should be started to take over control of video content playback. 17. A procedure comprising the following: Detecting, in a server, the playback of video content using a first video content player that includes multiple images to be played at corresponding display times; Sending, via an interface, payment option data of the video content; receiving a statement of purchase data; in response to the provision of purchase data, sending instructions which, when executed, in response to the initiation of video content playback by the first video content player, load a second video content player from electronic storage; and Sending data that allows the transfer of control of the playback of the video content from the first video content player to a second video content player, such that the multiple images instructed to be displayed by the second video content player are each displayed at their respective display times, as if they were displayed by the first video content player, and the first of the multiple images instructed to be displayed by the second video content player and the last of the multiple images displayed by the first video content player are successive images in the video content. 18. A server that includes the following: a detector designed to detect the playback of video content using a first video content player comprising multiple images to be displayed at corresponding display times; a receiver designed to receive a statement of purchase data; and a transmitter designed to send, via an interface, payment option data relating to the video content and, in response to the specification of purchase data, to send instructions which, when executed, load a second video content player from electronic storage in response to the first video content player initiating playback of the video content, and to send data which allows the transfer of control over the playback of the video content from the first video content player to a second video content player, such that the multiple images instructed to be displayed by the second video content player are each displayed at their respective display times, as if they had been displayed by the first video content player.and the first of the several images instructed to be displayed by the second video content player and the last of the several images displayed by the first video content player in the video content are subsequent images. 19. A non-transitory, computer-readable medium containing computer program instructions which, when executed by a computer, cause the computer to perform the procedure described in Section 17.

Claims

[1] A video content playback device (1410) comprising the following: a first video content player that is operable to start playing video content comprising several images to be displayed at appropriate times; a processing unit designed to load a second video content player in response to the first video content player initiating playback of the video content; a content control transmission unit designed to transmit control of the playback of the video content from the first video content player to the second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content; characterized by , that: the processing unit is designed to detect a data entry associated with the video content that identifies the second video content player; and the second video content player is located in an application environment, with the processing unit designed to start the application environment in response to a detection of the data item associated with the video content. [2] Device (1410) according to claim 1, wherein the first video content player is designed to receive data for video content in response to the initiation of a playback of the video content. [3] Device (1410) according to claim 2, comprising a user interface by means of which a viewer can select video content for display. [4] Device (1410) according to any one of claims 1 to 3, wherein the content control transmission unit is designed to transmit the control of the video content at a GOP boundary in the video content. [5] Device (1410) according to any one of claims 1 to 4, wherein: The content control transmission unit is designed to transmit playback status information of the video content to the second video content player; and The second video content player is designed to begin playing the video content according to the transmitted playback state information. [6] Device (1410) according to any one of claims 1 to 5, wherein the content control transmission unit is designed to delay the transmission of the control of the video content during one or more of the following: (i) playback-modifying operations performed on the video content; or (ii) Using a user interface associated with the first video content player. [7] Device (1410) according to any one of claims 1 to 6, wherein the content control transmission unit is designed to transmit the control of video content back to the first video content player at the end of video content playback or in response to detection of a further data item associated with the video content, wherein the further data item specifies a transmission back to the first video content player. [8] Device (1410) according to any one of claims 1 to 7, wherein: the video content is protected by digital rights management and the second video content player is designed to give a viewer an option to purchase access to the video content in response to a control transmission to the second video content player. [9] Device (1410) according to any one of claims 1 to 8, comprising a video buffer associated with the first video content player, in which the video content is pre-buffered by the video buffer before a playback operation is requested. [10] Device (1410) according to claim 9, wherein the second video content player is designed to use a buffer associated with the first video content player to continue playing the video content. [11] Method for playing back video content, the method comprising the following steps: Commencing (310) the playback of video content using a first video content player comprising several images to be played at corresponding display times; Loading (330) a second video content player in response to the first video content player initiating playback of the video content; Transferring (340) control of the playback of the video content from the first video content player to the second video content player, such that the multiple images displayed by the second video content player are each displayed at their respective display times as if they were displayed by the first video content player, and the first of the multiple images displayed by the second video content player and the last of the multiple images displayed by the first video content player are sequential images in the video content; characterized by , that the procedure includes: Detecting (320) a data entry associated with the video content that identifies the second video content player; and Starting (320) an application environment in response to a detection of the data item associated with the video content, wherein the second video content player is located in the application environment. [12] Computer software which, when executed by a computer, causes the computer to execute the method according to claim 11. [13] Non-transitory machine-readable storage medium that stores computer software according to claim 12. [14] Data structure (500) used in the video content, which is read during playback of the video content by a first video content player to indicate that a second video content player should be started to take over control of the video content playback, characterized by , that the second video content player is located in an application environment that should be started when reading the data structure.

Images