CN115150563A

CN115150563A - Video production method and system

Info

Publication number: CN115150563A
Application number: CN202110351079.2A
Authority: CN
Inventors: 屈小刚; 刘新宝
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-03-31
Filing date: 2021-03-31
Publication date: 2022-10-04
Also published as: WO2022206168A1

Abstract

A video production method and system, the method comprising: receiving a video production request message, wherein the video production request message comprises an identifier of a first video production mode, first time and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1; acquiring at least M images of the same scene captured by the M cameras from different angles at different times based on the identifications of the M cameras and the first time; and manufacturing a first video file, wherein the first video file comprises the at least M images. By the scheme, images at different moments can be obtained, and then videos are made according to the images at different moments. Compared with the static photo in time obtained in the prior art, the flexibility of video production can be improved, and therefore user experience is improved.

Description

Video production method and system

Technical Field

The present application relates to the field of image processing technologies, and in particular, to a video production method and system.

Background

With the rapid development of technology, some wonderful visual special effects such as slow-motion lenses realized by bullet times and the like often appear in videos such as television dramas, movies and the like.

For wonderful visual special effects, a target object is usually shot simultaneously by a plurality of camera arrays, that is, a plurality of cameras take a plurality of pictures at the same time, then the best time is selected from a plurality of times, a plurality of pictures taken by the plurality of cameras at the time are obtained based on the best time, and finally the plurality of pictures are combined into one video. That is, only still-time photographs can be generated at present when producing a wonderful visual effect. Moreover, if the currently produced visual effect is not satisfactory, it may be necessary to take a picture again, etc., which requires much cost.

Disclosure of Invention

The application provides a video production method and a video production system, which are used for improving the flexibility of video production and improving the user experience.

In a first aspect, the present application provides a video production method, including: receiving a video production request message, wherein the video production request message comprises an identifier of a first video production mode, first time and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1; acquiring at least M images of the same scene captured by the M cameras from different angles at different times based on the identifications of the M cameras and the first time; and manufacturing a first video file, wherein the first video file comprises the at least M images.

Through the technical scheme, a plurality of images can be acquired according to the identification and the starting time of the camera included in the video production request message, and the plurality of images are shot by the plurality of cameras from different angles at different moments, so that the images at different moments can be acquired, and further the video is produced according to the images at different moments. Compared with the static photo in time obtained in the prior art, the flexibility of video production can be improved, and therefore user experience is improved.

In one possible design, the acquiring at least M images based on the identification of the M cameras and the first time includes:

determining M video code streams based on the identifications of the M cameras; the M video code streams are obtained by shooting the same scene from different angles based on the M cameras respectively; the target timestamp of each video code stream in the M video code streams is related to the first time; acquiring the M images based on a target timestamp of each video code stream in the M video code streams; and the target timestamp of each video code stream in the M video code streams is different.

By the technical scheme, the target timestamp of each video code stream can be directly or indirectly determined in the M video code streams according to the first time, and then the corresponding image can be obtained based on the target timestamp.

In one possible design, the target timestamp of each of the M video streams is associated with a preset order of the M cameras. It should be understood that the preset order of the M cameras is related to the installation positions or photographing angles of the cameras. Therefore, the target timestamps can be determined through the preset sequence, the obtained images are continuous, the manufactured video effect is better, and the user experience can be improved.

In one possible design, the target timestamp of each of the M video streams is associated with an order of identification of the M cameras. It should be understood that the order of identification of the M cameras is not specifically limited in this application. Through the technical scheme, the target time stamp of the video code stream can be determined according to the sequence of the camera identification, so that the image can be acquired according to the requirement of a user.

In one possible design, the obtaining the M images based on the target timestamp of each of the M video streams includes:

decoding a frame of video stream data corresponding to a target timestamp of a first video stream to obtain a first image; the first video code stream is any one of the M video code streams, and the first image is any one of the M images.

By the technical scheme, the video code stream corresponding to the target timestamp can be decoded, and the image corresponding to the target timestamp can be obtained.

In a possible design, the video production request message further includes an identifier of a second video production mode and identifiers of L cameras corresponding to the second video production mode; l is an integer greater than 1; the method further comprises the following steps: acquiring L images based on the identifiers of the L cameras, wherein the L images are obtained by shooting the same scene from different angles at the same time through the L cameras; producing a second video file comprising the at least M images and the L images.

By the technical scheme, when the video production request message comprises a plurality of video production modes, the images corresponding to each video production mode can be respectively obtained, then the images obtained by the plurality of video production modes are combined into a group of images, and further the video is produced based on the group of images.

In one possible design, the determining the M video streams based on the identities of the M cameras includes: determining the M video code streams from N video code streams based on the identifications of the M cameras; the N code streams are obtained by shooting the same scene from different angles based on N cameras; the N cameras include the M cameras.

It should be noted that N cameras can be understood as the total number of cameras, and N video streams are video streams of all the cameras. By the technical scheme, the video code stream corresponding to the video production mode can be determined from the N video code streams.

In one possible design, the video production request message further includes production scene parameters; the N code streams are one of N live broadcast code streams, N time-shifting code streams or N point broadcast code streams.

If the production scene parameters indicate that the video production is real-time production, determining the M video code streams from the N live broadcast code streams; and the N live broadcast code streams are acquired from N cameras in real time. If the manufacturing scene parameters indicate that the video manufacturing is non-real-time manufacturing, determining the M video code streams from the N time-shift code streams or the N point-broadcast code streams; and the N point broadcast code streams or the N time shift code streams are obtained by storing the N live broadcast code streams.

By the technical scheme, N video code streams can be recorded, and the live broadcast, time shift and on-demand capabilities are provided, so that videos can be manufactured according to different timeliness requirements. For example, a video is required to be produced on site in real time, a live stream can be used for producing the video, if the video is required to be produced from the content several minutes ago, a time-shift stream can be used for producing the video, and if the video is required to be produced after shooting is finished, an on-demand stream can be used for producing the video. Moreover, the code stream is recorded, and when the video production result is not satisfactory, the video can be produced again.

In a second aspect, a receiving module of the present application is configured to receive a video production request message, where the video production request message includes an identifier of a first video production mode, a first time, and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1; an obtaining module, configured to obtain at least M images based on the identifiers of the M cameras and the first time, where the at least M images are obtained by the M cameras shooting a same scene from different angles at different times; and the making module is used for making a first video file, and the first video file comprises the at least M images.

In one possible design, the system further includes: the determining module is used for determining M video code streams based on the identifiers of the M cameras; the M video code streams are obtained by shooting the same scene from different angles based on the M cameras respectively; the target timestamp of each video code stream in the M video code streams is related to the first time; the acquisition module is used for acquiring the M images based on the target timestamp of each video code stream in the M video code streams; and the target timestamp of each video code stream in the M video code streams is different.

