FR3098074A1 - Method of transmitting audio content in a hybrid receiver by receiving manifests sent by a manager server, receiver and associated manager server - Google Patents

Abstract

TITLE: Method of transmitting audio content in a hybrid receiver by receiving manifests sent by a manager server, receiver and associated manager server The invention relates to a method of transmitting audio content in a hybrid receiver with a view to deferred reproduction, this content being broadcast in real time on a determined radio channel, and the data packets being available deferred by connecting to a dedicated server (CDN). First, a so-called "Manager" server sends to this dedicated server (CDN) requests to receive a manifesto identifying a succession of a determined number of data packets including the one containing the audio broadcast in real time on the channel. radio determined (2.1). The Manager server records the manifests sent by the dedicated server, dating them by the time of transmission of the most recent data packet broadcast on the determined radio channel (2.2). A hybrid receiver requests the Manager server to receive part of a broadcast content from a specific time (2.3). The Manager server then searches the stored manifests for references of the data packets corresponding to the part of the content broadcast from the determined moment and sends to the hybrid receiver a manifest referencing all of these data packets (2.4). The hybrid receiver then sends a request to the dedicated server (CDN) to receive the data packets referenced in this manifest (2.5). Figure 1

Description

Method for transmitting audio content in a hybrid receiver by receiving manifests transmitted by a manager server, receiver and associated manager server

The field of the invention is that of the reception of audio or audiovisual content in a hybrid receiver capable of receiving content from both a broadcast network and a bidirectional network. The invention relates more particularly to the fact of receiving deferred portions of an audio broadcast which has previously been broadcast on a radio channel by connecting to a dedicated server.

Prior art

Radio stations transmitting audio content in a given frequency channel are known. This radio source generally has a site for receiving streaming audio content in the form of a data packet file. It is also known that the broadcasting of digital documents can be carried out by digital television broadcasting networks, such as DTT networks, implementing the DVB-T2 standard ("Digital Video Broadcasting – Terrestrial" for "digital terrestrial video broadcasting "). The broadcasting of data packets is specified by standards so that they can be received by a large number of receivers of any type.

In the field of broadcasting audio content, so-called "hybrid" receivers are also known which are capable of receiving content and reproducing both broadcasts from a broadcast network, content transmitted from a site, and content transmitted in podcasting or "podcast" according to the Anglo-Saxon terminology. These receivers are equipped with a user interface comprising a screen and a keyboard, radio reception means and means for transmitting sound signals to loudspeakers. The user sets his device to receive content broadcast on the radio or from a website. Some hybrid devices can enrich the reception of audio content broadcast via an Internet or “IP” type connection, for example by improving the coverage area of the content broadcast by combining their traditional reception via the broadcast network according to the following broadcast standards (list non-limiting):

- FM (Frequency Modulated) or AM (amplitude modulation),

- DAB (acronym for “Digital Audio Broadcasting”), DAB+,

- DMB,

- DRM, DRM+,

- DVB (acronym for “Digital Audio Broadcasting”), DVB-T, DVB-S,

…

with downloads or "streaming" according to the Anglo-Saxon terminology by IP network (Wifi, 3G, 4G).

If the digital documents are of the audio and/or video type, then they are generally encoded according to the MPEG standard, then a server receives them from one or more sources and plans the real-time distribution of the content in digital form. At the same time, a server creates a succession of digital data packets (or "chunks" - this name will then be used in the rest of the document) allowing digital receivers to download them (in "streaming" for example) and be able to access this content offline. The duration of a chunk typically varies from 2 to 10 seconds. The segmentation techniques are known per se, mention may be made, for example, of the HLS, DASH or even Smooth Streaming technologies. Each chunk has a file data structure containing at least one payload (for example, audio and/or video data, with the data synchronizing their reproduction, for example time markers or "timestamps" in English language ), a reference making it possible to identify them, and possibly, an identifier of the source (typically the identifier of a broadcast channel).

The reproduction on a receiver of a content can occur either because of an action of the user, or by an event affecting the good conditions of the reception. This event may for example be the fact that the receiver is a smartphone (or "smartphone" in English terminology) and that at a certain moment a call is made interrupting the reproduction of the audio document. In another context, the receiver can be moved to an area with no radio carrier and can therefore no longer receive the radio transmission selected by the user (this is the case, for example, of a car radio when the vehicle passes through a tunnel ). In such a case, the user may wish to resume playback at the time when it stopped and therefore listen to the chosen program later.

