Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/845—Structuring of content, e.g. decomposing content into time segments
  • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
  • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
  • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
  • H04N21/440281—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the temporal resolution, e.g. by frame skipping
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
  • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
  • H04N21/637—Control signals issued by the client directed to the server or network components
  • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server

Definitions

• TITLE Management of management of the provision of segment addresses of multimedia content
• the field of the invention is that of managing the supply of segment addresses of multimedia content to a content reading device.
• the invention is particularly aimed at segmented content, the segments being accessible in several formats associated with respective sizes in bytes having more or less impact on the bandwidth of the network on which the content is downloaded.
• the invention particularly targets content downloaded using a technique called adaptive progressive downloading, or HAS, or any other downloading techniques using the same principle.
• a reading device When accessing content, a reading device generally sends a request to a server, indicating the chosen content; the reading device receives in return a stream of digital data relating to this content.
• a request In the context of a local communications network, such a request passes through the network access gateway, for example the residential gateway.
• the reading device is adapted to receive digital content in the form of multimedia data and to request a restitution of this content on a reproduction device.
• Received data corresponding to a video is generally decoded and then rendered as a display of the corresponding video with its associated soundtrack.
• the distribution of digital content on the Internet is often based on client-server protocols from the HTTP family (Hyper Text Transport Protocol).
• HTTP family Hyper Text Transport Protocol
• progressive mode downloading of digital content also called streaming, makes it possible to transport and consume data in real time, that is to say that the digital data is transmitted over the network and restored by the reading device as they progress arrival.
• the reading device receives and stores part of the digital data in a buffer memory before restoring them.
• This distribution method is particularly useful when the bandwidth available to the user is not guaranteed for the real-time transfer of the video.
• Adaptive progressive downloading in English HTTP Adaptive Streaming, abbreviated HAS, also makes it possible to broadcast and receive data in different qualities corresponding for example to different bit rates. These different qualities are described in a description file, called a “description file” by those skilled in the art, available for download on a data server, for example a content server.
• this description file makes it possible to select the correct format for the content to be consumed depending on the available bandwidth or the storage and decoding capabilities of the client reading device.
• This type of technique makes it possible in particular to take into account bandwidth variations on the link between the client reading device and the content server.
• Start Over allows a user who is watching content broadcast in real time (Live channel) to select a reading moment in a given time window; This function allows you to reread content from its beginning.
• a time window is particularly useful for so-called “live” digital content, ie which corresponds to television programs in real time, which do not, by nature, have a predefined duration or end date.
• the reading device receives a command to perform a time jump in the content to read the content, for example a television broadcast, from a time prior to the current reading time. For example, if a film starts at 9:00 p.m.
• catch-up mode we go from real-time reading mode to catch-up mode.
• the reading device retrieves at regular intervals, generally every two seconds, a description file which generally describes the last sixty seconds of the stream (30 segments of 2 seconds) by providing segment addresses corresponding to these last sixty seconds.
• a description file which generally describes the last sixty seconds of the stream (30 segments of 2 seconds) by providing segment addresses corresponding to these last sixty seconds.
• the video segments are short because we want to be as close as possible to the real thing. This is also why we retrieve the description file every two seconds and we generally limit the buffer depth to around fifteen seconds.
• the description file which is retrieved no longer describes the last sixty seconds but a time window of several hours, for example the last four hours (in the case where you want to be able to access the last 4 hours of the Live channel).
• the size of the description file is therefore multiplied by two hundred and forty (240) and the reading time (or parsing time for those skilled in the art) of the description file, most of the time in XML format, becomes a real problem. . Indeed, it is necessary to retrieve, as when reading the stream in real time, the description file periodically every two seconds and with each recovery browse the entire description file which includes a very large number of addresses of video and audio segments.
• One solution could be to reduce the time window, for example to two hours instead of four hours. In this case, the service provided to the user is greatly degraded because it is not guaranteed to be able to return, for example, to the beginning of the film he is watching.
• the invention improves the situation.
• the invention relates to a method for managing the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively the one after the other for reading by a reading device, characterized in that it comprises, during the transmission of the content in real time, a step of receiving a command to perform a time jump in the content to read the content from a time prior to the current reading time, the reception step triggering a step of transmitting a second description file comprising segment addresses to be read at said previous time, supplemented with part of the addresses of content segments which have already been transmitted.
• the invention makes it possible, when a time jump request is requested, to transmit not a complete description file comprising all the segment addresses having been broadcast as in the prior art but a subset of segment addresses of the file complete description.
• the transmitted description file is incomplete and only includes part of the segment addresses which will be judiciously chosen as we will see below.
• the description file created is greatly reduced in size compared to that of the state of the art because it ultimately only contains addresses of segments to be read, just like for classic reading, and at best a few others segment addresses as will be seen later in the description.
• the description file created according to the invention describes only a few minutes (three minutes for example) of description of the segments while a complete description file can describe hours, for example four hours.
• the time for retrieving a segment in the description file which is the subject of the invention is fast due to the very small number of segment addresses included in the second description file received; the transmission time on the network of such a description file is also advantageous in terms of bandwidth because of its reduced size.
• the address part includes segment addresses transmitted in the last description file, called first description file, in connection with real-time reading. This mode allows a return to live without delay because it avoids requiring the first description file linked to the return to live.
• the segment address part includes segments chosen from the first segments of the content.
• this mode allows from the current reading moment, in catch-up mode, to require a restart from the beginning without delay because the addresses of these segments are present in the second description file.
• the segments chosen from the first segments target the oldest segments accessible in the proposed time window. For example, if the catch-up mode allows you to go back to a time window of a few hours, for example four hours in the past, the oldest segments are the oldest segments in this time window of four hours.
• a progress bar (or timeline) can be restored in order to locate in time the current reading instant and allow selection of an earlier or later reading time in this progress bar and continue reading from the selected time.
• the second description file is updated over time; in particular, the last segment addresses associated with the stream transmitted in real time are updated.
• Each update allows a return to the stream transmitted in real time without requiring receiving an access request to the first description file for access to the content broadcast in real time.
• a selection, in the second description file, of one of the last segment addresses results in a transmission of 'a first description file, in place of the second description file.
• This fourth mode allows an automatic return to real-time playback mode. This mode allows a return to mode normal and therefore a return to the first description files which are smaller in size than the second description file.
• the previous instant is selected in a given time window, and the part of the other segment addresses of the content having been transmitted comes from this time window.
• the time window has a fixed duration. This mode is interesting when the content does not have a predefined start time; this is the case for most content transmitted in real time as explained below.
• the invention relates to an entity for managing the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively one after the other for reading by a reading device, characterized in that it comprises a microprocessor configured to, during the transmission of the content in real time, carry out a reception step of 'a command to perform a time jump in the content to read the content from a time prior to the current reading time, this reception step triggering a step of transmitting a second description file comprising segment addresses to be read at said previous instant, supplemented by part of the segment addresses of the content having already been transmitted.
• a microprocessor configured to, during the transmission of the content in real time, carry out a reception step of 'a command to perform a time jump in the content to read the content from a time prior to the current reading time, this reception step triggering a step of transmitting a second description file comprising segment addresses to be read at said previous instant, supplemented by part of the segment addresses of
• the invention relates to a reader terminal comprising a management entity as defined above.
• the subject of the invention is a computer program capable of being implemented on a management entity as defined above, the program comprising code instructions which, when executed by a processor, carries out the steps of the management process defined above.
• the invention relates to a data medium on which at least one series of program code instructions has been stored for the execution of a management method as defined above.
• the medium in question can be any entity or device capable of storing the program.
• the support may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk.
• the information carrier may be a transmissible medium such as an electrical or optical signal, which may be carried via an electrical or optical cable, by radio or by other means.
• the program according to the invention can in particular be downloaded onto an Internet type network.
• the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question.
• FIG 1 represents a progressive download architecture on the Internet based on the use of adaptive streaming according to one embodiment of the method of the invention
• FIG 2 schematically illustrates the hardware structure of a server capable of transmitting description files
• FIG 3 schematically illustrates the hardware structure of a reading device capable of reading multimedia streams in real time
• FIG 4 illustrates content and the segments available for that content.
• FIG 5 illustrates the playback status at a given time when catch-up mode is executed; we will see in particular that during this mode, the management entity implements an algorithm to generate a description file specific to the catch-up reading mode.
• FIG 6 illustrates the reading state at a time other than that described with reference to Figure 5 and always during reading in catch-up mode.
• FIG 7 schematically illustrates a time window implemented in which comes said part of the other segment addresses of the content having been transmitted, adding to the segment addresses to be read at said previous moment to ultimately form a second file of description.
• FIG 8 illustrates steps of one embodiment.
• FIG 1 represents a computer system SYS in which a content distribution network called CDN (Content Distribution Network) is implemented by those skilled in the art from which content is transmitted to client devices or content reading devices and description files associated with multimedia content.
• CDN Content Distribution Network
• the system includes a single STB reading device.
• the invention applies to any number of reading devices.
• the reading device is for example a digital reading device.
• the multimedia content referred to here is video content corresponding for example to a television channel on which television programs are broadcast having a start time corresponding to a scheduled broadcast time and an end time.
• the content in question is broadcast in multicast mode.
• the STB playback device is connected to a TV playback terminal such as a television.
• the STB playback device is connected to a port of the TV playback device; the STB reading device and the TV restitution device could also form a single device.
• the STB reading device is located in a local network LAN (English acronym for “Local Area Network”) managed by a GTW domestic gateway.
• LAN Local Area Network
• GTW domestic gateway The context of the local network is given as an example and could easily be transposed to a “best effort” type Internet network, a corporate network, etc.
• the GTW gateway is capable of communicating via a telecommunications network LI1 such as a WAN extended network known to those skilled in the art.
• the SYS computer system implements a content distribution network called CDN (Content Distribution Network) by those skilled in the art from which content is transmitted to client devices or STB content reading devices.
• CDN Content Distribution Network
• the CDN network is made up of servers linked together in the wide area network; these servers cooperate to make multimedia content available to users in unicast mode.
• a single SRV content server will be shown in Figure 1 to represent the CDN.
• the SRV content server is located, in our example, in the extended WAN network.
• the SRV content server receives, for example, digital television content channels from a broadcast television network (not shown), and makes them available in real time to client terminals, here the STB playback device.
• CNT content is made available in unicast mode in a given format.
• Such CNT content is, for example, content downloaded in adaptive streaming mode.
• the MPEG-DASH standard (Dynamic Adaptive Streaming over HTTP) is an audiovisual broadcast format standard on the Internet; this standard is based on the preparation of content in different representations of variable quality and bit rate, divided into short segments (of the order of a few seconds), also called “chunks" by those skilled in the art.
• Each of these segments is made available individually by means of an exchange protocol between the rendering terminal and the multimedia content provider server.
• the primarily targeted protocol is HTTP, but other protocols (e.g. FTP) can also be used.
• the organization of the segments and the associated parameters are published in a description file in XML format. We will not go into more detail about this download method because it is of no interest to the presentation of the invention.
• the SRV server is also equipped with at least one CPU2 processor and MEM2 memories for carrying out computer processing.
• the server is also equipped with a management entity ENT2, called the first entity, capable of managing the transmission of content and the description file associated with the content of the SRV server intended for one or more reading devices.
• the SRV server communicates with the GTW gateway via WAN network.
• the server includes, for communication with the WAN network, a communication module referenced COM2 in Figure 3. We will mainly focus in the following on the transmission of the description file rather than the transmission of the segments.
• FIG 3 represents an architecture of an STB reading device.
• This STB device conventionally comprises MEM1 memories associated with a processor CPU1.
• the memories can be of the ROM type (from the English “Read Only Memory”) or RAM (from the English “Random Access Memory”) or even Flash.
• the STB playback device can transmit content to be rendered to the TV rendering device via a COM12 communication module.
• This COM12 module is for example an HDMI connection.
• the STB reading device communicates with the gateway via an Ethernet module for local wired communication or via a WiFi type radio module for local wireless communication with the GTW residential gateway.
• the module in question is referenced CMO11 in Figure 2.
• the STB reading device includes a streaming mode download entity (not shown) capable of managing the download of segments of the content.
• the reading device STB also includes a management entity ENT1, called the second management entity in the following capable of reading a description file constructed specifically during reading in catch-up mode as explained below.
• FIG. 4 a schematic view of a main content Cl divided into segments and stored in the content server SRV. More precisely, the HAS content server exposes a video Cl in the form of segments Cli@Nj encoded at different encoding rates Nj, where the index i designates a temporal identifier of the segment Cli@Nj.
• the HAS download module called classic download mode below, of the STB playback device is responsible for retrieving the segments from the HAS content server by choosing the video quality Nj according to the available network resource.
• the HAS download module evaluates whether, based on the size of the segment and the time taken to retrieve it, the network conditions allow downloading the next segment at a higher encoding rate.
• the HAS download module In the classic case, if a video segment lasts three seconds, the recovery of the segment by the HAS download module must not exceed 3 seconds, in order to allow uninterrupted restitution of the content by the STB playback device. It is therefore appropriate for the HAS download module to make the best compromise between a restitution quality, and therefore an encoding rate, as high as possible, and the segment download time, which must be sufficiently low to allow a streaming reproduction on the TV set.
• the HAS module retrieves the description file which corresponds to the video content Cl in order to discover the available segments of the video content Cl, and the different associated video qualities Nj.
• the HAS module downloads, for example, successive segments C11@N1 (i.e. the first time segment at an encoding rate of 400 kb/s), then C12 @N3 (i.e. the second time segment at an encoding rate of 1200 kb/s), then C13@N3 (i.e. the third time segment at an encoding rate of 1200 kb/s), etc.
• the different segments downloaded by the download module HAS are then transmitted to a display module AFF capable of requiring display on a screen of the television set.
• the algorithm implemented by the HAS download module to determine which segment at which encoding rate must be downloaded in normal operating mode can be one of the already existing algorithms of the prior art. This algorithm will therefore not be described here in more detail.
• a function called “play from the beginning” or “catch-up” also called “Start Over” or “Restart” by those skilled in the art
• play from the beginning or “catch-up”
• catch-up also called “Start Over” or “Restart” by those skilled in the art
• reading the content can be resumed from its beginning. For example, if a film starts at 9:00 p.m. and if the user switches to the channel at 9:40 p.m., he can request that the content playback resumes from the beginning of the film. In this case, we therefore move from a reading mode with content in real time (or direct) to an on-demand reading mode.
• the STB reading device meaning the HAS entity installed on this device, generally retrieves every 2 seconds a description file which describes usually the last 60 seconds of the stream (30 2-second segments). We can then decide to buffer a certain part of the flow (up to 60 seconds maximum); the video segments are short because we want to be as close as possible to the real thing. This is also why we retrieve the description file every 2 seconds and we generally limit the buffer depth to around 15 seconds.
• the description file which is recovered no longer describes the last sixty seconds but a time window much greater than sixty seconds.
• the time window can be for the last four hours; in this case, if we can replay the content from a moment located in the time window.
• the size of the description file is therefore multiplied by two hundred and forty (240) and the parsing time of the XML file becomes a real problem. Indeed, it is necessary to recover, as when playing the Live stream, this description file in a manner periodically every 2 seconds and at each retrieval browse (or parse) the entire description file which includes a very large number of tags describing video and audio segments.
• the method of the invention comprises, during the broadcast of the content in real time, a step of receiving from the reading device a command to perform a time jump in the content to read the content from a time prior to the current reading time, the reception step triggering a step of transmitting a second description file comprising segment addresses to be read at said previous time, supplemented by part of the other segment addresses of the content that has been transmitted.
• the ENT2 management entity installed on the server creates a description file specific to the catch-up reading mode including not only addresses of segments to be read corresponding at the moment desired reading but also part of the other segment addresses of the content having been transmitted throughout the given time range, for example the last four hours.
• the size of the description file thus created is therefore reduced because the description file does not include all the addresses of the segments of the time range considered, that is to say the four past hours, but only part of these addresses .
• the first entity ENT1 accesses the description file constructed according to the invention, and continues reading in catch-up mode from the reading instant specified beforehand from which a resumption of reading is desired (for example 2hl7mn30sec in the past).
• the SRV server will construct a description file which includes
• a first part MNFm (m is an integer) including addresses of segments to be read corresponding to the desired reading instant; this part describes the 60 seconds of content corresponding to the desired reading time (between 2hl8mn30sec and 2hl7mn30 sec); this section can be compared to a description file received during normal reading of the content;
• AD11/AD21; AD12/AD22 At least a second part
• the second part which can be written ADli/AD2j (i and j being integers) can be subject to variations described below.
• the second part ADli includes a set of segment addresses associated with the oldest sixty seconds of segments available in the time window (or time range) considered; in our example, this ADli part corresponds to the segments that were transmitted approximately four hours ago or so. This variant allows you to go back in time as much as possible.
• the second part AD2j includes a set of AD2 segment addresses corresponding to the stream broadcast live, i.e. in our example, the 60 seconds of most recent video segments.
• the presence in the second description file of this second AD2j part is advantageous because the latter allows a return to live without delay.
• the second part combines the first and the second variant.
• the description file created specifically for the catch-up mode includes the segment addresses to be read at the selected time, and two parts ADI and AD2 as described above.
• each part ADli/MNFn/AD2j is updated during reading in catch-up mode.
• the index “n” designates the description file currently being read
• the index “i” designates the i-th update of the first ADI part
• the index “j” designates the jth update of part AD2; m,i,j being integers.
• Figures 5 and 6 illustrate the reading state at two distinct times TA and TA'(TA'>TA), respectively during a reading phase in catch-up mode.
• the number of description files used is very limited so as to explain the invention simply.
• first temporal axis LIV corresponding to a reading of content transmitted in real time (or direct) and a second axis dedicated to the so-called RTP catch-up mode.
• the second entity ENT2 present on the server creates a description file AD11/MNF2/AD21, called second description file, specific to this so-called catch-up reading mode which includes not only
• ADli/MNFn/AD2j This second description file specific to the so-called catch-up mode can be noted ADli/MNFn/AD2j; it is updated over time with a time interval similar to that used for the live stream.
• Figure 6 illustrates the status of reading in catch-up mode at another later time TA' (TA'>TA).
• the server transmits a description file AD12/MNF3/AD22.
• Figure 7 illustrates the FT time window linked to the catch-up reading mode.
• the FT time window is very useful for so-called “live” digital content, i.e. which corresponds to television programs in real time; in fact, this content does not, by nature, have a predefined duration or end date.
• a segment can be selected in this FT window; similarly, if the catch-up mode is executed for example at time TC2, a segment can be selected in this window FT which is shifted in time by a duration equal to TC2-TC1 (“-” is the mathematical sign corresponding to the subtraction).
• the time window is preferably of fixed duration. However, the duration of this time window may vary depending on the use case.
• Figure 8 illustrates another embodiment illustrating the possibility of returning to live broadcast after a phase in catch-up mode.
• This figure 8 includes two axes representative of a reading device STB and the content server CNT and the exchanges of messages between these two devices.
• the method comprises a first LIV phase for reading content transmitted in real time, a second RTP phase for reading the content in catch-up mode and a third LIV phase for returning to real time.
• the reading device STB transmits a request REQ1 for access to content.
• the SRV content server transmits at regular intervals in our example MNFl-MNFn description files, for example every 2 seconds.
• the RTP catch-up mode is activated ACT.
• a reading time “TA” prior to the current time “TC” (TA ⁇ TC) is selected so as to replay the content from the selected reading time. It is assumed that the instant TA corresponds to the instant at which the description file MNF2 was previously transmitted in connection with the content broadcast in real time.
• Data representative of the activation and the reading instant TA are transmitted by the reading device STB to the server and are received by the server SRV. This data can be conveyed via the same message or two separate messages.
• the SRV server On receipt of the data representative of an activation and the selected reading instant TA which corresponds to the segments described in the description file MNF2, the SRV server creates a specific description file AD11/MNF2/AD21 called second description file .
• the second description file is for example that described with reference to the third variant described above.
• the SRV server transmits regular updates of the second description files, namely AD12/MNF2/AD22 and AD13/MNF2/AD23.
• the updates take into account the temporal movement of the fixed time window, four hours in our example; for example part AD11 becomes AD12 during the update then AD22 and so on.
• a segment address is selected SEL(AD23) in the set AD23 described above included in the second description file.
• the SEL selection is transmitted by the reading device STB to the SRV server.
• This selection results in automatic transmission by the SRV server of a first description file MNF10, in place of the second description file of type ADli/MNFn/AD2j, for a return to the stream transmitted live.
• the server then continues transmitting the first description files, namely MNF11, etc.
• a selection of a segment address in the second description file corresponding to an address which will be transmitted by the server for reading the stream broadcast live is interpreted by the server as a desire to return to the real-time playback mode instead of catch-up mode.
• the second description file can include two parts of addresses, one targeting the oldest segments, the other targeting the most recent, namely the segments currently being broadcast in real time. These two parts and the times of the associated segments make it possible to construct a progress bar (or timeline) in order to locate in time the current reading time and allow selection of an earlier or later reading time in this progress bar and continue reading from the selected time.
• a software component can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more programs or subprograms computer or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
• a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .)

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=85570163

Family Applications (1)

Country Status (3)

• 2022
  • 2022-12-16 FR FR2213685A patent/FR3143930A1/fr active Pending
• 2023
  • 2023-12-04 WO PCT/EP2023/084142 patent/WO2024126138A1/fr not_active Ceased
  • 2023-12-04 EP EP23814502.3A patent/EP4635189A1/de active Pending

Also Published As

Similar Documents

Legal Events