WO2019131577A1 - 情報処理装置、情報処理方法、及びプログラム - Google Patents

情報処理装置、情報処理方法、及びプログラム Download PDF

Info

Publication number
WO2019131577A1
WO2019131577A1 PCT/JP2018/047434 JP2018047434W WO2019131577A1 WO 2019131577 A1 WO2019131577 A1 WO 2019131577A1 JP 2018047434 W JP2018047434 W JP 2018047434W WO 2019131577 A1 WO2019131577 A1 WO 2019131577A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
image
information processing
information
processing apparatus
Prior art date
Application number
PCT/JP2018/047434
Other languages
English (en)
French (fr)
Inventor
高久 雅彦
Original Assignee
キヤノン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by キヤノン株式会社 filed Critical キヤノン株式会社
Publication of WO2019131577A1 publication Critical patent/WO2019131577A1/ja
Priority to US16/911,146 priority Critical patent/US20200329266A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia components thereof involving special video data, e.g 3D video
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/74Browsing; Visualisation therefor
    • G06F16/745Browsing; Visualisation therefor the internal structure of a single video sequence
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/78Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/7867Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using information manually generated, e.g. tags, keywords, comments, title and artist information, manually generated time, location and usage information, user ratings
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6581Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present invention relates to a technology for handling metadata related to video data and the like.
  • the MPEG-DASH SRD specification is known as a metadata description method for spatially extracting and transmitting a specific position portion of video from video data, which is disclosed in, for example, Non-Patent Document 1.
  • metadata it is possible to describe the relative position to the entire video such as omnidirectional video and the size of the rectangular video to be clipped.
  • an omnidirectional image such as a fisheye image as a visually easy-to-see panoramic developed image
  • Patent Document 1 and the like.
  • any rectangular video clipped out from the entire video such as omnidirectional video is any of the omnidirectional video. It can not know whether it is a picture corresponding to the direction. For this reason, it is difficult for the receiving apparatus to request distribution of a video in a direction desired to be displayed in the omnidirectional video.
  • an object of the present invention is to make it possible to appropriately know the direction of an image on the receiving device side.
  • the present invention is directed to direction information generating means for generating direction information representing two or more directions when two or more second images corresponding to two or more different directions are generated from a first image.
  • address generation means for generating address information used when the receiving device acquires the second video, and the two or more second videos and the address information and the direction information are associated with each other.
  • metadata generation means for generating metadata.
  • the direction of the image can be appropriately known on the receiving device side.
  • FIG. 1 is a diagram showing an example of the configuration of an information processing system having a video transmission apparatus 101 and a video reception apparatus 102 according to the first embodiment.
  • the video transmission device 101 is an information processing device capable of transmitting video data via the network 103.
  • the video receiving apparatus 102 is an information processing apparatus capable of receiving video data via the network 103.
  • video generation processing such as generating video data compliant with MPEG-DASH, and is capable of generating and transmitting metadata relating to a video to be transmitted.
  • the video receiving apparatus 102 can request distribution of video data compliant with MPEG-DASH using the metadata acquired earlier.
  • the video data generated by the video transmission device 101 is transmitted in response to a request from the video reception device 102, for example, the video data may be distributed to the video reception device 102 after being stored in the Web server 104.
  • the video transmission device 101 may be realized as a camera having a communication function, or may be realized by one or more computer devices as needed.
  • the video transmission apparatus 101 provided with the omnidirectional camera provided with the two fisheye lenses 111 is mentioned as an example.
  • the video receiving apparatus 102 may be realized as a dedicated apparatus such as a television receiver having a communication function, or may be realized as an apparatus comprising one or more computers as needed.
  • the video reception device 102 may be realized by a head mounted display (HMD) or the like.
  • HMD head mounted display
  • an example will be described in which the functions of the video reception device 102 are realized by a computer and a video reproduction application program (hereinafter referred to as a video reproduction application) operating there.
  • the video transmission apparatus 101 in the video transmission device 101, light taken in from the fisheye lens 111 is converted into an electrical signal by the optical sensor 112, and further digitized by the A / D converter 113 and processed as a video by the image signal processing circuit 114.
  • the video transmission apparatus 101 of this embodiment is equipped with two sets of the combination of the imaging system of the fisheye lens 111 and the optical sensor 112.
  • FIG. 1 one of the two imaging systems captures an image of the space area at an angle of view of 180 degrees, and the other image picks up the image of the space area at an angle of view of 180 degrees adjacent to one another. It is possible to acquire a video.
  • two A / D converters 113 are physically provided corresponding to the two optical sensors 112, only one is shown in FIG. 1 for simplification of illustration.
  • the signal of the fisheye image with a field angle of 180 degrees acquired by the two sets of imaging systems in this way is sent to the image signal processing circuit 114.
  • the image signal processing circuit 114 generates a 360-degree omnidirectional image from the 180-degree fish-eye image acquired by the two sets of imaging systems, and the 360-degree image is a format called Equirectangular described later. Convert to video.
  • the compression encoding circuit 115 generates compressed video data conforming to the MPEG-DASH from 360-degree video data converted to the form of equidistant cylindrical projection by the image signal processing circuit 114.
  • the compressed video data generated by the compression coding circuit 115 is temporarily stored, for example, in the memory 119, and is output from the communication circuit 116 to the network 103 in response to a transmission request from the video reception device 102. Ru.
  • the compressed video data generated by the compression coding circuit 115 may be distributed from the Web server 104 in response to a request from the video receiving apparatus 102 after being stored in the Web server 104 or the like.
  • the ROM 118 is a read only memory that stores programs and parameters that do not need to be changed.
  • the memory 119 is a random access memory (RAM) that temporarily stores programs and data supplied from an external device or the like.
  • the CPU 117 is a central processing unit that controls the entire video transmission apparatus 101, and executes, for example, a program according to the present embodiment read from the ROM 118 and expanded in the memory 119.
  • the CPU 117 also executes processing to generate metadata about video data by executing a program.
  • the metadata includes the transmission URL and the direction data regarding the video to be transmitted.
  • the video transmission device 101 may be provided with a storage medium such as a removable semiconductor memory and a write / read device of the storage medium for the purpose of recording video data, etc. Good.
  • the video reception device 102 is configured of a computer or the like, and includes a CPU 121, a communication I / F unit 122, a ROM 123, a RAM 124, an operation unit 125, a display unit 126, a large capacity storage unit 127, and the like.
  • the communication I / F unit 122 can communicate with the Web server 104, the video transmission apparatus 101, and the like via the network 103.
  • the communication I / F unit 122 receives the metadata described above, transmits a distribution request for compressed video data of video streaming, receives compressed video data distributed according to the distribution request, and the like. .
  • the ROM 123 stores various programs and parameters, and the RAM 124 temporarily stores programs and data.
  • the large-capacity storage unit 127 is a hard disk drive or a solid state drive, and can store compressed video data received by the communication I / F unit 122, a video reproduction application, and the like.
  • the CPU 121 executes a video reproduction application or the like read from the large-capacity storage unit 127 and expanded in the RAM 124. In the case of the present embodiment, the CPU 121 controls the respective units to execute acquisition of video data compliant with MPEG-DASH based on a transmission URL described later included in the metadata acquired earlier by execution of the video reproduction application. Do.
  • the CPU 121 decompresses and decodes the compressed video data, and sends it to the display unit 126.
  • the display unit 126 has a display device such as liquid crystal, and displays a video based on the video data decompressed and decoded by the CPU 121.
  • the operation unit 125 includes a mouse, a keyboard, a touch panel, and the like when the user inputs an instruction or the like, and outputs an instruction input from the user to the CPU 121.
  • the video reception device 102 is an HMD, it also has a sensor or the like that can detect a change in posture.
  • an omnidirectional camera including two fisheye lenses 111 has been illustrated, but an omnidirectional camera in which many general lenses are combined may be used, or a 180 degree image with a field angle of 180 degrees captured with only one fisheye lens 111 It may be a camera.
  • a 180 degree camera for example, when the lens is directed to the sky (upward direction), an image with an angle of view of 180 degrees downward is not captured.
  • a spherical virtual image plane 201 represents a 360-degree image viewed from a 360-degree camera located at the center, and a cylinder 202 enclosing the image plane 201 has a spherical virtual image plane 201. It represents a plane converted to a regular-range cylindrical image.
  • the alternate long and short dash lines A, B and C on the cylinder 202 represent lines that correspond to the meridians on the spherical surface.
  • the dashed dotted line A is represented by the angle 0 degree in the yaw direction.
  • an alternate long and short dash line B is a line (y: 120) corresponding to a meridian represented by an angle 120 degrees in the yaw direction
  • an alternate long and short dash line C is a line (y: 240) corresponding to a meridian represented by an angle 240 degrees in the yaw direction.
  • FIGS. 2B to 2D are diagrams showing an example in which the spherical virtual image plane 201 of FIG. 2A, which is a 360-degree image, is converted into an equidistant cylindrical image.
  • FIG. 2B converts the image plane 201 of FIG. 2A into an equidistant cylindrical image, and develops the cylinder 202 with a dashed dotted line A (line (y: 0)) corresponding to a meridian at an angle of 0 degree in the yaw direction as a center line. It represents a picture.
  • the equidistant cylindrical video shown in FIG. 2B is displayed in the video receiving apparatus 102, for example, when both ends in the horizontal direction are connected, the display as an omnidirectional video of 360 degrees in the horizontal direction is performed. It becomes possible.
  • FIG. 2C is an equidistant cylindrical image in which the cylinder 202 is developed centering on an alternate long and short dash line B (line (y: 120)) corresponding to a meridian at an angle of 120 degrees in the yaw direction.
  • FIG. 2D is an equilateral cylindrical image in which the cylinder 202 is developed centering on an alternate long and short dash line C (line (y: 240)) corresponding to a meridian at an angle of 220 degrees in the yaw direction.
  • FIG. 2B when the equidistant cylindrical images shown in FIGS. 2C and 2D are displayed on the image receiving apparatus 102, the equidistant cylindrical images are connected at both ends in the horizontal direction, thereby providing 360 in the horizontal direction.
  • the image can be displayed as an omnidirectional image.
  • the respective cylinders 202, 206, and 207 are the same in that the virtual image plane 201 is converted to an equidistant cylindrical image, and the difference is that the center line of the rectangle converted to the equidistant cylindrical image is different. It is a point which becomes an alternate long and short dash line A, B, C. This can be rephrased as the difference of where to cut out at the time of conversion to the equidistant cylindrical image.
  • the zenith portion of the sphere is enlarged to the circle at the upper end of the cylinders 202, 206, and 207, respectively.
  • the image converted by the equidistant cylindrical projection is enlarged as it moves away from the equatorial plane of the sphere in the polar direction, and becomes distorted.
  • the sun-shaped object 203 and the star-shaped object 205 in FIG. 2A show an example of an object captured by a 360-degree camera placed at the center of a sphere.
  • the objects 203 and 205 shown in FIG. 2A appear as objects 204 and 208, respectively, on the cylinders 202, 206 and 207 of FIGS. 2B to 2C converted by the equidistant cylindrical projection.
  • FIG. 3 is a flowchart showing a flow of control processing until the video converted by the equidistant cylindrical projection is compressed and encoded and transmitted in the video transmitting apparatus 101 according to the present embodiment.
  • steps S301 to S307 in the flowchart of FIG. 3 will be abbreviated as S301 to S307.
  • the process of the flowchart of FIG. 3 may be executed by a software configuration or a hardware configuration, or a part may be implemented by a software configuration and the rest may be implemented by a hardware configuration.
  • the process is executed by the software configuration, for example, it is realized by the CPU 117 executing a program according to the present embodiment stored in the ROM 118 to control each unit.
  • the program according to the present embodiment may be prepared in advance in the ROM 118, may be read from a removable semiconductor memory or the like, or may be downloaded from a network such as the Internet.
  • the process of the flowchart of FIG. 3 is performed each time the 360-degree video is acquired.
  • the CPU 117 determines a plurality of center directions when converting the 360-degree video described above into an equidistant cylindrical video.
  • the plurality of central directions are the three lines (y: 0), (y: 120), (y :) represented by the angle of the meridian in the yaw direction described in FIGS. 2A to 2D described above.
  • Three central directions respectively corresponding to 240) are determined.
  • three central directions are described as an example, but this is an example, and it is not necessary to limit to three directions.
  • it may be two directions rotated by 180 degrees, such as a line (y: 0) corresponding to a meridian with an angle of 0 degrees and a line (y: 180) corresponding to a meridian with an angle of 180 degrees.
  • a line (y: 0) corresponding to a meridian with an angle of 0 degrees Assuming that the direction of the line (y: 0) corresponding to the meridian at an angle of 0 degrees is the front, the direction of the line (y: 180) corresponding to the meridian at an angle of 180 degrees is the back.
  • the pitch direction is not limited to the yaw direction, and may be a pitch direction corresponding to the latitudinal direction.
  • the CPU 117 controls the image signal processing circuit 114 to generate three equidistant cylinders respectively corresponding to the three central directions determined in S301 from the 360 degree image captured and acquired as described above. Generate a picture. That is, the image signal processing circuit 114 at this time generates three equidistant cylindrical images as shown in FIG. 2B to FIG. 2D different in the central direction by converting one 360 degree image to the equidistant cylindrical projection. Do.
  • step S303 the CPU 117 controls the compression encoding circuit 115 to compress and encode the video data of the three equidistant cylindrical images generated in step S302.
  • the compression encoding circuit 115 generates three compressed video data respectively corresponding to the three equidistant cylindrical videos.
  • these three compressed video data can be transmitted to the video receiving apparatus 102 after being stored in a place where it can be transmitted to the video receiving apparatus 102 or in a different place when there is a request from the video receiving apparatus 102. It is copied etc. Specifically, it is stored in the memory 119 or the web server 104 or the like.
  • step S304 the CPU 117 performs an address generation process for generating a URL, which is address information indicating the locations of the three compressed video data. That is, the CPU 117 generates a transmission URL used when the video reception device 102 requests distribution of video data as an address generation process. Then, in S305, the CPU 117 records transmission URLs respectively corresponding to the three compressed video data in the metadata of the MPEG-DASH.
  • the metadata is a manifest file or an MPD file in MPEG-DASH.
  • step S306 the CPU 117 performs direction information generation processing for generating direction information (hereinafter referred to as direction data) representing the center direction determined in step S301.
  • direction data direction information
  • the CPU 117 since three transmission URLs corresponding to three compressed video data are generated, the CPU 117 generates three direction data corresponding to the three transmission URLs as direction information generation processing.
  • the CPU 117 associates the respective direction data with the corresponding transmission URLs, and records them in the metadata.
  • the processing of the flowchart of FIG. 3 ends.
  • the metadata is sent from the communication circuit 116 to the video reception apparatus 102 via the network 103.
  • the video reception device 102 can obtain compressed video data corresponding to a desired direction by referring to the transmission URL and the direction data recorded in the received metadata.
  • FIG. 4 is a diagram showing an example of metadata (MPD) in the case of MPEG-DASH as an example.
  • MPD metadata
  • metadata is sometimes called a manifest file, and is shown as a manifest file 401 in FIG.
  • the manifest file 401 illustrated in FIG. 4 includes three representations 402, 403, and 404.
  • Representation is a unit that enables switching of one video, audio, etc. according to the situation in MPEG-DASH.
  • Direction data includes data representing the roll (r), pitch (p), and yaw (y) directions of the rotational coordinate system.
  • the second representation 403 also contains directional data.
  • the direction data of representation 403 is 120 (y: 120) only in the yaw (y) direction, and is rotated 120 degrees in the yaw direction (horizontal direction) with respect to the direction indicated by representation 402. It shows that there is.
  • the third representation 404 also contains directional data.
  • the direction data of representation 404 indicates that only the yaw (y) direction is 220 (y: 220) and it is rotated by 240 degrees in the yaw direction with respect to the direction indicated by representation 402. ing. Then, depending on which direction data of these representations 402 to 404 is selected, transmission of an image centered on any of the lines (y: 0) to (y: 240) in FIGS. 2B to 2D described above is performed. You will be able to decide what you want.
  • the direction in which the user of the video reception device 102 that has received the manifest file 401 in FIG. 4 desires reproduction display is, for example, the line (y: 0) in FIG. 2B centered on (r: 0, p: 0, y: 0) And the direction of the video.
  • the video reception device 102 can reproduce and display the video of the front (r: 0, p: 0, y: 0) centered on the line (y: 0) in FIG. 2B.
  • a representation 403 corresponding to direction "r: 0, p: 0, y: 120".
  • Compressed video data is acquired from the transmission URL of.
  • the video reception device 102 can reproduce and display a video centered on the line (y: 120) in FIG. 2C.
  • the CPU 121 can display the representation 403 or One of the transmission URLs 404 is acquired.
  • the central line (y: 120) by the representation 403 and the central line (y: 240) by the representation 403 both deviate from the 180 degrees (y: 180) of the meridian by 60 degrees. Because they are considered equivalent. Therefore, when the direction in which reproduction display is desired is designated as the rear image of 180 degrees (y: 180), the image receiving apparatus 102 acquires an image acquired from the transmission URL selected from either of the representations 403 or 403. It will be played back.
  • the seam of the 360-degree omnidirectional image in the horizontal direction is the center line (y: 0)
  • the position is shifted by 180 degrees with respect to the meridian (immediately behind the front). That is, since the seam in this case is on the back side as viewed from the user of the video reception device 102, there is an advantage that it can be made less visible to the user.
  • the direction in which the reproduction display is desired is a direction centered on the line of 180 degrees (y: 180)
  • what is acquired is an image of the center line being line (y: 120) or line (y: 240) .
  • the seam of 360-degree omnidirectional video in the horizontal direction is shifted from the 180-degree line (y: 180) by 60 degrees in the meridian, but it is far from the center of the video Therefore, it is considered to be less noticeable to the user.
  • the seam of the video in the case of displaying the 360-degree omnidirectional video in the horizontal direction (yaw direction) has been described, but the merit by recording the direction data as described above is not necessarily related to the processing of the seam Not only things.
  • a plurality of video data are generated also in the pan direction (the latitudinal direction of the ball) in the same manner as in the yaw direction described above, and metadata generation processing similar to the above is also performed. This makes it possible to obtain an image with less distortion on the zenith side.
  • the cylinder 202 shown in FIG. 2A and FIG. 2B is an equidistant cylindrical image centered on the alternate long and short dash line A, as described above.
  • the image display is performed by designating the direction in which the dashed dotted line A is at the center as the direction in which the playback display is desired.
  • the image portion between the alternate long and short dash line B and the alternate long and short dash line C that is, the image of the portion corresponding to the back side when the central portion of the alternate long and short dash line A is the front, has more importance than the image of the front portion It is considered low.
  • the importance of the object 204 in the form of a sun is considered to be high, and the importance of the star-shaped object 205 is considered low. Then, with regard to a video portion having a low degree of importance, it is considered that the influence on the visibility is small even if the bit rate of video compression is lowered, for example.
  • the CPU 117 of the video transmission device 101 controls the compression encoding circuit 115 to lower the video compression bit rate, for example, as it moves away from the central line (A) in the yaw direction.
  • the closer to the center line the higher the video compression bit rate.
  • the video compression bit rate of the area including the sun-shaped object 204 of FIG. 2B is high, while the video compression bit rate of the area including the star-shaped object 208 is low.
  • the bit rate of video compression is lowered as it goes away from the central line (B).
  • the video compression bit rate of the area including the sun-shaped object 204 is low, and the video compression bit rate of the area including the star object 208 is low.
  • the video receiving apparatus 102 when reproduction and display of the video with the line (y: 0) in front is performed, the video is generated based on the transmission URL described in the representation 402 of FIG. Data is acquired. In addition, in the case where reproduction and display of video centered on the line (y: 120) is performed, video data is acquired based on the transmission URL described in the representation 403 of FIG. 4.
  • the video in the central part is a video with little image quality deterioration, and the user You can appreciate the good images of
  • the control is performed such that the video compression bit rate is lowered as the distance from the center line is away, the transmission bit rate at the time of acquiring the video data is kept low as a whole.
  • the direction data may be described as direction data represented by relative angles with reference to the first representation 402 in FIG. 4 and other predetermined directions.
  • direction data represented by relative angles with reference to the first representation 402 in FIG. 4 and other predetermined directions.
  • yaw + 180 Description examples such as
  • which description format is used as the direction data can be appropriately set.
  • the video receiving apparatus 102 can acquire a suitable video according to the direction to be reproduced and displayed in a wide-field video such as an omnidirectional image. It becomes.
  • Second Embodiment In the first embodiment, an example in which a 360-degree video is converted into an equidistant cylindrical video has been described. In the following second embodiment, an example of converting a 360-degree image into a cubic format will be described.
  • the configurations of the video transmission device 101, the video reception device 102, and the like in the second embodiment are the same as those in FIG.
  • the image signal processing circuit 114 of the video transmission apparatus 101 converts the 360-degree video described above into a cube format as described later, and further develops the cube to generate a cube expanded video.
  • the compression encoding circuit 115 generates compressed video data compliant with MPEG-DASH from the video data of the cube-expanded video obtained by expanding the cube by the image signal processing circuit 114.
  • the CPU 117 performs metadata generation processing relating to a cube expansion video. Details of the direction data described in the metadata in the case of the second embodiment will be described later.
  • the video reception device 102 acquires video data conforming to the MPEG-DASH based on the transmission URL and the direction data included in the metadata, and displays the video data on the display unit 126.
  • a spherical virtual image plane 201 represents a 360-degree image as viewed from a 360-degree camera located at the center thereof, as described above. The same applies to the sun-shaped object 203 and the star-shaped object 205.
  • the spherical virtual image plane 201 is projected onto the cube 501.
  • FIG. 5B is a view showing a cube projection image 502 developed centering on the plane c of the cube 501 of FIG. 5A.
  • objects 204 and 208 in FIG. 5B represent the objects 203 and 205 in FIG. 5A that are displayed on the cube projection image 502.
  • the cube projection image 502 is expanded around the face c.
  • the face b is placed on the left side of the face a and the face e is placed on the right side of the face a. It may be expanded to be a rectangle having a size of 3 ⁇ 4 horizontally and 2 ⁇ 3 vertically.
  • FIG. 5C shows a cube projection image 503 developed centering on the plane a of the cube 501 of FIG. 5A.
  • the cube projection image 502 of FIG. 5B is centered on the object 204 in the shape of the near sun, whereas in the cube projection image 503 of FIG. 5C, it is centered on the upper surface a of the cube It is an example.
  • the image data of the cube projection image 502 of FIG. 5B and the image data of the cube projection image 503 of FIG. 5C are also compressed and encoded as described above. Note that the expansion method of the cube 501 is not limited to these examples.
  • the image c of the central area is improved in image quality, and the planes (a, b, d, e, f) of the other peripheral areas reduce the code amount (image quality To make the features of the image different. That is, in the case of the example of FIG. 5B, the CPU 117 of the video transmission apparatus 101 controls the compression encoding circuit 115 so that the area in the circle 505 drawn on the cube projection video 502 has high image quality. The same applies to the cube projection image 503 of FIG. 5C. Thereby, when the image 204 obtained by compression encoding the cube projection image 502 in FIG.
  • the cube projection image 504 in FIG. 5D has the same arrangement as that of the cube projection image 502 in FIG. 5C, and the example in FIG. 5C is different from that in FIG. And the same process can be performed.
  • the region to be subjected to the image quality improvement indicated by the circle 505 is not only a part of the face a and the face c, but a face d, a face f, a face e in the cube respectively contacting the face a. Some of the will be included.
  • the coding amount can be largely reduced by not coding as a skipped macroblock.
  • the flow when compression-coding and transmitting the converted cubic projection video is substantially the same as the flow chart of FIG. 3 described above.
  • a 360-degree video is converted into a cube-projected video, and a transmission URL in which the cube-projected video is associated with a center or a predetermined surface for high image quality is recorded in metadata.
  • the CPU 117 of the video transmission apparatus 101 determines a plurality of centers for expanding a 360-degree video into a cube-projected video or a plurality of predetermined planes for high image quality.
  • the plurality of predetermined planes determined here are, for example, the plane c of FIG. 5B, the plane a of FIG. 5C, the plane a of FIG.
  • step S302 the CPU 117 controls the image signal processing circuit 114 to generate cubic projection images centered on the plane determined as the central plane in step S301 from the 360 ° images described above.
  • step S303 the CPU 117 controls the compression encoding circuit 115 to compress and encode the video data of each cube projection image generated in step S302.
  • the compression encoding circuit 115 generates compressed video data respectively corresponding to each cubic projection video.
  • the image quality improvement processing is performed as described above in the compression encoding.
  • each compressed video data of each cube projection video is a video receiving apparatus after being stored at a place where it can be transmitted to the video receiving apparatus 102 or at a different place when there is a request from the video receiving apparatus 102. It is copied to a place where it can be sent to 102.
  • the CPU 117 determines a transmission URL, which is address information indicating the location of the compressed video data, and further, in S305, records the transmission URL corresponding to each of the compressed video data in the metadata.
  • the CPU 117 generates direction data representing a predetermined surface determined to be the center or to improve the image quality in S301. That is, the direction data in the case of the second embodiment is, for example, data representing a center or a predetermined surface to be subjected to high image quality among surfaces when the 360-degree image of the image surface 201 of FIG. Is done. Then, in S307, the CPU 117 associates the respective direction data with the corresponding transmission URLs, and records them in the metadata.
  • this metadata is sent from the communication circuit 116 to the video reception device 102 via the network 103.
  • the video reception device 102 can obtain compressed video data corresponding to a desired direction by referring to the transmission URL and the direction data recorded in the received metadata. Become.
  • FIG. 6 is a diagram showing an example of metadata taking MPEG-DASH as an example in the second embodiment.
  • metadata in the MPEG-DASH is shown as a manifest file 601.
  • the manifest file 601 in FIG. 6 includes three representations 603, 604, and 605 as described in the first embodiment.
  • this is called a map 602.
  • a 360-degree video is converted into a cube-projected video, and direction data representing a projected predetermined plane is described in metadata.
  • direction data representing a projected predetermined plane is described in metadata.
  • the example of converting a 360-degree image into an equidistant cylindrical image described with reference to FIGS. 2A to 2D is a case where a part of the cylinder 202 is used to generate an image that does not have a full circumference. Is also applicable.
  • the third embodiment is an application example in the case of generating an image that does not have a full circumference by using a part of the cylinder 202.
  • FIGS. 7A to 7D an example in which a 240-degree image is generated as an image that does not form the entire circumference of a part of the cylinder 202 will be described using FIGS. 7A to 7D.
  • FIG. 7A shows a spherical virtual image plane 201 and an image viewed from a 360-degree camera located at the center, and the cylinder 202 has an equal distance from the image plane 201. It is an image converted by cylindrical projection. Further, dashed dotted lines A, B and C on the cylinder 202 are lines corresponding to the meridians on the spherical surface as described above.
  • FIG. 7B shows a partial cylindrical image 701 obtained by converting the image plane 201 of FIG. 7A into equidistant cylindrical projection and cutting out 240 ° from the cylinder 202 with the dashed dotted line A (line (y: 0)) as the center line. ing.
  • FIG. 7C is centered at the alternate long and short dash line B (line (y: 120))
  • FIG. 7D is centered at the alternate long and short dash line C (line (y: 240)).
  • the partial cylindrical images 702 and 703 are shown.
  • the video receiving apparatus 102 is, for example, an HMD
  • the wearer of the HMD looks at, for example, a certain direction
  • the video on the opposite side is unnecessary, and thus part of the video is included. It is considered that no problem will occur even if the Therefore, also in the case of the third embodiment, as shown in the manifest file 401 of FIG. 4 described above, it is sufficient to obtain the optimum representation using the direction data.
  • FIG. 8 shows a description example of a manifest file as an example of metadata in the third embodiment.
  • range “y: 240” is further described.
  • the video reception device 102 referring to the manifest file of FIG. 8 can know that the corresponding representation holds a video having an angle of 240 degrees in the yaw direction.
  • the roll direction, the pitch direction, and the like may be simultaneously used.
  • the third embodiment video data that does not reach the entire circumference of a part of the cylinder 202 is transmitted, so it is possible to further reduce the transmission bit rate. Also in the third embodiment, as in the first embodiment, the video compression bit rate in the central area corresponding to the center line may be increased, and the video compression bit rate in the peripheral area may be decreased.
  • FIG. 9 shows still another example of the manifest file described with reference to FIG.
  • the media file is media data of a file format based on ISOBMFF (ISO / IEC 14496-12) as can be estimated from the file extension.
  • ISOBMFF ISO / IEC 14496-12
  • Such files have a mechanism for storing a plurality of media called tracks. That is, the representation 902 is described so as to obtain a media that matches the direction by using a media file (media data) stored in a designated track of a designated file.
  • Two consecutive media files designate different tracks because each media file is independent and it is assumed that media matched in directions are stored in different tracks.
  • the media data of the representations 903 and 904 indicate the same. That is, the representations 903 and 904 refer to the same media data.
  • the present embodiment is not limited to the MPEG-DASH, but can be applied to a system that transmits and receives video by combining a metadata file and a media file.
  • a format called m3u is adopted for the manifest file.
  • the present invention can also be embodied as, for example, a system, an apparatus, a method, a program, or a recording medium (storage medium).
  • the present invention may be applied to a system configured of a plurality of devices (for example, host computer, interface device, imaging device, web application, etc.), or may be applied to a device including one device. good. Further, it may be a cloud system composed of a plurality of distributed virtual computer groups.
  • the present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. Can also be realized. It can also be implemented by a circuit (eg, an ASIC) that implements one or more functions.
  • a circuit eg, an ASIC
  • Video transmission device 101 Video transmission device 102: Video reception device 103: Network 114: Video signal processing circuit 117: CPU

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Library & Information Science (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

受信装置側で映像の方向を適切に知ることができるようにすることを目的として、映像送信装置のCPUは、第1の映像から二つ以上の異なる方向に対応した二つ以上の第2の映像が生成された際の二つ以上の方向を表す方向データを生成し、映像受信装置が第2の映像を取得する際に用いられる送信URLを生成し、そして第2の映像と送信URLおよび方向データとをそれぞれ関連付けたメタデータを生成する。

Description

情報処理装置、情報処理方法、及びプログラム
本発明は、映像データ等に関するメタデータを扱う技術に関する。
近年、HTTPを代表とするWeb技術を用いて映像データを送信し、Webブラウザを用いてこの映像を再生する映像ストリーミング技術が広く使われるようになっている。特に広く使われる技術の特徴の一つは、送信しようとする映像データに関するメタデータを先に交換し、このメタデータを用いて実際の映像データを受信装置から送信装置に要求する形式である。
このような形式において、映像データの解像度への要求の高まりと共に、高解像度映像の特定部分を取得する方法が提案されている。
従来、例えば映像データから映像の特定位置部分を空間的に切り出して送信するメタデータの記載方法として、MPEG-DASH SRD仕様があり、これは例えば非特許文献1に開示されている。なお、メタデータには、全方位映像等の映像全体に対する相対位置と切り出される矩形映像のサイズとを記述することが可能となされている。また、例えば魚眼画像のような全方位画像を視覚的に見やすいパノラマ展開画像として再生する際に、容易に方向を特定するために、基準となる方向をメタデータとして映像に付随させる方法があり、これは特許文献1等に開示されている。その他にも、全方位映像等から、中央位置や主要な位置を変えた複数の映像を生成する技術も知られている。
特開2013-27012号公報
ISO/IEC 23009-1:2014/Amd2:2015
ところで、受信装置側では、前述したメタデータの記述を基に映像データの配信を要求する際、全方位映像等の映像全体から切り出し等された矩形映像が、その全方位映像の中の何れの方向に相当する映像であるのかを知ることができない。このため、受信装置は、全方位映像の中で表示したい方向の映像の配信を要求することが難しい。
そこで、本発明は、受信装置側で映像の方向を適切に知ることができるようにすること目的とする。
本発明は、第1の映像から二つ以上の異なる方向に対応した二つ以上の第2の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成手段と、受信装置が前記第2の映像を取得する際に用いられるアドレス情報を生成するアドレス生成手段と、前記二つ以上の前記第2の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成手段と、を有することを特徴とする。 
本発明によれば、受信装置側で映像の方向を適切に知ることができるようになる。
本実施形態の情報処理システムの構成を示すブロック図である。 360度映像を正距円筒映像へと変換する例を示す図である。 360度映像を正距円筒映像へと変換する例を示す図である。 360度映像を正距円筒映像へと変換する例を示す図である。 360度映像を正距円筒映像へと変換する例を示す図である。 映像の変換から伝送までの流れを示すフローチャートである。 MPEG-DASHを例としたメタデータの例を示す図である。 360度映像を立方体へと変換した例を示す図である。 360度映像を立方体へと変換した例を示す図である。 360度映像を立方体へと変換した例を示す図である。 360度映像を立方体へと変換した例を示す図である。 MPEG-DASHを例としたメタデータの他の例を示す図である。 円筒から240度映像を生成する例を示す図である。 円筒から240度映像を生成する例を示す図である。 円筒から240度映像を生成する例を示す図である。 円筒から240度映像を生成する例を示す図である。 マニフェストファイルの他の例を示す図である。 マニフェストファイルのさらに他の例を示す図である。
以下、本発明の実施形態を添付の図面を参照して詳細に説明する。なお、以下に説明する実施形態は、本発明を具体的に実施した場合の一例を示すものであり、本発明は以下の実施形態に限定されるものではない。
<<第1実施形態>>
図1は、第1実施形態の映像送信装置101と映像受信装置102を有する情報処理システムの構成例を示す図である。
映像送信装置101は、映像データを、ネットワーク103を介して送信可能な情報処理装置である。映像受信装置102は、映像データを、ネットワーク103を介して受信可能な情報処理装置である。本実施形態では、一例としてMPEG-DASHを用いた映像ストリーミング送信を行う例を挙げる。詳細については後述するが、映像送信装置101は、MPEG-DASHに準拠した映像データを生成するような映像生成処理を行い、また、送信する映像に関するメタデータを生成して送信可能となされている。映像受信装置102は、先に取得したメタデータを用いて、MPEG-DASHに準拠した映像データの配信を要求可能となされている。なお、映像送信装置101により生成された映像データは、映像受信装置102からの要求に応じて送信されるが、例えばWebサーバ104に蓄積された後に映像受信装置102へ配信されてもよい。
映像送信装置101は、通信機能を備えたカメラとして実現してもよいし、必要に応じて一つ以上のコンピュータ装置により実現するようにしてもよい。本実施形態では、一例として、二つの魚眼レンズ111を備えた全方位カメラを備えた映像送信装置101を挙げている。
映像受信装置102は、通信機能を備えたテレビジョン受像機といった専用装置として実現してもよいし、必要に応じて一つ以上のコンピュータからなる装置として実現するようにしてもよい。また、映像受信装置102は、ヘッドマウントディスプレイ(HMD)などで実現されてもよい。本実施形態では、コンピュータとそこで動作する映像再生アプリケーションプログラム(以下、映像再生アプリとする。)により映像受信装置102の機能を実現する例を挙げる。
図1において、映像送信装置101では、魚眼レンズ111から取り込まれた光が光学センサ112により電気信号に変換され、さらにA/Dコンバータ113によりデジタル化されて画像信号処理回路114で映像としての処理が行われる。なお、本実施形態の映像送信装置101は、魚眼レンズ111と光学センサ112の撮像系の組み合わせを二組備えている。本実施形態では、二組の撮像系のうち、一方が180度の画角で空間領域を撮像し、もう一方が隣接する180度の画角で空間領域を撮像することで、全方位の360度映像を取得可能としている。A/Dコンバータ113は、二つの光学センサ112に対応して物理的に二つ設けられているが、図1では図示の簡略化のために一つだけを記載している。
このように二組の撮像系によりそれぞれ取得された画角180度の魚眼画像の信号は、画像信号処理回路114に送られる。画像信号処理回路114は、二組の撮像系にて取得された180度魚眼画像から360度全方位映像を生成し、その360度映像を後述する正距円筒図法(Equirectangular)と呼ばれる形式の映像に変換する。圧縮符号化回路115は、画像信号処理回路114により正距円筒図法の形式に変換された360度映像データから、MPEG-DASHに準拠した圧縮映像データを生成する。本実施形態の場合、圧縮符号化回路115で生成された圧縮映像データは、例えばメモリ119に一時的に保持され、映像受信装置102からの送信要求に応じて通信回路116からネットワーク103に出力される。なお、圧縮符号化回路115で生成された圧縮映像データは、Webサーバ104等に蓄積された後、映像受信装置102等からの要求に応じてWebサーバ104から配信されてもよい。
ROM118は、変更を必要としないプログラムやパラメータを格納するリードオンリメモリである。メモリ119は、外部装置などから供給されるプログラムやデータを一時記憶するRAM(ランダムアクセスメモリ)である。CPU117は、映像送信装置101全体を制御する中央処理ユニットであり、例えばROM118から読み出されてメモリ119に展開された本実施形態に係るプログラムを実行する。また、CPU117は、プログラムの実行により、映像データに関するメタデータを生成する処理も行う。本実施形態の場合、詳細は後述するが、メタデータには、送信される映像に関する送信URLと方向データが含まれる。なお、図示は省略しているが、映像送信装置101は、映像データを記録するなどの目的で、着脱可能な半導体メモリ等の記憶メディアとその記憶メディアの書込み/読出し装置等を備えていてもよい。
映像受信装置102は、コンピュータ等からなり、CPU121、通信I/F部122、ROM123、RAM124、操作部125、表示部126、大容量記憶部127等を有する。
通信I/F部122は、ネットワーク103を介してWebサーバ104や映像送信装置101等と通信可能となされている。本実施形態の場合、通信I/F部122は、前述したメタデータの受信、映像ストリーミングの圧縮映像データの配信要求の送信、当該配信要求に応じて配信された圧縮映像データの受信等を行う。
ROM123は、各種プログラムやパラメータを格納し、RAM124はプログラムやデータを一時記憶する。大容量記憶部127はハードディスクドライブやソリッドステートドライブであり、通信I/F部122により受信された圧縮映像データや、映像再生アプリ等を記憶可能となされている。CPU121は、大容量記憶部127から読み出されてRAM124に展開された映像再生アプリ等を実行する。本実施形態の場合、CPU121は、映像再生アプリの実行により、先に取得したメタデータに含まれる後述する送信URLに基づき、MPEG-DASHに準拠した映像データの取得を行わせるように各部を制御する。そして、圧縮映像データを取得すると、CPU121は、その圧縮映像データを伸張復号化して、表示部126に送る。表示部126は、液晶等のディスプレイ装置を有し、CPU121により伸張復号化された映像データに基づく映像を表示する。操作部125は、ユーザが指示等を入力する際のマウスやキーボード、タッチパネル等を有し、ユーザからの指示入力をCPU121に出力する。なお、映像受信装置102がHMDである場合には、姿勢変化を検出可能なセンサ等も有する。
<正距円筒図法の概要説明>
本実施形態では、映像送信装置101の画像信号処理回路114において、360度映像を正距円筒映像へと変換する例を挙げている。360度映像を正距円筒映像へと変換しているのは、一般的な矩形映像を生成することで映像圧縮や表示が行い易くなるといった理由からである。なお、画像信号処理回路114では、後述する第2実施形態で説明するような正立方体へ投影(Cubic Projection)する変換処理が行われても良いし、さらに後述する第3実施形態等のような他の変換処理が行われてもよい。また本実施形態では、二つの魚眼レンズ111からなる全方位カメラを例示したが、一般的なレンズを多数組み合わせた全方位カメラでも良いし、一つの魚眼レンズ111のみで画角180度を撮影する180度カメラでもよい。なお、180度カメラを用いた場合には、レンズを例えば天空(上方向)に向けたときには下方向の画角180度分が撮像されない映像となるだけである。
ここで、360度映像を正距円筒映像へと変換する例について、後の説明をより明確にするため、図2A~図2Dを用いてもう少し説明を行う。
図2Aにおいて、球状の仮想的な映像面201は、その中心部に位置する360度カメラから見た360度映像を表し、映像面201を包み込む円筒202は、球状の仮想的な映像面201を正距円筒映像へと変換した面を表している。円筒202上の一点鎖線A,B,Cは、球面での経線にあたる線を表している。球状の映像面201における回転座標系の方向をロール(r)、ピッチ(p)、ヨー(y)の各方向で表した場合に、一点鎖線Aは、ヨー方向の角度0度で表される経線にあたる線(y:0)である。同様に、一点鎖線Bはヨー方向の角度120度で表される経線にあたる線(y:120)、一点鎖線Cはヨー方向の角度240度で表される経線にあたる線(y:240)である。
図2B~図2Dは、360度映像である図2Aの球状の仮想的な映像面201を、正距円筒映像へと変換した例を示した図である。
図2Bは、図2Aの映像面201を正距円筒映像へと変換し、ヨー方向の角度0度の経線にあたる一点鎖線A(線(y:0))を中心線として、円筒202を展開した映像を表している。なお、この図2Bに示した正距円筒映像は、映像受信装置102において表示が行われる際に、例えば水平方向の両端部が繋がれた場合、水平方向360度の全方位映像としての表示が可能となる。
また、図2Cは、ヨー方向の角度120度の経線にあたる一点鎖線B(線(y:120))を中心として円筒202を展開した正距円筒映像である。同様に、図2Dは、ヨー方向の角度220度の経線にあたる一点鎖線C(線(y:240))を中心として円筒202を展開した正距円筒映像である。これら図2C、図2Dに示した正距円筒映像も図2Bと同様に、映像受信装置102で表示される際に、正距円筒映像を水平方向の両端部で繋ぐことで、水平方向の360度全方位映像として表示可能となる。 
これら各円筒202,206,207は、仮想的な映像面201を正距円筒映像へと変換した図という点で同じであり、異なるのは正距円筒映像へと変換された矩形の中心線が一点鎖線A,B,Cとなっている点である。これは正距円筒映像への変換の際にどこを中心として切り出すかの違いと言い換えることもできる。
また、これら図2A~図2Dからも明らかなように、球の天頂にあたる部分はそれぞれ円筒202,206,207の上端の円へと拡大されている。このため、正距円筒図法で変換された映像は、球の赤道面から極方向へ離れるにしたがって拡大されて、いびつな形となる。また、図2A中の太陽の形のオブジェクト203と星形のオブジェクト205は、球の中心に置かれた360度カメラにより写されるオブジェクトの一例を示している。図2Aに示したオブジェクト203,205は、正距円筒図法で変換された図2B~図2Cの円筒202,206,207上では、それぞれオブジェクト204,208のように映ることになる。
<MPEG-DASHに準拠した映像データ及びメタデータ生成処理と送信>
次に、正距円筒図法で変換された映像を圧縮符号化して伝送する際の流れを、MPEG-DASHの例を用いて説明する。
図3は、本実施形態の映像送信装置101において、正距円筒図法で変換された映像を圧縮符号化して伝送するまでの制御処理の流れを示すフローチャートである。以下の説明では、図3のフローチャートの各ステップS301~ステップS307をS301~S307と略記する。図3のフローチャートの処理は、ソフトウェア構成またはハードウェア構成により実行されてもよいし、一部がソフトウェア構成で残りがハードウェア構成により実現されてもよい。ソフトウェア構成により処理が実行される場合、例えばROM118に記憶されている本実施形態に係るプログラムをCPU117が実行して各部を制御することにより実現される。本実施形態に係るプログラムは、ROM118に予め用意されていてもよく、また着脱可能な半導体メモリ等から読み出されたり、インターネット等のネットワークからダウンロードされたりしてもよい。この図3のフローチャートの処理は、360度映像の取得がなされる毎に行われる。
先ず、S301において、CPU117は、前述した360度映像を正距円筒映像へと変換する際の中心方向を複数決定する。本実施形態の場合、複数の中心方向は、前述の図2A~図2Dで説明したヨー方向における経線の角度で表される三つの線(y:0),(y:120),(y:240)にそれぞれ対応した三つの中心方向が決定される。なお、本実施形態では、三つの中心方向を例に挙げたが、これは一例であり三つの方向に限定する必要はない。例えば、角度0度の経線にあたる線(y:0)と、角度180度の経線にあたる線(y:180)のように180度分だけ回転した二つ方向であってもよい。角度0度の経線にあたる線(y:0)の方向を正面とすると、角度180度の経線にあたる線(y:180)の方向は背面となる。また、ヨー方向にも限定されず、緯度方向に相当するピッチ方向等であってもよい。
次に、S302において、CPU117は、画像信号処理回路114を制御し、前述のように撮像されて取得された360度映像から、S301で決定した三つの中心方向にそれぞれ対応した三つの正距円筒映像を生成させる。すなわちこの時の画像信号処理回路114は、一つの360度映像から、正距円筒図法への変換により、それぞれ中心方向が異なる図2B~図2Dで示したような三つの正距円筒映像を生成する。
次に、S303において、CPU117は、圧縮符号化回路115を制御し、S302で生成された三つの正距円筒映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路115からは、三つの正距円筒映像にそれぞれ対応した三つの圧縮映像データが生成される。そして、これら三つの圧縮映像データは、映像受信装置102からの要求があった場合に、当該映像受信装置102へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置102へ送信可能な場所にコピー等される。具体的には、メモリ119、或いはWebサーバ104等に格納される。
次に、S304において、CPU117は、それら三つの圧縮映像データの場所を表すアドレス情報であるURLを生成するアドレス生成処理を行う。すなわち、CPU117は、アドレス生成処理として、映像受信装置102が映像データの配信を要求する際に使用される送信URLを生成する。そして、S305において、CPU117は、それら三つの圧縮映像データにそれぞれ対応した送信URLを、MPEG-DASHのメタデータに記録する。本実施形態において、メタデータは、MPEG-DASHにおけるマニフェストファイル或いはMPDファイルである。
さらに、S306において、CPU117は、S301で決定した中心方向を表す方向情報(以下、方向データとする。)を生成する方向情報生成処理を行う。本実施形態の場合、三つの圧縮映像データに応じた三つの送信URLが生成されるため、CPU117は、方向情報生成処理として、それら三つの送信URLに対応した三つの方向データを生成する。
そして、CPU117は、S307において、それら各方向データをそれぞれ対応した送信URLと関連付けて、メタデータに記録する。このS307の後、図3のフローチャートの処理は終了する。その後、このメタデータは、通信回路116からネットワーク103を介して映像受信装置102に送られる。これにより、映像受信装置102は、受信したメタデータに記録されている送信URLと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
<メタデータの概要>
図4は、MPEG-DASHを例とした場合のメタデータ(MPD)の一例を示した図である。なお、MPEG-DASHにおいてメタデータはマニフェストファイルと呼ばれることがあり、図4ではマニフェストファイル401として示している。
図4に示したマニフェストファイル401には、3つのリプリゼンテーション402,403,404が含まれている。リプリゼンテーションは、MPEG-DASHにおいて一つの映像や音声などを状況によって切り替えられるようにする単位である。一番目のリプリゼンテーション402には、映像を取得するためのURLに加えて、direction=“r:0,p:0,y:0”の記述を含んでおり、これが前述のS306で生成された方向データである。方向データは、回転座標系のロール(r)、ピッチ(p)、ヨー(y)の各方向を表すデータを含んでいる。二番目のリプリゼンテーション403も同様に方向データを含んでいる。リプリゼンテーション403の方向データは、ヨー(y)方向のみが120(y:120)となっており、リプリゼンテーション402で示される方向に対しヨー方向(水平方向)に120度回転したものであることを示している。三番目のリプリゼンテーション404も同様に方向データを含んでいる。リプリゼンテーション404の方向データは、ヨー(y)方向のみが220(y:220)となっており、リプリゼンテーション402で示される方向に対しヨー方向に240度回転したものであることを示している。そして、これらリプリゼンテーション402~404の何れの方向データを選ぶかにより、前述した図2B~図2Dの線(y:0)~(y:240)の何れかを中心とした映像の送信を要求するかを決定できることになる。
例えば、図4のマニフェストファイル401を受信した映像受信装置102のユーザが再生表示を望む方向が、例えば図2Bの線(y:0)を中心(r:0,p:0,y:0)とした映像の方向であるとする。この場合、映像受信装置102のCPU121は、direction=“r:0,p:0,y:0”の方向データに対応した、リプリゼンテーション402に記述された送信URLに基づいて、圧縮映像データを取得する。これにより、映像受信装置102では、図2Bの線(y:0)を中心とした正面(r:0,p:0,y:0)の映像の再生表示が可能となる。例えば、再生表示を望む方向が図2Cの線(y:120)を中心とした映像である場合には、direction=“r:0,p:0,y:120”に対応したリプリゼンテーション403の送信URLから圧縮映像データが取得される。これにより、映像受信装置102では、図2Cの線(y:120)を中心とした映像の再生表示が可能となる。
また例えば、再生表示を望む方向が、線(y:0)を正面とした場合の背面、つまり経線の180度(y:180)の方向であるような場合、CPU121は、リプリゼンテーション403又は404の送信URLの何れかを取得する。これは、リプリゼンテーション403による中心の線(y:120)とリプリゼンテーション403による中心の線(y:240)は、経線の180度(y:180)から何れも60度のずれがあり、同等であると考えられるからである。したがって、再生表示を望む方向が180度(y:180)の背面映像に指定された場合、映像受信装置102では、リプリゼンテーション403又は403の何れか選択された送信URLから取得された映像が再生表示されることになる。
なお、再生表示を望む方向が、図2Bの線(y:0)を中心とした映像の方向である場合、水平方向の360度全方位映像の繋ぎ目は、中心の線(y:0)に対して経線で180度分だけずれた位置(正面に対し真後ろの位置)となる。つまりこの場合の繋ぎ目は、映像受信装置102のユーザからみて背面側となるため、ユーザから目につき難くできるメリットがある。また、再生表示を望む方向が180度の線(y:180)を中心とする方向の場合、取得されるのは中心線が線(y:120)又は線(y:240)の映像となる。このため、水平方向の360度全方位映像の繋ぎ目は、180度の線(y:180)から近い方が経線で60度分だけずれた位置となるが、映像の中央からは離れているためユーザから見てさほど目立たないと考えられる。
ここでは、水平方向(ヨー方向)の360度全方位映像の表示を行う場合の映像の繋ぎ目について述べたが、前述したような方向データを記録することによるメリットは、必ずしも繋ぎ目の処理に関するものだけではない。
<パン方向の映像を生成する例>
先に述べたように、正距円筒図法で変換された映像は、球の赤道面から極方向に距離が離れるに従いゆがみが大きくなっていく。このため、例えば線(y:0)を正面(r:0,p:0,y:0)とした映像を用いて、天頂(r:0,p:90,y:0)の映像を得ることは、必ずしも好ましくない。この場合、天頂(r:0,p:90,y:0)の映像が予め生成されているのであれば、この映像を用いて天頂側の映像を再生表示することが望ましい。
したがって、本実施形態では、パン方向(球の緯度方向)についても、前述したヨー方向の場合と同様にして複数の映像データを生成し、また前述同様のメタデータ生成処理も行う。これにより、天頂側でもゆがみの少ない映像を得ることが可能となる。
<映像圧縮ビットレートを変更する例>
さらに本実施形態の他の例として、中心となる線からの距離に応じて映像圧縮のビットレートを変更する例について、前述した図2A~図2Dを流用して説明する。
図2Aや図2Bに示した円筒202は、前述したように、一点鎖線Aが中心となる正距円筒映像である。ここで、映像受信装置102において映像が再生される際に、再生表示を望む方向として、一点鎖線Aが中央になる方向に指定されて映像表示が行われると仮定する。この場合、例えば一点鎖線Bと一点鎖線Cとの間の映像部分、つまり一点鎖線Aの中心部分を正面とした場合の後ろ側に相当する部分の映像は、正面部分の映像よりも重要度が低いと考えられる。すなわち、図2Bの円筒202の場合、例えば太陽の形のオブジェクト204の重要度は高く、星形のオブジェクト205の重要度は低いと考えられる。そして、重要度が低い映像部分については、例えば映像圧縮のビットレートを低くしたとしても、視認性に及ぼす影響は少ないと考えられる。
このため、本実施形態において、映像送信装置101のCPU117は、圧縮符号化回路115を制御し、中心となる線(A)からヨー方向に離れるに従い、映像圧縮のビットレートを例えば低くする。言い換えると、中心となる線に近くなるほど、映像圧縮のビットレートが高くなるようにする。これにより、図2Bの太陽の形のオブジェクト204を含む領域の映像圧縮ビットレートは高く、一方、星型のオブジェクト208を含む慮域の映像圧縮ビットレートは低くなされる。同様に、図2Cの円筒202の場合には、中心となる線(B)から離れるに従い映像圧縮のビットレートが低くなされる。これにより、太陽の形のオブジェクト204を含む領域の映像圧縮ビットレートは低く、星型のオブジェクト208を含む慮域の映像圧縮ビットレートは低くなされる。
また前述したように、映像受信装置102では、線(y:0)を正面とした映像の再生表示がなされる場合には、図4のリプリゼンテーション402に記述された送信URLを基に映像データが取得される。また、線(y:120)を中心とした映像の再生表示がなされる場合には、図4のリプリゼンテーション403に記述された送信URLを基に映像データが取得される。ここで、前述のように中心の線に近いほど映像圧縮ビットレートが高くなる制御が行われているため、それら何れの場合も、中央部の映像は画質劣化が少ない映像となり、ユーザは視認性の良い映像を鑑賞できる。一方で、中心の線から離れるほど映像圧縮ビットレートが低くなる制御が行われているため、映像データを取得する際の伝送ビットレートが全体として低く保たれることになる。
<回転座標系以外の記述例>
前述した説明では、方向データとして、例えば(r:0,p:0,y:0)のような回転座標系で表される情報を用いた例を挙げた。ここで、このような回転座標系の情報は、例えば正規化された直交座標系の情報に容易に変換することができる。すなわち、回転座標系の方向データ(r:0,p:0,y:0)は、(x,y,z)=(0,0,0)のような直交座標系の方向データとして記述されてもよい。
或いは、方向データは、図4の一番目のリプリゼンテーション402やその他の所定の方向を基準として、相対角による表される方向データとして記述されても良い。例えば(r:0,p:0,y:0)を正面とした映像に対して、後ろ側(r:0,p:0,y:180)のようにして方向を示す代わりに、(yaw+180)といった記述例も考えられる。方向データとしてこれら何れの記述形式を用いるかは、本実施形態が適用されるシステムに応じて適宜設定可能である。
以上説明したように、第1実施形態においては、メタデータを用いて映像の場所(送信URL)を特定する形式において、全方位映像等の広視野映像から方向を変えて生成した複数の映像と各方向データとを関連付けてメタデータに記述する。したがって、映像受信装置102は、メタデータに記述された送信URLと方向データを参照することにより、全方位画像等の広視野映像のなかで、再生表示したい方向に応じた好適な映像を取得可能となる。
<<第2実施形態>>
第1実施形態では、360度映像を正距円筒映像へと変換する例を挙げた。以下の第2実施形態では、360度映像を立方体(Cubic)の形式に変換する例を説明する。第2実施形態における映像送信装置101、映像受信装置102等の構成は、図1と同様であるため、図示は省略する。
第2実施形態の場合、映像送信装置101の画像信号処理回路114は、前述した360度映像を後述するように立方体の形式に変換し、さらに当該立方体を展開して立方体展開映像を生成する。そして、圧縮符号化回路115は、画像信号処理回路114により立方体を展開した立方体展開映像の映像データから、MPEG-DASHに準拠した圧縮映像データを生成する。また、CPU117は、立方体展開映像に関するメタデータ生成処理を行う。第2実施形態の場合のメタデータに記述される方向データの詳細は後述する。そして、第2実施形態の映像受信装置102は、メタデータに含まれる送信URLと方向データに基づき、MPEG-DASHに準拠した映像データを取得して表示部126に表示する。
以下、第2実施形態において360度映像を立方体の形式に変換して立方体展開映像を生成する例について、図5A~図5D、及び前述の図3のフローチャートを流用して説明する。
図5Aにおいて、球状の仮想的な映像面201は、前述同様に、その中心部に位置する360度カメラから見た360度映像を表している。太陽の形のオブジェクト203、星形のオブジェクト205についても前述同様のものである。第2実施形態の場合、球状の仮想的な映像面201は、立方体501に投影される。図5Bは、図5Aの立方体501の面cを中心に展開した立方体投影映像502を示した図である。また、図5Bのオブジェクト204,208は、立方体投影映像502上に映っている図5Aのオブジェクト203、205を表している。なおこの例では、立方体投影映像502は、面cを中心にして展開した形になっているが、例えば面bが面cを挟んで面aの左側に、面eが面aの右側に置かれるように展開して、横に3/4、縦に2/3の大きさの矩形とされても良い。
図5Cには、図5Aの立方体501の面aを中心に展開した立方体投影映像503を示している。別な表現をするならば、図5Bの立方体投影映像502は手前の太陽の形のオブジェクト204を中心としているのに対し、図5Cの立方体投影映像503では立方体の上側の面aを中心とした例である。そして、第2実施形態において、これら図5Bの立方体投影映像502や図5Cの立方体投影映像503の映像データも前述同様に圧縮符号化されることになる。なお、立方体501の展開方法はこれらの例に限定されない。
ここで、図5Bの立方体投影映像502の場合、中心領域である面cを高画質化し、それ以外の周辺領域の面(a,b,d,e,f)は符号量を低下させる(画質を落とす)ように、画像の特徴を異ならせるとする。すなわち、図5Bの例の場合、映像送信装置101のCPU117は、立方体投影映像502に描かれた円505の中の領域が高画質となるように圧縮符号化回路115を制御する。図5Cの立方体投影映像503についても同様とする。これにより、太陽の形のオブジェクト204を中心に考えた場合、図5Bの立方体投影映像502を圧縮符号化した映像データを映像受信装置102で再生表示した場合、高画質のオブジェクト204の表示が可能となる。一方、映像受信装置102で再生表示する際に面aを中心に考えた場合、図5Cの立方体投影映像503を圧縮符号化した映像データを再生表示すれば、面aが高画質となった映像の表示が可能となる。
なお、図5Dの立方体投影映像504は図5Cの立方体投影映像502と同じ面の配置であり、この図5Cの例は高画質化する領域を表す円505の配置が、図5Bとは異なるだけであり、同様に処理を行うことができる。図5Dの立方体投影映像504の場合、円505で示される高画質化される領域は、面aと面cの一部だけでなく、立方体において面aとそれぞれ接する面d、面f、面eの一部も含まれることになる。
また、立方体投影映像502~504の図中斜線の部分は映像が存在しないため、例えばスキップドマクロブロック(skipped macroblock)として符号化しないことで、大幅な符号量削減が可能となる。このようなことにより、第2実施形態では、ネットワーク103の全体としての通信量を下げながら、所定の面を高画質化した映像を映像受信装置102に対して送信することが可能となる。
第2実施形態において、変換された立方体投影映像を圧縮符号化して伝送する際の流れは、前述した図3のフローチャートと概ね同様である。ただし、第2実施形態の場合、360度映像を立方体投影映像に変換し、立方体投影映像と中心或いは高画質化等する所定の面とを関連付けた送信URLがメタデータに記録される。
第2実施形態の場合、図3のS301において、映像送信装置101のCPU117は、360度映像を立方体投影映像へと展開する際の中心或いは高画質化等する所定の面を複数決定する。ここで決定される複数の所定の面は、例えば前述したような図5Bの面cや図5Cの面a、図5Dの面a等である。
次に、S302において、CPU117は、画像信号処理回路114を制御し、前述した360度映像から、S301で中心面として決定された面を中心とした立方体投影映像をそれぞれ生成する。
さらに、S303において、CPU117は、圧縮符号化回路115を制御し、S302で生成した各立方体投影映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路115からは、各立方体投影映像にそれぞれ対応した圧縮映像データが生成される。このとき、S301で高画質化するとして決定された面(円505に対応した円)については、圧縮符号化の際に前述するように高画質化の処理が行われる。そして、これら各立方体投影映像の各圧縮映像データは、映像受信装置102からの要求があった場合に、当該映像受信装置102へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置102へ送信可能な場所にコピー等される。
次に、CPU117は、S304において、それぞれ圧縮映像データの場所を表すアドレス情報である送信URLを決定し、さらにS305において、それら圧縮映像データにそれぞれ対応した送信URLをメタデータに記録する。
さらに、CPU117は、S306において、S301で中心或いは高画質化するものとして決定された所定の面を表す方向データを生成する。すなわち、第2実施形態の場合の方向データは、例えば図5Aの映像面201の360度映像を立方体に投影した際の各面のうち、中心或いは高画質化される所定の面を表すデータとなされる。そして、CPU117は、S307において、それら各方向データをそれぞれ対応した送信URLと関連付けて、メタデータに記録する。
第2実施形態においても、このメタデータは、通信回路116からネットワーク103を介して映像受信装置102に送られる。これにより、第2実施形態の映像受信装置102は、受信したメタデータに記録されている送信URLと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
<第2実施形態の場合のメタデータの概要>
図6は、第2実施形態において、MPEG-DASHを例としたメタデータの一例を示した図である。図6においても前述した図4と同様に、MPEG-DASHにおけるメタデータをマニフェストファイル601として示している。
図6のマニフェストファイル601には、第1実施形態で説明したのと同様に、三つのリプリゼンテーション603,604,605が含まれている。第2実施形態の場合、第1実施形態とは異なり、図3のS306で生成された方向データであるdirection=“r:0,p:0,y:0”といった記述が別途予め定義されている。ここでは、これをマップ602と呼ぶものとする。もちろん、このようなマップを使用せずに第1実施形態の例と同様に記述されていてもよい。マップ602には、さらにview=“tp”といった記述も含まれている。これは、例えばdirection=“r:0,p:90,y:0”が上の方向を意味していることを、記号として記述したものである。また例えば、view=“fr”が前面、view=“bk”が背面のように方向を予め記号などで決めておくことで、より簡易に方向を示すことも可能となる。
図6において一番目のリプリゼンテーション603には、映像を取得するためのURLに加えてdir_id=“c”の記述が含まれている。これは、マップ602におけるrpy_mapping dir_id=“c”を参照するよう指示するものである。このようにすることによって、リプリゼンテーションの記載を簡略化したり、柔軟な方向データ記載を可能としたりすることが可能となる。詳細な説明は省略するが、リプリゼンテーション604やリプリゼンテーション605も同様である。また、図6のような方向データの記述は、投影手法に依存せずに適用可能である。
前述したように、第2実施形態の映像送信装置101においては、360度映像を立方体投影映像に変換し、投影された所定の面を表す方向データをメタデータに記述する。これにより、第2実施形態の映像受信装置102においても、メタデータを基に、再生表示したい方向に応じた好適な映像を取得可能となる。
<<第3実施形態>>
前述した第1実施形態において、図2A~図2Dを用いて説明した360度映像を正距円筒映像へと変換する例は、円筒202の一部を用いて全周とならない映像を生成する場合にも適用可能である。第3実施形態は、円筒202の一部を用いて全周とならない映像を生成する場合の適用例である。
第3の実施形態では、円筒202の一部の全周とならない映像として、240度映像を生成する例を図7A~図7Dを用いて説明する。
図7Aは、前述した図2Aと同様に、球状の仮想的な映像面201と、その中心部に位置する360度カメラから見た映像とを表しており、円筒202は映像面201を正距円筒図法で変換した映像である。また、円筒202上の一点鎖線A,B,Cは、前述同様に球面での経線にあたる線である。
図7Bは、図7Aの映像面201を正距円筒図法へと変換し、一点鎖線A(線(y:0))を中心線として円筒202から240度分を切り出した部分円筒映像701を表している。同様に、図7Cは一点鎖線B(線(y:120))を中心線とし、図7Dは一点鎖線C(線(y:240))を中心線として、円筒202からそれぞれ240度分を切り出した部分円筒映像702,703を表している。
これら図7B~図7Dのようにそれぞれ異なる中心線により240度分だけ切り出されたことで、例えば部分円筒映像702と703の中には部分円筒映像701に含まれていない映像部分が存在することになる。同様に、部分円筒映像701と703の中には部分円筒映像702に含まれていない映像部分が、部分円筒映像701と702の中には部分円筒映像703に含まれていない映像部分が、それぞれ存在することになる。すなわち例えば、映像受信装置102で部分円筒映像701により太陽の形のオブジェクト203を鑑賞するような場合、その投影されたオブジェクト204は鑑賞できるが、星形のオブジェクト205の投影されたオブジェクト208は鑑賞できない。但し、映像受信装置102が例えばHMDであるような場合、HMDの装着者が例えば一定方向を見ている場合には、その反対側の映像は不要であることから、映像の一部が含まれていない場合でもさほど問題は生じないと考えられる。したがって、第3実施形態の場合も、前述の図4のマニフェストファイル401で示したように、方向データを用いて最適なリプリゼンテーションを取得すれば良い。
図8には、第3実施形態におけるメタデータの一例としてのマニフェストファイルの記述例を示している。第3実施形態においても前述したマニフェストファイル401を適用することは可能であるが、図8のマニフェストファイルには、さらにrange=“y:240”が記述されている。このように記述することで、図8のマニフェストファイルを参照した映像受信装置102は、対応するリプリゼンテーションがヨーの方向で240度の角度の映像を保持していることを知ることができる。なお、第3実施形態の場合においても、言うまでもなくロール方向やピッチ方向などを同時に用いてもよい。
前述したように、第3実施形態においては、円筒202の一部の全周とならない映像データが伝送されることになるため、伝送ビットレートを更に低減することが可能となる。また、第3実施形態においても第1実施形態の場合と同様に、中心の線に対応する中心領域の映像圧縮ビットレートを高くし、周辺領域の映像圧縮ビットレートを低くしてもよい。
<<第4実施形態>>
前述した第1~第3実施形態では、MPEG-DASH及びマニフェストファイルの例を用いて説明を行ってきた。第4実施形態では、このマニフェストファイルの異なる例を挙げる。図9は、図4を用いて説明したマニフェストファイルのさらに別な例を表した図である。
図9に示したマニフェストファイル901は、一見図4で説明したマニフェストファイル401と似た構造を持っている。しかしながら、図9のマニフェストファイル901の場合、一番目のリプリゼンテーション902のSegmentURLには、track=“1”及びtrack=“2”が追記されている。これは、それぞれ、video31.mp4およびvideo32.mp4の指定されたtrack(トラック)を参照することを示している。すなわち、direction=“r:0,p:0,y:0”が指定されたリプリゼンテーション902は、SebmentURLで指定されたメディアファイルの特定のトラックを取得することを意図して記載されている。
ここで、トラックについて簡単に説明する。この例では、メディアファイルは、ファイルの拡張子から想定できるように、ISOBMFF(ISO/IEC 14496-12)を基礎としたファイル形式のメディアデータとなっている。このようなファイルでは、トラックと呼ばれる複数のメディアを格納する仕組みを備えている。すなわち、リプリゼンテーション902は、指定されたファイルの指定されたトラックに格納されたメディアファイル(メディアデータ)を用いることで、方向に合致したメディアを得るよう記載されている。連続した二つのメディアファイルが異なるトラックを指定しているのは、それぞれのメディアファイルが独立しており、異なるトラックに方向に合致したメディアが格納されていることを仮定しているためである。
一方、リプリゼンテーション903およびリプリゼンテーション904では、direction=“r:0,p:0,y:120”のような方向の記載の後に、track=“1”及びtrack=“2”のような記載がある。また、リプリゼンテーション903及びリプリゼンテーション904のメディアデータは、同じものを指示している。すなわち、リプリゼンテーション903及びリプリゼンテーション904は、同じメディアデータを参照する。ここでは連続したメディアデータに共通のトラックが指定されているため、例えばリプリゼンテーション903では、同じトラックのtrack=“1”が連続したメディアデータに適用される。第3実施形態によれば、このようにすることで、同じメディアデータを用いながら方向を記載することができる。
<<その他の実施形態>>
以上、これまでMPEG-DASHを例として説明してきたが、本実施形態は、MPEG-DASHに限らず、メタデータファイルとメディアファイルを組み合わせて映像を送信・受信するシステムにも適用できる。例えば、HTTP live Streamingと通称される形式では、マニフェストファイルにm3uと呼ばれる形式を採用している。ここでは、同様にメディアデータの取得位置を記録するが、これに例えばdirection=“r:0,p:0,y:120”といった方向データを付加情報として追記することで前述同様のことを実現可能となる。
また、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体(記憶媒体)等としての実施態様をとることが可能である。具体的には、複数の機器(例えば、ホストコンピュータ、インタフェース機器、撮像装置、Webアプリケーション等)から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、複数の分散した仮想コンピュータ群からなるクラウドシステムであってもよい。 
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
上述の実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明は、その技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である、従って、本発明の範囲を公にするために以下の請求項を添付する。
本願は、2017年12月27日提出の日本国特許出願特願2017-251208を基礎として優先権を主張するものであり、その記載内容の全てをここに援用する。
101:映像送信装置
102:映像受信装置
103:ネットワーク
114:映像信号処理回路
117:CPU

Claims (17)

  1. 第1の映像から二つ以上の異なる方向に対応した二つ以上の第2の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成手段と、
    受信装置が前記第2の映像を取得する際に用いられるアドレス情報を生成するアドレス生成手段と、
    前記二つ以上の前記第2の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成手段と、
    を有することを特徴とする情報処理装置。
  2. 前記メタデータを前記受信装置に送信する送信手段を更に有することを特徴とする請求項1に記載の情報処理装置。
  3. 前記第1の映像から前記二つ以上の異なる方向に対応した前記二つ以上の前記第2の映像を生成する映像生成手段を更に有することを特徴とする請求項1または2に記載の情報処理装置。
  4. 前記映像生成手段は、前記第1の映像から、画像の特徴が異なる前記二つ以上の前記第2の映像を生成することを特徴とする請求項3に記載の情報処理装置。
  5. 前記映像生成手段は、前記第1の映像から、それぞれ中心が異なる前記二つ以上の前記第2の映像を生成することを特徴とする請求項3または4に記載の情報処理装置。
  6. 前記映像生成手段は、前記二つ以上の前記第2の映像に対し、前記方向に応じた所定の処理を行うことを特徴とする請求項4または5に記載の情報処理装置。
  7. 前記映像生成手段は、前記方向に応じて映像圧縮のビットレートを変える前記所定の処理を行うことを特徴とする請求項6に記載の情報処理装置。
  8. 前記映像生成手段は、前記方向に応じて画質を変える前記所定の処理を行うことを特徴とする請求項6に記載の情報処理装置。
  9. 前記映像生成手段は、更に映像の中心領域と周辺領域とで異なる画質となるように前記所定の処理を行うことを特徴とする請求項8に記載の情報処理装置。
  10. 前記二つ以上の前記第2の映像が生成される際の前記第1の映像は360度全方位映像であり、
    前記映像生成手段は、前記二つ以上の第2の映像として、前記360度全方位映像から二つ以上の正距円筒映像を生成することを特徴とする請求項3から9のいずれか1項に記載の情報処理装置。
  11. 前記二つ以上の前記第2の映像が生成される際の前記第1の映像は360度全方位映像であり、
    前記映像生成手段は、前記二つ以上の第2の映像として、前記360度全方位映像から二つ以上の立方体投影映像を生成することを特徴とする請求項3から9のいずれか1項に記載の情報処理装置。
  12. 前記方向情報生成手段は、回転座標系のロール、ピッチ、ヨーの各方向を表す方向情報を生成することを特徴とする請求項1から11のいずれか1項に記載の情報処理装置。
  13. 前記方向情報生成手段は、予め定めた方向を表す記号を前記方向情報として用いることを特徴とする請求項1から12のいずれか1項に記載の情報処理装置。
  14. 前記アドレス情報は、URL、もしくはURLにより特定されるメディアファイルの一部を特定する情報の組み合わせであることを特徴とする請求項1から13のいずれか1項に記載の情報処理装置。
  15. 請求項1から14のいずれか1項に記載の情報処理装置を備える送信装置と、
    前記情報処理装置により生成された前記メタデータの前記アドレス情報および前記方向情報を基に、前記第2の映像を取得する前記受信装置と、
    を有することを特徴とするシステム。
  16. 情報処理装置が実行する情報処理方法であって、
    第1の映像から二つ以上の異なる方向に対応した二つ以上の第2の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成工程と、
    受信装置が前記第2の映像を取得する際に用いられるアドレス情報を生成するアドレス生成工程と、
    前記二つ以上の前記第2の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成工程と、
    を有することを特徴とする情報処理方法。
  17. コンピュータを、請求項1から15のいずれか1項に記載の情報処理装置の各手段として機能させるためのプログラム。
PCT/JP2018/047434 2017-12-27 2018-12-25 情報処理装置、情報処理方法、及びプログラム WO2019131577A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/911,146 US20200329266A1 (en) 2017-12-27 2020-06-24 Information processing apparatus, method for processing information, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-251208 2017-12-27
JP2017251208A JP2019118026A (ja) 2017-12-27 2017-12-27 情報処理装置、情報処理方法、及びプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/911,146 Continuation US20200329266A1 (en) 2017-12-27 2020-06-24 Information processing apparatus, method for processing information, and storage medium

Publications (1)

Publication Number Publication Date
WO2019131577A1 true WO2019131577A1 (ja) 2019-07-04

Family

ID=67063637

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/047434 WO2019131577A1 (ja) 2017-12-27 2018-12-25 情報処理装置、情報処理方法、及びプログラム

Country Status (3)

Country Link
US (1) US20200329266A1 (ja)
JP (1) JP2019118026A (ja)
WO (1) WO2019131577A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11816757B1 (en) * 2019-12-11 2023-11-14 Meta Platforms Technologies, Llc Device-side capture of data representative of an artificial reality environment
CN111666451B (zh) * 2020-05-21 2023-06-23 北京梧桐车联科技有限责任公司 路书展示方法、装置、服务器、终端及存储介质
CN112689088A (zh) * 2020-12-21 2021-04-20 维沃移动通信(杭州)有限公司 图像显示方法、装置和电子设备
US11099709B1 (en) 2021-04-13 2021-08-24 Dapper Labs Inc. System and method for creating, managing, and displaying an interactive display for 3D digital collectibles
US11210844B1 (en) 2021-04-13 2021-12-28 Dapper Labs Inc. System and method for creating, managing, and displaying 3D digital collectibles
USD991271S1 (en) 2021-04-30 2023-07-04 Dapper Labs, Inc. Display screen with an animated graphical user interface
US11227010B1 (en) 2021-05-03 2022-01-18 Dapper Labs Inc. System and method for creating, managing, and displaying user owned collections of 3D digital collectibles
US11170582B1 (en) 2021-05-04 2021-11-09 Dapper Labs Inc. System and method for creating, managing, and displaying limited edition, serialized 3D digital collectibles with visual indicators of rarity classifications
US11533467B2 (en) * 2021-05-04 2022-12-20 Dapper Labs, Inc. System and method for creating, managing, and displaying 3D digital collectibles with overlay display elements and surrounding structure display elements

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017202700A1 (en) * 2016-05-23 2017-11-30 Canon Kabushiki Kaisha Method, device, and computer program for improving streaming of virtual reality media content

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190021229A (ko) * 2016-05-26 2019-03-05 브이아이디 스케일, 인크. 뷰포트 적응형 360도 비디오 전달의 방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017202700A1 (en) * 2016-05-23 2017-11-30 Canon Kabushiki Kaisha Method, device, and computer program for improving streaming of virtual reality media content

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
K. KAMMACHI SREEDHAR ET AL.: "AHG8: Test results for viewport- dependent pyramid, cube map, and equirectangular panorama schemes", JVET-D0078, ITU-T, 6 October 2016 (2016-10-06), Retrieved from the Internet <URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/4_Chengdu/wgll/JVET-D0078-vl.zip> *

Also Published As

Publication number Publication date
JP2019118026A (ja) 2019-07-18
US20200329266A1 (en) 2020-10-15

Similar Documents

Publication Publication Date Title
WO2019131577A1 (ja) 情報処理装置、情報処理方法、及びプログラム
JP7009605B2 (ja) パノラマビデオのための提案されるビューポート指示
EP3466083B1 (en) Spatially tiled omnidirectional video streaming
CN112204993B (zh) 使用重叠的被分区的分段的自适应全景视频流式传输
US10939068B2 (en) Image capturing device, image capturing system, image processing method, and recording medium
JP3992045B2 (ja) 映像信号処理装置及び該方法並びに仮想現実感生成装置
US11539983B2 (en) Virtual reality video transmission method, client device and server
JP7218826B2 (ja) 再生装置および画像生成方法
JP4622570B2 (ja) 仮想現実感生成装置およびそれに用いられるプログラム
JP7217226B2 (ja) グローバルな回転における動き補償画像を符号化する方法、デバイス及びストリーム
JP6860485B2 (ja) 情報処理装置、および情報処理方法、並びにプログラム
CA3043247A1 (en) Methods, devices and stream to provide indication of mapping of omnidirectional images
JP7243631B2 (ja) 再生装置および方法、並びに、生成装置および方法
WO2018221211A1 (ja) 画像処理装置および方法、ファイル生成装置および方法、並びにプログラム
TW201943284A (zh) 資訊處理裝置、方法、及程式
US20230018560A1 (en) Virtual Reality Systems and Methods
JP2008510357A (ja) 画像のエンコーディング方法、エンコーディング装置、画像のデコーディング方法及びデコーディング装置
JP2020145590A (ja) 画像処理システム、画像処理方法及びプログラム
JP7415544B2 (ja) 撮影システム及び撮影方法
KR20210064654A (ko) 360도 3차원 영상 재생시스템
JP2021033354A (ja) 通信装置およびその制御方法
KR101773929B1 (ko) 광 시야각 영상 처리 시스템, 광 시야각 영상의 전송 및 재생 방법, 및 이를 위한 컴퓨터 프로그램
US20210289194A1 (en) System, method, and computer program for generating volumetric video
JP2020162118A (ja) 撮影装置、撮影システム、画像処理方法、及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18894245

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18894245

Country of ref document: EP

Kind code of ref document: A1