A first solution consists in the receiver continuing to receive the content during the interruption and recording it in a circularly managed memory. When resuming, the device reads its memory at the time of the interruption and reproduces the deferred content. This system requires local memory of sufficient size and, in any case, is not suitable for events that have prevented the content from being received correctly. Another way to continue the reproduction of content at a time when it has been interrupted is to connect to a site allowing the remaining part to be downloaded. The device downloads and saves at least some of the content and, using a user interface, the user can fast forward and thus skip over moments that have already been played.

Content sources, such as radio stations for example, have so-called CDN servers (acronym for “Content Delivery Network”, according to the English terminology) making it possible to transmit parts of audio content. These audio content packets are referenced in a data structure called “manifest”, a manifesto references several data packets corresponding to chunks whose audio contents follow each other. The creation of a new chunk triggers the update of the current manifest (or “Live” according to the Anglo-Saxon terminology) by the CDN, which thus produces a succession of manifests concomitantly with the distribution of the content. When a hybrid receiver wants to receive content that was broadcast at a certain time in the past, it asks the server dedicated to the radio source to send it the manifest whose first referenced chunk is the one created at this specific time. Following receipt of the manifesto, the receiver extracts the reference of the chunks, typically a URL address, and can then download the corresponding audio part and play it.

But, the dedicated server does not save all the manifests it creates as the content is delivered, only the last one: the Live manifest. Therefore, by addressing this dedicated server, a hybrid receiver can only retrieve a limited number of manifests and can therefore only have access to the last data packets broadcast. If the receiver wishes to return to a content broadcast a short time ago, the dedicated server has already erased the manifests that reference the corresponding chunks and therefore will not be able to transmit it to the receiver. It is all the more unfortunate that the dedicated server keeps the different chunks in memory for a certain time, even if the manifesto referencing them has been erased. In this way, it would still be possible to recover data packets from audio content broadcast some time ago.

One of the aims of the present invention is the possibility of recovering at least part of a previously broadcast audio content, although the manifest making it possible to reference this audio part is no longer available at the level of the server dedicated to this source of content.

Another object of the present invention is to be able to easily inform a hybrid receiver of the availability or not of a part of an audio content according to its source and its time of broadcast.

There is a need for such a technique, which makes it possible to compensate for the premature disappearance of manifests at the level of servers dedicated to radio sources.

There is also a need to provide users with means for recreating manifests which have been deleted and which reference audio content which is still available on the server of the radio source.

The invention meets this need by proposing a method for transmitting audio content in a hybrid receiver with a view to delayed reproduction, said content being broadcast in real time on a determined radio channel, the data packets of said content being available offline by connecting to a dedicated server (CDN), the method comprising at least the following steps:

- transmission by a so-called "Manager" server to this dedicated server (CDN) of a plurality of requests to receive a manifest identifying a succession of a determined number of data packets including the one containing the audio broadcast in real time on the determined radio channel,

- storage in the Manager server of the plurality of manifests transmitted by the dedicated server, the stored manifests being dated by the time of transmission of the most recent data packet broadcast on the determined radio channel,

- transmission by the hybrid receiver to the Manager server of a request to receive at least part of the content broadcast from a determined moment,

- search by the Manager server in the stored manifests of the references of the data packets corresponding to the part of content broadcast from the determined moment and transmission to the hybrid receiver of a manifesto referencing all of these data packets,

- transmission by the hybrid receiver to the dedicated server (CDN) of a request to receive the data packets referenced in the manifest transmitted by the Manager server.

According to a first embodiment, the requests sent by the Manager server to the dedicated server (CDN) to receive a new manifest are sent at regular time intervals, the duration of which is less than the duration of reproduction of the audio content of a packet. of data.

According to another embodiment, the transmission method comprises a step of sending to the dedicated server a request to receive a data packet broadcast at a determined time, a response sent by the dedicated server indicating an absence of availability of this packet triggering the deletion within the Manager server of the manifests having the references of this data packet, as well as the references of the data packets whose audio content was broadcast before that of the packet referenced in the request.

According to another embodiment, the manifests stored in the Manager server are managed circularly, the oldest being erased by the most recent.

