Method, apparatus, and storage medium for managing media storage and delivery

Abstract

Methods, devices, and storage media for managing media storage and delivery. The method includes obtaining, by a media access function (MAF), a glTF file corresponding to a scene; determining that the glTF file has a CBOR format; converting, using a first CBOR parsing function implemented by the MAF, the glTF file into a converted glTF file having a JSON format; and obtaining, based on the converted glTF file, media content corresponding to the scene.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 137,274, filed January 14, 2021, and U.S. Application No. 17 / 477,134, filed September 16, 2021, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0003] This application relates to a system design that uses 3D modeling syntax to support media objects, implements media syntax to support various media codecs, containers and formats, manages media storage and delivery methods through predefined programming interfaces, and provides media buffer control and rendering functions. Background Technology

[0004] The Graphics Language Transmission Format (glTF) is an API-neutral runtime asset delivery format for 3D modeling. Compared to traditional 3D modeling tools, glTF provides a more efficient, scalable, and interoperable format for the transfer and loading of 3D content. glTF 2.0 is the latest version of the glTF specification written by the Khronos 3D Group. This format supports simple scene graph formats, which typically support static (untimed) objects in scenes, including PNG and JPEG image formats. glTF 2.0 supports simple animations, including translation, rotation, and scaling of basic shapes (i.e., geometric objects) described using glTF primitives. glTF 2.0 does not support timed media and therefore does not support either video or audio.

[0005] "Information technology—Encoding of audiovisual objects—Part 12: ISO basic media file format", ISO / IEC 14496-12 (December 2015), "ISO / IEC 23000-19 Draft FDIS for Segmented Media Universal Media Application Format", ISO / IEC JTC1 / SC29 / WG11 MPEG117 / 16819 (April 2017), and "ISO / IEC FDIS 23009-1 Text 4th Edition", ISO / IEC JTC 1 / SC 29 / WG 11N18609 (August 2019) and the glTF2.0 specification are incorporated herein by reference in their entirety. Summary of the Invention

[0006] According to one embodiment, the method for managing media storage and delivery is implemented by at least one processor, including: obtaining a scene-specific glTF file via a Media Access Function (MAF); determining that the glTF file has a CBOR format; converting the glTF file into a converted glTF file with a JSON format using a first CBOR parsing function implemented by the MAF; and obtaining the scene-specific media content based on the converted glTF file.

[0007] According to one embodiment, an apparatus for managing media storage and delivery includes: at least one memory for storing program code; and at least one processor for reading the program code and operating according to the instructions of the program code, the program code including: first acquisition code for causing at least one processor to obtain a scene-corresponding glTF file via a Media Access Function (MAF); first determination code for causing at least one processor to determine that the glTF file has a CBOR format; first conversion code for causing at least one processor to convert the glTF file into a converted glTF file with a JSON format using a first CBOR parsing function implemented by the MAF; and second acquisition code for causing at least one processor to obtain the scene-corresponding media content based on the converted glTF file.

[0008] According to one embodiment, a non-volatile computer-readable medium stores instructions, including one or more instructions for causing, when executed by at least one processor of a device managing media storage and delivery, the at least one processor to: obtain a scene-corresponding glTF file via a Media Access Function (MAF); determine that the glTF file has a CBOR format; convert the glTF file into a converted glTF file with a JSON format using a first CBOR parsing function implemented by the MAF; and obtain the scene-corresponding media content based on the converted glTF file. Attached Figure Description

[0009] Other features, properties, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings, in which:

[0010] Figure 1 These are diagrams illustrating the environments in which the methods, apparatus, and systems described herein can be implemented according to the various embodiments.

[0011] Figure 2 These are various embodiments Figure 1 A block diagram of example components of one or more devices.

[0012] Figure 3 These are schematic diagrams of the glTF scene description objects in various embodiments.

[0013] Figure 4 This is a schematic diagram of the reference architecture of the media scene description system in various embodiments.

[0014] Figure 5 These are examples of how the glTF JavaScript object notation (JSON) format is presented in various embodiments.

[0015] Figure 6 These are examples of MPEG glTF extensions in various embodiments.