In one possible design, the target timestamp of each of the M video streams is associated with a preset order of the M cameras.

In one possible design, the target timestamp of each of the M video streams is associated with an order of identification of the M cameras.

In one possible design, the obtaining module is specifically configured to obtain the M images based on a target timestamp of each of the M video streams as follows: decoding a frame of video stream data corresponding to a target timestamp of a first video stream to obtain a first image; the first video code stream is any one of the M video code streams, and the first image is any one of the M images.

In a possible design, the video production request message further includes an identifier of a second video production mode and identifiers of L cameras corresponding to the second video production mode; l is an integer greater than 1; the acquisition module is further configured to acquire L images based on the identifiers of the L cameras, where the L images are obtained by shooting the same scene from different angles at the same time by the L cameras;

the making module is further configured to make a second video file, where the second video file includes the at least M images and the L images.

In one possible design, the determining module is specifically configured to determine the M video streams based on the identifiers of the M cameras as follows: determining the M video code streams from N video code streams based on the identifiers of the M cameras; the N code streams are obtained by shooting the same scene from different angles based on N cameras; the N cameras include the M cameras.

In one possible design, the video production request message further includes production scene parameters; the N code streams are one of N live broadcast code streams, N time shift code streams or N point broadcast code streams; the determining module is specifically configured to determine the M video code streams based on the identifiers of the M cameras as follows: if the manufacturing scene parameters indicate that the video manufacturing is real-time manufacturing, determining the M video code streams from the N live broadcast code streams; and the N live broadcast code streams are acquired from N cameras in real time.

In one possible design, if the production scene parameter indicates that the video production is non-real-time production, determining the M video streams from the N time-shifted streams or the N multicast streams; and the N point broadcast code streams or the N time shift code streams are obtained by storing the N live broadcast code streams.

In a third aspect, the present application provides a video production apparatus having a function of implementing the video production method of the first aspect or any one of the possible implementations of the first aspect. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware.

The apparatus comprises a communication interface for receiving and transmitting data, a processor configured to enable the apparatus to perform corresponding functions in any one of the above-described possible implementations of the first aspect or the first aspect, and a memory. The memory is coupled to the processor and retains program instructions necessary for the device.

In a fourth aspect, a computer-readable storage medium is provided, which has instructions stored therein, and when the instructions are executed on a computer, the instructions cause the computer to execute the method in the first aspect and the embodiments.

In a fifth aspect, a computer program product comprising instructions is provided, which when run on a computer, causes the computer to perform the method of the first aspect and embodiments described above.

A sixth aspect provides a chip, wherein logic in the chip is configured to perform the method in the first aspect and the embodiments.

With regard to the technical effects brought by the various embodiments of the second aspect to the sixth aspect, reference may be made to the description of the technical effects of the first aspect or the various embodiments of the first aspect, and redundant description is not repeated here.

Drawings

Fig. 1A is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 1B is a schematic view of another application scenario provided in the embodiment of the present application;

FIG. 2 is a diagram of a system architecture according to an embodiment of the present application;

fig. 3 is a flowchart of a method for calibrating a camera according to an embodiment of the present disclosure;

fig. 4 is a flowchart of a method for code stream synchronization according to an embodiment of the present application;

fig. 5 is a flowchart of a code stream recording method according to an embodiment of the present application;

fig. 6 is a flowchart of a video production method according to an embodiment of the present application;

fig. 7A to 7G are schematic diagrams illustrating video production effects provided by the embodiment of the present application;

fig. 8 is a flowchart of another video production method according to an embodiment of the present application;

fig. 9 is a block diagram of a video production system according to an embodiment of the present application;

fig. 10 is a schematic view of a video production apparatus according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

For ease of understanding, an explanation of concepts related to the present application is given by way of example for reference, as follows:

1) Bullet time: the method is used for simulating variable speed special effects, such as intensified slow lens, time static and the like, by using a photographing technology in movies, television advertisements or computer games. A series of still photographs are taken simultaneously by a plurality of camera arrays and combined into a video result.

2) And (4) at the moment of wonderful: a plurality of camera arrays shoot an object simultaneously, a series of images can be taken out from shot photo streams, live broadcast streams, time shift streams, on-demand streams and the like according to a certain motion track, then special effects are added, and finally the images are combined into a wonderful video. Bullet time is a special case of a bright moment.

It should be understood that at least one of the embodiments described herein includes one or more; wherein a plurality means greater than or equal to two. In the description of the present application, the terms "first", "second", and the like are used for the purpose of distinguishing between objects to be described, and are not intended to indicate or imply relative importance nor order to be construed.

First, an application scenario of the embodiment of the present application is described. As shown in fig. 1A, a schematic view of an application scenario provided in the embodiment of the present application is shown. Referring to fig. 1A, the application scenario may include a target object, N (where N is a positive integer) cameras, and a server.

The target object is an object to be shot by the camera. The camera is an image acquisition device and can provide functions of remote batch parameter configuration, single manual parameter configuration, photographing, encoding outflow, hard synchronization and the like. The N cameras can be arranged around the target object and can shoot the target object at the same time to obtain pictures or videos.

The server may include a plurality of functional modules, such as a calibration module, a camera stream access module, a recording module, and a video production module. The calibration module is used for obtaining internal parameters and external parameters of the camera according to pictures shot by the camera so as to eliminate focus jitter of the camera. And the camera stream access module is used for receiving the code stream of the camera, synchronizing the code stream and converting the format of the code stream into the same format. And the recording module is used for storing the code stream of the camera from the camera stream access module and providing the capabilities of live broadcasting, time shifting, recorded broadcasting and on-demand broadcasting. And the video production module is used for extracting images from the shot live stream, time shift stream or on-demand stream, then processing the images and finally synthesizing a wonderful video.

In the embodiment of the present application, the number of servers may be one or more. The functional modules may be located in the same or different servers.

For example, when the functional modules are located in different servers, as shown in fig. 1B, the embodiment of the present invention may include four servers, such as a calibration server 11, a camera stream access server 12, a recording server 13, and a highlight server 14 (or referred to as a video production server). It should be understood that the functions performed by each server may refer to the descriptions of each functional module described above, and are not repeated here.

Fig. 2 is a diagram of a system architecture provided in an embodiment of the present application. In the system architecture diagram, a control plane 21, an operation and maintenance plane 22, and a media plane 23 may be included. The control surface 21 is used to provide an operation interface for the highlight, such as configuring parameters required for making a video. The operation and maintenance surface 22 is used for providing operation and maintenance capabilities of the system, including alarms, performance indicators, logs, configuration, upgrades, and the like. The media surface 23 is used for providing functions of camera calibration, camera stream access, recording, video production and the like.