According to another embodiment, the step of searching in the circular memory stops until a determined number of the oldest manifests which are considered inaccessible.

According to another embodiment, the transmission method includes a step of associating within the Manager server each data packet referenced by a manifesto and the time of broadcast of this data packet on the determined radio channel, the server Manager emitting the references of a data packet following the receipt of a request mentioning this determined radio channel and the time of its broadcast.

According to another embodiment, the transmission method includes a step of renumbering the manifests received from the dedicated server, to always assign the value "1" to the last manifest and successively numbering the others up to the oldest manifest received and present in memory.

According to another embodiment, when the search has not made it possible to find a manifest referencing data packets corresponding to the part of content broadcast from the determined moment, then the search continues by searching for a manifest referencing data packets whose content was broadcast before the specified time.

According to another aspect, the invention relates to a data server comprising means of communication with at least one server (CDN) dedicated to the broadcasting of a given radio channel and at least one hybrid receiver, and storage means capable of recording at least one manifest identifying a succession of a determined number of data packets including that containing the audio broadcast in real time on the determined radio channel. The communication means transmits to this dedicated server (CDN) a plurality of requests to receive a manifest identifying the data packets containing the audio broadcast in real time on the determined radio channel, the storage means recording the plurality of manifests transmitted by the dedicated server by dating them with the time of transmission of the most recent data packet broadcast on the determined radio channel, the communication means receiving from the hybrid receiver at least one request to receive at least part of the content broadcast from a determined moment, the manager server having a means of searching in the stored manifests for the references of the data packets corresponding to the part of content broadcast from the determined moment and transmission to the hybrid receiver of a manifesto referencing the set of these data packets.

According to another aspect, the invention relates to a hybrid receiver comprising means for receiving content broadcast in real time on a determined radio channel, means of communication with at least one server (CDN) dedicated to the broadcasting of this channel determined radio station and at least one Manager server, a means of reproducing the audio content reproducing in real time the audio content received from the determined radio channel, and a means of memorizing the moment of the interruption of the reproduction of said content, characterized in that 'at the time of the resumption of the reproduction of the interrupted content, the means of communication sends to a server called "manager" a request to receive at least part of the content broadcast from a stored moment, the means of communication receiving from said Manager server a manifest identifying a succession of a determined number of data packets including that containing the audio broadcast at the determined time, the means of communication transmitting to the dedicated server (CDN) a request to receive the data packets referenced in the manifest transmitted by the Manager server, said received data packets being reproduced upon receipt.

According to another aspect, the invention relates to a computer program product, comprising program code instructions for implementing the method as described in the paragraphs above, when said program is executed on a computer.

Presentation of figures

Other aims, characteristics and advantages of the invention will appear more clearly on reading the following description, given by way of a simple illustrative example, and not limiting, in relation to the figures, among which:

: presents a general architecture of a content distribution system allowing hybrid receivers to receive and reproduce content offline, according to a particular embodiment of the invention;

: presents an example of a flowchart of the main steps of the method for the delayed transmission of at least part of an audio content, which has been broadcast beforehand;

: presents a diagram showing the presence of manifests and chunks within the different servers;

: represents a diagram of a hybrid receiver device, according to a particular embodiment of the invention;

: illustrates the main components of a remote server according to an exemplary embodiment.

Detailed description of the invention

In all the figures of this document, identical elements are designated by the same reference.

General principle.

The invention relates to a method for transmitting audio content in a hybrid receiver with a view to delayed reproduction, this content being broadcast in real time on a determined radio channel, and the data packets being available offline in connecting to a dedicated server (CDN). First, a so-called “Manager” server sends requests to this dedicated server to receive a manifest identifying a succession of a determined number of data packets, including the one containing the audio broadcast in real time on the determined radio channel. The Manager server saves the manifests issued by the dedicated server by dating them with the time of issue of the most recent data packet broadcast on the determined radio channel. A hybrid receiver asks the Manager server to receive part of a broadcast content from a determined time. The Manager server then searches the stored manifests for references to data packets corresponding to the portion of content broadcast from the determined time and sends a manifest to the hybrid receiver referencing all of these data packets. The hybrid receiver then sends the dedicated server (CDN) a request to receive the data packets referenced in this manifest.

Description of a particular embodiment

In all the figures of this document, identical elements (or steps) are designated by the same reference numeral.