[0016] Figure 7A These are illustrations of files in JSON format from various embodiments.

[0017] Figure 7B These are illustrations of files with CBOR format from various embodiments.

[0018] Figure 8 These are illustrations of examples of the glTF syntax in various embodiments.

[0019] Figures 9A to 9C This is a diagram illustrating example methods for managing media storage and delivery in various embodiments. Detailed Implementation

[0020] Figure 1 This is a schematic diagram of an environment 100 in which the methods, apparatus, and systems described herein can be implemented, according to an embodiment. Figure 1 As shown, environment 100 may include user equipment 110, platform 120, and network 130. The devices in environment 100 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0021] User equipment 110 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 120. For example, user equipment 110 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, cordless phones, etc.), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some embodiments, user equipment 110 may receive information from and / or send information to platform 120.

[0022] Platform 120 includes one or more devices as described elsewhere herein. In some embodiments, platform 120 may include a cloud server or a group of cloud servers. In some embodiments, platform 120 may be designed to be modular, allowing software components to be swapped in or out as needed. This allows platform 120 to be easily and / or quickly reconfigured for different purposes.

[0023] In some implementations, as shown in the figures, platform 120 may be hosted in a cloud computing environment 122. It is worth noting that while the implementations described herein describe platform 120 as hosted in a cloud computing environment 122, in some implementations, platform 120 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0024] The cloud computing environment 122 includes the environment of the hosting platform 120. The cloud computing environment 122 can provide services such as computing, software, data access, and storage, without requiring end users (e.g., user equipment 110) to know the physical location and configuration of the systems and / or devices of the hosting platform 120. As shown in the figure, the cloud computing environment 122 may include a set of computing resources 124 (collectively referred to as "computing resources 124" and individually as "computing resource 124").

[0025] Computing resource 124 includes one or more personal computers, workstations, server devices, or other types of computing and / or communication devices. In some embodiments, computing resource 124 may host platform 120. Cloud resources may include computing instances executing in computing resource 124, storage devices provided in computing resource 124, data transmission devices provided by computing resource 124, etc. In some embodiments, computing resource 124 may communicate with other computing resources 124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0026] Further as Figure 1 As shown, computing resources 124 include a set of cloud resources, such as one or more applications (“APP”) 124-1, one or more virtual machines (“VM”) 124-2, virtualized storage (“VS”) 124-3, one or more hypervisors (“HYP”) 124-4, etc.

[0027] Application 124-1 includes one or more software applications that can be provided to, or accessed by, user device 110 and / or platform 120. Application 124-1 does not require the installation and execution of any software applications on user device 110. For example, application 124-1 may include software associated with platform 120, and / or any other software available through cloud computing environment 122. In some implementations, an application 124-1 may send / receive information to or from one or more other applications 124-1 via virtual machine 124-2.

[0028] Virtual machine 124-2 includes a software implementation of a machine (e.g., a computer) that executes programs, similar to a physical machine. Virtual machine 124-2 can be a system virtual machine or a process virtual machine, depending on the extent to which virtual machine 124-2 uses and corresponds to any real machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine can execute a single program and can support a single process. In some implementations, virtual machine 124-2 can execute on behalf of a user (e.g., user device 110) and can manage the infrastructure of cloud computing environment 122, such as data management, synchronization, or long-term data transfer.

[0029] Virtualized storage 124-3 includes one or more storage systems and / or one or more devices that utilize virtualization technology within the storage systems or devices of computing resource 124. In some implementations, the type of virtualization within the context of the storage system may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed without regard to physical storage or heterogeneous architecture. Separation allows storage system administrators to flexibly manage end-user storage. File virtualization can eliminate the dependency between data accessed at the file level and the location of physical storage files. This can optimize storage usage, server consolidation, and / or performance for non-disruptive file migration.

[0030] Hypervisor 124-4 provides hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 124. Hypervisor 124-4 can provide a virtual operating platform to the guest operating systems and manage their execution. Multiple instances of various operating systems can share virtualized hardware resources.