A video production method provided by the embodiment of the present application is described in detail below. The method specifically comprises the following steps: 1. calibrating a camera; 2. code stream synchronization; 3. recording the code stream; 4. and (5) video production. The following describes the above four processes in sequence.

For convenience of description, it is assumed that the number of cameras is N (N is a positive integer, N is greater than or equal to 1), and the server takes the server in fig. 1B as an example to explain the method.

1. Camera calibration

In the embodiment of the application, the internal reference and the external reference of the camera can be obtained by calibrating the camera, and then the image shot by the camera can be corrected according to the internal reference and the external reference of the camera in the video production process so as to eliminate focus jitter.

Referring to fig. 3, which is a flowchart of a method for calibrating a camera according to an embodiment of the present disclosure, referring to fig. 3, the method may include the following steps:

s301: and the calibration server receives the calibration request message.

The calibration request message may include world coordinates of a center point of the shooting site, world coordinates of the calibration object, resolution of the cameras, the number of cameras, and the like. It should be understood that the world coordinates of the calibration object are the world coordinates of the object to be photographed by the camera.

In the application, a user (a video producer) can log in a video production platform on a terminal device through an account password, then a calibration task is created on an operation interface of the video production platform, and the terminal device can respond to the operation of the user and send a calibration request message to a calibration server. Accordingly, the calibration server may receive the calibration request message.

The terminal device may be a mobile phone, a tablet computer, a wearable device (e.g., a watch, a bracelet, smart glasses, a smart helmet, etc.), an in-vehicle device, an Augmented Reality (AR)/Virtual Reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), etc., and the embodiments of the present application are not limited thereto.

In addition, the terminal equipment and the calibration server can be connected through a communication network. The communication network may be a local area network or a wide area network that is switched over by a relay device.

When the communication network is a local area network, the communication network may be a wireless fidelity (wifi) hotspot network, a Bluetooth (BT) network, or a Near Field Communication (NFC) network, for example. When the communication network is a wide area network, the communication network may be, for example, a third generation mobile communication technology (3 rd-generation wireless telephone technology, 3G) network, a fourth generation mobile communication technology (4G) network, a fifth generation mobile communication technology (5G) network, a future-evolution Public Land Mobile Network (PLMN), the internet, or the like.

S302: and the calibration server sends a photographing instruction to at least one camera.

In some embodiments, after the calibration server receives the calibration request message, the N cameras may be triggered to take a picture. That is, the calibration server can trigger all cameras to take pictures.

In other embodiments, after the calibration server receives the calibration request message, the master camera (one camera) may be triggered to take a picture, and then the master camera triggers the slave camera to take a picture.

It should be noted that the distinction between the master camera and the slave camera may be set by a user. Generally, one master camera may be set and then the other cameras set as slave cameras. For example, a user may set the camera as a master or slave camera by toggling a master-slave setting switch/button on the camera.

It should be understood that different vendors may set the master and slave cameras differently. Also, some cameras may only be able to act as master or slave cameras, without a master-slave set switch.

S303: the calibration server obtains N pictures from N cameras.

In S302, the camera may receive a photographing instruction, and then the camera may perform a photographing function according to the photographing instruction, so that each camera may obtain a photographed picture. After the camera completes the photographing function, the calibration server may obtain N photos from the N cameras.

S304: and the calibration server obtains the internal parameters and the external parameters of the N cameras according to the N pictures.

It should be understood that the method for obtaining the internal reference and the external reference by the camera calibration is more, and the detailed description is not repeated herein, and specific reference may be made to the specific calculation process of the camera calibration method in the prior art.

By the calibration method of the embodiment shown in fig. 3, the internal reference and the external reference of each camera can be obtained, so that the image can be corrected. In one possible implementation, after S304, the calibration server may upload the internal and external parameters of the camera to the highlight server so that the image can be corrected later when video production is performed.

Of course, after S304, the user may also check the calibration result to avoid that the calibration result is omitted due to a camera failure or the like, thereby affecting the subsequent video production process.

2. Code stream synchronization

It should be understood that the code stream synchronization herein includes format synchronization and time synchronization. The code streams of the cameras can be adjusted to be in the same format, and meanwhile, video frames at the same time in the code streams of different cameras are set to be the same timestamp, so that the code streams can be conveniently processed. In the embodiment of the present application, the format of the codestream may include formats such as dash, hls, rtsp, rtmp, and the like.

As shown in fig. 4, a flow chart of a method for code stream synchronization according to an embodiment of the present application is shown, and referring to fig. 4, the method may include the following steps:

s401: the camera stream access server receives a camera stream access request message.

In one possible implementation, a user may create a task of camera stream access on an operation interface of the terminal device, and then the terminal device may transmit a camera stream access request message to the camera stream access server in response to the user's operation.

It should be understood that the camera identification of the N cameras, e.g., 1, 2, 3, etc., may be included in the camera stream access request message.

S402: the camera stream access server sends a shooting instruction to the N cameras to instruct the N cameras to start shooting.

When the camera stream access server receives the camera stream access request message, a photographing instruction may be triggered to the N cameras. Accordingly, the camera can start shooting after receiving the shooting instruction.

In the embodiment of the application, the camera can encode the code stream when shooting so as to distinguish the code streams of different cameras. Illustratively, the encoding of the codestream may be the same as or related to the identification of the camera. For example, the identifier of the camera is 1, and the code stream code shot by the camera may also be 1; or for example, the identifier of the camera is 1, the code stream code captured by the camera may be 1-1, and the like, which is not limited in this application.

S403: the camera stream access server acquires N code streams from N cameras.

After receiving the shooting instruction, the camera can execute the shooting function to output the code stream. Accordingly, the camera stream access server may obtain a corresponding stream from each camera.

S404: the camera stream access server converts the N code streams into the same format and synchronizes the time of the N code streams.

In the embodiment of the present application, the code stream formats may be different due to different camera manufacturers or different models of cameras. Therefore, in order to facilitate subsequent video production, the format of the code stream needs to be converted, so that the code stream formats are the same. For example, the format of the code stream may be uniformly converted into a dash format. Of course, the rtsp format may also be uniformly converted, and the like, which is not limited in this application. In some embodiments, the camera stream access server may further perform time synchronization on video frames at the same time in the N code streams, that is, set the video frames at the same time to be the same timestamp.

As a possible implementation manner, after S404, the camera stream access server may cache the acquired code stream. By the code stream synchronization method of the embodiment shown in fig. 4, N barcode streams of N cameras can be converted into the same format.

3. Code stream recording

As shown in fig. 5, a flow chart of a code stream recording method provided in the embodiment of the present application is shown, referring to fig. 5, the method may include the following steps:

s501: and the recording server receives the recording request message.

In the embodiment of the application, a user can create a recording task on an operation interface of the terminal device, and the terminal device can respond to the operation of the user and send a recording request message to the recording server.