We now present, in relation to FIG. 1 , a general architecture of an audio content broadcasting system allowing hybrid receivers to receive and reproduce content offline, according to a particular embodiment of the invention.

A radio source 1, called "radio studio" produces an audio stream corresponding to content such as: music, newspaper, cultural program, soap opera, etc. This radio source transmits the content to be broadcast over radio waves so that receivers can capture and reproduce them in real time. These receivers 2 are said to be “hybrid” in that they can receive radio transmissions on a broadcast channel and reproduce the content, and that they also have the means of connecting via a bidirectional link with a server to request to transmit data packets representing audio content. Within the radio source 1, its audio signals are encoded by an encoder 3 and put into data packets called “chunks”. Once produced, each chunk is sent to a so-called “CDN” server 4, which is a server dedicated to a particular content source. This CDN server manages the transmission of chunks to 2 hybrid receivers in the context of streaming or podcasting. Chunks are managed using a manifest, which is a data structure identifying several chunks, which correspond to consecutive audio content. As soon as a new chunk is created at a time T0, a new manifest is created which contains the references of the following three chunks:

- the chunk emitted by the source at T0,

- the chunk emitted by the source at T0-∆t ,

- the chunk emitted by the source at T0 – (2x∆t),

where ∆t is the duration of reproduction of the audio content of a chunk, for example 6 seconds, or 10 seconds. It is obvious that the number "three" is only given by way of example and that the number of chunks referenced in a manifesto can vary within the framework of the invention. The manifest also references a session number that identifies the radio source, and specifies a format (HLS or DASH, for example). When a hybrid receiver wants to receive content that has been broadcast previously, it asks the CDN server 4 of this radio source 1 to send it the manifest whose first referenced chunk is the one created at this determined moment, the payload of this chunk being the audio content that was broadcast at that time. Following receipt of the manifest, the receiver extracts the references of the three chunks, typically URL addresses. The receiver can then download them from the CDN server 4, and reproduce them.

But CDN 4 servers only keep a limited number of manifests in memory, the appearance of a new manifest triggering the erasure of the oldest in the memory of the CDN server. CDN servers save chunks longer than manifests. To compensate for the premature disappearance of the manifests, the present invention provides for the configuration of a so-called “Manager” server 5 which over time receives manifests from the CDN servers and saves them in a memory 6, typically a hard disk. Since the storage capacity is greater, the Manager server maintains 6 more manifests in its memory than a CDN server.

Fig. 2 shows a flowchart of the main steps of the method for the delayed transmission of at least part of an audio content, which has been broadcast beforehand. In step 2.1, the Manager server 5 transmits to the CDN server 4 a plurality of requests to receive a manifest. Advantageously, the requests are sent periodically to the CDN dedicated server to watch for the presence of a new manifesto, these requests being sent at regular time intervals, the duration of which is less than the reproduction duration of a chunk. This way, the Manager server cannot miss the appearance of a new manifest referencing a new chunk. Typically, the Manager server polls the CDN server every 50 milliseconds and thus watches for the appearance of a new manifest. The precision of the dating of a manifest (and therefore of each new chunk) corresponds to the polling period of the CDN server dedicated to a radio source.

Following the discovery of a new manifest, the Manager server analyzes it and extracts the identifiers of the chunks. The Manager server then updates in a memory 7 a table associating each chunk emitted by the same radio source, the references of the manifesto of which this chunk is the first element and the time of the broadcast of this chunk, that is to say the when the audio content of this chunk is broadcast by radio (step 2.2). The Manager server thus lists a history of all the manifests issued by a given CDN 4 server. In this way, the Manager server can retransmit to a receiver who requests it, a manifest which was previously sent by a CDN server and which was then erased. Using its history, the Manager server is able to associate each chunk with when its audio content was broadcast by the radio source.

During step 2.3, a hybrid receiver 2 wishes to resume the reproduction of interrupted audio content. To do this, it sends a request to the Manager server to receive at least part of the content broadcast from a given moment. The Manager server 5 then searches in the stored manifests for references of the data packets corresponding to the part of content broadcast from the determined moment and sends a manifest referencing the data packets to the hybrid receiver (step 2.4). Following receipt of the manifest and during a step 2.5, the hybrid receiver 4 sends a request to the dedicated server (CDN) to receive the data packets referenced in the received manifest. As soon as the data packets are received, they are decoded and the audio content is reproduced.