[0031] Network 130 includes one or more wired and / or wireless networks. For example, network 130 may include cellular networks (e.g., fifth-generation (5G) networks, Long-Term Evolution (LTE) networks, third-generation (3G) networks, Code Division Multiple Access (CDMA) networks, etc.), Public Land Mobile Networks (PLMNs), Local Area Networks (LANs), Wide Area Networks (WANs), Metropolitan Area Networks (MANs), telephone networks (e.g., Public Switched Telephone Networks (PSTNs)), private networks, self-organizing networks, intranets, the Internet, fiber-optic networks, etc., and / or combinations of these or other types of networks.

[0032] Figure 1 The number and arrangement of devices and networks shown are provided as an example. In reality, with... Figure 1 Compared to the devices and / or networks shown, there can be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or different arrangements of devices and / or networks. Furthermore, Figure 1 The two or more devices shown can be implemented within a single device, or Figure 1 The single device shown can be implemented as multiple distributed devices. Alternatively, a group of devices in environment 100 (e.g., one or more devices) can perform one or more functions described as being performed by another group of devices in environment 100.

[0033] Figure 2 yes Figure 1 A block diagram of example components for one or more devices. Device 200 may correspond to user device 110 and / or platform 120. Figure 2 As shown, device 200 may include bus 210, processor 220, memory 230, storage component 240, input component 250, output component 260 and communication interface 270.

[0034] Bus 210 includes components that allow communication between components of device 200. Processor 220 is implemented in hardware, firmware, or a combination of hardware and software. Processor 220 is a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing component. In some embodiments, processor 220 includes one or more processors that can be programmed to perform functions. Memory 230 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, and / or optical storage) that stores information and / or instructions for use by processor 220.

[0035] Storage component 240 stores information and / or software related to the operation and use of device 200. For example, storage component 240 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), optical disks (CDs), digital versatile disks (DVDs), floppy disks, cassette tapes, magnetic tapes, and / or other types of non-volatile computer-readable media, and corresponding drives.

[0036] Input component 250 includes components that allow device 200 to receive information, such as a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone. Alternatively, input component 250 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, accelerometer, gyroscope, and / or actuator). Output component 260 includes components that provide output information from device 200, such as a display, speaker, and / or one or more light-emitting diodes (LEDs).

[0037] Communication interface 270 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable device 200 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 270 may allow device 200 to receive information from and / or provide information to another device. For example, communication interface 270 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0038] Device 200 can perform one or more processes described herein. Device 200 can perform these processes in response to processor 220 executing software instructions stored in a non-volatile computer-readable medium (e.g., memory 230 and / or storage component 240). Computer-readable medium is defined herein as a non-volatile memory device. A memory device includes storage space within a single physical storage device or storage space distributed across multiple physical storage devices.

[0039] Software instructions can be read into memory 230 and / or storage component 240 from another computer-readable medium or from another device via communication interface 270. When executed, the software instructions stored in memory 230 and / or storage component 240 can cause processor 220 to perform one or more processes described herein. Alternatively or additionally, hardware wiring circuitry may be used in place of or in combination with the software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuitry and software.

[0040] Figure 2 The number and arrangement of components shown are provided as an example. In fact, with... Figure 2 Compared to the components shown, device 200 may include more components, fewer components, different components, or components arranged differently. Alternatively, a set of components of device 200 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 200.

[0041] refer to Figure 3 The Graphics Language Transfer Format (glTF) is a runtime resource delivery format for 3D modeling that does not restrict application programming interfaces (APIs). Compared to traditional 3D modeling tools, glTF provides a more efficient, scalable, and interoperable format for the transfer and loading of 3D content.

[0042] A glTF scene can be a combination of multiple glTF resources. A glTF resource can be a JavaScript Object Symbol (JSON) format file containing a complete scene description, which may include, for example, scene objects 301, nodes 302, cameras 303, meshes 304, lights 305, animations 306, accessors 307, assets 308, skins 309, buffer views 310, techniques 311, textures 312, buffers 313, procedural elements 314, images 315, samplers 316, shaders 317, and supported external data.

