Background
At present, a hardware coding device can support a plurality of independent coding channels, so that multi-channel parallel coding is realized, and the requirement that different application layer coding threads need to carry out video coding at the same time is met.
When the data coding on one coding channel is completed, the coding channel generates an interrupt notification to notify a driving module of the coding channel, and the driving module needs to wake up an application layer coding thread to read a code stream of the coding channel. Currently, for multi-path coding, a mode of querying after thread awakening is mostly adopted. When the encoding is successful once, all the application layer encoding threads are awakened, then the encoding channels allocated to the application layer encoding threads are known not to be encoded by inquiry, and then the application layer encoding threads enter the sleep waiting mode again. This wastes the system on much wasted work, which reduces the system efficiency.
For example, fig. 1 shows a schematic diagram of waking up an application layer encoding thread after one encoding channel encoding is completed according to the prior art. The hardware encoding device 120 may support multiple encoding channels 122-1, 122-2, … … 122-n. The driver module 124 of the hardware encoding device 120 assigns encoding channels 1122-1 for the encoding thread 1112 of the application layer 110 and encoding channels 2122-2 for the encoding thread 2114 of the application layer 110, and maintains such an assignment. As shown in FIG. 1, if the data encoding is completed in encoding channel 1, then encoding channel 1 will generate an interrupt to notify the driver module 124, as indicated by arrow 130, and the driver module 124 will wake up all the application layer encoding threads, i.e., 112 and 114, as indicated by arrows 132 and 134. Thereafter, both application-layer encoding threads 112 and 114 will query the driver module 124 for the presence of encoded data for the encoding pass assigned to itself. As shown in fig. 1, after being woken up, the encoding thread 2114 finds, through query, that there is no available encoding code stream on the encoding channel allocated to itself, and enters the sleep waiting state again. This waking up and sleeping again of the encoding thread 2114 is a waste of system resources.
For example, in the case that the driver module of the hardware coding device 120 is developed by using a Linux system, for multi-path coding, a select function is mostly used for querying, and after the function is woken back, a system call is used for querying whether encoded data is generated in the path, if so, the data is read out for processing, and if not, the sleep is continued for waiting. The processing in the driver program is that after one path of codes is generated, all threads waiting on the device are awakened through a poll function, for all n paths of codes, only one path of codes can really acquire data, other n-1 paths of codes are awakened, and the driver program sleeps again after inquiring that no data exists. Thus, the other n-1 ways are inefficiently and meaninglessly awakened and queried, burdening the system without actual efficiency.
Detailed Description
The principles and spirit of the present invention will be described with reference to a number of exemplary embodiments in conjunction with the following drawings. It is understood that these embodiments are given solely for the purpose of enabling those skilled in the art to better understand and to practice the invention, and are not intended to limit the scope of the invention in any way.
Fig. 2 is a schematic diagram illustrating that an application layer encoding thread is woken up after one encoding channel is encoded according to an embodiment of the present invention. Unlike the prior art processing method shown in fig. 1, the embodiment of the present invention establishes the binding relationship between the application layer coding thread and the hardware coding channel when opening a coding channel for an application layer coding thread. Therefore, after the hardware coding device completes the coding of a frame of code stream, the driver can accurately wake up the thread waiting on the path according to the binding relation, so that the coding thread can acquire the coded code stream.
As shown in fig. 2, the driver module 124 may, for example, upon receiving an encoding request of an application layer encoding thread 1112, assign and open an encoding channel 1122-1 for the encoding thread and record a binding relationship with the application layer encoding thread 1112. If the encoding of data is completed in encoding channel 1, then encoding channel 1 will generate an interrupt to notify the driving module 124, as indicated by arrow 130. The driver module 124, knowing the binding of code channel 1 to the application layer code thread 1112, only wakes up the application layer code thread 1112 and does not wake up the application layer code thread 2114. In contrast to the prior art wake-up scheme of fig. 1, it is also possible to omit the query process of the application layer encoding threads 1 and 2 to the driver module 124.
Fig. 3 shows a flow diagram of a video encoding method 300 according to an embodiment of the invention. The method starts in step S300.
Step S310, binding an application layer encoding thread of the plurality of application layer encoding threads with an encoding channel of the plurality of encoding channels. Usually, the maximum number of encoding paths that can be supported by a hardware encoding device is fixed, for example, if 16 encoding paths are simultaneously supported, there are 16 encoding paths, and one path can support one application thread to acquire a code stream. The binding relationship between the application layer coding thread and the coding channel can be established when the drive module opens one coding channel in the hardware coding device for one application layer coding thread.
Step S320, activating the bound encoding channel of the plurality of encoding channels so as to encode the video.
Step S330, after one of the multiple encoding channels finishes encoding, according to the binding, waking up the application layer encoding thread bound with the one of the multiple encoding channels.
To this end, the method 300 ends at step S340.
In one embodiment, an encoding pass is bound to only one application layer encoding thread, and after the encoding pass completes encoding, the encoding pass is unbound from the application layer encoding thread. This is particularly suitable where the number of application layer encoding threads expected to encode simultaneously is less than the number of encoding channels that the hardware encoding device can support.
In one embodiment, an encoding thread queue may be established for an encoding channel that is bound to a plurality of application layer encoding threads that make up the encoding thread queue. This is particularly suitable for situations where the number of surviving application layer coding threads is greater than the number of coding channels that the hardware coding device can support. In this case, all application layer encoding threads in the encoding thread queue for one encoding channel may be woken up after encoding on the encoding channel is completed.
The coding thread queue may adopt a first-in first-out queue, and in the code stream of the coding channel read by the application layer coding thread at the head of the queue, the application layer coding thread may be deleted from the coding thread queue.
An example of a driver module developed using the Linux system according to an embodiment of the present invention is described below. However, it should be understood that embodiments of the present invention may also be applied to driver modules of hardware coding devices developed using other operating systems or programming environments.
The drive of the hardware coding device works in a Linux kernel (kernel) part. The hardware coding device bottom layer can provide multiple paths of simultaneous coding, for example, 16 paths of code streams with different resolutions. The encoding thread is a program working in an application layer, and corresponding to 16 paths of encoding of hardware, 16 application threads can run simultaneously to obtain 16 paths of code streams with different resolutions. For example, a user a starts an application, and needs to encode a code stream of 640 × 480, which is an encoding thread; user B starts an application, and needs to encode a 720 × 576 code stream, which is also an encoding thread. The two threads appear to be acquiring codestreams simultaneously, and they work at the application layer, so they are called encoding threads of the application layer. And the two paths of codes are all completed by a code driving module at the bottom layer through one piece of hardware.
When the user A starts the application to start coding, the coding thread of the user A needs to call a bottom hardware coding device, and a coded code stream is obtained from the bottom hardware coding device. The encoding thread of the user A acquires a handle distributed by a drive module of the hardware encoding device through a system call function Open (), the handle is used for interaction information between the encoding thread and the drive module, and then the encoding thread of the user A calls a select function of the encoding thread to wait. For example, the driver module assigns handle a to user A's encoding thread and assigns encoding channel 1 of the 16-way encoding channel to it. Thus, the binding of handle a and code channel 1 is established in the driver module. In other words, for the driver module, the handle a represents the application layer encoding thread of the user a, and the encoding channel 1 of the hardware encoding device is the channel to which the handle a is bound. Likewise, the handle B and the encoding channel 2 allocated by the encoding thread of the user B may also be bound.
After binding, the data of all code channels 1 are only related to the handle a, and the data of all code channels 2 are only related to the handle b.
After the data on one coding channel is compressed, the driving module can judge that the data is the data of the physical channel according to the coded interrupt signal sent by the coding channel. For example, if the data of the encoding channel 1 is determined to be compressed, the data of the handle a can be known through binding, and the driver module will only wake up the select function corresponding to the handle a. Thus, only user A's encoding thread will be woken up to retrieve data, while other users' application layer encoding threads are not woken up.
When the application layer encoding thread of the user a is awakened because the select function thereof is called, the application layer encoding thread can inquire the completion status of the encoding channel allocated to the user a from the driving module, and call the system function Read () to Read the data on the allocated encoding channel.
In the above embodiments of the application layer encoding threads of user a and user B, one encoding channel supported by the hardware encoding device is allocated to only one application layer encoding thread. Alternatively, for example, after the application layer encoding thread of the user a is woken up, the system function Read () may also be directly called to Read the code stream on the allocated encoding channel.
In another embodiment, one encoding channel may also be allocated for multiple application layer encoding threads. In this way, an application layer encoding thread queue may be established for the encoding channel to which it is bound. And awakening all application layer coding threads bound with the coding channel each time the coding channel finishes coding. Each awakened application layer coding thread can query the driving module to acquire the position of the handle distributed to the driving module in the queue so as to acquire whether the finished coding code stream is specific to the driving module. If so, the system function Read () may be called to Read the codestream on the encoding channel and the handle a of the application thread is removed from the queue.
Referring now to fig. 4, a video encoding apparatus 400 capable of supporting simultaneous encoding of multiple application layer encoding threads using multiple encoding channels of a hardware encoding device in accordance with one embodiment of the present invention is schematically illustrated. The apparatus 400 comprises: a binding module 410 for binding at least one of the plurality of application layer coding threads with one of the plurality of coding channels; an encoding module 420 for activating the bound encoding channel of the plurality of encoding channels for encoding video; and a wake-up module 430, configured to wake up at least one application layer encoding thread bound to one of the multiple encoding channels after the encoding of the one of the multiple encoding channels is completed.
In one embodiment, the apparatus 400 may further include a unbinding module configured to unbind one of the plurality of application layer encoding threads after the one of the plurality of encoding passes completes encoding.
In one embodiment, the apparatus 400 may further include an encoding thread queue establishing module for establishing an encoding thread queue for each encoding channel of the plurality of encoding channels. The wake-up module 420 may further include: and the coding thread queue awakening module is used for awakening all application layer coding threads of the coding thread queue bound with the coding channel in the plurality of coding channels.
The apparatus 400 may further comprise: the reading module is used for enabling an application layer coding thread bound with one coding channel in the plurality of coding channels which completes coding and located at the head of the coding thread queue to read a code stream in the coding channel which completes coding; and the deleting module is used for deleting the application layer coding thread positioned at the head of the coding thread queue from the application layer coding thread.
It should be understood that each unit recited in the apparatus 400 corresponds to each step in the method 300 described with reference to fig. 3. Thus, the operations and features described above with respect to fig. 3 are equally applicable to the apparatus 40 and the units contained therein and will not be described again here.
It should also be understood that the apparatus 400 may be implemented in a variety of ways, for example, in some embodiments, the apparatus 400 may be implemented using software and/or firmware modules. Furthermore, the apparatus 400 may also be implemented using hardware modules. Other ways, now known or later developed, are also feasible, and the scope of the present invention is not limited in this respect.
Those skilled in the art will appreciate that the flow charts and block diagrams in the figures are merely schematic representations of the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
According to the embodiment of the invention, after a hardware coding device codes a frame of code stream, a driving module of the hardware coding device can accurately wake up an application layer coding thread waiting on the path, so that the thread can acquire the coded code stream without influencing other coding paths.
The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will occur to those skilled in the art. All changes and substitutions that may be made without departing from the spirit of the invention are intended to be within the scope of the invention as defined by the appended claims.