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

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing 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/234327—Processing 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/74—Browsing; Visualisation therefor
    • G06F16/745—Browsing; Visualisation therefor the internal structure of a single video sequence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/78—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/7867—Retrieval 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing 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/234345—Processing 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management 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/262—Content 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/26258—Content 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-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/47202—End-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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring 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

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

Description

情報処理装置、情報処理方法、及びプログラム
本発明は、映像データ等に関するメタデータを扱う技術に関する。
近年、ＨＴＴＰを代表とするＷｅｂ技術を用いて映像データを送信し、Ｗｅｂブラウザを用いてこの映像を再生する映像ストリーミング技術が広く使われるようになっている。特に広く使われる技術の特徴の一つは、送信しようとする映像データに関するメタデータを先に交換し、このメタデータを用いて実際の映像データを受信装置から送信装置に要求する形式である。
このような形式において、映像データの解像度への要求の高まりと共に、高解像度映像の特定部分を取得する方法が提案されている。
従来、例えば映像データから映像の特定位置部分を空間的に切り出して送信するメタデータの記載方法として、ＭＰＥＧ－ＤＡＳＨ　ＳＲＤ仕様があり、これは例えば非特許文献１に開示されている。なお、メタデータには、全方位映像等の映像全体に対する相対位置と切り出される矩形映像のサイズとを記述することが可能となされている。また、例えば魚眼画像のような全方位画像を視覚的に見やすいパノラマ展開画像として再生する際に、容易に方向を特定するために、基準となる方向をメタデータとして映像に付随させる方法があり、これは特許文献１等に開示されている。その他にも、全方位映像等から、中央位置や主要な位置を変えた複数の映像を生成する技術も知られている。
特開２０１３－２７０１２号公報
ＩＳＯ／ＩＥＣ　２３００９－１：２０１４／Ａｍｄ２：２０１５
ところで、受信装置側では、前述したメタデータの記述を基に映像データの配信を要求する際、全方位映像等の映像全体から切り出し等された矩形映像が、その全方位映像の中の何れの方向に相当する映像であるのかを知ることができない。このため、受信装置は、全方位映像の中で表示したい方向の映像の配信を要求することが難しい。
そこで、本発明は、受信装置側で映像の方向を適切に知ることができるようにすること目的とする。
本発明は、第１の映像から二つ以上の異なる方向に対応した二つ以上の第２の映像が生成された際の、前記二つ以上の方向を表す方向情報を生成する方向情報生成手段と、受信装置が前記第２の映像を取得する際に用いられるアドレス情報を生成するアドレス生成手段と、前記二つ以上の前記第２の映像と前記アドレス情報および前記方向情報とをそれぞれ関連付けたメタデータを生成するメタデータ生成手段と、を有することを特徴とする。 
本発明によれば、受信装置側で映像の方向を適切に知ることができるようになる。
本実施形態の情報処理システムの構成を示すブロック図である。 ３６０度映像を正距円筒映像へと変換する例を示す図である。 ３６０度映像を正距円筒映像へと変換する例を示す図である。 ３６０度映像を正距円筒映像へと変換する例を示す図である。 ３６０度映像を正距円筒映像へと変換する例を示す図である。 映像の変換から伝送までの流れを示すフローチャートである。 ＭＰＥＧ－ＤＡＳＨを例としたメタデータの例を示す図である。 ３６０度映像を立方体へと変換した例を示す図である。 ３６０度映像を立方体へと変換した例を示す図である。 ３６０度映像を立方体へと変換した例を示す図である。 ３６０度映像を立方体へと変換した例を示す図である。 ＭＰＥＧ－ＤＡＳＨを例としたメタデータの他の例を示す図である。 円筒から２４０度映像を生成する例を示す図である。 円筒から２４０度映像を生成する例を示す図である。 円筒から２４０度映像を生成する例を示す図である。 円筒から２４０度映像を生成する例を示す図である。 マニフェストファイルの他の例を示す図である。 マニフェストファイルのさらに他の例を示す図である。
以下、本発明の実施形態を添付の図面を参照して詳細に説明する。なお、以下に説明する実施形態は、本発明を具体的に実施した場合の一例を示すものであり、本発明は以下の実施形態に限定されるものではない。
＜＜第１実施形態＞＞
図１は、第１実施形態の映像送信装置１０１と映像受信装置１０２を有する情報処理システムの構成例を示す図である。
映像送信装置１０１は、映像データを、ネットワーク１０３を介して送信可能な情報処理装置である。映像受信装置１０２は、映像データを、ネットワーク１０３を介して受信可能な情報処理装置である。本実施形態では、一例としてＭＰＥＧ－ＤＡＳＨを用いた映像ストリーミング送信を行う例を挙げる。詳細については後述するが、映像送信装置１０１は、ＭＰＥＧ－ＤＡＳＨに準拠した映像データを生成するような映像生成処理を行い、また、送信する映像に関するメタデータを生成して送信可能となされている。映像受信装置１０２は、先に取得したメタデータを用いて、ＭＰＥＧ－ＤＡＳＨに準拠した映像データの配信を要求可能となされている。なお、映像送信装置１０１により生成された映像データは、映像受信装置１０２からの要求に応じて送信されるが、例えばＷｅｂサーバ１０４に蓄積された後に映像受信装置１０２へ配信されてもよい。
映像送信装置１０１は、通信機能を備えたカメラとして実現してもよいし、必要に応じて一つ以上のコンピュータ装置により実現するようにしてもよい。本実施形態では、一例として、二つの魚眼レンズ１１１を備えた全方位カメラを備えた映像送信装置１０１を挙げている。
映像受信装置１０２は、通信機能を備えたテレビジョン受像機といった専用装置として実現してもよいし、必要に応じて一つ以上のコンピュータからなる装置として実現するようにしてもよい。また、映像受信装置１０２は、ヘッドマウントディスプレイ（ＨＭＤ）などで実現されてもよい。本実施形態では、コンピュータとそこで動作する映像再生アプリケーションプログラム（以下、映像再生アプリとする。）により映像受信装置１０２の機能を実現する例を挙げる。
図１において、映像送信装置１０１では、魚眼レンズ１１１から取り込まれた光が光学センサ１１２により電気信号に変換され、さらにＡ／Ｄコンバータ１１３によりデジタル化されて画像信号処理回路１１４で映像としての処理が行われる。なお、本実施形態の映像送信装置１０１は、魚眼レンズ１１１と光学センサ１１２の撮像系の組み合わせを二組備えている。本実施形態では、二組の撮像系のうち、一方が１８０度の画角で空間領域を撮像し、もう一方が隣接する１８０度の画角で空間領域を撮像することで、全方位の３６０度映像を取得可能としている。Ａ／Ｄコンバータ１１３は、二つの光学センサ１１２に対応して物理的に二つ設けられているが、図１では図示の簡略化のために一つだけを記載している。
このように二組の撮像系によりそれぞれ取得された画角１８０度の魚眼画像の信号は、画像信号処理回路１１４に送られる。画像信号処理回路１１４は、二組の撮像系にて取得された１８０度魚眼画像から３６０度全方位映像を生成し、その３６０度映像を後述する正距円筒図法（Equirectangular）と呼ばれる形式の映像に変換する。圧縮符号化回路１１５は、画像信号処理回路１１４により正距円筒図法の形式に変換された３６０度映像データから、ＭＰＥＧ－ＤＡＳＨに準拠した圧縮映像データを生成する。本実施形態の場合、圧縮符号化回路１１５で生成された圧縮映像データは、例えばメモリ１１９に一時的に保持され、映像受信装置１０２からの送信要求に応じて通信回路１１６からネットワーク１０３に出力される。なお、圧縮符号化回路１１５で生成された圧縮映像データは、Ｗｅｂサーバ１０４等に蓄積された後、映像受信装置１０２等からの要求に応じてＷｅｂサーバ１０４から配信されてもよい。
ＲＯＭ１１８は、変更を必要としないプログラムやパラメータを格納するリードオンリメモリである。メモリ１１９は、外部装置などから供給されるプログラムやデータを一時記憶するＲＡＭ（ランダムアクセスメモリ）である。ＣＰＵ１１７は、映像送信装置１０１全体を制御する中央処理ユニットであり、例えばＲＯＭ１１８から読み出されてメモリ１１９に展開された本実施形態に係るプログラムを実行する。また、ＣＰＵ１１７は、プログラムの実行により、映像データに関するメタデータを生成する処理も行う。本実施形態の場合、詳細は後述するが、メタデータには、送信される映像に関する送信ＵＲＬと方向データが含まれる。なお、図示は省略しているが、映像送信装置１０１は、映像データを記録するなどの目的で、着脱可能な半導体メモリ等の記憶メディアとその記憶メディアの書込み／読出し装置等を備えていてもよい。
映像受信装置１０２は、コンピュータ等からなり、ＣＰＵ１２１、通信Ｉ／Ｆ部１２２、ＲＯＭ１２３、ＲＡＭ１２４、操作部１２５、表示部１２６、大容量記憶部１２７等を有する。
通信Ｉ／Ｆ部１２２は、ネットワーク１０３を介してＷｅｂサーバ１０４や映像送信装置１０１等と通信可能となされている。本実施形態の場合、通信Ｉ／Ｆ部１２２は、前述したメタデータの受信、映像ストリーミングの圧縮映像データの配信要求の送信、当該配信要求に応じて配信された圧縮映像データの受信等を行う。
ＲＯＭ１２３は、各種プログラムやパラメータを格納し、ＲＡＭ１２４はプログラムやデータを一時記憶する。大容量記憶部１２７はハードディスクドライブやソリッドステートドライブであり、通信Ｉ／Ｆ部１２２により受信された圧縮映像データや、映像再生アプリ等を記憶可能となされている。ＣＰＵ１２１は、大容量記憶部１２７から読み出されてＲＡＭ１２４に展開された映像再生アプリ等を実行する。本実施形態の場合、ＣＰＵ１２１は、映像再生アプリの実行により、先に取得したメタデータに含まれる後述する送信ＵＲＬに基づき、ＭＰＥＧ－ＤＡＳＨに準拠した映像データの取得を行わせるように各部を制御する。そして、圧縮映像データを取得すると、ＣＰＵ１２１は、その圧縮映像データを伸張復号化して、表示部１２６に送る。表示部１２６は、液晶等のディスプレイ装置を有し、ＣＰＵ１２１により伸張復号化された映像データに基づく映像を表示する。操作部１２５は、ユーザが指示等を入力する際のマウスやキーボード、タッチパネル等を有し、ユーザからの指示入力をＣＰＵ１２１に出力する。なお、映像受信装置１０２がＨＭＤである場合には、姿勢変化を検出可能なセンサ等も有する。
＜正距円筒図法の概要説明＞
本実施形態では、映像送信装置１０１の画像信号処理回路１１４において、３６０度映像を正距円筒映像へと変換する例を挙げている。３６０度映像を正距円筒映像へと変換しているのは、一般的な矩形映像を生成することで映像圧縮や表示が行い易くなるといった理由からである。なお、画像信号処理回路１１４では、後述する第２実施形態で説明するような正立方体へ投影（Cubic Projection）する変換処理が行われても良いし、さらに後述する第３実施形態等のような他の変換処理が行われてもよい。また本実施形態では、二つの魚眼レンズ１１１からなる全方位カメラを例示したが、一般的なレンズを多数組み合わせた全方位カメラでも良いし、一つの魚眼レンズ１１１のみで画角１８０度を撮影する１８０度カメラでもよい。なお、１８０度カメラを用いた場合には、レンズを例えば天空（上方向）に向けたときには下方向の画角１８０度分が撮像されない映像となるだけである。
ここで、３６０度映像を正距円筒映像へと変換する例について、後の説明をより明確にするため、図２Ａ～図２Ｄを用いてもう少し説明を行う。
図２Ａにおいて、球状の仮想的な映像面２０１は、その中心部に位置する３６０度カメラから見た３６０度映像を表し、映像面２０１を包み込む円筒２０２は、球状の仮想的な映像面２０１を正距円筒映像へと変換した面を表している。円筒２０２上の一点鎖線Ａ，Ｂ，Ｃは、球面での経線にあたる線を表している。球状の映像面２０１における回転座標系の方向をロール（ｒ）、ピッチ（ｐ）、ヨー（ｙ）の各方向で表した場合に、一点鎖線Ａは、ヨー方向の角度０度で表される経線にあたる線（ｙ：０）である。同様に、一点鎖線Ｂはヨー方向の角度１２０度で表される経線にあたる線（ｙ：１２０）、一点鎖線Ｃはヨー方向の角度２４０度で表される経線にあたる線（ｙ：２４０）である。
図２Ｂ～図２Ｄは、３６０度映像である図２Ａの球状の仮想的な映像面２０１を、正距円筒映像へと変換した例を示した図である。
図２Ｂは、図２Ａの映像面２０１を正距円筒映像へと変換し、ヨー方向の角度０度の経線にあたる一点鎖線Ａ（線（ｙ：０））を中心線として、円筒２０２を展開した映像を表している。なお、この図２Ｂに示した正距円筒映像は、映像受信装置１０２において表示が行われる際に、例えば水平方向の両端部が繋がれた場合、水平方向３６０度の全方位映像としての表示が可能となる。
また、図２Ｃは、ヨー方向の角度１２０度の経線にあたる一点鎖線Ｂ（線（ｙ：１２０））を中心として円筒２０２を展開した正距円筒映像である。同様に、図２Ｄは、ヨー方向の角度２２０度の経線にあたる一点鎖線Ｃ（線（ｙ：２４０））を中心として円筒２０２を展開した正距円筒映像である。これら図２Ｃ、図２Ｄに示した正距円筒映像も図２Ｂと同様に、映像受信装置１０２で表示される際に、正距円筒映像を水平方向の両端部で繋ぐことで、水平方向の３６０度全方位映像として表示可能となる。 
これら各円筒２０２，２０６，２０７は、仮想的な映像面２０１を正距円筒映像へと変換した図という点で同じであり、異なるのは正距円筒映像へと変換された矩形の中心線が一点鎖線Ａ，Ｂ，Ｃとなっている点である。これは正距円筒映像への変換の際にどこを中心として切り出すかの違いと言い換えることもできる。
また、これら図２Ａ～図２Ｄからも明らかなように、球の天頂にあたる部分はそれぞれ円筒２０２，２０６，２０７の上端の円へと拡大されている。このため、正距円筒図法で変換された映像は、球の赤道面から極方向へ離れるにしたがって拡大されて、いびつな形となる。また、図２Ａ中の太陽の形のオブジェクト２０３と星形のオブジェクト２０５は、球の中心に置かれた３６０度カメラにより写されるオブジェクトの一例を示している。図２Ａに示したオブジェクト２０３，２０５は、正距円筒図法で変換された図２Ｂ～図２Ｃの円筒２０２，２０６，２０７上では、それぞれオブジェクト２０４，２０８のように映ることになる。
＜ＭＰＥＧ－ＤＡＳＨに準拠した映像データ及びメタデータ生成処理と送信＞
次に、正距円筒図法で変換された映像を圧縮符号化して伝送する際の流れを、ＭＰＥＧ－ＤＡＳＨの例を用いて説明する。
図３は、本実施形態の映像送信装置１０１において、正距円筒図法で変換された映像を圧縮符号化して伝送するまでの制御処理の流れを示すフローチャートである。以下の説明では、図３のフローチャートの各ステップＳ３０１～ステップＳ３０７をＳ３０１～Ｓ３０７と略記する。図３のフローチャートの処理は、ソフトウェア構成またはハードウェア構成により実行されてもよいし、一部がソフトウェア構成で残りがハードウェア構成により実現されてもよい。ソフトウェア構成により処理が実行される場合、例えばＲＯＭ１１８に記憶されている本実施形態に係るプログラムをＣＰＵ１１７が実行して各部を制御することにより実現される。本実施形態に係るプログラムは、ＲＯＭ１１８に予め用意されていてもよく、また着脱可能な半導体メモリ等から読み出されたり、インターネット等のネットワークからダウンロードされたりしてもよい。この図３のフローチャートの処理は、３６０度映像の取得がなされる毎に行われる。
先ず、Ｓ３０１において、ＣＰＵ１１７は、前述した３６０度映像を正距円筒映像へと変換する際の中心方向を複数決定する。本実施形態の場合、複数の中心方向は、前述の図２Ａ～図２Ｄで説明したヨー方向における経線の角度で表される三つの線（ｙ：０），（ｙ：１２０），（ｙ：２４０）にそれぞれ対応した三つの中心方向が決定される。なお、本実施形態では、三つの中心方向を例に挙げたが、これは一例であり三つの方向に限定する必要はない。例えば、角度０度の経線にあたる線（ｙ：０）と、角度１８０度の経線にあたる線（ｙ：１８０）のように１８０度分だけ回転した二つ方向であってもよい。角度０度の経線にあたる線（ｙ：０）の方向を正面とすると、角度１８０度の経線にあたる線（ｙ：１８０）の方向は背面となる。また、ヨー方向にも限定されず、緯度方向に相当するピッチ方向等であってもよい。
次に、Ｓ３０２において、ＣＰＵ１１７は、画像信号処理回路１１４を制御し、前述のように撮像されて取得された３６０度映像から、Ｓ３０１で決定した三つの中心方向にそれぞれ対応した三つの正距円筒映像を生成させる。すなわちこの時の画像信号処理回路１１４は、一つの３６０度映像から、正距円筒図法への変換により、それぞれ中心方向が異なる図２Ｂ～図２Ｄで示したような三つの正距円筒映像を生成する。
次に、Ｓ３０３において、ＣＰＵ１１７は、圧縮符号化回路１１５を制御し、Ｓ３０２で生成された三つの正距円筒映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路１１５からは、三つの正距円筒映像にそれぞれ対応した三つの圧縮映像データが生成される。そして、これら三つの圧縮映像データは、映像受信装置１０２からの要求があった場合に、当該映像受信装置１０２へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置１０２へ送信可能な場所にコピー等される。具体的には、メモリ１１９、或いはＷｅｂサーバ１０４等に格納される。
次に、Ｓ３０４において、ＣＰＵ１１７は、それら三つの圧縮映像データの場所を表すアドレス情報であるＵＲＬを生成するアドレス生成処理を行う。すなわち、ＣＰＵ１１７は、アドレス生成処理として、映像受信装置１０２が映像データの配信を要求する際に使用される送信ＵＲＬを生成する。そして、Ｓ３０５において、ＣＰＵ１１７は、それら三つの圧縮映像データにそれぞれ対応した送信ＵＲＬを、ＭＰＥＧ－ＤＡＳＨのメタデータに記録する。本実施形態において、メタデータは、ＭＰＥＧ－ＤＡＳＨにおけるマニフェストファイル或いはＭＰＤファイルである。
さらに、Ｓ３０６において、ＣＰＵ１１７は、Ｓ３０１で決定した中心方向を表す方向情報（以下、方向データとする。）を生成する方向情報生成処理を行う。本実施形態の場合、三つの圧縮映像データに応じた三つの送信ＵＲＬが生成されるため、ＣＰＵ１１７は、方向情報生成処理として、それら三つの送信ＵＲＬに対応した三つの方向データを生成する。
そして、ＣＰＵ１１７は、Ｓ３０７において、それら各方向データをそれぞれ対応した送信ＵＲＬと関連付けて、メタデータに記録する。このＳ３０７の後、図３のフローチャートの処理は終了する。その後、このメタデータは、通信回路１１６からネットワーク１０３を介して映像受信装置１０２に送られる。これにより、映像受信装置１０２は、受信したメタデータに記録されている送信ＵＲＬと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
＜メタデータの概要＞
図４は、ＭＰＥＧ－ＤＡＳＨを例とした場合のメタデータ（ＭＰＤ）の一例を示した図である。なお、ＭＰＥＧ－ＤＡＳＨにおいてメタデータはマニフェストファイルと呼ばれることがあり、図４ではマニフェストファイル４０１として示している。
図４に示したマニフェストファイル４０１には、３つのリプリゼンテーション４０２，４０３，４０４が含まれている。リプリゼンテーションは、ＭＰＥＧ－ＤＡＳＨにおいて一つの映像や音声などを状況によって切り替えられるようにする単位である。一番目のリプリゼンテーション４０２には、映像を取得するためのＵＲＬに加えて、ｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：０”の記述を含んでおり、これが前述のＳ３０６で生成された方向データである。方向データは、回転座標系のロール（ｒ）、ピッチ（ｐ）、ヨー（ｙ）の各方向を表すデータを含んでいる。二番目のリプリゼンテーション４０３も同様に方向データを含んでいる。リプリゼンテーション４０３の方向データは、ヨー（ｙ）方向のみが１２０（ｙ：１２０）となっており、リプリゼンテーション４０２で示される方向に対しヨー方向（水平方向）に１２０度回転したものであることを示している。三番目のリプリゼンテーション４０４も同様に方向データを含んでいる。リプリゼンテーション４０４の方向データは、ヨー（ｙ）方向のみが２２０（ｙ：２２０）となっており、リプリゼンテーション４０２で示される方向に対しヨー方向に２４０度回転したものであることを示している。そして、これらリプリゼンテーション４０２～４０４の何れの方向データを選ぶかにより、前述した図２Ｂ～図２Ｄの線（ｙ：０）～（ｙ：２４０）の何れかを中心とした映像の送信を要求するかを決定できることになる。
例えば、図４のマニフェストファイル４０１を受信した映像受信装置１０２のユーザが再生表示を望む方向が、例えば図２Ｂの線（ｙ：０）を中心（ｒ：０，ｐ：０，ｙ：０）とした映像の方向であるとする。この場合、映像受信装置１０２のＣＰＵ１２１は、ｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：０”の方向データに対応した、リプリゼンテーション４０２に記述された送信ＵＲＬに基づいて、圧縮映像データを取得する。これにより、映像受信装置１０２では、図２Ｂの線（ｙ：０）を中心とした正面（ｒ：０，ｐ：０，ｙ：０）の映像の再生表示が可能となる。例えば、再生表示を望む方向が図２Ｃの線（ｙ：１２０）を中心とした映像である場合には、ｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：１２０”に対応したリプリゼンテーション４０３の送信ＵＲＬから圧縮映像データが取得される。これにより、映像受信装置１０２では、図２Ｃの線（ｙ：１２０）を中心とした映像の再生表示が可能となる。
また例えば、再生表示を望む方向が、線（ｙ：０）を正面とした場合の背面、つまり経線の１８０度（ｙ：１８０）の方向であるような場合、ＣＰＵ１２１は、リプリゼンテーション４０３又は４０４の送信ＵＲＬの何れかを取得する。これは、リプリゼンテーション４０３による中心の線（ｙ：１２０）とリプリゼンテーション４０３による中心の線（ｙ：２４０）は、経線の１８０度（ｙ：１８０）から何れも６０度のずれがあり、同等であると考えられるからである。したがって、再生表示を望む方向が１８０度（ｙ：１８０）の背面映像に指定された場合、映像受信装置１０２では、リプリゼンテーション４０３又は４０３の何れか選択された送信ＵＲＬから取得された映像が再生表示されることになる。
なお、再生表示を望む方向が、図２Ｂの線（ｙ：０）を中心とした映像の方向である場合、水平方向の３６０度全方位映像の繋ぎ目は、中心の線（ｙ：０）に対して経線で１８０度分だけずれた位置（正面に対し真後ろの位置）となる。つまりこの場合の繋ぎ目は、映像受信装置１０２のユーザからみて背面側となるため、ユーザから目につき難くできるメリットがある。また、再生表示を望む方向が１８０度の線（ｙ：１８０）を中心とする方向の場合、取得されるのは中心線が線（ｙ：１２０）又は線（ｙ：２４０）の映像となる。このため、水平方向の３６０度全方位映像の繋ぎ目は、１８０度の線（ｙ：１８０）から近い方が経線で６０度分だけずれた位置となるが、映像の中央からは離れているためユーザから見てさほど目立たないと考えられる。
ここでは、水平方向（ヨー方向）の３６０度全方位映像の表示を行う場合の映像の繋ぎ目について述べたが、前述したような方向データを記録することによるメリットは、必ずしも繋ぎ目の処理に関するものだけではない。
＜パン方向の映像を生成する例＞
先に述べたように、正距円筒図法で変換された映像は、球の赤道面から極方向に距離が離れるに従いゆがみが大きくなっていく。このため、例えば線（ｙ：０）を正面（ｒ：０，ｐ：０，ｙ：０）とした映像を用いて、天頂（ｒ：０，ｐ：９０，ｙ：０）の映像を得ることは、必ずしも好ましくない。この場合、天頂（ｒ：０，ｐ：９０，ｙ：０）の映像が予め生成されているのであれば、この映像を用いて天頂側の映像を再生表示することが望ましい。
したがって、本実施形態では、パン方向（球の緯度方向）についても、前述したヨー方向の場合と同様にして複数の映像データを生成し、また前述同様のメタデータ生成処理も行う。これにより、天頂側でもゆがみの少ない映像を得ることが可能となる。
＜映像圧縮ビットレートを変更する例＞
さらに本実施形態の他の例として、中心となる線からの距離に応じて映像圧縮のビットレートを変更する例について、前述した図２Ａ～図２Ｄを流用して説明する。
図２Ａや図２Ｂに示した円筒２０２は、前述したように、一点鎖線Ａが中心となる正距円筒映像である。ここで、映像受信装置１０２において映像が再生される際に、再生表示を望む方向として、一点鎖線Ａが中央になる方向に指定されて映像表示が行われると仮定する。この場合、例えば一点鎖線Ｂと一点鎖線Ｃとの間の映像部分、つまり一点鎖線Ａの中心部分を正面とした場合の後ろ側に相当する部分の映像は、正面部分の映像よりも重要度が低いと考えられる。すなわち、図２Ｂの円筒２０２の場合、例えば太陽の形のオブジェクト２０４の重要度は高く、星形のオブジェクト２０５の重要度は低いと考えられる。そして、重要度が低い映像部分については、例えば映像圧縮のビットレートを低くしたとしても、視認性に及ぼす影響は少ないと考えられる。
このため、本実施形態において、映像送信装置１０１のＣＰＵ１１７は、圧縮符号化回路１１５を制御し、中心となる線（Ａ）からヨー方向に離れるに従い、映像圧縮のビットレートを例えば低くする。言い換えると、中心となる線に近くなるほど、映像圧縮のビットレートが高くなるようにする。これにより、図２Ｂの太陽の形のオブジェクト２０４を含む領域の映像圧縮ビットレートは高く、一方、星型のオブジェクト２０８を含む慮域の映像圧縮ビットレートは低くなされる。同様に、図２Ｃの円筒２０２の場合には、中心となる線（Ｂ）から離れるに従い映像圧縮のビットレートが低くなされる。これにより、太陽の形のオブジェクト２０４を含む領域の映像圧縮ビットレートは低く、星型のオブジェクト２０８を含む慮域の映像圧縮ビットレートは低くなされる。
また前述したように、映像受信装置１０２では、線（ｙ：０）を正面とした映像の再生表示がなされる場合には、図４のリプリゼンテーション４０２に記述された送信ＵＲＬを基に映像データが取得される。また、線（ｙ：１２０）を中心とした映像の再生表示がなされる場合には、図４のリプリゼンテーション４０３に記述された送信ＵＲＬを基に映像データが取得される。ここで、前述のように中心の線に近いほど映像圧縮ビットレートが高くなる制御が行われているため、それら何れの場合も、中央部の映像は画質劣化が少ない映像となり、ユーザは視認性の良い映像を鑑賞できる。一方で、中心の線から離れるほど映像圧縮ビットレートが低くなる制御が行われているため、映像データを取得する際の伝送ビットレートが全体として低く保たれることになる。
＜回転座標系以外の記述例＞
前述した説明では、方向データとして、例えば（ｒ：０，ｐ：０，ｙ：０）のような回転座標系で表される情報を用いた例を挙げた。ここで、このような回転座標系の情報は、例えば正規化された直交座標系の情報に容易に変換することができる。すなわち、回転座標系の方向データ（ｒ：０，ｐ：０，ｙ：０）は、（ｘ，ｙ，ｚ）＝（０，０，０）のような直交座標系の方向データとして記述されてもよい。
或いは、方向データは、図４の一番目のリプリゼンテーション４０２やその他の所定の方向を基準として、相対角による表される方向データとして記述されても良い。例えば（ｒ：０，ｐ：０，ｙ：０）を正面とした映像に対して、後ろ側（ｒ：０，ｐ：０，ｙ：１８０）のようにして方向を示す代わりに、（ｙａｗ＋１８０）といった記述例も考えられる。方向データとしてこれら何れの記述形式を用いるかは、本実施形態が適用されるシステムに応じて適宜設定可能である。
以上説明したように、第１実施形態においては、メタデータを用いて映像の場所（送信ＵＲＬ）を特定する形式において、全方位映像等の広視野映像から方向を変えて生成した複数の映像と各方向データとを関連付けてメタデータに記述する。したがって、映像受信装置１０２は、メタデータに記述された送信ＵＲＬと方向データを参照することにより、全方位画像等の広視野映像のなかで、再生表示したい方向に応じた好適な映像を取得可能となる。
＜＜第２実施形態＞＞
第１実施形態では、３６０度映像を正距円筒映像へと変換する例を挙げた。以下の第２実施形態では、３６０度映像を立方体（Cubic）の形式に変換する例を説明する。第２実施形態における映像送信装置１０１、映像受信装置１０２等の構成は、図１と同様であるため、図示は省略する。
第２実施形態の場合、映像送信装置１０１の画像信号処理回路１１４は、前述した３６０度映像を後述するように立方体の形式に変換し、さらに当該立方体を展開して立方体展開映像を生成する。そして、圧縮符号化回路１１５は、画像信号処理回路１１４により立方体を展開した立方体展開映像の映像データから、ＭＰＥＧ－ＤＡＳＨに準拠した圧縮映像データを生成する。また、ＣＰＵ１１７は、立方体展開映像に関するメタデータ生成処理を行う。第２実施形態の場合のメタデータに記述される方向データの詳細は後述する。そして、第２実施形態の映像受信装置１０２は、メタデータに含まれる送信ＵＲＬと方向データに基づき、ＭＰＥＧ－ＤＡＳＨに準拠した映像データを取得して表示部１２６に表示する。
以下、第２実施形態において３６０度映像を立方体の形式に変換して立方体展開映像を生成する例について、図５Ａ～図５Ｄ、及び前述の図３のフローチャートを流用して説明する。
図５Ａにおいて、球状の仮想的な映像面２０１は、前述同様に、その中心部に位置する３６０度カメラから見た３６０度映像を表している。太陽の形のオブジェクト２０３、星形のオブジェクト２０５についても前述同様のものである。第２実施形態の場合、球状の仮想的な映像面２０１は、立方体５０１に投影される。図５Ｂは、図５Ａの立方体５０１の面ｃを中心に展開した立方体投影映像５０２を示した図である。また、図５Ｂのオブジェクト２０４，２０８は、立方体投影映像５０２上に映っている図５Ａのオブジェクト２０３、２０５を表している。なおこの例では、立方体投影映像５０２は、面ｃを中心にして展開した形になっているが、例えば面ｂが面ｃを挟んで面ａの左側に、面ｅが面ａの右側に置かれるように展開して、横に３／４、縦に２／３の大きさの矩形とされても良い。
図５Ｃには、図５Ａの立方体５０１の面ａを中心に展開した立方体投影映像５０３を示している。別な表現をするならば、図５Ｂの立方体投影映像５０２は手前の太陽の形のオブジェクト２０４を中心としているのに対し、図５Ｃの立方体投影映像５０３では立方体の上側の面ａを中心とした例である。そして、第２実施形態において、これら図５Ｂの立方体投影映像５０２や図５Ｃの立方体投影映像５０３の映像データも前述同様に圧縮符号化されることになる。なお、立方体５０１の展開方法はこれらの例に限定されない。
ここで、図５Ｂの立方体投影映像５０２の場合、中心領域である面ｃを高画質化し、それ以外の周辺領域の面（ａ，ｂ，ｄ，ｅ，ｆ）は符号量を低下させる（画質を落とす）ように、画像の特徴を異ならせるとする。すなわち、図５Ｂの例の場合、映像送信装置１０１のＣＰＵ１１７は、立方体投影映像５０２に描かれた円５０５の中の領域が高画質となるように圧縮符号化回路１１５を制御する。図５Ｃの立方体投影映像５０３についても同様とする。これにより、太陽の形のオブジェクト２０４を中心に考えた場合、図５Ｂの立方体投影映像５０２を圧縮符号化した映像データを映像受信装置１０２で再生表示した場合、高画質のオブジェクト２０４の表示が可能となる。一方、映像受信装置１０２で再生表示する際に面ａを中心に考えた場合、図５Ｃの立方体投影映像５０３を圧縮符号化した映像データを再生表示すれば、面ａが高画質となった映像の表示が可能となる。
なお、図５Ｄの立方体投影映像５０４は図５Ｃの立方体投影映像５０２と同じ面の配置であり、この図５Ｃの例は高画質化する領域を表す円５０５の配置が、図５Ｂとは異なるだけであり、同様に処理を行うことができる。図５Ｄの立方体投影映像５０４の場合、円５０５で示される高画質化される領域は、面ａと面ｃの一部だけでなく、立方体において面ａとそれぞれ接する面ｄ、面ｆ、面ｅの一部も含まれることになる。
また、立方体投影映像５０２～５０４の図中斜線の部分は映像が存在しないため、例えばスキップドマクロブロック（skipped macroblock）として符号化しないことで、大幅な符号量削減が可能となる。このようなことにより、第２実施形態では、ネットワーク１０３の全体としての通信量を下げながら、所定の面を高画質化した映像を映像受信装置１０２に対して送信することが可能となる。
第２実施形態において、変換された立方体投影映像を圧縮符号化して伝送する際の流れは、前述した図３のフローチャートと概ね同様である。ただし、第２実施形態の場合、３６０度映像を立方体投影映像に変換し、立方体投影映像と中心或いは高画質化等する所定の面とを関連付けた送信ＵＲＬがメタデータに記録される。
第２実施形態の場合、図３のＳ３０１において、映像送信装置１０１のＣＰＵ１１７は、３６０度映像を立方体投影映像へと展開する際の中心或いは高画質化等する所定の面を複数決定する。ここで決定される複数の所定の面は、例えば前述したような図５Ｂの面ｃや図５Ｃの面ａ、図５Ｄの面ａ等である。
次に、Ｓ３０２において、ＣＰＵ１１７は、画像信号処理回路１１４を制御し、前述した３６０度映像から、Ｓ３０１で中心面として決定された面を中心とした立方体投影映像をそれぞれ生成する。
さらに、Ｓ３０３において、ＣＰＵ１１７は、圧縮符号化回路１１５を制御し、Ｓ３０２で生成した各立方体投影映像の映像データを圧縮符号化させる。これにより、圧縮符号化回路１１５からは、各立方体投影映像にそれぞれ対応した圧縮映像データが生成される。このとき、Ｓ３０１で高画質化するとして決定された面（円５０５に対応した円）については、圧縮符号化の際に前述するように高画質化の処理が行われる。そして、これら各立方体投影映像の各圧縮映像データは、映像受信装置１０２からの要求があった場合に、当該映像受信装置１０２へ送信可能な場所、または、異なる場所に蓄積された後に映像受信装置１０２へ送信可能な場所にコピー等される。
次に、ＣＰＵ１１７は、Ｓ３０４において、それぞれ圧縮映像データの場所を表すアドレス情報である送信ＵＲＬを決定し、さらにＳ３０５において、それら圧縮映像データにそれぞれ対応した送信ＵＲＬをメタデータに記録する。
さらに、ＣＰＵ１１７は、Ｓ３０６において、Ｓ３０１で中心或いは高画質化するものとして決定された所定の面を表す方向データを生成する。すなわち、第２実施形態の場合の方向データは、例えば図５Ａの映像面２０１の３６０度映像を立方体に投影した際の各面のうち、中心或いは高画質化される所定の面を表すデータとなされる。そして、ＣＰＵ１１７は、Ｓ３０７において、それら各方向データをそれぞれ対応した送信ＵＲＬと関連付けて、メタデータに記録する。
第２実施形態においても、このメタデータは、通信回路１１６からネットワーク１０３を介して映像受信装置１０２に送られる。これにより、第２実施形態の映像受信装置１０２は、受信したメタデータに記録されている送信ＵＲＬと方向データを参照することにより、所望の方向に対応した圧縮映像データを取得することが可能となる。
＜第２実施形態の場合のメタデータの概要＞
図６は、第２実施形態において、ＭＰＥＧ－ＤＡＳＨを例としたメタデータの一例を示した図である。図６においても前述した図４と同様に、ＭＰＥＧ－ＤＡＳＨにおけるメタデータをマニフェストファイル６０１として示している。
図６のマニフェストファイル６０１には、第１実施形態で説明したのと同様に、三つのリプリゼンテーション６０３，６０４，６０５が含まれている。第２実施形態の場合、第１実施形態とは異なり、図３のＳ３０６で生成された方向データであるｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：０”といった記述が別途予め定義されている。ここでは、これをマップ６０２と呼ぶものとする。もちろん、このようなマップを使用せずに第１実施形態の例と同様に記述されていてもよい。マップ６０２には、さらにｖｉｅｗ＝“ｔｐ”といった記述も含まれている。これは、例えばｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：９０，ｙ：０”が上の方向を意味していることを、記号として記述したものである。また例えば、ｖｉｅｗ＝“ｆｒ”が前面、ｖｉｅｗ＝“ｂｋ”が背面のように方向を予め記号などで決めておくことで、より簡易に方向を示すことも可能となる。
図６において一番目のリプリゼンテーション６０３には、映像を取得するためのＵＲＬに加えてｄｉｒ＿ｉｄ＝“ｃ”の記述が含まれている。これは、マップ６０２におけるｒｐｙ＿ｍａｐｐｉｎｇ　ｄｉｒ＿ｉｄ＝“ｃ”を参照するよう指示するものである。このようにすることによって、リプリゼンテーションの記載を簡略化したり、柔軟な方向データ記載を可能としたりすることが可能となる。詳細な説明は省略するが、リプリゼンテーション６０４やリプリゼンテーション６０５も同様である。また、図６のような方向データの記述は、投影手法に依存せずに適用可能である。
前述したように、第２実施形態の映像送信装置１０１においては、３６０度映像を立方体投影映像に変換し、投影された所定の面を表す方向データをメタデータに記述する。これにより、第２実施形態の映像受信装置１０２においても、メタデータを基に、再生表示したい方向に応じた好適な映像を取得可能となる。
＜＜第３実施形態＞＞
前述した第１実施形態において、図２Ａ～図２Ｄを用いて説明した３６０度映像を正距円筒映像へと変換する例は、円筒２０２の一部を用いて全周とならない映像を生成する場合にも適用可能である。第３実施形態は、円筒２０２の一部を用いて全周とならない映像を生成する場合の適用例である。
第３の実施形態では、円筒２０２の一部の全周とならない映像として、２４０度映像を生成する例を図７Ａ～図７Ｄを用いて説明する。
図７Ａは、前述した図２Ａと同様に、球状の仮想的な映像面２０１と、その中心部に位置する３６０度カメラから見た映像とを表しており、円筒２０２は映像面２０１を正距円筒図法で変換した映像である。また、円筒２０２上の一点鎖線Ａ，Ｂ，Ｃは、前述同様に球面での経線にあたる線である。
図７Ｂは、図７Ａの映像面２０１を正距円筒図法へと変換し、一点鎖線Ａ（線（ｙ：０））を中心線として円筒２０２から２４０度分を切り出した部分円筒映像７０１を表している。同様に、図７Ｃは一点鎖線Ｂ（線（ｙ：１２０））を中心線とし、図７Ｄは一点鎖線Ｃ（線（ｙ：２４０））を中心線として、円筒２０２からそれぞれ２４０度分を切り出した部分円筒映像７０２，７０３を表している。
これら図７Ｂ～図７Ｄのようにそれぞれ異なる中心線により２４０度分だけ切り出されたことで、例えば部分円筒映像７０２と７０３の中には部分円筒映像７０１に含まれていない映像部分が存在することになる。同様に、部分円筒映像７０１と７０３の中には部分円筒映像７０２に含まれていない映像部分が、部分円筒映像７０１と７０２の中には部分円筒映像７０３に含まれていない映像部分が、それぞれ存在することになる。すなわち例えば、映像受信装置１０２で部分円筒映像７０１により太陽の形のオブジェクト２０３を鑑賞するような場合、その投影されたオブジェクト２０４は鑑賞できるが、星形のオブジェクト２０５の投影されたオブジェクト２０８は鑑賞できない。但し、映像受信装置１０２が例えばＨＭＤであるような場合、ＨＭＤの装着者が例えば一定方向を見ている場合には、その反対側の映像は不要であることから、映像の一部が含まれていない場合でもさほど問題は生じないと考えられる。したがって、第３実施形態の場合も、前述の図４のマニフェストファイル４０１で示したように、方向データを用いて最適なリプリゼンテーションを取得すれば良い。
図８には、第３実施形態におけるメタデータの一例としてのマニフェストファイルの記述例を示している。第３実施形態においても前述したマニフェストファイル４０１を適用することは可能であるが、図８のマニフェストファイルには、さらにｒａｎｇｅ＝“ｙ：２４０”が記述されている。このように記述することで、図８のマニフェストファイルを参照した映像受信装置１０２は、対応するリプリゼンテーションがヨーの方向で２４０度の角度の映像を保持していることを知ることができる。なお、第３実施形態の場合においても、言うまでもなくロール方向やピッチ方向などを同時に用いてもよい。
前述したように、第３実施形態においては、円筒２０２の一部の全周とならない映像データが伝送されることになるため、伝送ビットレートを更に低減することが可能となる。また、第３実施形態においても第１実施形態の場合と同様に、中心の線に対応する中心領域の映像圧縮ビットレートを高くし、周辺領域の映像圧縮ビットレートを低くしてもよい。
＜＜第４実施形態＞＞
前述した第１～第３実施形態では、ＭＰＥＧ－ＤＡＳＨ及びマニフェストファイルの例を用いて説明を行ってきた。第４実施形態では、このマニフェストファイルの異なる例を挙げる。図９は、図４を用いて説明したマニフェストファイルのさらに別な例を表した図である。
図９に示したマニフェストファイル９０１は、一見図４で説明したマニフェストファイル４０１と似た構造を持っている。しかしながら、図９のマニフェストファイル９０１の場合、一番目のリプリゼンテーション９０２のＳｅｇｍｅｎｔＵＲＬには、ｔｒａｃｋ＝“１”及びｔｒａｃｋ＝“２”が追記されている。これは、それぞれ、ｖｉｄｅｏ３１．ｍｐ４およびｖｉｄｅｏ３２．ｍｐ４の指定されたｔｒａｃｋ（トラック）を参照することを示している。すなわち、ｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：０”が指定されたリプリゼンテーション９０２は、ＳｅｂｍｅｎｔＵＲＬで指定されたメディアファイルの特定のトラックを取得することを意図して記載されている。
ここで、トラックについて簡単に説明する。この例では、メディアファイルは、ファイルの拡張子から想定できるように、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ　１４４９６－１２）を基礎としたファイル形式のメディアデータとなっている。このようなファイルでは、トラックと呼ばれる複数のメディアを格納する仕組みを備えている。すなわち、リプリゼンテーション９０２は、指定されたファイルの指定されたトラックに格納されたメディアファイル（メディアデータ）を用いることで、方向に合致したメディアを得るよう記載されている。連続した二つのメディアファイルが異なるトラックを指定しているのは、それぞれのメディアファイルが独立しており、異なるトラックに方向に合致したメディアが格納されていることを仮定しているためである。
一方、リプリゼンテーション９０３およびリプリゼンテーション９０４では、ｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：１２０”のような方向の記載の後に、ｔｒａｃｋ＝“１”及びｔｒａｃｋ＝“２”のような記載がある。また、リプリゼンテーション９０３及びリプリゼンテーション９０４のメディアデータは、同じものを指示している。すなわち、リプリゼンテーション９０３及びリプリゼンテーション９０４は、同じメディアデータを参照する。ここでは連続したメディアデータに共通のトラックが指定されているため、例えばリプリゼンテーション９０３では、同じトラックのｔｒａｃｋ＝“１”が連続したメディアデータに適用される。第３実施形態によれば、このようにすることで、同じメディアデータを用いながら方向を記載することができる。
＜＜その他の実施形態＞＞
以上、これまでＭＰＥＧ－ＤＡＳＨを例として説明してきたが、本実施形態は、ＭＰＥＧ－ＤＡＳＨに限らず、メタデータファイルとメディアファイルを組み合わせて映像を送信・受信するシステムにも適用できる。例えば、ＨＴＴＰ　ｌｉｖｅ　Ｓｔｒｅａｍｉｎｇと通称される形式では、マニフェストファイルにｍ３ｕと呼ばれる形式を採用している。ここでは、同様にメディアデータの取得位置を記録するが、これに例えばｄｉｒｅｃｔｉｏｎ＝“ｒ：０，ｐ：０，ｙ：１２０”といった方向データを付加情報として追記することで前述同様のことを実現可能となる。
また、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、Ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、複数の分散した仮想コンピュータ群からなるクラウドシステムであってもよい。 
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
上述の実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明は、その技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である、従って、本発明の範囲を公にするために以下の請求項を添付する。
本願は、２０１７年１２月２７日提出の日本国特許出願特願２０１７－２５１２０８を基礎として優先権を主張するものであり、その記載内容の全てをここに援用する。
１０１：映像送信装置
１０２：映像受信装置
１０３：ネットワーク
１１４：映像信号処理回路
１１７：ＣＰＵ

Claims (17)

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