Determining the dating of a chunk

There is generally a lag between the moment when the audio content is broadcast by radio and the moment when the chunk containing the data of this content appears in a manifest at the output of the CDN server 4. When the hybrid receiver 2 wants to resume the reproduction, it must indicate the moment when the reproduction of the audio content broadcast by radio was interrupted, which is not necessarily the moment of appearance of the manifest referencing the chunk corresponding to this audio content. The way to calculate the date associated with the appearance of the chunk (or of the manifesto which references it) according to the date of broadcast of its audio content, will now be described.

Content source 1 has a software module that can be called “Delay compute”, this module makes it possible to calculate, for the same radio, the delay between two audio sources. For a radio, the source that is broadcast first, often the Frequency Modulated (FM) radio wave, is considered the reference. We call “R” the value of the delay between the streaming stream and the audio stream broadcast in real time to all the receivers. The “R” value is advantageously calculated dynamically by receiving the broadcast IP stream on one side and the broadcast content on the other, and by comparing the content to evaluate the offset.

By periodically querying the CDN server, we obtain the date of appearance of a new manifest signaling the addition of a new chunk, this date is noted Dp. The link between the audio content broadcast and that transmitted in a chunk is made using a database which lists, for each radio station, the associated IP streams. In addition, algorithms evaluate the two contents and develop a confidence index on their resemblance. If this index is low, then the contents are different.

Let “Dur” be the duration of a chunk, then the estimated “Dck” date of the oldest part of the audio in the chunk can be calculated by the following equation:

Dck = Dp - Hard - R,

In other words, a new chunk appears on the CDN server 4 at a date and time Dp which is determined by the date and time of broadcast Dck of the audio content in real time, to which we add the duration of the Dur chunk and a delay value R which is calculated for a certain time at least. Once the Dp, Dur and R values have been calculated for a chunk n, the dates of the following chunks are calculated using the relationship: Dckn+1 = Dckn + duration of chunk n.

The Manager 5 server, which periodically scans the appearance of new manifests, checks that the actual availability date of a chunk does not diverge. If the deviation is greater than a preconfigured threshold, then the rapid scan every 50 milliseconds performed previously must be repeated to resynchronize. This drift is normal because it is related to the clock differences between the stream encoder and the RB platform (acronym for "RadioBridge"). A stoppage of the flux at the input of the encoder can have the same effect.

Determining the number of chunks available on a CDN server

Manifests that describe an adaptive streaming real-time stream only include references to a small number of chunks. Indeed, these manifestos ultimately concern only the chunks of the latest pieces of audio broadcast by the station. This prevents the file from being too large as it is loaded very frequently by Hybrid Receivers 2. For example, the manifest may only contain references to the three most recent chunks, while several hundred chunks may still be available on the CDN server.

The availability of each chunk at the level of the CDN server is determined by a duration called "Lifetime" or TTL (from the Anglo-Saxon: "Time To Live"). If the time between the appearance of the chunk and the current time reaches this value, then the chunk is erased from the memory of the CDN server. Throughout the TTL duration, the chunk remains available even if it is no longer referenced by manifests appearing over time on the CDN server.

If at a given moment, the Manager server connects to a CDN server, it receives a manifest referencing only a small number of chunks, but the CDN server can still provide many other chunks. To improve the quantity of chunks which are actually available within the CDN server, the Manager server sets up a search mechanism which is notably launched when the Manager server is reinitialized.

This mechanism consists of first loading the manifest and then searching for the name of the oldest chunk referenced in this manifest. This name ends with a chunk number. The mechanism continues by decreasing the number by '1' to obtain the reference of the previous chunk, then the mechanism tries to download it from the CDN server. If the chunk can be downloaded, it is added to the list of available chunks.

The operation is then repeated iteratively until the Manager server can no longer download the chunk whose name it has just constructed. To limit the volume downloaded by this mechanism, the HTTP HEAD method will be preferred to check the availability of a chunk.

In order to limit the impact of short cuts and according to an improvement, in the event of failure of a download of chunks, the Manager server seeks to download a certain number of chunks having a number lower than that which is not available. If all the attempts fail, then we cannot go back any further in time and the number of manifests making it possible to find chunks on the CDN server is then frozen using the last available chunk found. These manifests are saved in a circular memory managed by two pointers, the size of this memory being directly proportional to the number of chunks available.

