Title of Invention

PLAYBACK DEVICE AND METHOD FOR PROVIDING FUNCTIONALITY BASED ON EVENT INFORMATION RETRIEVED FROM A PLAYLIST

Abstract

ABSTRACT: Instead of using events stored in the datastream itself applications can retrieve event information from the playlist on a record carrier such as DVD and blu-disc. By retrieving the event information from the payiist changes in the event information do not require reprocessing of the data stream. In addition the application knows before the start of the playback of the data stream where the events are located and what functionality in terms of resources is required. A better schedulingof resources is thus possible. Fig. 4

Full Text

Playback device and method for providing fijnctionaJity based on event information retrieved from a playlist The invention relates to a playback device for retrieving a data stream comprising video data comprising a Java processor for processing an application, the Java processor comprising an input for receiving an event information, to a Java processor for processing an application, the Java processor comprising an input for receiving an event information and to a method for processing an Java application. Such a playback device is known &om set top boxes complying with the MHP standard. Such set topbox comprises a processor for processing an application, for instance a Java application. The Java application provides a functionally to the set top box that is related to the data stream being played back by the set top box. For this the Java application receives an event from the MHP video stream that indicates to the Java application that a certain position in the stream of video information is reached and that the associated fiinctionali^ is to be provided by the Java application. The event is stored in the video stream as a DSM-CC stream event. Storing the event in the stream has the disadvantage that the stream must be reprocessed if an event is to be changed. It is an object of the invention to provide a method that allows changes to the events without extensive processing of the data stream and while still being able to provide event information at the appropriate position during playback of the video or aucUo data. To achieve this objective the method is characterized in that the event information is retrieved from a playlist of the data stream. By retrieving the event information from the play list that is associated with the data sheam comprising video or audio data the event information is no longer retrieved from the data stream comprising the video or audio data. Since the event infonnation is not comprised in the data stream, reprocessing of the data stream is not required and the data stream can remain unchanged when the event information is changed. In addition, by r^ieving the event information &om the play list a timing correl^oo between the playback of the video or audio information in the data stream and tiie event information can be established. The playlist provides the playback device with information about when sections of the video or audio stream are to be played back. For instance a chapter mark indicating the start of a chf^jter can be used to activate ftinctiooali^ provided by a Java aplication that is related to this chapter. In this way the functionality associated to a chapter can be provided at the right moment, i.e. coordinated with the start of the playback of that chapter. Changing event information requires tbe reprocessing of the playlist, which results in substantially less processing compared to the situation where the data stream must be reprocessed to change event information. In addition the playback device benefits from having the event information in the playlist because it no longer needs to demultiplex the event information from the data stream, reducing the required processing resources. An additional advanlage is that the pJayback device is aware of die event Information before fte event arrives, because the playlist is retrieved before the events happen, and can thus schedule the launch of applications much better by anticipating the need to start the application and the anticipated processor work load at the moment of the start of the application and at the moment the event is reached during playback. Hence the event information retrieved from the playlist allows the same Junctionality to be implemented as event infonnation stored in the data stream itself, while avoiding the reprocessing of the data stream in order to change the event information. The object of the invention is consequently achieved. An embodiment of the meUiod is characterized in that the playlist comprises a mark with a presentation time and that the event information is information that the playback device reached the mark presen^on time during playback. Tlie application needs to know when the tiinctionality is to be provided. The event information is retrieved from the playlist before the event is reached. The application, now in the possesion of the event information subsequently monitors the progress of the playback and provide the functionality when the playback has progressed to the point indicated in the playlist. The application then provides flie functionality associated with the event. Alternatively the event infonnation can be provided to the application only at the moment the application must provide the fimctionallty. The processor in the playback device retrieves event infonnation fix)m the playlist and only provides the event information to the application when the processor determines that the playback reached that point in the data stream corresponding to the event information in the playlist. Thus a regular application can be used. The application does not need to monitor the progress of the playback of the data stream but relies on other processes running on the processor to monitor the play back of tiie data stream. Especially in the case of Java applications this is an advantage because the Java application does not need to be aware of lower level processes in the playback device and can be kept independent of the underlying hardware. A playback device according to the invention is ciiaracterized in that the event information is received from a playlist of the data stream. By retrievit^ the event information from the play list that is associated with the data stream comprismg video or audio data the playback no longer retrieves the event information from the data stream comprising the video or audio data. Since the event infonnation is no longer comprised in the data stream, reprocessing of the data stream is not reqiured and the data stream can remain unchanged whrai the event information is changed. In addition, by retrievii^ the event information from the play list a timing correlation between the playback of the video or audio information in the data stream and the event information can stiii be established. The playlist provides the playback device with information about when sections of the video or audio stream are to be played back. For instance a chapter marie indicating the start of a chapter can be used to activate functionality provided by a Java application that is related to (his chapter. In this way the fimdionali^ associated to a chf^)ter can be provided at the right moment, i.e. coordmated with the start of the playback of that chapter. Changing event information requires the reprocessing of the playlist only, which results in substantially less processing compared to the situation where the data stream must be reprocessed to change event information. In addition the playback device benefits from having the event infonnation in the playlist because it no longer needs to demultiplex the event information from the data stream, reducing the reqmred processing resources. An additional advantage is that the playback device is aware of the event information before the event arrives, because the playlist is retrieved before the events happen, and can thus schedule the launch of applications much better by anticipating the need to start the application and the anticipated processor work load at the moment of the start of the application and at the moment the event is reached during playback. Hence by retrieving the event information from the playlist the playback device is able to provide the same fimctionality as when the event information is stored in the data stream itself, while avoiding the reprocessing of the data stream in order to change the event information. The object of the invention is consequently achieved. An embodunent of the playback device is characterized in that the Java processor comprises means for providing the event information to the application. The flppJication needs to know when the functionality is to be provided. The event information is retrieved from the playlist before the event is reached. The application, now in the possesion of the event information subsequently monitors the progress of the playback and provide the functionality when the playback has progressed to the point indicated in the playlist. The application then provides the fiinctionali^ associated with the event. Alternatively the event information can be provided to the application only at the moment the application must provide the fimctionali^. The processor in the playback device retrieves event inforoiation &om the playlist and only provides the event information to the application when the processor determines that the playback reached that point in the data stream corresponding to the event information in the playlist Thus a regular application can be used. The application does not need to monitor the progress of the playback of the data stream but relies on other processes running on the processor to monitor the play back of the data stream. Especially in the case of Java applications this is an advantage because the Java application does not need to be aware of lower level processes in the playback device and can be kept independent of the underlying hardware. A further embodiment of the playback device is characterized in that the playlist comprises a mark with a presentation time and that Qie event information is information that the playback device reached the mark presentation time during playback. A mark can have a presentation time which is the tune in the playback of the data stream when the presentation of a section of the data stream commences or stops. This an event A functionality can be associated with this event An application is used to provide this liinctionali^. A further embodiment of the playback device is characterized in that the maik is a chapter mark or a skip mark or a link maik. Chapter marks, skip marks and link marks are already defined in the playlist. It can be beneficial to provide functionality through a Java application to the user when a new chapter on the record carrier starts, or ends. For instance when an interactive record can-ier complying with the DVD or blu-disk standard reaches a new chapter, the functionali^ may include displaying an interactive menu specially tailored to the video content of the chapter reached. Similar ftmctionality may be provided in association to the skip mark or the link mark. A further embodiment of the playback device is characterized in that the mark is reserved for use by the application Special mari:s may be inserted in the playltst. The special marks are not recognized by the playback device as regular playlist entries and thus current playback devices that do not comprise this invention can still correctly playback the information on the record carrier. Playbck devices comprising the present invention recognize the special marks and provide the special marks to the Java application. AH advantages of storing the event information in marks in the playlist as discussed above are maintained when special marks are placed in and retrieved from the playlist while compatibiliQ' with the existing playback devices is mwntained as well. A fiirther embodiment of the playback device is characterized in that the mark comprises fiirther mformation for the application. Application infonnation may be appended to the marie. In that case the event information is derived from the mark itself while in addition the application information is provided to the application started by the event information. This allows more flexibili^ and more customization of the functionality provided by the application. Because current playback devices do not recognize the additional infonnation the additional information is ignore during playback and compatibility of a record carrier comprising additional infonnation in the playlist for existing marks is achieved. A Java processor according to the invention is characterized in that the event information is received from a playlist of a video stream. By retrieving the event information from the play list that is associated with the data stream comprising video or audio data the playback no longer retrieves the event information from the data stream comprising the video or audio data. Since the event infonnation is no longer comprised in the data streamj reprocessing of the data stream is not required and the data stream can remain unchanged when the event inforraation is changed. In addition, by retrieving the event information from the play list a timing correlation between the playback of the video or audio information in the data stream and the event infonnation can still be established. The playlist provides the playback device with information about when sections of the video or audio stream are to be played back. For instance a chapter mark indicaling the start of a chapter can be used to activate functionality provided by a Java application that is related to this chapter. In this way the functionality associated to a chapter can be provided at the right moment, i.e. coordinated with the start of the playback of that chapter. Changing event information requhes the reprocessing of the playlist only, which results in substantially less processing compared to the situation where the data stream must be reprocessed to change event infonnation. In addition the playback device benefits itom having the event mformation in the playlist because it no longer needs to demultiplex the event information &om the data stream, reducing the required processing resources. An additional advantage is that the playback device is aware of the event information before the event arrives, because the playlist is retrieved before the events happen, and can thus schedule the launch of applications much better by anticipating the need to start the application and the anticipated processor work load at the moment ofthe start of the application and at the moment the event is reached during playback. Hence by retrieving the event information from the playlist the playback device is able to provide the same fiinctionality as when the event information is stored in the data stream itself, while avoiding the reprocessing ofthe data stream in order to change the event information. The object ofthe invention is consequently achieved. The invention will now be described based on figures. Figure 1 shows a playback device comprising a Java processor. Figure 2 shows the application layers. Figure 3 shows a flow chart ofthe method where the top level application layer monitors the progress ofthe playback ofthe dafa stream. Figure 4 shows a flow chart of another embodiment ofthe method where tiie intermediate layer monitors the progress ofthe playback ofthe data stream. Figure 1 shows a playback device comprising a Java processor. The playback device 2 is arranged for retrieving data, comprising a data stream, &om the record carrier J. TTw record carrier can be a DVD or a Blu-disk or any other record carrier comprising a data stream comprising video information and a playlist The playback device comprises a basic engine 3 for retrieving the data form the record carrier 1. The basic engine 3 is connected to a processor 4 via a bidhectional mterface. The processor can, via the bidirectional inter&ce. instruct the basic engine to retrieve data from locations on the record carrier I indicated by the processor 4. The processor 4 can tiius instruct the basic engine 3 to retrieve a playlist from the record carrier 1 and to retrieve data comprising a data stream, or sections there of, from the record carrier I. After the processor 4 received tlie playlist from the basic engine 3 the processor 4 retrieves event information fonn the playlist in a first section 7 of the processor 4 and provides monitors whether the playback of the record carrier reached the location of one of the events retrieved from the playlist When the playback reaches the location of an event the fint section of the processor provides the event information to a second section 6 of the processor that is used to run an application for providing a certain functionality when the location of a certain event is reached during playback. The application run by the second section 6 of the processor receives the event information and provides a functionality for instance in the form of video information to be displayed on a television set or monitor coupled to the playback device 2, In order to provide the ftincdonality the second section 6 provides, in the example of video information, the video information to an output means 8 in the processor. The output means 8 provides the received video information obtained fix)m the second section 6 to an output 9 of the playback device 2. The outpxA 9 is connected to a television set or a monitor for viewing the video information. The first section 7 comprises monitoring means to monitor the progress of the playback of the video information but can also comprise the decoding of the video information. The first section is in that case also coupled to the output means 8 in order to provide the video information to the output 9 of the playback device 2. The output device can consequently, if provided with the video information of the functionality provided by the application and the video information obtained from decoding tile video information in the data stream, output both at the same time, fiir instance by providmg the video information from the data stream full screen and inserting the video information associated to the functionality provided by the application that received the event information mto video information from the data stream. In case the functionality associated with the event provided by the application is a menu, the playback of the video information from the data stream can be halted until a choice from the menu is made. The menu can in that case be full screen and the video information from the data stream can be suppressed. Figure 2 shows the explication layers. The hardware layer 20 is made independent of the top application layer 22 by an intermediate layer 21. Instructions from the top application layer, for instance a Java application are provided to the intermediate layer 21. The intermediate layer 21 translated the instructions for the hardwrae layer 20, thus allowing the top application layer to be completely independent of the hardware layer 20. As explained in figures 3 and 4 there are two alternative solutions for handling the event information. - the top application layer 22 monitors the progress of the playback of the data stream - the intermediate layer 21 monitors the progress of the playback of the data stream. When the top application layer 22 monitors the progress of the playback of the data stream the top application layer 22 requests retrieval of the playlist from the record carrier. This request, given to the intermediate layer 21 is translated and the intermediate layer 21 requests the retrieval of the playlist by the hardware layer 20. The liardware layer 20retrieves the playlist from the recording medium and provides the playlist to the intermediate layer 21. The intermediate layer 21 than translates the playlist into the correct format for the top qipUcation layer 22. The top application layer 22 processes the playlist and retrievest the event information. Based on the event information the top aplication level 22 starts monitoring the progress of the playback by requesting playback progress status reports from the intermediate layer 21, which in turn request these playback progress status reports from the hardware layer 20. Once a playback progress status report is received, from the hardware layer 20 through the intermediate layer 21, indicating that the playback has progressed to the point in the data stream associated with the event derived from the event information, the top level ^plication starts providing the flmctronalily associated with the event. When the intermediate layer 21 monitors the progress of the playback of the data stream the intermediate layer 21 requests retrieval of the playlist from the record carrier. The intermediate layer 21 requests the retrieval of the playlist by the hardware layer 20. The hardware layer 20retrieves the playlist from the recording medium and provides the playlist to the intermediate layer 21. The intermediate layer 21 than extracts the event information from the playlist. Based on the event information the intermediate level 21 starts monitoring the progress of the playback by requesting playback progress status reports from the hardware layer 20. Once a playback progress status report is received indicating that the playback has progressed to the point in the data stream associated with the event derived from the event information, the intermediate level 21 provides the event information to the top level application 22 which can then in turn start providing the functionality associated with the event Figure 3 shows a flow chart of the method where the top level application layer monitors the progress of the playback of the data stream. In a first step 30 the top level application request the retrieval of the play list Once tiie playlist is retrieved the event information is extracted from the playlist in a second step 31. The event information is then provided to the top level aaplication in a third step 32. Subsequently the top level application, in a fourth step 33, requests the processor, i.e. as explained an intermediate level application running on the processor, to monitor the progress of the playback of the data stream. This intermediate level application running on the processor monitors, in a fifth step 34 ,the progress of the playback of the data stream in a fifth step comprising a loop. The intermediate level ^plication checks whether the playback has progressed to a certain point If the playback has not reached the event location the mtermediate application continues to monitor. If the playback reached the event location a report is issued in the fifth step 34 to the top level aplication, the operation of the fourth step 33 continuing fitim this point and advancing to the sixth step 35 where the application starts providing the functionality associated with the event. Thus the event information provided in this case is the location of the event The top level application is aware of the monitoring of the playback and is waiting, expecting a trigger in the form of information about the status of the playback fixjm another application that actually performs the monitoring. Figure 4 shows a flow chart of another embodiment of the method where the intermediate layer monitors the progress of the playback of the data stream. In a first step 40 the top level application request the reoieval of the playlist. Once the playlist is retrieved the event information is extracted from the playlist in a second step 41. The event information is then provided to the an intermediate level aplication in a tiiird step 42. Subsequently the intermediate level application, running on the processor starts monitoring the progress of the playback of the data stream. The monitoring of the progress of the playback of the data stream in the fourth step 44 comprises a loop. The intermediate level application checks whether the playback has progressed to a certain point. If the playback has not reached the event location the intermediate ^plication continues to monitor. If the playback reached the event location a report comprising the event information retrieved from the playlits is issued in the fifth step 43 to the top level plication. The method then advances to the sixth step 45 where the application starts providing the fimctionality associated with the event Thus the event information provided in this case is the actual reaching of the event by the playback. The top level application is not aware of the monitoring of the playback but gets a trigger in the form of the event infoimation from another application that actually performs the monitoring. WE CLAIM: 1. Playback device (2) for retrieving a data stream comprising video data, the data stream to be played in accordance with a playlist, the playback device comprising a Java processor (4) for processing an application relating to a content of the data stream, the Java processor (4) comprising an input for receiving an event information for causing the Java processor (4) to process the application, characterized in that the event information is received from a the playlist of the data stream. 2. Playback device (2) as claimed in claim I, wherein the Java processor (4) comprises means for providing the event information to the application. 3. Playback device (2) as claimed in claim 1 or 2, wherein the playlist comprises a mark with a presentation time and that the event information is information that the playback device reached the mark presentation time during playback. 4. Playback device (2) as claimed in claim 3, wherein the mark is a chapter mark or a skip mark or a link mark. 5. Playback device (2) as claimed in claim 3, wherein the mark comprises a chapter mark or a skip mark or a link mark. 6. Playback device (2) as claimed in claim 3, wherein the mark is reserved for use by the application 7. Playback device (2) as claimed in claim 6, wherein the mark comprises further information for the application. 8. Java processor (4) for processing an application relating to a content of a data stream, the data stream to be played in accordance with a playlist the Java processor (4) comprising an input for receiving an event information for causing the Java processor (4) to process the application, characterized in that the event information is received from a the playlist of a video stream. 9. Method for processing an Java application relating to a content of a data stream, the data stream to be played in accordance with a playlist, the method comprising the steps of starting a Java application starting playback of a data stream comprising video information or audio information retrieving an event information (31,41) for causing the Java processor to process the application (35, 45), providing the event information to the Java application (32,42) characterized in that the event information is retrieved (30,40) from s the playlist of the data stream. jO. Method for processing an Java application as claimed in claim 9 wherein the playlist comprises a mark with a presentation time and that the event information is information that the playback device reached the mark presentation time (33,43) during playback.

Documents:

1648-CHENP-2006 FORM-13.pdf

1648-chenp-2006 abstract-duplicate.pdf

1648-chenp-2006 abstract.jpg

1648-chenp-2006 abstract.pdf

1648-chenp-2006 claims-duplicate.pdf

1648-chenp-2006 claims.pdf

1648-chenp-2006 correspondence-others.pdf

1648-chenp-2006 correspondence-po.pdf

1648-chenp-2006 description (complete)-duplicate.pdf

1648-chenp-2006 description (complete).pdf

1648-chenp-2006 drawings-duplicate.pdf

1648-chenp-2006 drawings.pdf

1648-chenp-2006 form-1.pdf

1648-chenp-2006 form-18.pdf

1648-chenp-2006 form-26.pdf

1648-chenp-2006 form-3.pdf

1648-chenp-2006 form-5.pdf

1648-chenp-2006 pct search report.pdf

1648-chenp-2006 pct.pdf