CN107920258A - A kind of data processing method and device - Google Patents
A kind of data processing method and device Download PDFInfo
- Publication number
- CN107920258A CN107920258A CN201610887828.2A CN201610887828A CN107920258A CN 107920258 A CN107920258 A CN 107920258A CN 201610887828 A CN201610887828 A CN 201610887828A CN 107920258 A CN107920258 A CN 107920258A
- Authority
- CN
- China
- Prior art keywords
- played
- caching
- data
- medium data
- write
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
- H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
-
- 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The invention discloses a kind of data processing method, applied to reciprocity (Peer) node, is provided with the first caching, P2P players can obtain multi-medium data to be played from each subregion of the described first caching successively according to the subregion of the described first caching；Method includes：According to preset condition, the Part I data in multi-medium data to be played are write into the described first top n buffer area cached successively；N is the integer more than or equal to 1；The multi-medium data to be played of each buffer area storage can make the P2P players normal play in the preset condition characterization top n buffer area, and the multi-medium data to be played of top n buffer area storage can make the duration of the P2P players normal play reach the first predetermined threshold value；Part II data in the multi-medium data to be played are write to M memory block of first caching in addition to top n memory block successively；M is the integer more than or equal to 1.The present invention also discloses a kind of data processing equipment.
Description
Technical field
The present invention relates to stream media technology, more particularly to a kind of data processing method and device.
Background technology
As shown in Figure 1, existing peer-to-peer network (P2P, Peer to Peer) player uses Web Service technologies mostly
To realize the data interaction of reciprocity (Peer) between node and decoder.
Needed in the interaction based on Web Service technologies by command analysis, data buffer storage, data forwarding etc.
Step.However, these excessive intermediate links can be expended in P2P playing process the time, memory and central processing unit (CPU,
Central Processing Unit) etc. resource so that many P2P players do not reach second level and start at present, playing efficiency
It is relatively low, thus in the business such as live, video is social, virtual reality (VR, Virtual Reality), KTV user experience compared with
Difference.
The content of the invention
To solve existing technical problem, the embodiment of the present invention provides a kind of data processing method and device.
What the technical solution of the embodiment of the present invention was realized in：
An embodiment of the present invention provides a kind of data processing method, applied to Peer nodes, is provided with the first caching, P2P
Player can obtain multimedia to be played from each subregion of the described first caching successively according to the subregion of the described first caching
Data；The described method includes：
According to preset condition, the Part I data in multi-medium data to be played are write into first caching successively
Top n buffer area；N is the integer more than or equal to 1；Each buffer area storage in the preset condition characterization top n buffer area
Multi-medium data to be played can make the P2P players normal play, and the multimedia number to be played of top n buffer area storage
Reach the first predetermined threshold value according to the duration of the P2P players normal play can be made；
Part II data in the multi-medium data to be played are write to described in addition to top n memory block successively
M memory block of one caching；M is the integer more than or equal to 1.
In such scheme, according to preset condition, the Part I data in multi-medium data to be played are write into institute successively
The top n buffer area of the first caching is stated, including：
Multi-medium data to be played is write in first buffer area of the described first caching；
When the multi-medium data size for writing first buffer area reaches the second predetermined threshold value, notice P2P players open
It is dynamic to play；And data to be played are write in second buffer area to top n buffer area successively；Write the multimedia of each buffer area
Size of data is second predetermined threshold value.
In such scheme, the Part II data by the multi-medium data to be played write except top n successively
M memory block of first caching outside memory block, including：
According to the size of the M memory block, the Part II data are write into the M memory block successively.
In such scheme, the method further includes：
Receive the preset condition of the P2P players instruction.
In such scheme, the method further includes：
Data to be played are read from the described first caching, and the number to be played read is actively sent to the P2P players
According to；Wherein,
Read and write operation can not be carried out at the same time in same buffer area.
It is described according to preset condition in such scheme, the Part I data in multi-medium data to be played are write successively
Before the top n buffer area for entering first caching, the method further includes：
Receive multi-medium data to be played.
In such scheme, the method further includes：
When needing to share multi-medium data to be played to other Peer nodes, multimedia is read from the described first caching
Data.
In such scheme, the Peer nodes are additionally provided with the second caching；The method further includes：
Receive multi-medium data to be played；
The multi-medium data to be played of reception is also write to the second caching and storage device at the same time.
In such scheme, the method further includes：
When the second caching of program request write-in and the multi-medium data to be played of storage device, and according to preset condition, will wait to broadcast
Put the Part I data in multi-medium data to write successively before the top n buffer area of first caching, the method is also
Including：
Multi-medium data to be played is read in being set from the second caching and/or storage, by the multimedia to be played of reading
The first caching of data write-in.
In such scheme, the Peer nodes are additionally provided with the 3rd caching；The method further includes：
When needing to share multi-medium data to be played to other Peer nodes, multimedia is read from the storage device
Data, and the multi-medium data write-in the described 3rd of reading is cached；
And/or
Multi-medium data is read from the described second caching.
The embodiment of the present invention additionally provides a kind of data processing equipment, is arranged on Peer nodes, and the Peer nodes are set
There is the first caching, P2P players can be obtained from each subregion of the described first caching successively according to the subregion of the described first caching
Take multi-medium data to be played；Described device includes：
First writing unit, for according to preset condition, by the Part I data in multi-medium data to be played successively
Write the top n buffer area of first caching；N is the integer more than or equal to 1；The preset condition characterizes top n buffer area
In the multi-medium data to be played of each buffer area storage can make the P2P players normal play, and top n buffer area is deposited
The multi-medium data to be played of storage can make the duration of the P2P players normal play reach the first predetermined threshold value；
Second writing unit, for writing successively the Part II data in the multi-medium data to be played except preceding N
M memory block of first caching outside a memory block；M is the integer more than or equal to 1.
In such scheme, described device further includes：
First receiving unit, for receiving the preset condition of the P2P players instruction.
In such scheme, described device further includes：
First reading unit, for reading data to be played from the described first caching, and actively sends out to the P2P players
Send the data to be played of reading；Wherein,
Read and write operation can not be carried out at the same time in same buffer area.
In such scheme, described device further includes：
Second receiving unit, for receiving multi-medium data to be played.
In such scheme, described device further includes：
Second reading unit, for when needing to share multi-medium data to be played to other Peer nodes, from described the
Multi-medium data is read in one caching.
In such scheme, the Peer nodes are additionally provided with the second caching；Described device further includes：
3rd receiving unit, for receiving multi-medium data to be played；
3rd writing unit, for also the caching of write-in second and storage to be set at the same time by the multi-medium data to be played of reception
It is standby.
In such scheme, described device further includes：
3rd reading unit, for reading multi-medium data to be played in being set from the second caching and/or storage, will read
The first caching of multi-medium data to be played write-in taken.
In such scheme, the Peer nodes are additionally provided with the 3rd caching；Described device further includes：
4th reading unit, for when needing to share multi-medium data to be played to other Peer nodes, being deposited from described
Multi-medium data is read in storage equipment, and the multi-medium data write-in the described 3rd of reading is cached；And/or from described second
Caching reads multi-medium data.
Data processing method provided in an embodiment of the present invention and device, Peer nodes are provided with the first caching, P2P players
Multi-medium data to be played can be obtained from each subregion of the described first caching successively according to the subregion of the described first caching；Press
According to preset condition, the top n that the Part I data in multi-medium data to be played are write to first caching successively caches
Area；N is the integer more than or equal to 1；More matchmakers to be played of each buffer area storage in the preset condition characterization top n buffer area
Volume data can make the P2P players normal play, and the multi-medium data to be played of top n buffer area storage can make institute
The duration for stating P2P player normal plays reaches the first predetermined threshold value；By the Part II in the multi-medium data to be played
Data write M memory block of first caching in addition to top n memory block successively；M is integer more than or equal to 1, Peer
Node and P2P players realize caching and share, and reduce caching number and occupation condition, so, it is possible to greatly improve
Playing efficiency.Meanwhile cache shared mode and can make Peer nodes and P2P players in same process, i.e., data pass
The synchronous transmission technology of defeated use, the communication and switching not being related between process, therefore response speed is faster than asynchronous transmission, such as
This, further substantially increases playing efficiency.
Brief description of the drawings
In attached drawing (it is not necessarily drawn to scale), similar reference numeral phase described in different views
As component.Similar reference numerals with different letter suffix can represent the different examples of similar component.Attached drawing with example and
Unrestricted mode generally shows each embodiment discussed herein.
Fig. 1 is the method flow schematic diagram of one data processing of the embodiment of the present invention；
Fig. 2 is two set up box structure schematic diagram of the embodiment of the present invention；
Fig. 3 is two request program flow diagram of the embodiment of the present invention；
Fig. 4 is two Peer cache structure schematic diagrames of the embodiment of the present invention；
Fig. 5 is cache management process schematic under two live scene of the embodiment of the present invention；
Fig. 6 is cache management process schematic under two program request scene of the embodiment of the present invention；
Fig. 7 is three data processing equipment structure diagram of the embodiment of the present invention.
Embodiment
The present invention is described in further detail again with reference to the accompanying drawings and embodiments.
During realizing the data interaction between Peer nodes and decoder using Web Service technologies, exist
Following shortcoming：
First, during using Web Service technical transmission data, the Web Service positioned at Peer (can be understood as one
Kind of application program) first downloading program data and cache, player copies a data from Web Service and is put into the caching of oneself
Pond, then plays；So in playing process, cached twice, copied once altogether, than relatively time-consuming, and occupy compared with
More memory, cpu resource.Therefore, the occasion of 1G band above is required in VR etc., once caching means very big property with forwarding more
Can consumption and hydraulic performance decline.And start in the interactive occasion such as social activity and improve hundreds of milliseconds, the experience of user has great lifting.
Second, when transmitting data using Web Service, Peer nodes belong to two processes with P2P players, largely
The transmission of data can only use asynchronous transmission technology；P2P players first can initiate playing request to Peer nodes in asynchronous transmission,
After Peer nodes have received a certain amount of data, first send out message informing P2P player data and arrived, P2P players are notified
Read data again afterwards, refer here to the links such as process scheduling, message transmission, the regular hour can be expended, therefore respond too late
When, therefore can also to start slow.
Based on this, in various embodiments of the present invention：Peer nodes are provided with the first caching, and P2P players can be by
According to the subregion of the described first caching multi-medium data to be played is obtained from each subregion of the described first caching successively；According to default
Part I data in multi-medium data to be played, are write the top n buffer area of first caching by condition successively；N is
Integer more than or equal to 1；The multi-medium data to be played of each buffer area storage in the preset condition characterization top n buffer area
It can make the P2P players normal play, and the multi-medium data to be played of top n buffer area storage can make the P2P
The duration of player normal play reaches the first predetermined threshold value；By the Part II data in the multi-medium data to be played according to
M memory block of first caching of the secondary write-in in addition to top n memory block；M is the integer more than or equal to 1.
Embodiment one
The method of data processing of the embodiment of the present invention, applied to Peer nodes, is provided with the first caching, P2P player energy
Enough subregions according to the described first caching obtain multi-medium data to be played from each subregion of the described first caching successively.Also
It is to say, Peer nodes share a caching with P2P players.
Fig. 1 is the method flow schematic diagram of one data processing of the embodiment of the present invention.As shown in Figure 1, this method includes：
Step 101：According to preset condition, the Part I data in multi-medium data to be played are write described successively
The top n buffer area of one caching；
Wherein, N is the integer more than or equal to 1.
The multi-medium data to be played of each buffer area storage can make institute in the preset condition characterization top n buffer area
P2P player normal plays are stated, and the multi-medium data to be played of top n buffer area storage can make the P2P players just
The duration often played reaches the first predetermined threshold value.
Here, the normal play refers to：Broadcasting speed meets the threshold speed of setting.
Specifically, multi-medium data to be played is write in first buffer area of the described first caching；
When the multi-medium data size for writing first buffer area reaches the second predetermined threshold value, notice P2P players open
It is dynamic to play；And data to be played are write in second buffer area to top n buffer area successively；Write the multimedia of each buffer area
Size of data is second predetermined threshold value, and the multi-medium data size for writing each buffer area is the described second default threshold
Value, energy streamlining management process, so as to save resource.
In one embodiment, before performing this step, this method can also include：
Receive the preset condition of the P2P players instruction.
In other words, the P2P players can indicate the first predetermined threshold value of Peer nodes, the second predetermined threshold value.
Wherein, first predetermined threshold value can be arranged as required to, so that it is criterion that the P2P players, which quickly start,.
Second predetermined threshold value can also be arranged as required to.
During practical application, when under live scene, before this step is performed, it is necessary first to from content provider's (its
Its Peer node) obtain multi-medium data to be played, that is to say, that and the Peer nodes want what first reception content supplier sent
Multi-medium data to be played.
When under program request scene, following two situations can be divided into：
The first situation, the Peer nodes are not locally stored with multi-medium data to be played, at this time, are performing this step
Before 101, the Peer nodes need the multi-medium data to be played that first reception content supplier sends；Then reception is treated
Play multi-medium data and also write the second caching and storage device at the same time, so as to next user's program request.
Wherein, the storage setting can be the equipment such as flash memory (Flash), external storage card, external hard disk.
The second situation, the Peer nodes local (the second caching and storage device) are stored with multimedia number to be played
According to before step 101 is performed, the Peer nodes read multimedia number to be played in being set from the second caching and/or storage
According to by the first caching of multi-medium data to be played write-in of reading.
Step 102：Part II data in the multi-medium data to be played are write in addition to top n memory block successively
It is described first caching M memory block.
Here, M is the integer more than or equal to 1.
In other words, first caching includes N and M subregion.
Specifically, the Peer nodes write the Part II data according to the size of the M memory block successively
The M memory block.
During practical application, the size of the multi-medium data to be played of the caching of write-in first meets that broadcasting demand i.e. first is slow
Deposit area and write the multi-medium data size of first buffer area when reaching the second predetermined threshold value (meeting broadcasting demand), it is possible to from
Read multi-medium data to be played in first caching, hereafter during, multi-medium data to be played write-in and read can be same
Shi Jinhang, but write-in and read operation cannot be carried out at the same time in same subregion.That is, for a subregion, or into
Row read operation, otherwise carry out write operation.
In embodiments of the present invention, Peer nodes and P2P players share the first caching, it is possible to take push
(PUSH) pattern sends multi-medium data to be played to P2P players, and PUSH patterns can support live and two kinds of scenes of program request.
Specifically, the Peer nodes read data to be played from the described first caching, and are actively played to the P2P
Device sends the data to be played read；Wherein,
Read and write operation can not be carried out at the same time in same buffer area.
In other words, in data transmission procedure, multi-medium data to be played is constantly actively transmitted to P2P by Peer nodes and broadcasts
Device is put, flow (transmission speed) is by Peer node controls.Specifically, in on-demand process, Peer sections can be according to video frequency program
Code check, sends remaining data volume in caching, to realize the control of data traffic to P2P players.During live, Peer sections
Multi-medium data in caching is directly all sent to P2P players by point.
As Peer nodes, it is also necessary to there is sharing function, i.e., as content provider, the multimedia number that will be locally stored
According to being shared with other Peer nodes.
Based on this, under live scene, when needing to share multi-medium data to be played to other Peer nodes, from described
Multi-medium data is read in first caching；
Under program request scene, the Peer nodes are additionally provided with the 3rd caching, share when needs to other Peer nodes and treat
When playing multi-medium data, multi-medium data is read from the storage device, and by described in the multi-medium data write-in of reading
3rd caching；And/or read multi-medium data from the described second caching.
Wherein, for live scene, the broadcasting of program is identical with the live content (multi-medium data) shared, so
It need not will play content and sharing contents are stored separately, i.e., using different cachings, so be easy to implement.
If distinguishing each caching from the function of caching, the first caching is properly termed as playing, and the second caching is properly termed as
Memory buffers, the 3rd caching are properly termed as sharing caching.
In addition, during practical application, stopping that the Peer nodes can also be sent according to P2P players, F.F., rewind,
The order such as redirect, corresponding broadcasting content (multi-medium data to be played) is put into the first caching according to these orders.
Method provided in an embodiment of the present invention, Peer nodes are provided with the first caching, and P2P players can be according to described
The subregion of one caching obtains multi-medium data to be played from each subregion of the described first caching successively；, will according to preset condition
Part I data in multi-medium data to be played write the top n buffer area of first caching successively；N be more than or equal to
1 integer；The multi-medium data to be played of each buffer area storage can make institute in the preset condition characterization top n buffer area
P2P player normal plays are stated, and the multi-medium data to be played of top n buffer area storage can make the P2P players just
The duration often played reaches the first predetermined threshold value；Part II data in the multi-medium data to be played are write successively and are removed
M memory block of first caching outside top n memory block；M is the integer more than or equal to 1, Peer nodes and P2P players
It is shared to realize caching, reduces caching number and occupation condition, so, it is possible to greatly improve playing efficiency.Meanwhile
Peer nodes and P2P players in same process, i.e., data transfer use synchronous transmission technology, be not related between process
Communication and switching, so response speed is faster than asynchronous transmission；In built-in player, optimization is calculated with millisecond
, scheme provided in an embodiment of the present invention can lift the response time.
Embodiment two
On the basis of embodiment one, by taking set-top box as an example, the machine top with P2P nodal functions is described in detail in the present embodiment
The internal structure of box, the function of each several part and program playing flow.
As shown in Fig. 2, set-top box mainly includes：Player application (APK or HTML APP), P2P players, Peer sections
Point.Wherein, P2P players and Peer nodes are realized at Native layers (ccf layers), the two modules are in same process,
Program data (multi-medium data to be played) is transmitted by way of shared buffer memory；Player application is application layer software, can be with
It is the application based on the language development such as Java or HyperText Markup Language (HTML, HyperText Markup Language).
In fig. 2,Represent internal interface,Represent external interface.
The function of each module is described in detail below.
(1) P2P players
P2P players are responsible for all playing functions beyond data acquisition, and major function includes：
1st, service authentication, to examine whether playback equipment has the right to play selected program；
2nd, the various instructions for playing program are sent to Peer nodes；
3rd, it is responsible for obtaining the multi-medium data of the types such as TS, MP4 from Peer nodes, and decodes output；
4th, it is responsible for the state of control program, for example broadcasting, pause, F.F., rewind, redirects；
5th, it is responsible for the output window management of video frequency program.
(2) Peer nodes
PEER nodes are mainly responsible for the programme content for obtaining and specifying, and are transferred to P2P players, its major function includes：
1st, after the content acquisition request for receiving P2P players, directly broadcast if the content for the request that locally prestored to P2P
Put the content that device returns to request, if it is local not if according to local scheduling result from content distributing network (CDN, Content
Delivery Network) (node listing is obtained by following the trail of (Tracker) server for system, super node or other P2P nodes
Take) obtain corresponding content；
2nd, when the content of request is returned P2P players, first by the (locally prestoring or obtained from other places of acquisition
Taking) content of multimedia is put into shared buffer memory, and notifies P2P that player commences play out, and take PUSH patterns to be sent out to P2P players
Data are sent, support live and program request；
3rd, receive P2P players transmission F.F., rewind, redirect when instruction when, according to these instruction generation play in
Hold and be put into shared buffer memory；
4th, shared buffer memory is managed, for example prevents spilling etc.；
5th, the situation downloaded to upper layer application reported data, such as：Number is buffered, burst is lost, mistake burst etc.；
6th, received content is subjected to Safe Cache, and service is provided to other Peer nodes when needing.
(3) player application
Player application can be APK or HTML5 applications, soft by JNI or JavaScript interface and Native layers
Part is connected, i.e., is connected with P2P players, is mainly used for carrying out user interface (UI) displaying, that is, is presented to user's viewing.
(4) external interface of the internal interface between each module and set-top box
1st, internal interface
Internal interface main function includes：
(1) control is played
Send to play and start, stop, F.F., rewind, the order such as redirect, play and start order and need incoming to play unified money
Source finger URL (URL, Uniform Resource Locator) and security information.
(2) reading and writing data
Peer nodes are to P2P players direction：Peer nodes are to P2P players with appropriate speed push shared buffer memory
Multi-medium data, and Load Game is set.
(3) information inquiry
P2P players are to Peer node directions：Version, the P2P of inquiry Peer nodes share the information such as rate；
Peer nodes are to P2P players direction：Inquire about P2P players version, terminal software and hardware information etc..
Wherein, the logic of itself is adjusted according to the version information of other side, and P2P shares rate and is used to judge Peer nodes
Efficiency.
2nd, external interface explanation
(1) P2P players external interface
P2P player external interface main functions include：
1st, obtain and play programm name：Selected according to user, obtained by player application (APK) according to programme information inquiry
Take；
2nd, service authentication：Program play right is examined according to hardware and account information；
3rd, broadcast state is reported to player application：According to SQM related specifications, report player startup, stopping, interim card,
The information such as buffering, the quality played with monitor video；
4th, audio and video export：The programme informations such as audio, video, subtitle are output to the playback equipments such as TV, and control window
Mouth size and location；
(2) Peer nodes external interface
Mainly include following external interface：
Traditional CDN interfaces：For obtaining program data from traditional CDN according to local scheduling strategy；
P2PCDN interfaces：For obtaining program data from P2PCDN according to local scheduling strategy；
Tracker interfaces：A part of P2PCDN, is mainly responsible for the Peer nodes row that request resource is provided to Peer nodes
Table, manages the content of Peer nodes, and provides completeness check；
With other Peer node interfaces：For mutual sharing data.
Structure with reference to shown in Fig. 2, as shown in figure 3, request program playing flow mainly includes the following steps that：
Step 301：Player application sends program playing request to P2P players；
Step 302：P2P players initiate service authentication request, and play program according to authentication information and antitheft chain building
URL；
Step 303：P2P players are to Peer node request program data；
Step 304：After Peer nodes receive request, from being locally stored, CDN or P2PCDN obtain program data, and are put into
Shared buffer memory；
Step 305：When the data of shared buffer memory reach broadcasting demand, Peer nodes notice P2P players commence play out；
Step 306：Peer nodes read shared buffer memory program data, and send program to P2P players in a manner of PUSH
Data；
Step 307：After P2P players receive program data, decoded, and exported to player application, carry out program
Play.
Here, the playing flow of programme televised live and the playing flow of request program are similar, except that：In step 304
In, the data acquiring mode of Peer nodes is different, that is, when playing programme televised live, Peer nodes can only be obtained from CDN or P2PCDN
Program data.
Program, which stops broadcasting, to be needed to support two ways：
First way, actively stops playing
Initiated by player application or fatal exception occur in P2P players, mainly included：
Step 308：In program playing process, if user actively stops playing, player application is to P2P players
Send and stop playing instruction；
Step 309：P2P players are sent to Peer nodes to be stopped playing instruction.
The second way, program, which plays, to be terminated
Initiated by Peer nodes, for example program request file is played and terminated, and is mainly included：
Step 310：At the end of request program plays, the notice P2P players request program of Peer nodes, which plays, to be terminated；
Step 311：After P2P players are notified, sent to Peer nodes and stop play instruction；
Step 312：P2P players notice player application, which plays, to be terminated.
Wherein, for shared buffer memory, it is a module in Peer nodes, and Peer nodes are the library files of a standard
Or a Service in android system, developed, may migrate to big at present based on C language and (SuSE) Linux OS
In the terminal devices such as most set-top boxes.And shared buffer memory be mainly used for Peer nodes and decoding terminals module (P2P players) it
Between data interaction.
Fig. 4 is the buffer structure schematic diagram of Peer nodes.Described respectively in detail with reference to Fig. 4 under live and program request scene
Way to manage of the Peer nodes to own cache.In Fig. 4, solid line with the arrow represents live or program request data flow at initial stage；
Dotted line with the arrow represents data cached flow direction when program speed of download is more than broadcasting speed in program request.
First, the cache management process under live scene is described.
Program is related only to since P2P is live to play and share, and is not related to program storage, therefore it is slow only to have used broadcasting
Deposit (shared buffer memory i.e. in step 304).
As shown in figure 5, the cache management process of Peer nodes comprises the following steps during live：
Step 501：When live, P2P players can set a startup broadcast to Peer nodes first when set-top box starts
Put cache threshold；
During practical application, it is believed that Peer intra-nodes have a caching management module, and P2P players are to cache management
Module sets one to start and plays cache threshold, and caching management module is mainly responsible for the distribution and recycling of buffer area, subsequently according to
The size of the buffer area of distribution writes corresponding program data.
Step 502：After Peer nodes get program data, program data first is write to first buffer area, reaches and sets
After the startup put plays cache threshold, Peer nodes notice P2P players, which start, to be played, and reads first buffer area at the same time
Program data, and it is transferred to P2P players；
Step 503：The buffer area of Peer nodes successively rearwards writes an equal amount of program data, and constantly repeats this
A process；
The program data size of i.e. each buffer area write-in is that the startup of setting plays cache threshold.
Step 504：When the program caching not played reaches safe range, (for example smooth broadcasting is for a period of time, that is, plays
Speed reaches a threshold value and continue for a period of time) after, Peer nodes appropriate increase write-in program in buffer area below
The size of data, slows down until writing full seeding and saves as only；
During program data is write, Peer nodes are successively read deposit buffer area always according to broadcasting speed at the same time
Program data.
Step 505：When progress P2P programme televised lives are shared, the downstream site of live tree can only passively receive superior node
The data shared, therefore Peer nodes read sharing contents in broadcasting caching.
Here, it is necessary to which explanation is：During practical application, the live middle buffer area number for playing caching can be according to actual feelings
Condition is selected, and for ease of management, at least needs two buffer areas, one when read, another is write, same buffer area
Read and write operation cannot be carried out at the same time.
Then, the cache management process under program request scene is described
The caching of P2P program requests is divided into three classes, respectively plays caching (shared buffer memory), memory buffers and shares caching；Only
There is broadcasting caching to be shared with P2P players.Request program can manage memory buffers when commencing play out together with playing caching
Reason, the separate management again after order program data downloads to safe range.
As shown in fig. 6, the cache management process of Peer nodes comprises the following steps in on-demand process：
Step 601：During request program, P2P players can set a startup to Peer nodes first when set-top box starts
Cache threshold is played, cache contents will be played if necessary and be directly stored in storage device；
During practical application, it is believed that Peer intra-nodes have a caching management module, and P2P players are to cache management
Module sets one to start and plays cache threshold, and caching management module is mainly responsible for the distribution and recycling of caching.
Step 602：After Peer nodes get program data, program data first is write to first buffer area, reaches and sets
After the startup put plays cache threshold, notice P2P players, which start, to be played, and reads the number of programs of first buffer area at the same time
According to, and it is transferred to P2P players；
Step 603：The broadcasting buffer area of Peer nodes successively rearwards writes an equal amount of data, and constantly repeats this
A process；
The program data size of i.e. each buffer area write-in is that the startup of setting plays cache threshold.
Step 604：When the program caching not played reaches safe range, (for example smooth broadcasting is for a period of time, that is, plays
Speed reaches a threshold value and continue for a period of time) after, Peer nodes are by Xie Man further caches area；
Step 605：After the program data not played is cached close to certain threshold value (such as 80% always cached), at this time may be used
Caching is divided into and broadcasts caching and memory buffers；
Here, during practical application, the speed of download of program data is generally higher than broadcasting speed, i.e. Peer sections in program request scene
The speed that point receives program data is more than the speed that data are sent to P2P players, so the program data caching that ought do not played
During close to certain threshold value, that is, when the program data size downloaded can be far longer than the program data size of broadcasting, it will can cache
It is divided into and broadcasts caching and memory buffers.
Step 606：The follow-up data newly received first write memory buffers and storage device, then further according to broadcasting caching
Program to be broadcast data are played caching by size from memory buffers and/or storage device write-in；
During program data is write, Peer nodes are successively read deposit buffer area always according to broadcasting speed at the same time
Program data.
Step 607：When carrying out P2P request programs and sharing, sharing contents directly read in storage device and write point
Caching is enjoyed, then sharing contents are read from caching is shared, and/or when memory buffers also have sharing contents, directly from memory buffers
Sharing contents are read, to be shared with other Peer nodes, broadcasting caching is not related to during being somebody's turn to do.
It should be noted that：During practical application, as shown in figure 4, each buffer area can only carry out a kind of behaviour a moment
Make, or being read operation, or being write operation, and reading cannot be carried out at the same time and write two kinds of operations.
In conclusion in scheme provided in an embodiment of the present invention, P2P players and Peer nodes employ shared buffer memory skill
Art, P2P players can directly play the data of shared buffer memory, reduce a data buffer storage and copy link, improve performance.
Meanwhile using shared buffer memory technology can synchronous data transmission technology, so as to improve the response time of control instruction and data transfer.
P2P player systems based on shared buffer memory are live etc. in social activity, interaction than traditional Web Service technical efficiency highers
Field can be obviously improved user experience；Playing efficiency can be improved in fields such as following VR, AR, improves dizziness.
In addition, set-top box has player application, P2P players and Peer nodes, this modular structure can drop
Low efficiently player realizes difficulty.
Embodiment three
To realize the method for the embodiment of the present invention, the present embodiment provides a kind of data processing equipment, is arranged on Peer nodes,
The Peer nodes are provided with the first caching, and P2P players can be according to the subregion of the described first caching successively from described first
Multi-medium data to be played is obtained in each subregion of caching；As shown in fig. 7, the device includes：
First writing unit 71, for according to preset condition, by the Part I data in multi-medium data to be played according to
The top n buffer area of secondary write-in first caching；N is the integer more than or equal to 1；The preset condition characterization top n caching
The multi-medium data to be played of each buffer area storage can make the P2P players normal play, and top n buffer area in area
The multi-medium data to be played of storage can make the duration of the P2P players normal play reach the first predetermined threshold value；
Second writing unit 72, for before the Part II data in the multi-medium data to be played are write successively removes
M memory block of first caching outside N number of memory block；M is the integer more than or equal to 1.
In other words, first caching includes N and M subregion.
Wherein, the normal play refers to：Broadcasting speed meets the threshold speed of setting.
First writing unit 71, is specifically used for：
When the multi-medium data size for writing first buffer area reaches the second predetermined threshold value, notice P2P players open
It is dynamic to play；And data to be played are write in second buffer area to top n buffer area successively；Write the multimedia of each buffer area
Size of data is second predetermined threshold value, and the multi-medium data size for writing each buffer area is the described second default threshold
Value, energy streamlining management process, so as to save resource.
In one embodiment, which can also include：
First receiving unit, for receiving the preset condition of the P2P players instruction.
In other words, the P2P players can indicate the first predetermined threshold value of Peer nodes, the second predetermined threshold value.
Wherein, first predetermined threshold value can be arranged as required to, so that it is criterion that the P2P players, which quickly start,.
Second predetermined threshold value can also be arranged as required to.
During practical application, when under live scene, before first writing unit 71 performs its function, need first
Multi-medium data to be played is obtained from content provider's (other Peer nodes), that is to say, that the Peer nodes will first connect
Receive the multi-medium data to be played that content provider sends.
Based on this, which can also include：
Second receiving unit, the multi-medium data to be played sent for reception content supplier.
When under program request scene, following two situations can be divided into：
The Peer nodes are not locally stored with multi-medium data to be played, at this time, it are performed in the first writing unit 71
Before function, the Peer nodes need the multi-medium data to be played that first reception content supplier sends；Then by reception
Multi-medium data to be played also write-in second at the same time caches and storage device, so as to next user's program request.
Wherein, the storage setting can be the equipment such as flash memory (Flash), external storage card, external hard disk.
Based on this, which can also include：
3rd receiving unit, for receiving multi-medium data to be played；
3rd writing unit, for also the caching of write-in second and storage to be set at the same time by the multi-medium data to be played of reception
It is standby.
The second situation, the Peer nodes local (the second caching and storage device) are stored with multimedia number to be played
According to before the first writing unit 71 performs its function, the Peer nodes read in being set from the second caching and/or storage and treat
Multi-medium data is played, by the first caching of multi-medium data to be played write-in of reading.
Based on this, which can also include：
3rd reading unit, for reading multi-medium data to be played in being set from the second caching and/or storage, will read
The first caching of multi-medium data to be played write-in taken.
During practical application, the size of the multi-medium data to be played of the caching of write-in first meets that broadcasting demand i.e. first is slow
Deposit area and write the multi-medium data size of first buffer area when reaching the second predetermined threshold value (meeting broadcasting demand), it is possible to from
Read multi-medium data to be played in first caching, hereafter during, multi-medium data to be played write-in and read can be same
Shi Jinhang, but write-in and read operation cannot be carried out at the same time in same subregion.That is, for a subregion, or into
Row read operation, otherwise carry out write operation.
In embodiments of the present invention, Peer nodes and P2P players share the first caching, it is possible to take push
(PUSH) pattern sends multi-medium data to be played to P2P players, and PUSH patterns can support live and two kinds of scenes of program request.
Specifically, which can also include：
First reading unit, for reading data to be played from the described first caching, and actively sends out to the P2P players
Send the data to be played of reading；Wherein,
Read and write operation can not be carried out at the same time in same buffer area.
In other words, in data transmission procedure, multi-medium data to be played is constantly actively transmitted to P2P by Peer nodes and broadcasts
Device is put, flow (transmission speed) is by Peer node controls.Specifically, in on-demand process, first reading unit can basis
The code check of video frequency program, sends remaining data volume in caching, to realize the control of data traffic to P2P players.Live mistake
Multi-medium data all in caching is directly sent to P2P players by Cheng Zhong, first reading unit.
As Peer nodes, it is also necessary to there is sharing function, i.e., as content provider, the multimedia number that will be locally stored
According to being shared with other Peer nodes.
Based on this, under live scene, when needing to share multi-medium data to be played to other Peer nodes, from described
Multi-medium data is read in first caching.
Therefore, in one embodiment, which can also include：Second reading unit, needs to other Peer for working as
When node shares multi-medium data to be played, multi-medium data is read from the described first caching.
Under program request scene, the Peer nodes are additionally provided with the 3rd caching, share when needs to other Peer nodes and treat
When playing multi-medium data, multi-medium data is read from the storage device, and by described in the multi-medium data write-in of reading
3rd caching；And/or read multi-medium data from the described second caching.
Therefore, in one embodiment, which can also include：
4th reading unit, for when needing to share multi-medium data to be played to other Peer nodes, being deposited from described
Multi-medium data is read in storage equipment, and the multi-medium data write-in the described 3rd of reading is cached；And/or from described second
Caching reads multi-medium data.
Wherein, for live scene, the broadcasting of program is identical with the live content (multi-medium data) shared, so
It need not will play content and sharing contents are stored separately, i.e., using different cachings, so be easy to implement.
If distinguishing each caching from the function of caching, the first caching is properly termed as playing, and the second caching is properly termed as
Memory buffers, the 3rd caching are properly termed as sharing caching.
In addition, during practical application, stopping that first writing unit 71 can also be sent according to P2P players, F.F.,
Rewind, the order such as redirect, and corresponding broadcasting content (multi-medium data to be played) is put into the first caching according to these orders.
During practical application, first writing unit 71, the second writing unit 72, the first receiving unit, the 3rd write-in are single
Member, the 3rd reading unit, the first reading unit, the second reading unit, the 4th reading unit can be by data processing equipments
Central processor (CPU, Central Processing Unit), microprocessor (MCU, Micro Control Unit), numeral letter
Number processor (DSP, Digital Signal Processor) or programmable logic array (FPGA, Field-
Programmable Gate Array) realize；Second receiving unit, the 3rd receiving unit can be by data processing equipments
Communication chip realize.
Scheme provided in an embodiment of the present invention, Peer nodes are provided with the first caching, and P2P players can be according to described
The subregion of one caching obtains multi-medium data to be played from each subregion of the described first caching successively；, will according to preset condition
Part I data in multi-medium data to be played write the top n buffer area of first caching successively；N be more than or equal to
1 integer；The multi-medium data to be played of each buffer area storage can make institute in the preset condition characterization top n buffer area
P2P player normal plays are stated, and the multi-medium data to be played of top n buffer area storage can make the P2P players just
The duration often played reaches the first predetermined threshold value；Part II data in the multi-medium data to be played are write successively and are removed
M memory block of first caching outside top n memory block；M is the integer more than or equal to 1, Peer nodes and P2P players
It is shared to realize caching, reduces caching number and occupation condition, so, it is possible to greatly improve playing efficiency.Meanwhile
Peer nodes and P2P players in same process, i.e., data transfer use synchronous transmission technology, be not related between process
Communication and switching, so response speed is faster than asynchronous transmission；In built-in player, optimization is calculated with millisecond
, scheme provided in an embodiment of the present invention can lift the response time.
It should be understood by those skilled in the art that, the embodiment of the present invention can be provided as method, system or computer program
Product.Therefore, the shape of the embodiment in terms of the present invention can use hardware embodiment, software implementation or combination software and hardware
Formula.Moreover, the present invention can use the computer for wherein including computer usable program code in one or more to use storage
The form for the computer program product that medium is implemented on (including but not limited to magnetic disk storage and optical memory etc.).
The present invention be with reference to according to the method for the embodiment of the present invention, the flow of equipment (system) and computer program product
Figure and/or block diagram describe.It should be understood that it can be realized by computer program instructions every first-class in flowchart and/or the block diagram
The combination of flow and/or square frame in journey and/or square frame and flowchart and/or the block diagram.These computer programs can be provided
The processors of all-purpose computer, special purpose computer, Embedded Processor or other programmable data processing devices is instructed to produce
A raw machine so that the instruction performed by computer or the processor of other programmable data processing devices, which produces, to be used in fact
The device for the function of being specified in present one flow of flow chart or one square frame of multiple flows and/or block diagram or multiple square frames.
These computer program instructions, which may also be stored in, can guide computer or other programmable data processing devices with spy
Determine in the computer-readable memory that mode works so that the instruction being stored in the computer-readable memory, which produces, to be included referring to
Make the manufacture of device, the command device realize in one flow of flow chart or multiple flows and/or one square frame of block diagram or
The function of being specified in multiple square frames.
These computer program instructions can be also loaded into computer or other programmable data processing devices so that counted
Series of operation steps is performed on calculation machine or other programmable devices to produce computer implemented processing, thus in computer or
The instruction performed on other programmable devices is provided and is used for realization in one flow of flow chart or multiple flows and/or block diagram one
The step of function of being specified in a square frame or multiple square frames.
The foregoing is only a preferred embodiment of the present invention, is not intended to limit the scope of the present invention.
Claims (18)
1. a kind of data processing method, it is characterised in that applied to reciprocity Peer nodes, be provided with the first caching, peer-to-peer network
P2P players can obtain more matchmakers to be played from each subregion of the described first caching successively according to the subregion of the described first caching
Volume data；The described method includes：
According to preset condition, the Part I data in multi-medium data to be played are write into the described first preceding N cached successively
A buffer area；N is the integer more than or equal to 1；Each buffer area storage waits to broadcast in the preset condition characterization top n buffer area
The P2P players normal play, and the multi-medium data energy to be played of top n buffer area storage can be made by putting multi-medium data
The duration of the P2P players normal play is enough set to reach the first predetermined threshold value；
Part II data in the multi-medium data to be played are write described first in addition to top n memory block successively to delay
The M memory block deposited；M is the integer more than or equal to 1.
2. according to the method described in claim 1, it is characterized in that, according to preset condition, by multi-medium data to be played
Part I data write the top n buffer area of first caching successively, including：
Multi-medium data to be played is write in first buffer area of the described first caching；
When the multi-medium data size for writing first buffer area reaches the second predetermined threshold value, notice P2P players, which start, to be broadcast
Put；And data to be played are write in second buffer area to top n buffer area successively；Write the multi-medium data of each buffer area
Size is second predetermined threshold value.
3. according to the method described in claim 1, it is characterized in that, second by the multi-medium data to be played
Divided data writes M memory block of first caching in addition to top n memory block successively, including：
According to the size of the M memory block, the Part II data are write into the M memory block successively.
4. according to the method described in claim 1, it is characterized in that, the method further includes：
Receive the preset condition of the P2P players instruction.
5. according to the method described in claim 1, it is characterized in that, the method further includes：
Data to be played are read from the described first caching, and the data to be played read are actively sent to the P2P players；Its
In,
Read and write operation can not be carried out at the same time in same buffer area.
6. method according to any one of claims 1 to 5, it is characterised in that it is described according to preset condition, will be to be played more
Part I data in media data write before the top n buffer area of first caching successively, and the method further includes：
Receive multi-medium data to be played.
7. according to the method described in claim 6, it is characterized in that, the method further includes：
When needing to share multi-medium data to be played to other Peer nodes, multimedia number is read from the described first caching
According to.
8. method according to any one of claims 1 to 5, it is characterised in that it is slow that the Peer nodes are additionally provided with second
Deposit；The method further includes：
Receive multi-medium data to be played；
The multi-medium data to be played of reception is also write to the second caching and storage device at the same time.
9. according to the method described in claim 8, it is characterized in that, the method further includes：
, will be to be played more when the second caching of program request write-in and the multi-medium data to be played of storage device, and according to preset condition
Part I data in media data write before the top n buffer area of first caching successively, and the method further includes：
Multi-medium data to be played is read in being set from the second caching and/or storage, by the multi-medium data to be played of reading
The caching of write-in first.
10. according to the method described in claim 8, it is characterized in that, the Peer nodes are additionally provided with the 3rd caching；The side
Method further includes：
When needing to share multi-medium data to be played to other Peer nodes, multimedia number is read from the storage device
According to, and the multi-medium data write-in the described 3rd of reading is cached；
And/or
Multi-medium data is read from the described second caching.
A kind of 11. data processing equipment, it is characterised in that Peer nodes are arranged on, the Peer nodes are provided with the first caching,
P2P players can obtain more matchmakers to be played from each subregion of the described first caching successively according to the subregion of the described first caching
Volume data；Described device includes：
First writing unit, for according to preset condition, the Part I data in multi-medium data to be played to be write successively
The top n buffer area of first caching；N is the integer more than or equal to 1；It is every in the preset condition characterization top n buffer area
The multi-medium data to be played of a buffer area storage can make the P2P players normal play, and the storage of top n buffer area
Multi-medium data to be played can make the duration of the P2P players normal play reach the first predetermined threshold value；
Second writing unit, for writing successively the Part II data in the multi-medium data to be played except top n is deposited
M memory block of first caching outside storage area；M is the integer more than or equal to 1.
12. according to the devices described in claim 11, it is characterised in that described device further includes：
First receiving unit, for receiving the preset condition of the P2P players instruction.
13. according to the devices described in claim 11, it is characterised in that described device further includes：
First reading unit, for reading data to be played from the described first caching, and actively sends to the P2P players and reads
The data to be played taken；Wherein,
Read and write operation can not be carried out at the same time in same buffer area.
14. according to claim 11 to 13 any one of them device, it is characterised in that described device further includes：
Second receiving unit, for receiving multi-medium data to be played.
15. device according to claim 14, it is characterised in that described device further includes：
Second reading unit, for when needing to share multi-medium data to be played to other Peer nodes, delaying from described first
Deposit middle reading multi-medium data.
16. according to claim 11 to 13 any one of them device, it is characterised in that the Peer nodes are additionally provided with second
Caching；Described device further includes：
3rd receiving unit, for receiving multi-medium data to be played；
3rd writing unit, for the multi-medium data to be played of reception also to be write to the second caching and storage device at the same time.
17. device according to claim 16, it is characterised in that described device further includes：
3rd reading unit, for reading multi-medium data to be played in being set from the second caching and/or storage, by reading
The first caching of multi-medium data write-in to be played.
18. device according to claim 16, it is characterised in that the Peer nodes are additionally provided with the 3rd caching；It is described
Device further includes：
4th reading unit, for when needing to share multi-medium data to be played to other Peer nodes, being set from the storage
Standby middle reading multi-medium data, and the multi-medium data write-in the described 3rd of reading is cached；And/or cached from described second
Read multi-medium data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610887828.2A CN107920258B (en) | 2016-10-11 | 2016-10-11 | Data processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610887828.2A CN107920258B (en) | 2016-10-11 | 2016-10-11 | Data processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107920258A true CN107920258A (en) | 2018-04-17 |
| CN107920258B CN107920258B (en) | 2020-09-08 |
Family
ID=61892703
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610887828.2A Active CN107920258B (en) | 2016-10-11 | 2016-10-11 | Data processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107920258B (en) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109151194A (en) * | 2018-08-14 | 2019-01-04 | Oppo广东移动通信有限公司 | Data transmission method, device, electronic equipment and storage medium |
| CN109889875A (en) * | 2019-01-23 | 2019-06-14 | 北京奇艺世纪科技有限公司 | Communication means, device, terminal device and computer-readable medium |
| CN110209447A (en) * | 2019-04-28 | 2019-09-06 | 五八有限公司 | A kind of list page data display method and list page data presentation device |
| WO2020093504A1 (en) * | 2018-11-07 | 2020-05-14 | 网宿科技股份有限公司 | Method, apparatus, and system for downloading data block of resource file |
| CN111669618A (en) * | 2019-03-08 | 2020-09-15 | 杭州海康威视***技术有限公司 | Picture playing control method, device, equipment and storage medium |
| CN113596495A (en) * | 2021-07-28 | 2021-11-02 | 广州方硅信息技术有限公司 | Live broadcast stream pushing processing method and device, equipment and medium thereof |
| WO2024082688A1 (en) * | 2022-10-20 | 2024-04-25 | 上海哔哩哔哩科技有限公司 | Method and apparatus for playing gift special-effect resource |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1845059A (en) * | 2005-04-08 | 2006-10-11 | 国际商业机器公司 | Data storage system with shared cache address space and operation method thereof |
| US20080016205A1 (en) * | 2006-07-11 | 2008-01-17 | Concert Technology Corporation | P2P network for providing real time media recommendations |
| CN101184021A (en) * | 2007-12-14 | 2008-05-21 | 华为技术有限公司 | Method, equipment and system for implementing stream media caching replacement |
| CN101448139A (en) * | 2009-01-08 | 2009-06-03 | 中国科学院计算技术研究所 | A P2P network based digital media program order method |
| CN101472143A (en) * | 2007-12-27 | 2009-07-01 | 华为技术有限公司 | Method and system for implementing stream medium service |
| CN101540882A (en) * | 2008-03-21 | 2009-09-23 | 盛大计算机（上海）有限公司 | P2P programme ordering method based on memory stream transmission |
| CN102917028A (en) * | 2012-09-26 | 2013-02-06 | 深圳好视网络科技有限公司 | Network video live broadcasting caching method and device |
| CN103401888A (en) * | 2013-08-21 | 2013-11-20 | 杭州浦禾通信技术有限公司 | Multimedia data receiving and processing method and device |
| CN103685344A (en) * | 2012-09-03 | 2014-03-26 | ***通信集团公司 | Synergetic method and system for multiple P2P (point-to-point) cache peers |
| CN103714038A (en) * | 2012-10-09 | 2014-04-09 | 中兴通讯股份有限公司 | Data processing method and device |
| CN103731720A (en) * | 2013-11-25 | 2014-04-16 | 乐视致新电子科技（天津）有限公司 | Method and device for caching multimedia data of smart television |
| CN104301356A (en) * | 2013-07-19 | 2015-01-21 | ***通信集团公司 | Data transmission method and system of P2P network |
| CN104717545A (en) * | 2013-12-17 | 2015-06-17 | 乐视网信息技术（北京）股份有限公司 | Video playing method and device |
| CN105447197A (en) * | 2015-12-29 | 2016-03-30 | 腾讯科技（深圳）有限公司 | Video downloading processing method and device, and intelligent terminal |
-
2016
- 2016-10-11 CN CN201610887828.2A patent/CN107920258B/en active Active
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1845059A (en) * | 2005-04-08 | 2006-10-11 | 国际商业机器公司 | Data storage system with shared cache address space and operation method thereof |
| US20080016205A1 (en) * | 2006-07-11 | 2008-01-17 | Concert Technology Corporation | P2P network for providing real time media recommendations |
| CN101184021A (en) * | 2007-12-14 | 2008-05-21 | 华为技术有限公司 | Method, equipment and system for implementing stream media caching replacement |
| CN101472143A (en) * | 2007-12-27 | 2009-07-01 | 华为技术有限公司 | Method and system for implementing stream medium service |
| CN101540882A (en) * | 2008-03-21 | 2009-09-23 | 盛大计算机（上海）有限公司 | P2P programme ordering method based on memory stream transmission |
| CN101448139A (en) * | 2009-01-08 | 2009-06-03 | 中国科学院计算技术研究所 | A P2P network based digital media program order method |
| CN103685344A (en) * | 2012-09-03 | 2014-03-26 | ***通信集团公司 | Synergetic method and system for multiple P2P (point-to-point) cache peers |
| CN102917028A (en) * | 2012-09-26 | 2013-02-06 | 深圳好视网络科技有限公司 | Network video live broadcasting caching method and device |
| CN103714038A (en) * | 2012-10-09 | 2014-04-09 | 中兴通讯股份有限公司 | Data processing method and device |
| CN104301356A (en) * | 2013-07-19 | 2015-01-21 | ***通信集团公司 | Data transmission method and system of P2P network |
| CN103401888A (en) * | 2013-08-21 | 2013-11-20 | 杭州浦禾通信技术有限公司 | Multimedia data receiving and processing method and device |
| CN103731720A (en) * | 2013-11-25 | 2014-04-16 | 乐视致新电子科技（天津）有限公司 | Method and device for caching multimedia data of smart television |
| CN104717545A (en) * | 2013-12-17 | 2015-06-17 | 乐视网信息技术（北京）股份有限公司 | Video playing method and device |
| CN105447197A (en) * | 2015-12-29 | 2016-03-30 | 腾讯科技（深圳）有限公司 | Video downloading processing method and device, and intelligent terminal |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109151194A (en) * | 2018-08-14 | 2019-01-04 | Oppo广东移动通信有限公司 | Data transmission method, device, electronic equipment and storage medium |
| CN109151194B (en) * | 2018-08-14 | 2021-03-02 | Oppo广东移动通信有限公司 | Data transmission method, device, electronic equipment and storage medium |
| WO2020093504A1 (en) * | 2018-11-07 | 2020-05-14 | 网宿科技股份有限公司 | Method, apparatus, and system for downloading data block of resource file |
| US11343306B2 (en) | 2018-11-07 | 2022-05-24 | Wangsu Science & Technology Co., Ltd. | Method, device and system for downloading data block of resource file |
| CN109889875A (en) * | 2019-01-23 | 2019-06-14 | 北京奇艺世纪科技有限公司 | Communication means, device, terminal device and computer-readable medium |
| CN109889875B (en) * | 2019-01-23 | 2021-07-16 | 北京奇艺世纪科技有限公司 | Communication method, communication device, terminal equipment and computer readable medium |
| CN111669618A (en) * | 2019-03-08 | 2020-09-15 | 杭州海康威视***技术有限公司 | Picture playing control method, device, equipment and storage medium |
| CN111669618B (en) * | 2019-03-08 | 2022-11-15 | 杭州海康威视***技术有限公司 | Picture playing control method, device, equipment and storage medium |
| CN110209447A (en) * | 2019-04-28 | 2019-09-06 | 五八有限公司 | A kind of list page data display method and list page data presentation device |
| CN113596495A (en) * | 2021-07-28 | 2021-11-02 | 广州方硅信息技术有限公司 | Live broadcast stream pushing processing method and device, equipment and medium thereof |
| CN113596495B (en) * | 2021-07-28 | 2023-11-24 | 广州方硅信息技术有限公司 | Live broadcast push stream processing method and device, equipment and medium thereof |
| WO2024082688A1 (en) * | 2022-10-20 | 2024-04-25 | 上海哔哩哔哩科技有限公司 | Method and apparatus for playing gift special-effect resource |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107920258B (en) | 2020-09-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107920258A (en) | A kind of data processing method and device | |
| JP6346859B2 (en) | Receiving device, receiving method, transmitting device, and transmitting method | |
| KR102637023B1 (en) | Receiving devices, transmitting devices, and data processing methods | |
| US20220174346A1 (en) | Video playing method and apparatus | |
| WO2014084071A1 (en) | Reception apparatus, reception method, transmission apparatus and transmission method | |
| CN105847941B (en) | A kind of audio/video flow live broadcasting method based on HLS protocol | |
| CN101868793A (en) | Illustration supported P2P media content streaming | |
| CN108566561A (en) | Video broadcasting method, device and storage medium | |
| WO2014183487A1 (en) | Video playback method and device in webpage | |
| US20220385989A1 (en) | Video playing control method and system | |
| CN107147921A (en) | Based on section and the intelligence CDN video playback accelerated methods dispatched and equipment | |
| WO2013000680A1 (en) | Streaming video to cellular phones | |
| CN104363509B (en) | A kind of video conversion method, device, play system and terminal | |
| AU2022217784A1 (en) | Systems, apparatus and methods for rendering digital content | |
| KR20120107004A (en) | Edge content delivery apparatus and content delivery network for the internet protocol television system | |
| CN104683726A (en) | Online game video recording and playing method | |
| CN1905670A (en) | Method and apparatus for implementing video-on-demand live telecasting based on network technique | |
| CN109347967A (en) | A kind of method and device obtaining audio, video data | |
| CN112714341B (en) | Information acquisition method, cloud set top box system, entity set top box and storage medium | |
| WO2017071642A1 (en) | Media playback method, device and computer storage medium | |
| US20180324480A1 (en) | Client and Method for Playing a Sequence of Video Streams, and Corresponding Server and Computer Program Product | |
| JP2004104704A (en) | Video reproducing apparatus, video reproducing method, and program | |
| US10820041B2 (en) | Reception apparatus, transmission apparatus and data processing method | |
| CN115297095A (en) | Return source processing method and device, computing equipment and storage medium | |
| KR101631190B1 (en) | Method for providing Video On Demand service and system thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 32 Xuanwumen West Street, Xicheng District, Beijing 100053 Patentee after: CHINA MOBILE COMMUNICATION LTD., Research Institute Patentee after: CHINA MOBILE COMMUNICATIONS GROUP Co.,Ltd. Address before: 32 Xuanwumen West Street, Xicheng District, Beijing 100053 Patentee before: CHINA MOBILE COMMUNICATION LTD., Research Institute Patentee before: CHINA MOBILE COMMUNICATIONS Corp. |
|
| CP01 | Change in the name or title of a patent holder |