In order to limit the size of this circular memory, the Manager server only searches iteratively for a limited number of chunks, for example 300. If the number of referenced chunks reaches this value, then the search process is interrupted.

If during the search for chunks, the counter used to build their identifiers reaches the value 0, then the search is stopped. There is indeed no chunk number with a negative value.

For each chunk discovered on the CDN server, an entry is added to the handler database. This entry contains:

- the reference of the chunk (typically its URL address),

- the production date of its audio content,

- a session number corresponding to the manifest pointing the chunk as the first to be read. The associated manifest is built using the N discovered chunks that precede the one emitted in real time. According to the HLS standard, this manifest has the reference "session_number.m3u8". This method has the advantage of making the system self-adaptive to the number of chunks available on the CDN server.

According to a refinement and in order to avoid providing manifests that would reference chunks recently deleted from the CDN server, the last N chunks of the buffer must not be addressable for a resumption of reading. For a buffer containing M chunks, only (M-N) chunks will be addressable via the manifests produced by the platform.

The Manager server manages the availability of chunks in a circular memory, by asking the CDN server to download manifests in real time, by registering the references of new chunks, and by updating the references according to the availability of chunks.

These three steps are repeated cyclically with a period that can vary, since it must be slightly less than the duration of the last loaded chunk (one second less for example).

Checking the availability of a chunk within the CDN server causes its lifespan counter to be reset to zero, and its availability to increase. A systematic check of all chunks therefore has the effect of artificially increasing the number of chunks available on the CDN server and increasing operating costs. In order to limit the cost of implementation, the verification of the presence of a chunk must be carried out using the “http HEAD” method rather than the GET method.

In order to avoid the effects described above, the oldest chunk N is automatically removed from the list of available chunks when a new chunk is added and chunk N-1 (which becomes the last chunk) is tested. If the Manager server finds that the N-1 chunk is no longer available within the CDN server, then it is deleted from the circular memory and the N-2 chunk is tested. These steps are repeated until an available chunk is discovered.

The Manager server manages as many circular memories as radio sources 1.

During each emission of a new chunk, the radio source 1 creates a new manifesto by referencing it by a chronological number and a suffix, for example “.m3u8”, for example the 125° manifest bears the reference “125.m3u8” . The Manager server manages memory in a circular fashion, the most recent manifest referenced "1" overwrites the oldest which is referenced "N". During each addition to the memory, all of the manifests, except the one that has just been added, is then renamed by increasing its index by 1. The manifest “125.m3u8” becomes “126.m3u8”, etc… The renumbering must start with manifesto N-1 which is renamed to N. During this renumbering, the session Ni no longer has a manifesto while manifesto N-i+1 is renamed to Ni. Manifest access requests that may arrive on the platform during this renumbering phase must therefore be delayed. For performance reasons, renumbering must be done atomically locally using an operating system atomic method, which means that this action is performed in a single operation from an operating system perspective. This cannot be done remotely via FTP.

Once the renumbering of the old manifests is complete, the last broadcast that includes the chunk corresponding to the content broadcast in real time bears the reference “1.m3u8”. Let's take an example by considering that the depth of the circular memory is 2 hours and that the chunks have a duration of 10 seconds. The 7200 seconds of content addressable by this memory are accessible by 720 manifests which each address 10-second chunks. According to this example and considering that a manifest references three chunks, the 720 manifests occupy a memory not exceeding 2 MB on the Manager server, which is quite reasonable.

Fig. 3 presents a diagram showing the presence of manifests and chunks within the various servers using the present invention. Specifically, the diagram describes the relationship between the existing data on the radio source's CDN server, the manifests created by the platform, the session identifiers and the resume times associated with them.

The left part of the diagram shows the contents of the CDN server's memory, the chunk referenced "1" is the last created, the manifest entitled "M3u live" is the last created, it references chunks 1, 2 and 3.