The recording request message may include camera identifications of the N cameras.

S502: and the recording server acquires and stores the video code stream from the camera stream access server.

In the embodiment shown in fig. 4, the camera stream access server may obtain the code stream from the camera, and then cache the code stream, so that the recording server may obtain the video code stream from the camera stream access server, and then store the video code stream, so that if the manufactured video is not satisfactory subsequently, the manufactured video can be manufactured again by using the stored video code stream, and user experience can be improved.

In some embodiments, the recording server may provide live, time-shifted, and on-demand services, and then the user may start at least one of the live, time-shifted, and on-demand services, so that the user may select a corresponding video stream according to different timeliness requirements when making a video.

4. Video production

Referring to fig. 6, a flow chart of a video production method according to an embodiment of the present invention is shown, and referring to fig. 6, the method may include the following steps:

s601: the highlight server receives a video production request message.

The video production request message may include an identifier of a video production mode, a start time corresponding to the video production mode, and an identifier of a camera corresponding to the video production mode.

As a possible implementation manner, the user may configure parameters of the highlight on the operation interface of the terminal device, and then trigger video production (for example, click a "production" button on the operation interface), and the terminal device may send a video production request message to the highlight server in response to the operation of the user. The parameter of the highlight may be included in the video production request message.

In some embodiments, the parameters for the highlight may include: the method comprises the following steps of (1) highlighting moment (namely starting time), track point list (arrangement sequence among marks of cameras), highlighting moment mode (also called as video production mode), corresponding marks of cameras in the highlighting moment mode, special effect (such as zooming-in and zooming-out and slow motion), output resolution and the like. It should be understood that the list of track points may include an identification of the camera through which the video was produced. For example, the machine position numbers of the video production choices are: 1-10, sequencing the position numbers in the video production in sequence: 1. 2, 3, 4, 5, 6, 7, 8, 9, 10, then the start and stop positions (i.e., which camera the video starts with and which camera ends with) are 1 and 10, and the intermediate pass positions are: 2. 3, 4, 5, 6, 7, 8, 9.

Of course, the sorting of the machine bit numbers is not limited to the above sequence, for example, sorting according to the magnitude relationship of the machine bit numbers, such as 1, 3, 5, 7, 9, 2, 4, 6, 8, 10, etc., may also be performed, which is not limited in this application.

In the embodiment of the present application, the video production mode may include three modes, i.e., a dynamic streaming mode, a static bullet time mode, and a fixed machine position mode. For convenience of description, in the embodiment of the present application, the "dynamic streaming mode" may be referred to as a "first video production mode", the "static bullet time mode" may be referred to as a "second video production mode", and the "fixed station mode" may be referred to as a "third video production mode". Of course, the video production modes in the embodiment of the present application include, but are not limited to, the above three modes.

Wherein, the dynamic circulation mode can be understood as: and selecting images from the videos of the plurality of the stands within a certain time range, and further synthesizing the videos. I.e. the time is changing while the space is also changing.

The static bullet time pattern can be understood as: and selecting images at the same time from the images of the plurality of stands, and further synthesizing the images of different stands at the same time into a video. I.e. time is constant and space is changing.

The fixed machine position mode can be understood as: and selecting a video within a certain time range from videos of one machine position. I.e., time is changing and space is not changing.

As a possible implementation manner, the video production request message may include an identifier of at least one video production mode, a start time corresponding to the at least one video production mode, and a camera identifier corresponding to each video mode. Specifically, the following cases may be included:

in the first case: the video production request message includes an identifier of the first video production mode, a start time T1 corresponding to the first video production mode, and identifiers of M cameras corresponding to the first video production mode. M is an integer greater than 1, and M is equal to or less than N. For example, referring to fig. 7A, an effect diagram of a dynamic circulation mode provided in the embodiment of the present application is shown.

In the second case: the video production request message includes an identifier of the second video production mode, a start time T2 corresponding to the second video production mode, and identifiers of L cameras corresponding to the second video production mode. L is an integer greater than 1, and L is not greater than N. For example, referring to fig. 7B, a schematic diagram of the effect of a static bullet time pattern provided in the embodiment of the present application is shown.

In the third case: the video production request message includes an identifier of the third video production mode, a start-stop time T3 corresponding to the third video production mode, and identifiers of P cameras corresponding to the third video production mode. Where P is equal to 1. For example, refer to fig. 7C, which is a schematic view illustrating an effect of a fixed machine position mode according to an embodiment of the present application.

It should be understood that T1 and T2 represent start times, T3 represents time ranges, and the size relationship between M, L, and P in the embodiment of the present application is not particularly limited.

In a fourth case: the video production request message includes an identifier of the first video production mode, a start time T1 corresponding to the first video production mode or a start time T2 corresponding to the second video production mode, identifiers of M cameras corresponding to the first video production mode, identifiers of the second video production mode, and identifiers of L cameras corresponding to the second video production mode. For example, referring to fig. 7D, a schematic diagram of the effect of mixing the dynamic circulation mode and the static bullet time mode provided in the embodiment of the present application is shown.

In the fifth case: the video production request message includes an identifier of the first video production mode, a start time T1 corresponding to the first video production mode or a start-stop time T3 corresponding to the third video production mode, identifiers of M cameras corresponding to the first video production mode, identifiers of the third video production mode, and identifiers of P cameras corresponding to the third video production mode. For example, referring to fig. 7E, a schematic diagram illustrating an effect of mixing a dynamic stream mode and a fixed-position mode according to an embodiment of the present application is provided.

In the sixth case: the video production request message includes an identifier of the second video production mode, a start time T2 corresponding to the second video production mode or a start-stop time T3 corresponding to the third video production mode, identifiers of L cameras corresponding to the second video production mode, identifiers of the third video production mode, and identifiers of P cameras corresponding to the third video production mode. For example, referring to fig. 7F, a schematic diagram of the effect of mixing the static bullet time mode and the fixed station mode provided in the embodiment of the present application is shown.

In the seventh case: the video production request message includes an identifier of the first video production mode, a start time T1 corresponding to the first video production mode, a start time T2 corresponding to the second video production mode, or a start-stop time T3 corresponding to the third video production mode, identifiers of M cameras corresponding to the first video production mode, identifiers of the second video production mode, identifiers of L cameras corresponding to the second video production mode, identifiers of the third video production mode, and identifiers of P cameras corresponding to the third video production mode. For example, referring to fig. 7G, a schematic diagram of the effect of mixing the dynamic circulation mode, the static bullet time mode and the fixed station mode provided in the embodiment of the present application is shown.