[0043] glTF also supports external data sources that can be referenced in any of the aforementioned scene objects. In some embodiments, binary files can be used to represent animation 306 or other buffer-based data 313. Image files can be used to represent object textures 312.

[0044] refer to Figure 5 As mentioned above, glTF scenes can be organized as JSON format. A glTF resource can include zero or more than zero scenes (503), which can be a collection of visual objects to be rendered. Scene arrays can be used to define scenes. Figure 5 In the example, there exists a single scene 506 with a single node 501, but the embodiment is not limited to this. Each node object can be associated with various parameters. For example, name 502 can indicate the name of the node object, while scene name 504 can indicate the name of the single scene.

[0045] glTF scene assets can be used by rendering engines to present 3D or immersive scenes to users. The existing glTF syntax only supports 3D objects, including static or computer-generated animated objects. Media types such as video or audio are not supported, let alone rendered.

[0046] At the same time, the existing glTF cannot use a geographic coordinate system to describe scenes, which is required in some media presentation scenarios.

[0047] Therefore, glTF needs to be extended to support a variety of media types, including traditional 2D flat video as well as immersive media content such as virtual reality (VR), augmented reality (AR), extended reality (XR), and spatial audio. This may require extensions to support video / audio syntax as well as systems for media delivery and presentation.

[0048] The Moving Picture Experts Group (MPEG) defined several extensions on top of the glTF specification to support immersive media content. (Reference) Figure 3 The new extensions are MPEG_media 330, MPEG_scene_dynamic 331, MPEG_texture_video 333, MPEG_animation_timing 332, MPEG_audio_spatial 334, MPEG_accessor_timed 335, and MPEG_buffer_circular 336. Figure 3Typically, elements with circular outlines (such as elements 301-317) can be glTF elements, and elements with square outlines (such as elements 330-336) can correspond to extensions of the MPEG-based glTF specification, but the embodiments are not limited thereto.

[0049] If MPEG_media 330 is specified as the root identifier, then MPEG_media will be supported. (See reference) Figure 6 Syntax that supports MPEG media can be declared as top-level JSON syntax. Figure 6 The syntax from 601 to 604, if supported, can appear exactly as shown in the figure.

[0050] Scene updates can be expressed using the JSON patching protocol, and the MPEG_scene_dynamic 331 protocol can be used to support the JSON patching protocol.

[0051] The MPEG Texture Video extension, identified by MPEG_texture_video 333, provides the ability to link glTF texture objects to MPEG media and their corresponding tracks listed by the MPEG_media object. The MPEG Texture Video extension also provides a reference to MPEG_accessor_timed 335, where decoded timed textures become available.

[0052] The MPEG_audio_spatial 334 extension can support a variety of audio types.

[0053] To support timed data access, the buffer element can be extended to provide circular buffer functionality. This extension is named MPEG_buffer_circular 336 and can be included as part of a glTF "buffer" object, such as buffer 313.

[0054] The MPEG extensions described above make it possible to create immersive experiences using glTF. Finally, glTF resources with MPEG extensions can also be loaded into rendering engines used for visualization.

[0055] refer to Figure 4The reference media scene description architecture 400 illustrates an example of how MPEG extensions can be used to support media types such as audio / video. Media content can be extracted from external sources such as a media cloud 401 by a media retrieval engine and media access functions (MAFs) 402, processed by video decoders 403, audio decoders 404, and other data compressors 405, buffered in video buffers 406, audio buffers 407, and other buffers 408, and rendered by a rendering engine 409. In some cases, media content can be stored in local storage 410.

[0056] refer to Figure 4 The MPEG Scene Description Extensions (MDLE) can separate the rendering engine 409 from the media extraction engine 402. The rendering engine 409 and the media extraction engine 402 can communicate through a predefined programming interface, allowing the rendering engine 409 to request the media data needed to render the scene. The media extraction engine 402 can extract the requested media and make it available in a timely manner and in a format that the rendering engine 409 can directly process. For example, the requested media resource may be compressed and reside on a network; therefore, the media extraction engine 402 extracts and decodes the resource and passes the resulting media data to the rendering engine 409 for rendering. The media data can be passed from the media extraction engine 402 to the rendering engine 409 in the form of a buffer. Requests for media data can be passed from the rendering engine 409 to the media extraction engine 402 via the media extraction API. For flexible use of video decoding resources, a video decoder 403 can be used. When using the video decoder 403, the rendering engine 409 can provide the video decoder 403 with information for input formatting and output formatting via the application configuration API.