The central part describes the manifests created by the Manager server, they are accessible by a so-called “cache” server bearing the reference 7 in FIG. 1 . The Manager server keeps in memory the manifests referenced M3u1, M3u2, M3u3, … M3uN-2, which are numbered from 1 to 300. The first manifest (i.e. the most recent) M3u1, numbered 1, references the chunk 1 , 2, and 3. The second manifest M3u2, M3u3, numbered 2, references chunks 2, 3, and 4. The third manifest M3u3, numbered 3, references chunks 3, 4, and 5, and so on. The last manifest present in the memory of the Manager server is the 300th, it makes it possible to search in the memory of the CDN server, the last chunks still available and respectively referenced N-2, N-1, N.

The right part of the diagram shows the contents of the memory of a part of the Manager server called “Time Shift manager” bearing the reference 8 in FIG. 1 . Using the formula for calculating the "Dck" date of the oldest part of the audio in the chunk, given the length of a chunk, the current time, and the delay, the Time subserver Shift manager 8 updates a table associating session numbers with dates and times of resumption of audio content. In this way, a hybrid receiver sends a request to the sub-server 8 presenting the date and time of the interruption and the identification of the source radio, the sub-server 8 searches in its association table and immediately extracts a session number which is then used to retrieve the manifesto referencing the first chunk to be reproduced.

Presentation of a hybrid receiving device

Fig. 4 represents a diagram of a hybrid receiver device 2, according to a particular embodiment of the invention. The hybrid receiver 2 typically comprises a central unit 10 associated with a program memory 11, a module for receiving a radio stream 12 receiving transmissions from a one-way network, an FM network for example, and a communication module 13 authorizing two-way communications at short or long range by cable or by radio, using for example the Bluetooth, Wifi and/or GSM network. The receiver also has command input means 14 (keyboard, buttons, touch screen, etc.), and display means (screen, indicator lights, voice synthesis, etc.). These means can be integrated into the device or remote. The device also has a means of reproducing audio and/or audiovisual content, composed for example of a remote screen 15, and/or of an amplifier 16 integrated into the device emitting acoustic signals to remote speakers 17. The device has a data storage memory, typically chunks 18 for recording audio content.

A receiver in the process of reproducing content broadcast from a radio source may be interrupted for any reason whatsoever: action by the user, lack of reception, power cut, mobilization of the means of reproduction of the sound for another use, etc. At the time of the interruption, the receiver stores the current date and time and the identification of the source radio broadcasting the audio content.

A little later, the user can request to resume the reproduction of this interrupted audio content. The hybrid receiver 2 then sends a request to the Time-Shift manager sub-server 8 for calculating the time shift, the request includes at least the following information: the current time, the date and time of the interruption and the identification of the source radio whose broadcast has been interrupted (these last two pieces of information having been stored). This sub-server 8 then calculates the resumption time on the server side, which makes it possible to know the identifier of the session corresponding to the desired resumption time for the requested radio. Server 7 then returns to Receiver 2 the URL of the manifest to use to resume playback.

Through the cache server 7, the hybrid receiver 2 transmits the identifier of the manifest to the Manager server 5 which sends back to it the content of the identified manifest. The hybrid receiver 2 extracts the identifiers of the chunks from the received manifest and sends requests to the CDN server in order to download and reproduce them.

Presentation of a Manager or CDN server

Fig. 5 illustrates the main components of a remote server 20 such as a CDN server and a Manager server, according to an example embodiment. Such a server 20 comprises a central unit ALU 21 connected to an executable program memory PM 22, a hard disk HD 23 containing a database for storing data in a non-volatile manner. The server 20 also contains an I/O interface 24 for communication with a hybrid receiver 2 via a computer network. Such a server 20 makes it possible to provide manifests referencing chunks whose content is broadcast in real time, and to manage the resumption of deferred content. This server can transmit, at the request of a receiver 1, the chunks of content transmitted in adaptive streaming or blocks of data in MP3 format of content to be downloaded. It is not excluded that the connection means differ according to the type of device in communication, thus the server 20 can communicate with the receivers 2 through a wireless network (3G/4G/5G mobile telephony) and/or by a cable via any digital network.

It should be apparent to those skilled in the art that the present invention permits embodiments in many other specific forms without departing from the scope of the invention as claimed. Accordingly, the present embodiments are to be considered illustrative but may be modified within the scope defined by the scope of the appended claims.

Claims (11)