The following explanation is made for the provision of the time in the examples of the present application: if the video production mode included in the video production request message is one, namely a dynamic circulation mode or a static bullet time mode, the video production request message also includes a start time; if the video production mode included in the video production request message is the fixed-set-top mode, a start-stop time (i.e., a time range) is also included in the video production request message.

In some embodiments, if the video production mode included in the video production request message is two, such as a dynamic streaming mode and a static bullet time mode, the start time T1 of the dynamic streaming mode or the start time T2 of the static bullet time mode may be provided; if the dynamic circulation mode and the fixed machine position mode exist, providing a starting time T1 of the dynamic circulation mode or a starting and stopping time range T3 of the fixed machine position mode; if the static bullet time mode and the fixed machine position mode are provided, a start time T2 of the static bullet time mode or a start-stop time range T3 of the fixed machine position mode is provided.

If the video production modes included in the video production request message are three, one of the start time T2 of the static bullet time mode, the start time T1 of the dynamic streaming mode, or the start-stop time T3 of the fixed station mode may be provided.

In other embodiments, when the video production request message includes a plurality of video production modes, the start time of each video production mode may also be included in the video production request message.

It should be understood that fig. 7A-7G are only schematic illustrations, and in practical applications, the effect of the video production mode is not limited to the above example.

S602: and the wonderful moment server determines a corresponding video code stream according to the identifier of the camera corresponding to the video production mode.

When the video production request messages in S601 are different, the obtained video code streams are also different. The obtained video code stream is introduced based on the above seven cases, respectively.

In the first case: and the wonderful moment server acquires M video code streams according to the identifications of the M cameras corresponding to the first video production mode. The M video code streams are obtained by shooting the same scene from different angles based on M cameras respectively. For example, assuming that the camera identifier includes 1 to 10, the highlight server may start to acquire the code stream from the code stream identified by 1 of the camera stored in the recording server until the code stream identified by 10 of the camera is acquired.

In the second case: and the wonderful moment server acquires L video code streams according to the identifications of the L cameras corresponding to the second video production mode. The L video code streams are obtained by shooting the same scene from different angles based on the L cameras respectively.

In a third case: and the wonderful moment server acquires 1 video code stream according to the identifier of the 1 camera corresponding to the third video production mode. Wherein, 1 video code stream is obtained by shooting the same scene from the same angle by 1 camera in a certain time period.

In a fourth case: and the wonderful moment server acquires (M + L) video code streams according to the identifications of the M cameras corresponding to the first video production mode and the identifications of the L cameras corresponding to the second video production mode.

In a fifth case: and the wonderful moment server acquires (M + P) video code streams according to the identifications of the M cameras corresponding to the first video production mode and the identifications of the P (the P = 1) cameras corresponding to the third video production mode.

In the sixth case: and the wonderful moment server acquires (L + P) video code streams according to the identifications of the L cameras corresponding to the second video production mode and the identifications of the P cameras corresponding to the third video production mode.

In a seventh case: and the wonderful moment server acquires (M + L + P) video code streams according to the identifications of the M cameras corresponding to the first video production mode, the identifications of the L cameras corresponding to the second video production mode and the identifications of the P cameras corresponding to the third video production mode.

Further, in this embodiment of the application, when the video production request message includes at least two video production modes, the video production request message may further include a sequence of the video production modes, so that the highlight moment server may sequentially obtain the code streams according to the sequence of the video production modes when obtaining the code streams. Illustratively, if the video production mode includes a dynamic streaming mode and a static bullet time mode, and the dynamic streaming mode is before the static bullet time mode, assuming that the identifier of the camera corresponding to the dynamic streaming mode is 1-5 and the identifier of the camera corresponding to the static bullet time mode is 5-3, the highlight moment server may sequentially obtain the code stream from the code stream with the identifier of 1-5 stored in the recording server, and then continue to obtain the code stream from the recording server according to the identifier of the camera corresponding to the static bullet time mode after the dynamic streaming mode is finished.

S603: the highlight moment server obtains a corresponding image from the video code stream determined in S602 based on the start time corresponding to the video production mode.

This step is described in detail below based on the seven cases.

In the first case: and acquiring at least one image from each video code stream of the M video code streams based on the starting time T1 of the dynamic streaming mode to obtain at least M images. Wherein the at least M images are from video frames of different time stamps in the M video code streams.

In some embodiments, the target timestamp of each of the M video streams may be determined directly or indirectly by the start time T1. Or in other words, the target timestamp of each of the M video streams is associated with the start time T1. It should be understood that the target timestamp is the timestamp of the target video frame determined in each video bitstream. It is understood that the M images may be obtained based on the target video frame in each of the video streams. For example, suppose that a target video frame of a first video code stream in the M video code streams is a first video frame, a target video frame of a second video code stream in the M video code streams is a second video frame, and a target video frame of a third video code stream in the M video code streams is a third video frame \8230. The timestamp of the first video frame may be determined by the start time T1 (for example, a video frame in the first video code stream whose timestamp is closest to T1 may be taken as the first video frame), the timestamp of the second video frame may be determined by the timestamp of the first video frame (for example, a timestamp of a next frame corresponding to the timestamp of the first video frame), the timestamp of the third video frame may be determined by the timestamp of the second video frame (for example, a timestamp of a next frame to the timestamp of the second video frame), and so on, the timestamp of each video frame may be determined.

In other embodiments, the target timestamp of each of the M video streams is associated with a predetermined order of the M cameras. The preset sequence is related to the installation position or shooting angle of the camera.

In still other embodiments, the target timestamp of each of the M video streams is related to an order of identification of the M cameras.

As a possible implementation manner, the identifier of the camera with the smallest number may be determined among the identifiers of the M cameras, for example, the identifier is recorded as a first identifier, then a first video frame in a video stream of the camera corresponding to the first identifier is determined, and finally a first image is obtained based on the first video frame, where a timestamp of the first video frame is closest to T1.

Similarly, the identifier of the camera with the next lowest number may be determined from the identifiers of the M cameras, for example, the identifier may be recorded as a second identifier, then a second video frame in the video stream of the camera corresponding to the second identifier may be determined, and finally a second image may be obtained based on the second video frame. Wherein the timestamp of the second video frame is the same as the timestamp of the next frame of the first video frame. By analogy, M images can be obtained in sequence according to the method.

For example, assuming that the start time T1 of the dynamic streaming mode is 9 minutes 0 milliseconds, and the identifier of the camera corresponding to the dynamic streaming mode includes 5 identifiers, for example, 1 to 5, the identifier of the camera with the smallest number among the identifiers of the cameras is first determined to be 1, then the first video frame corresponding to the timestamp (e.g., 9 minutes 0 seconds) closest to T1 is determined in the video stream of the camera with the identifier of 1 of the camera, and finally the image of 9 minutes 0 seconds is acquired based on the first video frame. Then, the identification of the camera with the smaller number in the identification of the camera is determined to be 2, then a second video frame corresponding to the video code stream with the time stamp of 9 minutes, 0 seconds and 20 milliseconds is determined in the video code stream with the identification of the camera as 2, and then the image with the time stamp of 9 minutes, 0 seconds and 20 milliseconds is obtained based on the second video frame. It should be understood that a video frame corresponding to 20 milliseconds for 9 minutes 0 seconds is the next video frame of a video frame corresponding to 9 minutes 0 seconds.