[0057] As mentioned above, glTF syntax can be expressed in JSON files. Compared to the traditional JSON format, the Internet Engineering Task Force (IETF) Concise Binary Object Representation (CBOR) provides a more concise data format. CBOR involves data objects in a name / value pair format similar to JSON, but expressed in a binary and compact manner, and also offers more support for key-value types. CBOR format files can be smaller than their JSON counterparts. In some cases, CBOR files can be more than 50% smaller than their corresponding JSON files. CBOR is registered with the Internet Assigned Numbers Authority (IANA) as "application / CBOR".

[0058] CBOR can be used as one of the interchangeable compressed file formats with glTF, and it is also widely supported due to its compact data size and interchangeability with JSON.

[0059] Information in CBOR is stored in binary form. Because many use cases for information involve machines understanding the data, binary data formats may have a speed advantage over human-readable data formats such as JSON or XML. Human-readable data formats may need to be parsed each time a computer or machine tries to understand the data stored within them.

[0060] Figure 7A An example of a JSON-formatted file is shown. Figure 7B An example of a corresponding file in CBOR format is shown. For example, Figure 7A The character "a" (711) in the JSON format file can correspond to Figure 7B 0x61 (721) in the CBOR format file. Similarly, Figure 7A The character "b" (712) in the JSON format file can correspond to Figure 7B 0x62 (722) in the CBOR format file, Figure 7A The character "c" (713) in the JSON format file can correspond to Figure 7B 0x63 (723) in the CBOR format file.

[0061] Compared to JSON, CBOR offers the following advantages in scene description: smaller data size and support for multiple key-value types, unlike JSON which only supports string objects. The functional programming interface can be used in the presented media scene description reference architecture, more specifically in the media access functionality module.

[0062] As glTF's support for CBOR becomes more widespread, such support can be added to MPEG scene descriptions to, for example, increase the interoperability of the glTF file format, reduce the size of files stored locally or cached, and reduce glTF file transfer latency with minimal processing power at MAF 402.

[0063] According to some embodiments, the CBOR parsing function can be implemented by MAF 402 to convert CBOR input into JSON format natively supported by glTF, and can also be used as a file compressor to save large glTF files to local storage or cache 410.

[0064] The CBOR parser API provides methods such as cbor2Json(), json2Cbor, and save(), as shown in Table 1 below:

[0065] Table 1

[0066] cbor2Json(file) Convert CBOR format to JSON format json2Cbor(file) Convert JSON format to CBOR format cbor2Json(object) Convert CBOR data blob to JSON format

[0067] A detailed description of the interface is as follows:

[0068]

[0069] The functions mentioned above can be used in various scenarios, such as those described below.

[0070] refer to Figure 8 The glTF "url" or "uri" syntax can point to a CBOR binary data block (802). In some embodiments, there are two ways to specify whether the binary code is indeed in CBOR data format. According to Example 1, a Multipurpose Internet Mail Extension (MIME) type can be indicated by a signal, which uses "application / cbor" (801) to indicate "mimeTypes". According to Example 2, the prefix "application / cbor;" can be included before the actual binary data. Examples 1 and 2 can be used together. In any case, a function named "cbor2Json(Object)" that receives the CBOR binary data can be called to parse the CBOR file format into JSON.

[0071] If the input glTF is in CBOR format, the output of the cbor2Json() API can be glTF.

[0072] If the input is in native glTF format, no conversion is needed.

[0073] For local storage or caching, glTF files can be saved as CBOR using the json2Cbor() and save() interfaces.

[0074] Accordingly, some embodiments may involve methods for providing interoperability with CBOR for the glTF file format, reducing the file size in local storage or caching, increasing data transfer speed, and reducing file transfer latency.

[0075] refer to Figures 9A to 9C The following describes methods for managing media storage and delivery: 900A, 900B, and 900C.