Method for transmitting audio content in a hybrid receiver with a view to delayed reproduction, said content being broadcast in real time on a determined radio channel,
the data packets of said content being available offline by connecting to a dedicated server (CDN), the method comprising at least the following steps:
- transmission (2.1) by a server called "Manager" to this dedicated server (CDN) of a plurality of requests to receive a manifest identifying a succession of a determined number of data packets including that containing the audio broadcast in time real on the determined radio channel,
- storage (2.2) in the Manager server of the plurality of manifests transmitted by the dedicated server, the stored manifests being dated by the time of transmission of the most recent data packet broadcast on the determined radio channel,
- transmission (2.3) by the hybrid receiver to the Manager server of a request to receive at least part of the content broadcast from a determined moment,
- search (2.4) by the Manager server in the stored manifests of the references of the data packets corresponding to the part of content broadcast from the determined moment and transmission to the hybrid receiver of a manifest referencing all of these data packets ,
- transmission (2.5) by the hybrid receiver to the dedicated server (CDN) of a request to receive the data packets referenced in the manifest transmitted by the Manager server. Transmission method according to claim 1 characterized in that the requests sent by the Manager server to the dedicated server (CDN) to receive a new manifest are sent at regular time intervals, the duration of which is less than the duration of reproduction of the content audio from a data packet. Transmission method according to Claim 1 or 2, characterized in that it comprises a step of sending to the dedicated server a request to receive a data packet broadcast at a determined time, a response sent by the dedicated server indicating a lack of availability of this packet triggering the deletion within the Manager server of the manifests having the references of this data packet, as well as the references of the data packets whose audio content was broadcast before that of the packet referenced in the request. Transmission method according to any one of the preceding claims, characterized in that the manifests stored in the Manager server are managed in a circular manner, the oldest being erased by the most recent. Transmission method according to claim 4, characterized in that the search step (2.4) in the circular memory stops until a determined number of the oldest manifests which are considered inaccessible. Transmission method according to any one of the preceding claims, characterized in that it includes a step of associating within the Manager server each data packet referenced by a manifesto and the time when this data packet is broadcast on the determined radio channel, the Manager server transmitting the references of a data packet following receipt of a request mentioning this determined radio channel and the time of its broadcast. Transmission method according to any one of the preceding claims, characterized in that it comprises a step of renumbering the manifests received from the dedicated server, to always assign the value "1" to the last manifest and by successively numbering the others up to the most old manifesto received and present in memory. Transmission method according to any one of the preceding claims, characterized in that, when the search (2.4) has not made it possible to find a manifesto referencing data packets corresponding to the part of content broadcast from the determined moment, then the search continues by looking for a manifest referencing data packets whose content was released before the specified time. Data server comprising means of communication with at least one server (CDN) dedicated to the broadcasting of a determined radio channel and at least one hybrid receiver, and storage means capable of recording at least one manifest identifying a succession of a determined number of data packets including that containing the audio broadcast in real time on the determined radio channel, characterized in that the means of communication 24 to this dedicated server (CDN) a plurality of requests to receive a manifest identifying the data packets containing the audio broadcast in real time on the determined radio channel, the storage means recording the plurality of manifests transmitted by the dedicated server by dating them with the time of transmission of the most recent data packet broadcast on the channel determined radio, the communication means 24 receiving from the hybrid receiver at least one request to receive at least part of the content broadcast from a determined time, the e manager server having a means of searching in the stored manifests for the references of the data packets corresponding to the part of content broadcast from the determined moment and transmission to the hybrid receiver of a manifest referencing all of these packets of data. Hybrid receiver comprising means for receiving content broadcast in real time on a determined radio channel, means of communication with at least one server (CDN) dedicated to the broadcasting of this determined radio channel and at least one Manager server, a means for reproducing the audio content reproducing in real time the audio content received from the determined radio channel, and a means for memorizing the moment of the interruption of the reproduction of the said content, characterized in that at the moment of the resumption of the reproduction of the interrupted content, the means of communication sends to a so-called "manager" server a request to receive at least part of the content broadcast from a stored moment, the means of communication receiving from said Manager server a manifest identifying a succession of a determined number of data packets including the one containing the audio broadcast at the determined time, the communication means transmitting to the dedicated server (CDN) a request to receive the the data packets referenced in the manifest transmitted by the Manager server, said received data packets being reproduced upon receipt. Computer program product, comprising program code instructions for implementing the method according to at least one of claims 1 to 8, when said program is executed on a computer.