Of course, in the embodiment of the present application, the images may also be acquired not according to the order of the numbers of the identifiers of the cameras, but directly according to the order of the identifiers of the cameras. For example, it is assumed that the video production request message further includes an arrangement order between the identifiers of the cameras, such as the arrangement order of the identifiers of the cameras is as follows: 2. 1, 3, 4, 5, the start time T1 of the dynamic streaming mode is 9 minutes 0 seconds, then the first video frame corresponding to the timestamp closest to T1 (e.g., 9 minutes 0 seconds) may be first determined in the video bitstream of the camera identified as 2 of the camera, and then the 9 minutes 0 seconds of image may be acquired based on the first video frame. Then, a second video frame corresponding to a camera with a timestamp of 9 min 0 sec and 20 ms may be determined in the video code stream of the camera identified as 1, and then an image with a timestamp of 9 min 0 sec and 20 ms may be acquired based on the second video frame. Push through this column until all images are obtained.

It should be noted that after the video frame is extracted from the video code stream, the video frame may be decoded to obtain a corresponding image.

In the second case: and acquiring an image from each video code stream of the L video code streams based on the starting time T2 of the static bullet time mode to obtain L images. And the L images are from video frames with the same time stamp in the L video code streams.

For example, assuming that T2 is a time stamp of 9 minutes, 0 seconds and 20 milliseconds, and L is 3, that is, the identification of the camera corresponding to the static bullet time mode includes three, and assuming that 1, 2 and 3 are included, then images corresponding to 9 minutes, 0 seconds and 20 milliseconds can be respectively obtained from the video code streams of the cameras identified as 1, 2 and 3.

In the third case: and acquiring at least one image from P (P = 1) video code streams based on the starting and ending time T3 of the fixed station mode to obtain at least P images. Wherein at least P images come from video frames with different time stamps in 1 video code stream.

In a fourth case: based on the starting time T1 of the dynamic streaming mode or the starting time T2 of the static bullet time mode, at least one image is obtained from each video code stream of the M video code streams to obtain at least M images, one image is obtained from each video code stream of the L video code streams to obtain L images, and at least M + L images are obtained in total.

In a fifth case: based on the starting time T1 of the dynamic streaming mode or the starting and ending time T3 of the fixed machine position mode, at least one image is obtained from each video code stream of the M video code streams, at least M images are obtained, at least P images are obtained from the P video code streams, at least P images are obtained, and at least M + P images are obtained in total.

In the sixth case: and acquiring an image from each video code stream of the L video code streams based on the starting time T2 of the static bullet time mode or the starting and ending time T3 of the fixed machine position mode to obtain L images, acquiring at least P images from the P video code streams to obtain at least P images, and acquiring at least L + P images in total.

In the seventh case: based on the starting time T1 of the dynamic streaming mode or the starting time T2 of the static bullet time mode or the starting and stopping time T3 of the fixed machine position mode, at least one image is obtained from each video code stream of the M video code streams to obtain at least M images, one image is obtained from each video code stream of the L video code streams to obtain L images, at least P images are obtained from the P video code streams to obtain at least P images, and at least M + L + P images are obtained in total.

For the fourth to seventh cases, when the video production request message includes at least two video production modes, the video production request message may further include a sequence of the video production modes, so that the highlight server may start to acquire an image according to the start time of the previous video production mode when acquiring the image, and then determine the start time of the subsequent video production mode based on the timestamp of the video frame corresponding to the image acquired by the previous video production mode.

Illustratively, if the video production mode includes a dynamic streaming mode and a static bullet time mode, and the dynamic streaming mode is before the static bullet time mode, it is assumed that the initial time corresponding to the dynamic streaming mode is T1, the identifier of the camera corresponding to the dynamic streaming mode is 1-5, and the identifier of the camera corresponding to the static bullet time mode is 5-3, the highlight moment server may sequentially obtain images from the video streams with the identifiers of the cameras being 1-5, and then continue to sequentially obtain images from the cameras with the identifiers of the cameras corresponding to the static bullet time mode from 5-3 after the dynamic streaming mode is finished. That is, the start time of the static bullet time mode is the end time of the dynamic streaming mode, or in other words, the start time of the static bullet time mode may be determined according to the timestamp of the video frame corresponding to the image acquired by the dynamic streaming mode.

It should be understood that if the start times of at least two video production modes are included in the video production request message, since the start times of different video production modes may be different, the end time of a video production mode located at the front may not necessarily be the start time of a video production mode located at the rear.

S604: and the wonderful moment server processes the acquired image to obtain a video file.

When the video production request message includes a video production mode, the highlight moment server can acquire a group of images corresponding to the video production mode; when the video production request message includes at least two video production modes, the highlight moment server may obtain a group of images corresponding to each video production mode, for example, obtain a first group of images and a second group of images, and then may process left and right images of the first group of images and the second group of images to obtain a video file.

In some embodiments, after the wonderful moment server acquires the image, the image may be subjected to focus anti-shake correction according to the internal parameters and the external parameters of the camera obtained in the camera calibration process. For example, suppose the production mode of the video is: dynamic streaming mode-static bullet time mode-dynamic streaming mode, and the track point list is in turn: 1-100, 100-50, 50-100, then 200 images can be obtained by the highlight server, and then focus anti-shake correction is performed on 200 pictures.

Of course, in the embodiment of the present application, the image may also be subjected to special effect processing according to a special effect included in the parameter of the highlight moment, and then the processed image is encoded and finally encapsulated into a media file, that is, a video file.

Through the embodiment, the wonderful moment server can generate wonderful moments in any video production mode, and a user can select the wonderful moment mode according to the requirement of the user, so that wonderful moment videos are richer, and user experience can be improved. And the code stream shot by the camera is stored, so that a user can make a video based on the stored code stream at any time.

Further, in other embodiments, the video production request message may further include production scene parameters, which are used to indicate the time of video production, such as real-time production or non-real-time production.

When the video production request message includes production scene parameters, the highlight instant server can obtain the video code stream from one of the N live broadcast streams, the N time shift code streams or the N point broadcast code streams stored in the code stream recording process according to the production scene parameters. Illustratively, the highlight moment server may obtain M video code streams from N live broadcast streams; or the wonderful moment server can obtain M video code streams from the N time shift code streams, and the like.