[0076] Figure 9A This is a flowchart of example method 900A for managing media storage and delivery.

[0077] like Figure 9A As shown, method 900A may include obtaining the scene-corresponding glTF file by a media access function (MAF) (box 911). In some embodiments, MAF may correspond to MAF 402.

[0078] like Figure 9A As further shown in the diagram, method 900A may include determining that the glTF file has a CBOR format (box 912).

[0079] like Figure 9A As shown, method 900A may include converting the glTF file into a JSON-formatted glTF file using a first CBOR parsing function implemented by MAF (box 913).

[0080] like Figure 9A As shown, method 900A may include obtaining the media content corresponding to the scene based on the converted glTF file (box 914).

[0081] In some embodiments, the converted glTF file in JSON format can be larger than the glTF file in CBOR format.

[0082] In some embodiments, the MAF may be included in the Moving Picture Experts Group (MPEG) Scene Description Architecture. In some embodiments, the MPEG Scene Description Architecture may correspond to the Media Scene Description Architecture 400.

[0083] In some embodiments, the first CBOR resolution function can be implemented using the API associated with MAF. In some embodiments, the API may correspond to any of the APIs discussed above.

[0084] Figure 9B This is a flowchart of an example method 900B for managing media storage and delivery. In some embodiments, one or more blocks of method 900B may be performed in combination with one or more blocks of method 900A. For example, one or more blocks of method 900B may be performed after one or more blocks of method 900A.

[0085] like Figure 9B As shown, method 900B may include obtaining a Uniform Resource Locator (URL) parameter (box 921) from the converted glTF file that indicates the binary data bundle.

[0086] like Figure 9B As further shown in the diagram, method 900B may include determining that the binary data group has a CBOR format (box 922).

[0087] like Figure 9B As further shown in the figure, method 900B may include using a second CBOR parsing function implemented by MAF to convert the binary data blobs into objects with JSON format (box 923).

[0088] In some embodiments, it can be determined that the binary data packet has CBOR format based on the Multipurpose Internet Mail Extensions (MIME) type represented by a signal in the glTF file.

[0089] In some embodiments, the binary data block may be determined to have CBOR format based on the prefix included at the beginning of the binary data block.

[0090] In some embodiments, the binary data group may be determined to have CBOR format based on the Multipurpose Internet Mail Extensions (MIME) type indicated by a signal in the glTF file and the prefix included at the beginning of the binary data group.

[0091] Figure 9C This is a flowchart of an example method 900C for managing media storage and delivery. In some embodiments, one or more blocks of method 900C may be performed in combination with one or more blocks of methods 900A and / or 900B. For example, one or more blocks of method 900C may be performed after one or more blocks of method 900A or after one or more blocks of method 900B.

[0092] like Figure 9CAs shown, method 900C may include using a JSON parsing function implemented by MAF to reconvert the converted glTF file into a reconverted glTF with CBOR format (box 931).

[0093] like Figure 9C As further shown in the diagram, method 900C may include at least one step of storing the reconverted glTF file in local storage or a cache (box 932).

[0094] In some embodiments, the reconverted glTF file in CBOR format may be smaller than the reconverted glTF file in JSON format.

[0095] In some embodiments, the JSON parsing functionality can be implemented using the application programming interface associated with MAF. In some embodiments, this API can correspond to any of the APIs discussed above.

[0096] Although Figures 9A to 9C Example boxes for methods 900A, 900B, and 900C are shown, but in some implementations, methods 900A, 900B, and 900C may include... Figures 9A to 9C The boxes depicted are compared to more boxes, fewer boxes, different boxes, or boxes arranged in a different manner. Additionally or alternatively, two or more boxes in the process boxes of methods 900A, 900B, and 900C may be performed in parallel. In some embodiments, any one or more boxes in methods 900A, 900B, and 900C may be combined with any other one or more boxes in methods 900A, 900B, and 900C in any order, and any one or more boxes in methods 900A, 900B, and 900C may be split or combined as needed.

[0097] Furthermore, the proposed method can be implemented using processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-volatile computer-readable medium to perform one or more methods of the proposed method.

