WO2008148930A1 - Système et procédé pour stocker des présentations de visioconférence à plusieurs participants - Google Patents

Système et procédé pour stocker des présentations de visioconférence à plusieurs participants Download PDF

Info

Publication number
WO2008148930A1
WO2008148930A1 PCT/FI2008/000061 FI2008000061W WO2008148930A1 WO 2008148930 A1 WO2008148930 A1 WO 2008148930A1 FI 2008000061 W FI2008000061 W FI 2008000061W WO 2008148930 A1 WO2008148930 A1 WO 2008148930A1
Authority
WO
WIPO (PCT)
Prior art keywords
track
file
presentation
multiparty
split
Prior art date
Application number
PCT/FI2008/000061
Other languages
English (en)
Inventor
Ye-Kui Wang
Miska Hannuksela
Original Assignee
Nokia Corporation
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 Nokia Corporation filed Critical Nokia Corporation
Publication of WO2008148930A1 publication Critical patent/WO2008148930A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1831—Tracking arrangements for later retrieval, e.g. recording contents, participants activities or behavior, network status
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/50—Telephonic communication in combination with video communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/567—Multimedia conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/155—Conference systems involving storage of or access to video conference sessions

Definitions

  • the present invention relates generally to video conferencing presentations and video call presentations. More particularly, the present invention relates to the storage of video conferencing presentations and video call presentations in files for local playback or transmission.
  • Background of the Invention This section is intended to provide a background or context to the invention that is recited in the claims.
  • the description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
  • the file format is an important element in the chain of multimedia content production, manipulation, transmission and consumption. There is a difference between the coding format and the file format.
  • the coding format relates to the action of a specific coding algorithm that codes the content information into a bitstream.
  • the file format comprises a mechanism for organizing the generated bitstream in such way that it can be accessed for local decoding and playback, transferred as a file, or streamed, all utilizing a variety of storage and transport architectures.
  • the file format can be used to facilitate the interchange and editing of the media. For example, many streaming applications require a pre-encoded bitstream on a server to be accompanied by metadata (stored in "hint-tracks") that assists the server in streaming the video to the client. Examples of hint-track metadata include timing information, indications of synchronization points, and packetization hints. This information is used to reduce the operational load of the server and to maximize the end-user experience.
  • Available media file format standards include the international organization for standardization (iso) base media file format (iso/international electrotechnical commission (iec) 14496-12) (also referred to as the iso file format in short), the moving picture experts group (mpeg)-4 file format (iso/iec 14496-14), the advanced video coding (avc) file format (iso/iec 14496-15) and the 3 rd generation partnership project (3gpp) file format (3gpp ts 26.244). Efforts are also underway in mpeg for the development of the scalable video coding (svc) file format, which is expected to become an amendment to avc file format.
  • the iso file format is the basis for derivation of all the above-identified file formats
  • each file contains exactly one movie box.
  • the movie box may contain one or more tracks, and each track resides in one track box.
  • typically one track is selected. It is possible for there to be more than one track storing information of a certain media type.
  • a subset of these tracks may form an alternate track group, wherein each track is independently decodable and can be selected for playback.
  • receivers In multiparty conferencing, receivers typically display videos from a selected subset of participants in split-screen windows, e.g. An arrangement of display of decoded video from is illustrated in figure 4.
  • a multipoint control unit may transcode the incoming video streams of the selected subset of participants to one video stream, which contains all the video contents from the selected subset of participants.
  • the mcu can simply forward the incoming video streams of the selected subset of participants to the receivers, after which each video stream is decoded individually.
  • Receivers may want to store multiparty conferencing presentations for future use.
  • the current file format designs do not support the storage of presentations of multiparty video conferences, if the mcu forwards streams to participants.
  • a receiver may store the video streams to be displayed in separate video tracks according to existing file format designs, e.g., the iso base media file format.
  • existing file format designs e.g., the iso base media file format.
  • a player that takes the file as input has no way of knowing which video tracks should be decoded and how to display the respective video tracks.
  • FIG. 1 is a representation of a generic multimedia communications system for use with various embodiments of the present invention
  • Figure 2 is a perspective view of an electronic device that can be used in conjunction with the implementation of various embodiments of the present invention
  • Figure 3 is a schematic representation of the circuitry which may be included in the electronic device of figure 1.
  • Figure 4 is a schematic representation of an arrangement of multi-picture display.
  • Figure 5 is a flow-diagram of generating a media container file according to one embodiment of the file format design.
  • Figure 6 is a flow-diagram of generating a media container file according to another embodiment of the file format design.
  • Figure 7 is a flow-diagram of generating a media container file according to yet another embodiment of the file format design.
  • Various embodiments provide a file format design that supports the storage of multiparty video conferencing presentations. This support is enabled via the inclusion of indications of which tracks belong to a multiparty conference presentation, as well as indications of how to display the decoded video streams in a split-screen. With this arrangement, a player is capable of playing back a recorded multiparty video conferencing presentation in exactly the same manner as it was presented during the actual conference.
  • the file format design also supports the storage of other types of presentations that require the use of simultaneous, multiple independently-decodable video tracks.
  • Various embodiments involve the providing of indications of which tracks to belong to a multiparty conference presentation.
  • Fig. 5 is a flow-diagram of a method of generating a media container file according to the present embodiment of the file format design.
  • the container file format comprises indications of which tracks belong to a multi- party conference presentation.
  • a new track reference of type 'mpcp' is defined.
  • any video track that belongs to a multiparty conference presentation contains a trackreferencetypebox of type 'mpcp' (i.e., with reference type equal to 'mpcp').
  • the track id of each other track belonging to the same multiparty conference presentation is equal to one of the track ids present in the trackreferencetypebox of type 'mpcp'.
  • a file reader can obtain the information regarding which tracks belong to a multiparty conference presentation by checking all of the tracks. In the event that more than one track containing a trackreferencetypebox of type 'mpcp' form an alternate track group, then only one of them is selected for playback.
  • a multiparty_presentation value equal to 1 specifies that the presentation stored in this file is a multiparty presentation that requires more than one video track to be simultaneously decoded and displayed.
  • Figure 6 is a flow-diagram of a method of generating a media container file according to the present embodiment of the file format design.
  • the container file format comprises indications of which tracks is to be simultaneously displayed.
  • a new box is defined and contained in the movie box for the file.
  • the movieheaderbox is also changed as follows, such that one of the reserved bits is used to indicate whether the presentation contained in the file is a multiparty conference presentation.
  • This new box referred to as the track relation box, is defined as follows:
  • version is an integer that specifies the version of this box (equal to 0 in this instance)
  • flags is a 24- bit integer with flags.
  • bit 0 is the least significant bit
  • bit 1 is the second least significant bit
  • bit 0 is the least significant bit
  • bit 0 is the least significant bit
  • bit 1 is the second least significant bit
  • bit 0 is the least significant bit
  • bit 0 is the least significant bit
  • bit 1 is the second least significant bit
  • bit 0 When bit 0 is equal to 1, this indicates that information of multiparty presentation track groups is present in this box. When bit 0 is equal to 0, this indicates that information of multiparty presentation track groups is not present in this box.
  • number_multiparty_presentation_groups indicates the number of multiparty presentation track groups that are signaled.
  • multiparty_presentation_group_id indicates the identifier of the multiparty presentation track group that is signaled.
  • number_tracks_in_group indicates the number of tracks in the multiparty presentation track group that is signaled.
  • multiparty_presentation_track_id indicates the track id of the track in the multiparty presentation track group that is signaled.
  • number_switch_groups indicates the number of switching track groups that are signaled,
  • switch group id indicates the identifier of the i-th switching track group that is signaled. The value does not equal 0. For any track associated with a switchgroup id, if a track selection box is present, then switch_group is equal to switch_group_id. For any track having a track selection box present, if alternate group is not equal to 0, then the track is associated with a switch_group_id.
  • number_tracks_in_switch_group indicates the number of tracks in the i- th switch track group that is signaled
  • switch track id indicates the track id of the j-th track in the i-th switch track group that is signaled.
  • This further embodiment supports the signaling of multiple groups of tracks, where each group forms a multiparty presentation. This is useful when there exists some alternate groups, but no track of one alternate group is appropriate for playing at the same time with any track of another alternate group, for example.
  • FIG. 4 illustrates an arrangement for display of decoded video streams from a plurality of multiparty presentations in a presentation window 400.
  • 401, 402, 403 and 404 each represent decoded video streams from separate multiparty presentation tracks and are characterized by their position in window 400.
  • Figure 7 is a flow-diagram of a method of generating a media container file according to the present embodiment of the file format design.
  • the container file format comprises indications as to how the decoded video streams should be display in a window.
  • the container file comprises indications of the positions within a window where a track is to be displayed.
  • a new sample grouping of type 'sswp' is defined to specify the split-screen window position where each sample of a track should be displayed.
  • each track that belongs to a multiparty presentation includes a sampletogroupbox with grouping type equal to 'sswp' and a samplegroupdescriptionbox with grouping type equal to 'sswp'.
  • the sampletogroupbox maps each sample to a split- screen window position sample group, and each sample group typically contains multiple samples.
  • a sswpsamplegroupentry as defined below is included in the samplegroupdescriptionbox to document the position in the split-screen window where each sample of the corresponding sample group should be displayed: aligned(8) class sswpsamplegroupentry()extends visualsamplegroupentry('sswp') ⁇ unsigned int(8) sswp x; unsigned int(8) sswp_y;
  • sswp_x specifies the horizontal coordinate of the split-screen window where samples of the corresponding sample group should be displayed.
  • the top-left split-screen window has sswp x equal to 0.
  • Sswp_y specifies the vertical coordinate of the split-screen window where samples of the corresponding sample group should be displayed.
  • the top-left split-screen window has sswp_y equal to 1.
  • a new box is included in each track to signal the coordinates in the split-screen window for each segment of decoding time or composition (i.e., display) time.
  • the decoded video of only one participant is displayed, then the mcu does not transmit videos of other participants. Consequently, for that time period, those invisible tracks would have edit lists, and the player can know based upon these lists which track it should display, preferably scaled into the entire screen in one embodiment.
  • Figure 1 is a graphical representation of a generic multimedia communication system within which various embodiments of the present invention may be implemented. As shown in figure 1, a data source 100 provides a source signal in an analog, uncompressed digital, or compressed digital format, or any combination of these formats.
  • An encoder 1 10 encodes the source signal into a coded media bitstream. It should be noted that a bitstream to be decoded can be received directly or indirectly from a remote device located within virtually any type of network. Additionally, the bitstream can be received from local hardware or software.
  • the encoder 110 may be capable of encoding more than one media type, such as audio and video, or more than one encoder 110 may be required to code different media types of the source signal.
  • the encoder 1 10 may also get synthetically produced input, such as graphics and text, or it may be capable of producing coded bitstreams of synthetic media. In the following, only processing of one coded media bitstream of one media type is considered to simplify the description.
  • typically real-time broadcast services comprise several streams (typically at least one audio, video and text sub-titling stream).
  • the system may include many encoders, but in figure 1 only one encoder 110 is represented to simplify the description without a lack of generality.
  • text and examples contained herein may specifically describe an encoding process, one skilled in the art would understand that the same concepts and principles also apply to the corresponding decoding process and vice versa.
  • the coded media bitstream is transferred to a storage 120.
  • the storage 120 may comprise any type of mass memory to store the coded media bitstream.
  • the format of the coded media bitstream in the storage 120 may be an elementary self-contained bitstream format, or one or more coded media bitstreams may be encapsulated into a container file. Some systems operate "live", i.e. Omit storage and transfer coded media bitstream from the encoder 110 directly to the sender 130.
  • the coded media bitstream is then transferred to the sender 130, also referred to as the server, on a need basis.
  • the format used in the transmission may be an elementary self-contained bitstream format, a packet stream format, or one or more coded media bitstreams may be encapsulated into a container file.
  • the encoder 110, the storage 120, and the server 130 may reside in the same physical device or they may be included in separate devices.
  • the encoder 110 and server 130 may operate with live real-time content, in which case the coded media bitstream is typically not stored permanently, but rather buffered for small periods of time in the content encoder 110 and/or in the server 130 to smooth out variations in processing delay, transfer delay, and coded media bitrate.
  • the server 130 sends the coded media bitstream using a communication protocol stack.
  • the stack may include but is not limited to real-time transport protocol (rtp), user datagram protocol (udp), and internet protocol (ip).
  • rtp real-time transport protocol
  • udp user datagram protocol
  • ip internet protocol
  • the server 130 encapsulates the coded media bitstream into packets.
  • rtp real-time transport protocol
  • udp user datagram protocol
  • ip internet protocol
  • the server 130 encapsulates the coded media bitstream into packets.
  • rtp When rtp is used, the server 130 encapsulates the coded media bitstream into rtp packets according to an rtp payload format. Typically, each media type has a dedicated rtp payload format.
  • a system may contain more than one server 130, but for the sake of simplicity, the following description only considers one server 130.
  • the server 130 may or may not be connected to a gateway 140 through a communication network.
  • the gateway 140 may perform different types of functions, such as translation of a packet stream according to one communication protocol stack to another communication protocol stack, merging and forking of data streams, and manipulation of data stream according to the downlink and/or receiver capabilities, such as controlling the bit rate of the forwarded stream according to prevailing downlink network conditions.
  • Examples of gateways 140 include mcus, gateways between circuit- switched and packet-switched video telephony, push-to-talk over cellular (poc) servers, ip encapsulators in digital video broadcasting-handheld (dvb-h) systems, or set-top boxes that forward broadcast transmissions locally to home wireless networks.
  • the gateway 140 is called an rtp mixer or an rtp translator and typically acts as an endpoint of an rtp connection.
  • the system includes one or more receivers 150, typically capable of receiving, demodulating, and de-capsulating the transmitted signal into a coded media bitstream.
  • the coded media bitstream is transferred to a recording storage 155.
  • the recording storage 155 may comprise any type of mass memory to store the coded media bitstream.
  • the recording storage 155 may alternatively or additively comprise computation memory, such as random access memory.
  • the format of the coded media bitstream in the recording storage 155 may be an elementary self-contained bitstream format, or one or more coded media bitstreams may be encapsulated into a container file.
  • a container file is typically used and the receiver 150 comprises or is attached to a container file generator producing a container file from input streams.
  • Some systems operate "live,” i.e. Omit the recording storage 155 and transfer coded media bitstream from the receiver 150 directly to the decoder 160.
  • the most recent part of the recorded stream e.g., the most recent 10-minute excerption of the recorded stream, is maintained in the recording storage 155, while any earlier recorded data is discarded from the recording storage 155.
  • the coded media bitstream is transferred from the recording storage 155 to the decoder 160. If there are many coded media bitstreams, such as an audio stream and a video stream, associated with each other and encapsulated into a container file, a file parser (not shown in the figure) is used to decapsulate each coded media bitstream from the container file.
  • the recording storage 155 or a decoder 160 may comprise the file parser, or the file parser is attached to either recording storage 155 or the decoder 160.
  • the coded media bitstream is typically processed further by a decoder 160, whose output is one or more uncompressed media streams.
  • a renderer 170 may reproduce the uncompressed media streams with a loudspeaker or a display, for example.
  • the receiver 150, recording storage 155, decoder 160, and renderer 170 may reside in the same physical device or they may be included in separate devices.
  • Communication devices of the present invention may communicate using various transmission technologies including, but not limited to, code division multiple access (cdma), global system for mobile communications (gsm), universal mobile telecommunications system (umts), time division multiple access (tdma), frequency division multiple access (fdma), transmission control protocol/internet protocol (tcp/ip), short messaging service (sms), multimedia messaging service (mms), e-mail, instant messaging service (ims), bluetooth, ieee 802.11, etc.
  • a communication device may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.
  • FIGS 2 and 3 show one representative mobile device 12 within which the present invention may be implemented. It should be understood, however, that the present invention is not intended to be limited to one particular type of electronic device.
  • the mobile device 12 of figures 2 and 3 includes a housing 30, a display 32 in the form of a liquid crystal display, a keypad 34, a microphone 36, an ear-piece 38, a battery 40, an infrared port 42, an antenna 44, a smart card 46 in the form of a uicc according to one embodiment of the invention, a card reader 48, radio interface circuitry 52, codec circuitry 54, a controller 56 and a memory 58.
  • Individual circuits and elements are all of a type well known in the art, for example in the nokia range of mobile telephones.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention concerne une conception de format qui supporte le stockage de présentations de visioconférence à plusieurs participants et d'autres types de présentations qui requièrent l'utilisation de multiples pistes vidéo simultanées décodables de manière indépendante. Ce support est activé par le biais de l'inclusion d'indications au sujet de quelles pistes appartiennent à une présentation de conférence à plusieurs participants, tout comme des indications sur la manière d'afficher les flux de données vidéo décodés dans une image composite. Avec ce dispositif, un lecteur est en mesure de reproduire une présentation enregistrée de visioconférence à plusieurs participants exactement de la même manière avec laquelle elle a été préparée lors de la vraie conférence.