When the time for making scene parameter indication is different, the obtaining ways of the video code stream are different. Specifically, the following two cases may be included:

case 1: and if the manufacturing scene parameters indicate that the video is manufactured in real time, acquiring video code streams from the N live broadcast code streams. The N live broadcast code streams are acquired from N cameras in real time, and the N cameras are used for shooting the same scene from different angles.

Case 2: and if the manufacturing scene parameters indicate that the video is manufactured in non-real time, acquiring the video code stream from the N time-shift code streams or the N point-broadcast code streams. And the N point broadcast code streams or the N time shift code streams are obtained by storing the N live broadcast code streams.

Illustratively, if the production scene parameters indicate that the video is produced in real-time and the video production mode is the first video production mode, the highlight reel server may obtain M video streams from the N live streams. If the production scene parameter indicates that the video is not produced in real time and the video production mode is the first video production mode, the wonderful moment server can obtain M video code streams from N point broadcast code streams or N time shift code streams.

As yet another example, if a video is required to be produced in real time on site, a video code stream may be obtained from a live stream to produce the video; if the video is required to be produced by the content shot at the time before the current time, the video code stream can be obtained from the time-shifting code stream to produce the video; and if the video is required to be made after the shooting is finished, the video code stream making video can be obtained through the on-demand code stream.

By the embodiment, videos can be manufactured according to different timeliness requirements, and the stored code streams can be used for manufacturing the videos, so that when a user is unsatisfied with the videos manufactured last time, the videos can be manufactured again based on the stored code streams, and user experience is improved.

The steps executed by the different servers are introduced separately, and the process of the video production method will be described below with reference to the interaction between the servers.

Referring to fig. 8, a flow chart of another video production method according to an embodiment of the present invention is shown, and referring to fig. 8, the method may include the following steps:

step 1: and the user creates a calibration task and triggers a calibration request message.

Step 2: and the calibration server triggers the camera to take a picture. Wherein, the camera includes a plurality ofly.

And step 3: the calibration server obtains a photograph from the camera.

And 4, step 4: and the calibration server runs a calibration algorithm to obtain the internal parameters and the external parameters of the camera.

And 5: and the calibration server uploads the internal parameters and the external parameters of the camera to the wonderful moment server.

Optionally, after step 5, the user may view the calibration results.

It should be noted that, the steps 1 to 5 are a camera calibration process, and specific reference may be made to the description of the embodiment shown in fig. 3, which is not repeated herein.

And 6: and the user creates a camera stream access task and triggers a camera stream access request message.

And 7: the camera stream access server triggers the camera to start shooting.

And 8: the camera stream access server acquires the code stream from the camera.

And step 9: the camera stream access server converts the code stream format into a uniform format and synchronizes the time of the code stream.

Step 10: the camera stream access server caches the code stream.

It should be noted that, the step 6 to the step 10 are a code stream synchronization process, and specific reference may be made to the description of the embodiment shown in fig. 4, which is not repeated herein.

Step 11: and the user creates a recording task and triggers a recording request message.

Step 12: and the recording server acquires the cached code stream from the camera stream access server.

Step 13: the recording server stores the code stream and starts the live broadcast, time shift and on-demand service.

Optionally, after step 13, the user may check the code stream recording status to avoid an exception.

It should be noted that, the steps 11 to 13 are a process of recording a code stream, and specific reference may be made to the description of the embodiment shown in fig. 5, which is not repeated herein.

Step 14: the user configures parameters of the wonderful moment, creates a production task and triggers a production request message.

Step 15: and the wonderful moment server acquires the code stream from the recording server according to the identification of the camera.

Step 16: and the wonderful moment server extracts the video frames from the code stream according to the initial time included in the manufacturing request message and decodes the video frames to obtain images.

And step 17: and the wonderful moment server corrects the image according to the internal parameters and the external parameters of the camera uploaded by the calibration server.

Step 18: the wonderful moment server carries out special effect processing on the image.

Step 19: and the wonderful moment server encodes the processed image and encapsulates the encoded image into a file.

Optionally, after step 19, the highlight server may display a prompt on the terminal device to remind the user that the video production is complete.

It should be noted that steps 14 to 19 are a video production process, and specific reference may be made to the description of the embodiment shown in fig. 6, which is not repeated herein.

Based on the foregoing embodiments, the present application further provides a video production system, and referring to fig. 9, the apparatus 900 may include: a receiving module 901, an obtaining module 902 and a making module 903.

The receiving module 901 is configured to receive a video production request message, where the video production request message includes an identifier of a first video production mode, a first time, and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1; an obtaining module 902, configured to obtain at least M images based on the identifiers of the M cameras received by the receiving module 901 and the first time, where the at least M images are obtained by shooting the same scene from different angles by the M cameras at different times; a creating module 903, configured to create a first video file, where the first video file includes the at least M images.

In one possible design, the system further includes: a determining module 904, configured to determine M video code streams based on the identifiers of the M cameras; the M video code streams are obtained by shooting the same scene from different angles based on the M cameras respectively; the target timestamp of each of the M video streams is associated with the first time.

The obtaining module 902 is configured to obtain the M images based on a target timestamp of each video stream in the M video streams; and the target timestamp of each video code stream in the M video code streams is different.

In one possible design, the obtaining module 902 is specifically configured to obtain the M images based on the target timestamp of each of the M video streams as follows:

In a possible design, the video production request message further includes an identifier of a second video production mode and identifiers of L cameras corresponding to the second video production mode; and L is an integer greater than 1.

The obtaining module 902 is further configured to obtain L images based on the identifiers of the L cameras, where the L images are obtained by shooting the same scene from different angles at the same time by the L cameras;

the creating module 903 is further configured to create a second video file, where the second video file includes the at least M images and the L images.

In one possible design, the determining module 904 is specifically configured to determine the M video streams based on the identifiers of the M cameras as follows:

determining the M video code streams from N video code streams based on the identifiers of the M cameras; the N code streams are obtained by shooting the same scene from different angles based on N cameras; the N cameras include the M cameras.

In one possible design, the video production request message further includes production scene parameters; the N code streams are one of N live broadcast code streams, N time shift code streams or N point broadcast code streams.

The determining module 904 is specifically configured to determine the M video streams based on the identifiers of the M cameras as follows:

if the production scene parameters indicate that the video production is real-time production, determining the M video code streams from the N live broadcast code streams; and the N live broadcast code streams are acquired from N cameras in real time.

All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

The division of the modules in the embodiments of the present application is schematic, and is only a logical function division, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processor, or may exist alone physically, or two or more modules are integrated in one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.