[0098] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation schemes to the precise forms disclosed. Modifications and variations to the schemes can be obtained from the foregoing disclosure or from the practice of the implementation schemes.

[0099] Clearly, the systems and / or methods described herein can be implemented by various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to these embodiments. Therefore, it should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

[0100] While specific combinations of features are stated in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible embodiments. In fact, many of these features can be combined in ways not specifically listed in the claims and / or not disclosed in the specification. Although each dependent claim listed below may be directly subordinated to only one claim, the disclosure of possible embodiments includes combinations of each dependent claim with each other claim in the group of claims.

[0101] Elements, actions, or instructions used herein should not be construed as critical or necessary unless explicitly stated otherwise. Furthermore, as used herein, the articles “a” and “an” are intended to include one or more objects and are used interchangeably with “one or more.” Additionally, as used herein, the term “set” is intended to include one or more objects (e.g., related objects, unrelated objects, a combination of related and unrelated objects, etc.) and is used interchangeably with “one or more.” The term “an” or similar language is used when referring to only one object. Furthermore, as used herein, the terms “having,” “possessing,” “containing,” etc., are open-ended terms. Further, the phrase “based on” is intended to mean “at least partially based on” unless the opposite is explicitly stated.

Claims

1. A method for managing media storage and delivery, characterized in that, include: A glTF file in the graphics language transmission format corresponding to a scene is obtained through the Media Access Function (MAF). The glTF file is determined to have a Concise Binary Object Representation (CBOR) format. The glTF file is converted into a glTF file with JavaScript object notation in JSON format using the first CBOR parsing function implemented by the MAF; and The media content corresponding to the scene is obtained based on the converted glTF file.

2. The method according to claim 1, characterized in that, The converted glTF file with the JSON format is larger than the glTF file with the CBOR format.

3. The method according to claim 1, characterized in that, The MAF is included in the Moving Picture Experts Group MPEG Scene Description Architecture.

4. The method according to claim 1, characterized in that, The first CBOR parsing function is implemented by an application programming interface associated with the MAF.

5. The method according to claim 1, characterized in that, Further includes: The converted glTF file is reconverted into a reconverted glTF file with the CBOR format using the JSON parsing function implemented by the MAF. and The reconverted glTF file is stored in at least one of the local storage or cache.

6. The method according to claim 5, characterized in that, The reconverted glTF file with the CBOR format is smaller than the converted glTF file with the JSON format.

7. The method according to claim 5, characterized in that, The JSON parsing function is implemented by the application programming interface associated with the MAF.

8. A device for managing media storage and delivery, characterized in that, include: The first acquisition module is used to obtain a glTF file in the graphics language transmission format corresponding to a scene through the Media Access Function (MAF). The first determining module is used to determine that the glTF file has a Simple Binary Object Representation (CBOR) format. The first conversion module is used to convert the glTF file into a converted glTF file with JavaScript object notation JSON format using the first CBOR parsing function implemented by the MAF; and The second acquisition module is used to obtain the media content corresponding to the scene based on the converted glTF file.

9. The device according to claim 8, characterized in that, The converted glTF file with the JSON format is larger than the glTF file with the CBOR format.

10. The device according to claim 8, characterized in that, The MAF is included in the Moving Picture Experts Group MPEG Scene Description Architecture.

11. The device according to claim 8, characterized in that, The device further includes: A re-conversion module is used to re-convert the converted glTF file into a re-converted glTF file with the CBOR format using the JSON parsing function implemented by the MAF; and A storage module for storing the reconverted glTF file in at least one of local storage or cache.

12. The device according to claim 11, characterized in that, The reconverted glTF file with the CBOR format is smaller than the converted glTF file with the JSON format.

13. A device for managing media storage and delivery, characterized in that, It includes a processor and a memory, the memory storing instructions for causing the processor to perform the method according to any one of claims 1-7.

14. A non-volatile computer-readable medium storing instructions, characterized in that, The instructions are used to cause the at least one processor, when executed by a device that manages media storage and delivery, to perform the method according to any one of claims 1-7.

Images