PCT/FI2008/000061 2007-06-08 2008-06-05 Système et procédé pour stocker des présentations de visioconférence à plusieurs participants WO2008148930A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US94300907P 2007-06-08 2007-06-08
US60/943,009 2007-06-08

Publications (1)

Publication Number Publication Date
WO2008148930A1 true WO2008148930A1 (fr) 2008-12-11

Family

ID=40093230

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2008/000061 WO2008148930A1 (fr) 2007-06-08 2008-06-05 Système et procédé pour stocker des présentations de visioconférence à plusieurs participants

Country Status (1)

Country Link
WO (1) WO2008148930A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010040898A1 (fr) * 2008-10-08 2010-04-15 Nokia Corporation Système et procédé servant à stocker des présentations multimédias à sources multiples
EP2501129A1 (fr) * 2009-12-07 2012-09-19 Huawei Technologies Co., Ltd. Procédé, appareil et système de mise en uvre pour applications de télécommunications assistées par ordinateur

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5915091A (en) * 1993-10-01 1999-06-22 Collaboration Properties, Inc. Synchronization in video conferencing
US6119147A (en) * 1998-07-28 2000-09-12 Fuji Xerox Co., Ltd. Method and system for computer-mediated, multi-modal, asynchronous meetings in a virtual space
WO2003107622A1 (fr) * 2002-06-13 2003-12-24 Nice Systems Ltd. Procede d'enregistrement d'une conference multimedia
US20060047674A1 (en) * 2004-09-01 2006-03-02 Mohammed Zubair Visharam Method and apparatus for supporting storage of multiple camera views
US20060098086A1 (en) * 2004-11-09 2006-05-11 Nokia Corporation Transmission control in multiparty conference
US20060146124A1 (en) * 2004-12-17 2006-07-06 Andrew Pepperell Video conference recorder
US7170886B1 (en) * 2001-04-26 2007-01-30 Cisco Technology, Inc. Devices, methods and software for generating indexing metatags in real time for a stream of digitally stored voice data

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5915091A (en) * 1993-10-01 1999-06-22 Collaboration Properties, Inc. Synchronization in video conferencing
US6119147A (en) * 1998-07-28 2000-09-12 Fuji Xerox Co., Ltd. Method and system for computer-mediated, multi-modal, asynchronous meetings in a virtual space
US7170886B1 (en) * 2001-04-26 2007-01-30 Cisco Technology, Inc. Devices, methods and software for generating indexing metatags in real time for a stream of digitally stored voice data
WO2003107622A1 (fr) * 2002-06-13 2003-12-24 Nice Systems Ltd. Procede d'enregistrement d'une conference multimedia
US20060047674A1 (en) * 2004-09-01 2006-03-02 Mohammed Zubair Visharam Method and apparatus for supporting storage of multiple camera views
US20060098086A1 (en) * 2004-11-09 2006-05-11 Nokia Corporation Transmission control in multiparty conference
US20060146124A1 (en) * 2004-12-17 2006-07-06 Andrew Pepperell Video conference recorder

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010040898A1 (fr) * 2008-10-08 2010-04-15 Nokia Corporation Système et procédé servant à stocker des présentations multimédias à sources multiples
US9357274B2 (en) 2008-10-08 2016-05-31 Nokia Technologies Oy System and method for storing multi-source multimedia presentations
EP2501129A1 (fr) * 2009-12-07 2012-09-19 Huawei Technologies Co., Ltd. Procédé, appareil et système de mise en uvre pour applications de télécommunications assistées par ordinateur
EP2501129A4 (fr) * 2009-12-07 2012-12-19 Huawei Tech Co Ltd Procédé, appareil et système de mise en uvre pour applications de télécommunications assistées par ordinateur

Similar Documents

Publication Publication Date Title
US8365060B2 (en) System and method for indicating track relationships in media files
CA2661578C (fr) Systeme et procede pour indiquer des relations de pistes dans des fichiers multimedias
US9992555B2 (en) Signaling random access points for streaming video data
US9357274B2 (en) System and method for storing multi-source multimedia presentations
EP2314072B1 (fr) Regroupement de pistes et de sous-ensembles de pistes pour decodage de vues video multiples.
US8774284B2 (en) Signaling of multiple decoding times in media files
CN103069828A (zh) 提供用于串流传输视频数据的序列数据集
CN103081488A (zh) 发信号通知用于特技模式视频表示的视频样本
US7711718B2 (en) System and method for using multiple meta boxes in the ISO base media file format
WO2008148930A1 (fr) Système et procédé pour stocker des présentations de visioconférence à plusieurs participants
AU2012202346B2 (en) System and method for indicating track relationships in media files
US11863767B2 (en) Transporting HEIF-formatted images over real-time transport protocol
US20240163461A1 (en) Transporting heif-formatted images over real-time transport protocol
CN117099375A (zh) 通过实时传输协议传输经heif格式化的图像

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: 08761615

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: 08761615

Country of ref document: EP

Kind code of ref document: A1