As shown in fig. 10, a video production apparatus 1000 according to an embodiment of the present application is provided, where the apparatus 1000 includes at least one processor 1002, and is configured to implement or support the apparatus 1000 to implement the functions of the obtaining module and the production module shown in fig. 9 according to an embodiment of the present application. For example, the processor 1002 may acquire at least M images of the same scene taken by the M cameras from different angles at different times based on the identities of the M cameras and the first time; and a first video file is created, where the first video file includes the at least M images, and the like, for specific reference, the detailed description in the method example is omitted here for further details.

The apparatus 1000 may also include at least one memory 1001 for storing program instructions. The memory 1001 is coupled to the processor 1002. The coupling in the embodiments of the present application is an indirect coupling or a communication connection between devices, units or modules, and may be an electrical, mechanical or other form for information interaction between the devices, units or modules. The processor 1002 may cooperate with the memory 1001. Processor 1002 may execute program instructions and/or data stored in memory 1001. At least one of the at least one memory may be included in the processor.

Apparatus 1000 may also include a communication interface 1003 for communicating with other devices over a transmission medium. Processor 1002 may send and receive data using a communication interface 1003.

The present application does not limit the specific connection medium among the communication interface 1003, the processor 1002, and the memory 1001. In fig. 10, the memory 1001, the processor 1002, and the communication interface 1003 are connected by a bus 1004, which is represented by a thick line in fig. 10. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 10, but this is not intended to represent only one bus or type of bus.

In the embodiments of the present application, the processor 1002 may be a general purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, and may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be implemented directly by a hardware processor, or by a combination of hardware and software modules in a processor.

In the embodiment of the present application, the memory 1001 may be a non-volatile memory, such as a Hard Disk Drive (HDD) or a solid-state drive (SSD), and may also be a volatile memory (e.g., a RAM). The memory is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory in the embodiments of the present application may also be circuitry or any other device capable of performing the storage function to store the program instructions.

Optionally, the computer-executable instructions in this embodiment may also be referred to as application program codes, which is not specifically limited in this embodiment.

Also provided in embodiments of the present application is a computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of the above-described embodiments.

Also provided in embodiments of the present application is a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of the above-described embodiments.

The embodiment of the application also provides a chip, and the logic in the chip is used for executing the method of the embodiment.

Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by instructions. These instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A method of video production, comprising:

receiving a video production request message, wherein the video production request message comprises an identifier of a first video production mode, first time and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1;

acquiring at least M images of the same scene captured by the M cameras from different angles at different times based on the identifications of the M cameras and the first time;

and manufacturing a first video file, wherein the first video file comprises the at least M images.

2. The method of claim 1, wherein said acquiring at least M images based on the identification of the M cameras and the first time comprises:

determining M video code streams based on the identifications of the M cameras; the M video code streams are obtained by shooting the same scene from different angles based on the M cameras respectively; the target timestamp of each video code stream in the M video code streams is related to the first time;

acquiring the M images based on a target timestamp of each video code stream in the M video code streams; and the target timestamp of each video code stream in the M video code streams is different.

3. The method of claim 2, wherein the target timestamp of each of the M video streams is associated with a preset order of the M cameras.

4. The method of claim 2, wherein the target timestamp of each of the M video streams is related to an order of identification of the M cameras.

5. The method of any of claims 2-4, wherein said obtaining the M images based on the target timestamp of each of the M video streams comprises:

6. The method of any of claims 1-4, wherein the video production request message further includes an identification of a second video production mode and identifications of L cameras corresponding to the second video production mode; l is an integer greater than 1;

the method further comprises the following steps:

acquiring L images based on the identifiers of the L cameras, wherein the L images are obtained by shooting the same scene from different angles at the same time through the L cameras;

producing a second video file comprising the at least M images and the L images.

7. The method of any of claims 2-4, wherein the determining the M video codestreams based on the identities of the M cameras comprises:

8. The method of claim 5, wherein the video production request message further includes production scene parameters; the N code streams are one of N live broadcast code streams, N time shift code streams or N point broadcast code streams;

the determining the M video streams based on the identities of the M cameras includes:

9. The method of claim 8,

if the production scene parameters indicate that the video production is non-real-time production, determining the M video code streams from the N time-shifting code streams or the N point-broadcasting code streams; and the N point broadcast code streams or the N time shift code streams are obtained by storing the N live broadcast code streams.

10. A video production system, comprising:

the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a video production request message, and the video production request message comprises an identifier of a first video production mode, first time and identifiers of M cameras corresponding to the first video production mode; m is an integer greater than 1;

an obtaining module, configured to obtain at least M images of a same scene captured by the M cameras from different angles at different times based on the identifications of the M cameras and the first time;

and the making module is used for making a first video file, and the first video file comprises the at least M images.

11. The system of claim 10, wherein the system further comprises: the determining module is used for determining M video code streams based on the identifications of the M cameras; the M video code streams are obtained by shooting the same scene from different angles based on the M cameras respectively; the target timestamp of each video code stream in the M video code streams is related to the first time;

the acquisition module is used for acquiring the M images based on the target timestamp of each video code stream in the M video code streams; and the target timestamp of each video code stream in the M video code streams is different.

12. The system of claim 11, wherein the target timestamp of each of the M video streams is associated with a preset order of the M cameras.

13. The system of claim 11, wherein the target timestamp of each of the M video streams is related to an order of identification of the M cameras.

14. The system according to any one of claims 11 to 13, wherein the obtaining module, when obtaining the M images based on the target timestamp of each of the M video streams, is specifically configured to: decoding a frame of video stream data corresponding to a target timestamp of a first video stream to obtain a first image; the first video code stream is any one of the M video code streams, and the first image is any one of the M images.

15. The system of any of claims 10-13, wherein the video production request message further includes an identification of a second video production mode and identifications of L cameras corresponding to the second video production mode; l is an integer greater than 1;

the acquisition module is further configured to acquire L images based on the identifiers of the L cameras, where the L images are obtained by shooting the same scene from different angles at the same time by the L cameras;

16. The system according to any one of claims 11 to 13, wherein the determining module, when determining the M video streams based on the identifications of the M cameras, is specifically configured to:

17. The system of claim 14, wherein said video production request message further includes production scene parameters; the N code streams are one of N live broadcast code streams, N time shift code streams or N point broadcast code streams;

when determining the M video code streams based on the identifiers of the M cameras, the determining module is specifically configured to:

18. The system of claim 17, wherein the M video codestreams are determined from the N time-shifted codestreams or the N on-demand codestreams if the production scene parameters indicate that the video production is non-real-time production; and the N point broadcast code streams or the N time shift code streams are obtained by storing the N live broadcast code streams.

19. A video production apparatus, comprising: a memory, a communication interface, and a processor;

the memory stores computer instructions;

the communication interface is used for receiving and sending data;

the processor is configured to execute computer instructions stored by the memory to cause the apparatus to perform the method of any of claims 1-9.

20. A computer storage medium storing computer instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-9.