KR102153611B1 - 멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법 - Google Patents

멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법 Download PDF

Info

Publication number
KR102153611B1
KR102153611B1 KR1020187023649A KR20187023649A KR102153611B1 KR 102153611 B1 KR102153611 B1 KR 102153611B1 KR 1020187023649 A KR1020187023649 A KR 1020187023649A KR 20187023649 A KR20187023649 A KR 20187023649A KR 102153611 B1 KR102153611 B1 KR 102153611B1
Authority
KR
South Korea
Prior art keywords
message
format
field
data
downlink
Prior art date
Application number
KR1020187023649A
Other languages
English (en)
Other versions
KR20180137477A (ko
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
Priority claimed from CN201610074442.XA external-priority patent/CN107026827B/zh
Priority claimed from CN201610074851.XA external-priority patent/CN107026887B/zh
Priority claimed from CN201610107748.0A external-priority patent/CN107135184B/zh
Application filed by 상하이 지아오통 유니버시티 filed Critical 상하이 지아오통 유니버시티
Publication of KR20180137477A publication Critical patent/KR20180137477A/ko
Application granted granted Critical
Publication of KR102153611B1 publication Critical patent/KR102153611B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23611—Insertion of stuffing data into a multiplex stream, e.g. to obtain a constant bitrate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H04L67/2823—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)

Abstract

본 발명은 두 가지 형식의 멀티미디어 시스템의 정보 교환 메카니즘 및 네트워크 전송 방법을 제공하며, 그 중 하나는 교환 메시지 본체를 사용하여 양방향의 신속한 정보 교환을 구현함으로써, 기존 미디어 전송 시스템에서 효율적이고 원활한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결할 수 있고 동시에 모든 미디어 전송 시스템에 적용될 수 있으며, 다른 하나는 프로토콜 전송 포맷이 강요한 가장 단순한 데이터 패킷에 대하여, 프로토콜 포맷이 신속한 정보 교환에 적응하도록 프로토콜 포맷 헤더의 데이터 크기를 단순화하고, 이에 따라 기존 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결할 수 있다. 또한, 본 발명은 전 프레임의 이미지가 정지하는 프레임 데이터에 대해 플래그 비트를 증가하며, 상기 플래그 비트의 정보만 전송하고 상기 프레임 데이터를 전송하지 않아 스트리밍 동영상 전송 시의 정지 이미지 프레임에 의한 대역폭 점용과 유량 낭비 문제를 해결하는 동영상 스트림의 정지 이미지를 위한 최적화 전송 메카니즘을 제공한다.

Description

멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법
본 발명은 멀티미디어 시스템의 정보 교환 메카니즘에 관한 것으로, 더욱 정확하게는, 멀티미디어 시스템의 정보 교환 메카니즘, 네트워크 전송 방법 및 최적화 전송 메카니즘에 관한 것이다.
클라우드 컴퓨팅, 사물 인터넷, 스마트형 착용 가능 장비 등 신세대 애플리케이션 소비 패턴의 발전에 따라, 종래의 음성/동영상 미디어에 의한 일방향 데이터 전송은 이미 각종 애플리케이션의 요구를 만족시킬 수 없게 되었다. 신세대 멀티미디어 전송 시스템에서, 신형 데이터 전송 포맷은 각종 가능한 데이터 유형을 포함해야 하고, 동시에 통신하는 양자는 양방향 통신을 지원하여 서로 다른 서비스 로직과 서비스 과정을 구현해야 한다.
실시간 정보 교환은 갈수록 미래의 멀티미디어 시스템에서 데이터를 교환하는 중요한 추세로 되고 있으며, 그 중 서버가 사용자의 현재 조작과 작업 상태를 파악하도록 사용자가 교환 데이터를 서버에 실시간으로 업로드해야 하는 한편, 서버가 획득한 정보를 분석하고 계산하여 신속히 응답함으로써 처리 결과를 실시간으로 사용자에게 전달한다. 그 특점은 매번 획득한 정보의 데이터량이 적으나 교환 빈도가 매우 높고, 업로드, 다운로드의 즉시성에 대한 요구가 높아 메시지 포맷이 단순해야 하며, 비용이 낮을수록 좋은 것이다. 따라서, 이와 같은 신속한 정보 교환의 포맷 설계와 네트워크 전송 방법의 설계가 매우 중요하다.
비실시간 정보 교환은 주로 자원 요청 응답 정보를 교환하는 것으로서, 그 목적은 사용자가 필요에 따라 능동적으로 서버단의 자원 데이터를 요청하는 요구를 만족하는 것이고, 그 특점은 대화식 교환, 비실시간 빈번 교환이지만 클라이언트에서 서버단까지의 통신 링크의 지원 및 서버의 효과적인 응답이 필요한 것이다. 그 과정은 사용자가 프로그램 스트림을 수신한 후 상기 프로그램 스트림이 제공하는 설명 파일과 미디어 데이터를 포함하는 사용 가능한 자원 정보를 획득하고 서버단으로 해당 데이터를 요청하며, 서버가 요청을 수신한 후 요청의 적법성을 체크하고, 적법 시 확인 정보를 송신하고 데이터를 전송하며, 적법하지 않으면 실패 정보를 송신한다. 효율적인 멀티미디어 전송 시스템은 더욱 경량한 요청과 응답 교환 방식을 만족해야 하며 동시에 멀티미디어에 대한 교환 포맷도 지원해야 한다.
검색 결과에 따르면, 중국 발명 특허 CN200310123710.5에서 제시한 시스템은 멀티미디어 대상이 부가된 프로그램 내용과 프로그램 가이드 데이터의 통신에 편리한 프로그램 고유 정보 데이터 구조에 관한 것으로, 멀티미디어 대상은 음성, 동영상, 애니메이션, 정지 이미지, 인터넷, 이메일, 텍스트 및 다른 유형의 데이터를 포함한다. 상기 데이터 구조는 수동적 관람과 같은 일방향 통신 애플리케이션 및 교환 유형의 기능과 같은 양방향 통신 애플리케이션을 지원한다. 디코더는 패킷화 프로그램 데이터 및 보조적 설명 정보를 포함하는 프로그램 고유 정보를 처리하고, 보조적 설명 정보는 멀티미디어 대상의 유형, 위치 및 다른 설명적 인디케이터를 포함한다. 이러한 인디케이터는 상이한 정보원으로부터 획득한 멀티미디어 대상을 획득하고 디코딩하여 동영상 프로그램 내용 또는 프로그램 가이드를 표시하는 복합 동영상 이미지에 나타내도록 한다. 부가한 보조적 위치와 획득한 설명 정보를 이용하여 추가된 프로그램 고유 정보 유닛과 프로그램 내용 데이터를 획득할 수 있다. 상기 특허는 여전히 기존 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환이 결핍되는 문제를 해결하지 못하였다.
또한, 현재의 네트워크 유량에서, 멀티미디어 서비스, 특히 동영상 서비스가 인터넷 유량의 대부분을 차지하고 있다. 네트워크 전송에서 동영상 데이터가 점용하는 대역폭을 효과적으로 줄이는 것이 새로운 연구 주제로 되었다.
현재 시장에서 널리 사용하는 H.264, HEVC 등의 동영상 코딩 기술은 프레임 내 코딩 및 프레임 간 코딩 등 기술을 사용하며, 극히 높은 코딩 압축 비율과 코딩 효율을 가지고 있고 동시에 거의 사용자의 체험에 영향을 끼치지 않는다. H.264로 압축된 동영상 데이터는 네트워크에서 전송할 때 필요하는 대역폭이 더 적고, 또한 더욱 경제적이다. 따라서, H.264는 출시하자마자 거대한 성공을 얻었고, 2011년 말까지 80%의 동영상이 H.264 코딩 기술을 사용하였다.
H.264, HEVC의 프레임 간 코딩 기술은 동작 예측 및 동작 보상 등의 기술을 기반으로 하고 동영상의 전후 프레임 간의 유사성을 이용하여 전후 프레임 간의 차이를 코딩하므로 낮은 부호율로 코딩할 수 있다. 그러나, 원격 데스크톱과 원격 동영상 모니터링 등과 같은 일부 특정한 동영상 적용 환경에서 H.264, HEVC를 사용하여 코딩하는 것은 여전히 부족한 점이 있다. 이러한 환경과 일반적인 동영상 적용 환경의 차이는 주로 대부분 시간에서 동영상 내용이 유지되거나 변화가 매우 작은 것이다. 동영상 내용이 변하지 않는 시간 동안에 H.264 등과 같은 프레임 간 코딩 기술을 사용하더라도 동영상의 각 프레임을 모두 코딩해야 하므로, 여전히 어느 정도의 대역폭 점용과 유량 낭비를 초래할 수 있다.
검색 결과에 따르면, 공개 번호가 CN101889447A인 중국 발명 특허에서는 a. 복수개의 연속 동영상 프레임의 데이터를 포함하는 동영상 스트림의 데이터를 포착하는 단계; b. 상기 동영상 스트림에 대해 임의의 시간 간격으로 포착한 하나 또는 복수개의 정지 이미지를 포착하는 단계; c. 각 정지 이미지를 상기 동영상 프레임 내에 순차적으로 삽입함으로써 조합 데이터 스트림을 형성하는 단계; d. 수정된 서열 파라미터셋의 새로운 배치 속성 정의를 이용함으로써 고해상도의 정지 이미지의 존재를 전달하는 단계; e. 상기 조합 데이터 스트림을 코딩하는 단계; 및 f. 코딩된 조합 데이터 스트림을 단일층 전송으로 송신하는 단계;를 포함하는 데이터 코딩 방법을 공개한다.
또한, 공개 번호가 CN101878649A인 중국 발명 특허에서는 동영상과 직렬적으로 고해상도의 디지털 정지 화면을 코딩하는 확장 AVC 표준을 공개한다.
그러나, 상기 특허들은 여전히 전술한 문제를 해결하지 못하였다.
기존 기술의 단점을 감안하여, 본 발명의 목적은 기존 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결하는 멀티미디어 시스템의 정보 교환 메카니즘 및 네트워크 전송 방법을 제공하고, 또한 동영상 스트림에서 이미지가 변하지 않는 경우에 동영상 코딩에 의한 대역폭 점용과 유량 낭비를 감소시키는 동영상 스트림의 정지 이미지를 위한 최적화 전송 메카니즘을 제공하는 것이다.
상기 목적을 구현하기 위해, 본 발명은 아래와 같은 기술 방안에 의해 구현된다.
본 발명의 제1 측면에 따르면,
메시지 식별 필드;
메시지 버전 번호 필드;
메시지 길이 식별 필드;
현재 메시지 페이로드(payload)의 페이로드 데이터 세그먼트;를 포함하는 메시지를 사용하여 양방향의 신속한 정보 교환을 구현하는 멀티미디어 시스템의 정보 교환 메카니즘을 제공한다.
나아가, 상기 현재 메시지 페이로드(payload)의 페이로드 데이터 세그먼트는 메시지 내용 유형 식별 필드를 포함하거나 또는 리저브드 필드를 더 포함한다.
더 나아가, 상기 현재 메시지 페이로드(payload)를 나타내는 페이로드 데이터 세그먼트는,
상기 메시지의 서열번호를 나타내는 필드;
상기 메시지와 관련되는 메시지의 서열번호를 나타내는 필드;
피드백 상태를 나타내는 필드;
상기 메시지의 내용 포맷을 나타내는 필드;
상기 메시지의 내용 데이터 길이를 나타내는 필드;
현재 교환 정보를 나타내는 바이트 데이터 세그먼트;를 더 포함한다.
본 발명에서, 메시지는 대화식 교환이고, 사용자의 요청과 시스템 응답 포맷은 유기적으로 일치하며, 본 메카니즘을 지원하는 서버와 클라이언트 양자는 http 프로토콜의 인터페이스가 없더라도 멀티미디어에 대한 자원 요청 응답과 같은 경량한 교환에 적용될 수 있다. 이것은 미디어 네트워크 전송에 큰 편리를 가져다 주었다.
본 발명에서 제시하는 원활한 메시지 포맷 메카니즘에 따르면, 다양한 미디어 서비스의 구체적인 요구에 대해 정확하고 구체적인 메시지 포맷을 설계할 수 있다. 신속하고 효율적인 전송 프로토콜은 원활하고 정의 가능한 메시지 포맷과 결합하여 본 발명이 모든 미디어 전송 시스템에 적용될 수 있도록 한다.
본 발명의 제2 측면에 따르면,
단말기가 기 설정된 메시지 포맷에 따라 메시지를 데이터 패킷으로 패킹하는 단계;
데이터 패킷을 네트워크 서버로 전송하는 단계;
서버가 기 설정된 메시지 포맷에 따라 데이터 패킷에 대해 페이로드 데이터를 분석하고 해당 처리와 응답을 진행하는 단계;를 포함하며,
서버에서 단말기로의 통신은 상기 대응하는 단계를 따르는 상기 멀티미디어 시스템의 정보 교환 메카니즘을 기반으로 하는 멀티미디어 시스템 정보 데이터 교환 네트워크 전송 방법을 제공한다.
본 발명에서 제공하는 네트워크 전송 방법은 아래와 같은 단계를 더 포함한다.
네트워크 단말기에서 메시지가 기 설정한 확장 가능한 메시지 포맷 내의 구체적인 비트 페이로드 데이터 세그먼트의 포맷 또는 자체 정의한 포맷에 따라 메시지의 "PRR_data_byte" 필드를 패킹한다(단계(a)).
네트워크 단말기가 교환 메시지 본체의 포맷에 따라 메시지 전체를 패킹한다(단계(b)).
네트워크 단말기가 선정한 네트워크 통신 프로토콜 "payload" 포맷 정의에 따라 메시지를 프로토콜 "payload"에 패킹한다(단계(c)).
네트워크 단말기가 프로토콜 포맷 정의에 따라 하나 또는 복수개의 packet 네트워크 전송 데이터 패킷을 생성한다(단계(d)).
네트워크 서버가 하나 또는 복수개의 클라이언트에서 출력한 packet 데이터 패킷을 수신한 후, 데이터 패킷의 프로토콜 헤더에 따라 완전한 프로토콜급 "payload" 데이터 세그먼트를 분석한다(단계(e)).
네트워크 서버가 선정한 네트워크 프로토콜 "payload" 포맷 정의에 따라 완전한 메시지 데이터 세그먼트를 분석한다(단계(f)).
네트워크 서버가 메시지 헤더 정의에 따라 메시지의 비트 페이로드 데이터 세그먼트(즉, "PRR_data_byte" 필드에 포함된 데이터)를 분석한다(단계(g)).
네트워크 서버가 메시지가 정의한 포맷 또는 자체 정의한 포맷에 따라 비트 페이로드 데이터 세그먼트(즉, "PRR_data_byte" 필드에 포함된 데이터)를 분석하고 해당 처리와 응답을 진행한다(단계(h)).
서버단에서 네트워크 단말기로의 통신도 상기 단계를 따른다. 상기 데이터 포맷과 적용 방법은 네트워크의 양방향 통신 요구를 만족한다.
본 발명의 제3 측면에 따르면,
프로토콜 전송 포맷이 강요한 가장 단순한 데이터 패킷에 대하여, 프로토콜 포맷이 신속한 정보 교환에 적응하도록 프로토콜 포맷 헤더의 데이터 크기를 단순화하고,
데이터 패킷 아이디(Packet_id), 타임스탬프(Timestamp), 데이터 패킷 서열번호(Packet_squence_number) 등 3개의 필드 중의 어느 하나, 2개 또는 3개를 단순화하며, 바이트수가 작은 인디케이터를 이용하여 상기 3개의 필드를 사용하는지를 나타내고, 프로토콜 포맷 헤더의 데이터 바이트수를 작게 하여 프로토콜 포맷이 신속한 정보 교환에 적응하도록 하는 멀티미디어 시스템의 신속한 정보 교환 메카니즘을 제공한다.
구체적으로, 상기 프로토콜 포맷 헤더의 데이터 크기를 단순화하는 것은 기존 프로토콜 전송 포맷의 리저브드 필드를 플래그 비트로 선택하며, Packet_id, Timestamp, Packet_squence_number 등 3개의 필드를 단순화한 것의 사용 여부의 선택을 제공하고 프로토콜 포맷 헤더의 데이터 바이트수를 작게 하여 프로토콜 포맷이 신속한 정보 교환에 적응하도록 하는 것을 의미한다.
나아가, 인디케이터는 알파벳, 부호 등을 사용하는데, 그 유형이 한정되지 않는다.
나아가, 인디케이터는 T, P와 F 식별 필드를 사용하고, 각각 하나의 바이트를 점용한다.
나아가, 상기 프로토콜 포맷 헤더의 데이터 크기를 단순화하는 것은 구체적으로 기존 프로토콜 전송 포맷의 리저브드 필드를 선택하여 각각 T 식별 필드로 수정하는 것인데, 그 중 T는 timestamp_flag로서, 1로 설정하면 timestamp 필드를 사용하고 0으로 설정하면 사용하지 않으며, 교환 정보가 매우 강한 즉시성을 가지고 있을 때, 즉 클라이언트 또는 서버단이 상기 정보를 수신하자마자 바로 응답할 때 상기 필드를 0으로 설정하는데, 그 전제는 신뢰할 수 있는 베이스 통신 프로토콜을 제공하는 것이다.
나아가, 상기 프로토콜 포맷 헤더의 데이터 크기를 단순화하는 것은 구체적으로 기존 프로토콜 전송 포맷의 리저브드 필드를 선택하여 각각 P 식별 필드로 수정하는 것인데, 그 중 P는 packet_id_flag로서, 1로 설정하면 packet_id 필드를 사용하고 0으로 설정하면 사용하지 않으며, 페이로드 정보량이 작아 하나의 데이터 패킷에 넣어 전송할 수 있거나 또는 데이터를 나누어 패킹하여 베이스 프로토콜에 의해 구현할 때, 상기 필드를 0으로 설정하는데, 그 전제는 신뢰할 수 있는 베이스 통신 프로토콜을 제공하는 것이다.
나아가, 상기 프로토콜 포맷 헤더의 데이터 크기를 단순화하는 것은 구체적으로 기존 프로토콜 전송 포맷의 리저브드 필드를 선택하여 각각 TF 식별 필드로 수정하는 것인데, 그 중 F는 fragmentation_flag로서, 1로 설정하면 packet_sequence_number 필드를 사용하고 0으로 설정하면 사용하지 않으며, 이 필드와 "P" 필드를 조합하여 사용하고 "P" 필드가 0으로 되는 조건을 만족하면 이 필드를 0으로 설정한다.
본 발명에서 프로토콜 포맷 헤더의 데이터 크기를 단순화함으로써, 바이트수를 크게 감소하여 네트워크 전송의 신속성을 향상시키며, 신속한 네트워크 정보 교환에 적응할 수 있다. 나아가, 상기 신속한 네트워크 정보 교환의 전제하에, 다양한 미디어 서비스의 구체적인 요구에 따라 신속한 메시지 교환 포맷과 신속한 양방향의 자원 요청 응답 메시지 포맷을 설계할 수 있으며, 신속하고 효율적인 전송 프로토콜은 원활하고 정의 가능한 메시지 포맷과 결합하여 본 발명이 모든 미디어 전송 시스템에 적용될 수 있도록 한다.
상기 신속한 정보 교환에서, 신속하게 교환하는 메시지 실체는 시그널링 모드에서 전송된다.
나아가, 상기 신속한 정보 교환에서 신속하게 교환하는 정보 본체는,
실시간 교환 메시지의 메시지 식별 필드;
메시지 버전 번호 필드;
메시지 길이 식별 필드;
확장 필드;
현재 메시지 페이로드(payload)를 나타내는 데이터 세그먼트;를 포함한다.
더 나아가, 상이한 유형의 메시지 페이로드는 상이한 포맷을 구비하며, 그 중 실시간 교환 메시지 페이로드(payload)는,
현재 메시지 시그널링 페이로드가 확장 가능한 데이터를 포함하는지를 나타내는 하나의 확장 플래그 비트 필드;
상기 메시지 시그널링에 포함한 교환 데이터의 개수를 나타내는 필드;
현재 교환 정보의 유형을 나타내는 필드;
현재 교환 데이터 길이를 나타내는 필드;
현재 교환 정보를 나타내는 바이트 데이터 세그먼트;
사용자에 의해 자체 정의하거나 또는 미래에 확장하기 위한 데이터 포맷 데이터 세그먼트;를 포함하고,
자원 요청 응답 메시지 페이로드(payload)는,
현재 사용자가 자원을 요청하는 방법을 나타내는 자원 요청 방법 식별 필드;
현재 메시지 시그널링 페이로드가 확장 가능한 데이터를 포함하는지를 나타내는 하나의 확장 플래그 비트 필드;를 포함한다.
상기 실시간 교환 메시지 페이로드(payload)에 있어서, 본 발명은 그 범용 포맷을 미리 정의하며, 구체적인 메시지 포맷 정의를 미리 설정한다. 자원 요청 응답 메시지는 대화식 교환이고, 사용자의 요청은 시스템 응답 포맷과 유기적으로 일치하며, 본 메카니즘을 지원하는 서버와 클라이언트 양자는 http 프로토콜의 인터페이스가 없더라도 멀티미디어에 대한 자원 요청 응답과 같은 경량한 교환에 적용될 수 있다. 이것은 미디어 네트워크 전송에 큰 편리를 가져다 주었다.
본 발명의 제4 측면에 따르면,
네트워크 단말기에서 메시지가 미리 정의한 신속한 교환 메시지 페이로드 데이터 세그먼트(payload)의 포맷 또는 자체 정의한 payload 포맷에 따라 메시지의 "payload" 필드를 패킹하는 단계(a);
네트워크 단말기가 신속한 교환 메시지 본체 포맷에 따라 메시지 전체를 패킹하는 단계(b);
네트워크 단말기가 MMT(ISO/IEC 23008-1)의 기존 프로토콜 "payload" 포맷 정의에 따라 메시지를 프로토콜 "payload"에 패킹하는 단계(c);
네트워크 단말기가 프로토콜 포맷 정의에 따라 하나 또는 복수개의 packet 네트워크 전송 데이터 패킷을 생성하는 단계(d);
네트워크 서버가 하나 또는 복수개의 클라이언트에서 출력한 packet 데이터 패킷을 수신한 후, 데이터 패킷 프로토콜 헤더에 따라 완전한 프로토콜급 "payload" 데이터 세그먼트를 분석하는 단계(e);
네트워크 서버가 프로토콜 "payload" 포맷 정의에 따라 완전한 메시지 데이터 세그먼트를 분석하는 단계(f);
네트워크 서버가 메시지 헤더 정의에 따라 메시지의 "payload" 데이터 세그먼트를 분석하는 단계(g);
네트워크 서버에서 메시지가 정의한 포맷 또는 자체 정의한 포맷에 따라 메시지의 "payload" 데이터 세그먼트를 해독하고 해당 처리와 응답을 진행하는 단계(h);를 포함하는 상기 멀티미디어 시스템의 신속한 정보 교환 메카니즘을 기반으로 하는 멀티미디어 시스템에서 정보 데이터를 교환하는 네트워크 전송 방법을 제공한다.
서버단에서 네트워크 단말기로의 통신도 상기 단계를 따른다. 상기 데이터 포맷과 적용 방법은 네트워크의 양방향 통신 요구를 만족한다.
본 발명의 제5 측면에 따르면,
전 프레임의 이미지의 정지한 프레임 데이터에 대해 플래그 비트를 증가하며, 상기 플래그 비트의 정보만 전송하고 상기 프레임 데이터를 전송하지 않아 스트리밍 동영상 전송 시의 정지 이미지 프레임에 따른 대역폭 점용과 유량 낭비 문제를 해결하는 동영상 스트림의 정지 이미지를 위한 최적화 전송 메카니즘을 제공한다.
구체적으로, 상기 동영상 스트림의 정지 이미지를 위한 최적화 전송 메카니즘은 기존 동영상 전송 패킷 헤더의 포맷에 대해,
전송하는 패킷 헤더 또는 시그널링에 동영상 이미지 정지 프레임 플래그 비트를 설정하며;
동영상 전송 시, 정지한 동영상 프레임 이미지에 대응하는 데이터 패킷에 대해 패킷 헤더 또는 시그널링 중의 동영상 정지 프레임 플래그 비트 정보만 송신하고 해당 정지 프레임 데이터를 포기하며;
클라이언트가 동영상 정지 프레임 플래그 비트를 수신한 후, 전 프레임의 이미지를 이용하여 현재 프레임의 이미지를 재건한다.
바람직한 일 실시형태에서, 상기 전송하는 패킷 헤더 또는 시그널링에 동영상 정지 프레임 플래그 비트를 설정하는 것은 MMTP 패킷 헤더 내의 리저브드 필드에서 하나의 비트를 동영상 정지 프레임 플래그 비트로 추출하여 현재 MMTP 패킷에 대응하는 프레임 데이터가 전 프레임과 동일함을 나타내는 것을 의미한다.
바람직한 일 실시형태에서, 상기 전송하는 패킷 헤더 또는 시그널링에 동영상 정지 프레임 플래그 비트를 설정하는 것은 DU header 내의 priority 필드를 사용하고, 특정값으로 현재 MMTP 패킷에 대응하는 프레임 데이터가 전 프레임과 동일함을 나타내는 것을 의미한다.
기존 기술에 비해, 본 발명은 아래와 같은 유익한 효과를 가진다.
1. 본 발명의 제1 측면과 제2 측면에 따른 기술 방안을 사용함으로써, 정보 교환 메카니즘은 각종 다른 교환식 데이터의 특점에 따라 동일한 교환식 데이터의 전송 포맷을 설계할 수 있고, 동일한 교환식 데이터의 전송 단계를 통해, 통신하는 양자는 상이한 유형의 데이터에 적응하기 위해 발생한 비용을 크게 절감할 수 있으며, 나아가 메시지의 "payload" 데이터 세그먼트도 자체 정의될 수 있고 메시지 헤더 내의 리저브드 필드를 결합하면 시스템을 매우 편리하게 확장할 수 있다. 본 발명은 미디어 네트워크의 전송 효율을 효과적으로 향상시킬 수 있다.
2. 본 발명의 제3 측면과 제4 측면에 따른 기술 방안을 사용함으로써, 신속한 정보 교환 메카니즘은 각종 다른 교환식 데이터의 특점에 따라 동일한 교환식 데이터의 전송 포맷을 설계할 수 있고, 동일한 교환식 데이터의 전송 단계를 통해, 통신하는 양자는 상이한 유형의 데이터에 적응하기 위해 발생한 비용을 크게 절감할 수 있으며, 나아가 메시지의 "payload" 데이터 세그먼트도 자체 정의될 수 있고 메시지 헤더 내의 리저브드 필드를 결합하면 시스템을 매우 편리하게 확장할 수 있다. 본 발명은 미디어 네트워크의 전송 효율을 효과적으로 향상시킬 수 있다.
3. 본 발명의 제5 측면에 따른 기술 방안은 MMTP 패킷 헤더, DU header 등과 같은 현재의 동영상 데이터 전송 시의 패킷 헤더 또는 시그널링에 대해 해당 정지 프레임 플래그 비트를 설정하며, 플래그 비트만 전송하고 해당 프레임 데이터를 전송하지 않는 방법을 통해 네트워크 대역폭을 절감하여 스트리밍 동영상 전송 시 정지 이미지 프레임에 따른 대역폭 점용과 유량 낭비 문제를 해결하였다.
이하의 첨부 도면을 참조하여 상세히 설명한 비제한적인 실시예에 의해 본 발명의 다른 특징, 목적과 장점이 더욱 명확해진다.
도 1은 본 발명의 실시예 1에 따른 교환 메시지의 적용 모식도이다.
도 2는 본 발명의 실시예 2에 따른 메시지의 전달 및 분석에 관한 흐름도이다.
도 3은 본 발명의 실시예 2에 따른 MMTP의 기존 프로토콜 전송 포맷이 강요한 가장 단순한 데이터 패킷 포맷의 모식도이다.
도 4는 본 발명의 실시예 2에 따른 실시간 교환 메시지의 적용 모식도이다.
도 5는 본 발명의 실시예 2에 따른 단순화한 최소 데이터 헤더 포맷의 모식도이다.
도 6은 본 발명의 실시예 2에 따른 자원 요청 응답 메시지의 적용 모식도이다.
도 7은 본 발명의 실시예 2에 따른 MMT의 기존 payload의 헤더 데이터 포맷의 모식도이다.
도 8은 본 발명의 실시예 3에 따른 MMTP 패킷 헤더 내의 리저브드 필드를 정지 프레임 플래그 비트로 하는 모식도이다.
도 9는 본 발명의 실시예 3에 따른 DU header 내의 priority 필드를 사용하는 모식도이다.
이하에서는, 본 발명의 실시예를 상세하게 설명하고, 본 실시예는 본 발명의 기술 방안을 전제로 하여 실시하며, 상세한 실시형태과 구체적인 조작 과정을 제시한다. 해당 분야에서 통상의 지식을 가진 자라면 본 발명의 사상을 벗어나지 않고 약간의 변형과 개선을 할 수 있으며, 이것은 모두 본 발명의 보호 범위에 속할 것임을 유의해야 한다.
실시예 1
본 실시예는 기존 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결하는 멀티미디어 전송 시스템의 정보 교환 메카니즘을 제공한다. 상기 메카니즘은 동일한 교환식 데이터의 전송 포맷을 설계하고, 동일한 교환식 데이터의 전송 단계를 통해 상이한 유형의 데이터에 적응하기 위해 발생한 비용을 절감한다.
이하, 본 실시예의 세부 사항에 대해 예를 들어 설명하기로 하며, 본 실시예의 일부 실시형태에서 교환 정보 본체는,
메시지의 아이디 코드를 나타내는 메시지 식별 필드(message_id);
메시지의 버전 번호를 나타내는 메시지 버전 번호 필드(version);
메시지의 길이를 나타내는 메시지 길이 식별 필드(length);
메시지의 페이로드를 포함하고 나타내는 현재 메시지 페이로드(payload)의 페이로드 데이터 세그먼트(message_payload);를 포함한다(표 3 참조).
나아가, 본 실시예의 일부 실시형태에서 페이로드 데이터 세그먼트는,
적어도 메시지가 서버와 클라이언트 사이에서의 업링크 또는 다운링크 상태인 것을 나타내는 메시지 내용 유형 식별 필드(PRR_type)를 포함하며, 선택적으로 적어도 리저브 정보를 나타내는 리저브드 필드(reserved)를 더 포함한다.
리저브드 필드의 비트 길이와 부여값이 제한되지 않으며, 바이트 내의 비트수(하나의 바이트가 8 비트)의 정수배와 메시지 내용 유형 식별 필드의 비트수 사이의 비트수 차이에 따라 결정하는 것이 바람직하고, 표 3에 나타낸 바와 같이 바이트 내의 비트가 8이며, PRR_type은 1비트를 점용하고, 본 실시예에서는 리저브드 필드를 7비트로 설정하고 부여값을 "1111111"로 하며, 8의 정수배로 하여 정보 처리에 편리하도록 한다.
그 중, 메시지 내용 유형 식별 필드는 상이한 부여값을 통해 각각 업링크 또는 다운링크 상태를 나타낸다. 하기 표 1의 PRR_type 필드 값과 같이, 메시지 내용 유형 식별 필드는 부여값 0을 통해 업링크 상태를 나타내며, 부여값 1을 통해 다운링크 상태를 나타낸다.
PRR_type 필드 값
값 조작
0 POST 업링크 전송
1 POST 다운링크 전송
더 나아가, 메시지 내용 유형 식별 필드가 상기 업링크 상태일 때, 즉 본 실시예에서 상기 부여값 "0"에 대응하는 경우 메시지는,
상기 메시지의 서열번호를 나타내고, 상기 메시지의 업링크 서열번호를 나타내는 메시지 업링크 서열번호 식별 필드;
상기 메시지의 내용 포맷을 나타내고, 업링크 바이트 데이터 세그먼트의 포맷을 나타내는 내용 포맷 필드;
상기 메시지의 내용 데이터의 길이를 나타내고, 업링크 바이트 데이터 세그먼트의 길이를 나타내는 내용 길이 필드;
현재 교환 정보의 바이트 데이터 세그먼트, 즉 현재 교환이 업링크 상태일 때의 바이트 스트림을 포함하는 업링크 바이트 데이터 세그먼트;를 포함한다.
더 나아가, 메시지 내용 유형 식별 필드가 상기 다운링크 상태일 때, 즉 본 실시예에서 부여값 "1"에 대응하는 경우 상기 메시지는,
상기 메시지와 관련되는 메시지의 서열번호를 나타내고, 상기 메시지의 다운링크 서열번호를 나타내는 메시지 다운링크 서열번호 식별 필드;
상태를 피드백하고, 현재 교환이 다운링크 상태일 때의 바이트 스트림을 포함하고 나타내는 필드, 즉 다운링크 바이트 데이터 세그먼트;를 포함하며,
상기 다운링크 서열번호와 상기 업링크 서열번호 사이가 상호 관련되며, 상기 관련 방식은 업링크와 다운링크 시 서열번호가 동일하고, 기 설정한 방식이 대응하는 것을 포함한다.
status_number 필드값
값 조작
0x00 POST 업링크 정보 전송 실패, 기 설정된 시간 내에 수신 미완성
0x01 POST 업링크 정보 전송 성공
0x02 POST 업링크 정보 전송 성공, 상기 메시지가 피드백 데이터를 포함
0x03~0x7F ISO 표준 리저브
0x80~0xFF 사설 필드 리저브
상기 표 2에 나타낸 바와 같이, 본 실시예에서 피드백 상태 필드는 상이한 부여값을 통해 적어도 3개의 피드백 상태, 즉 표 2의 0x00, 0x01 및 0x02에 대응하는 3개의 피드백 상태를 대응하게 나타내는데, 상기 상태는 각각정보의 업링크 전송이 실패하고, 적어도 기 설정된 시간 내에 수신을 완성하지 못한 경우를 포함하는 제1 피드백 상태;
정보의 업링크 전송이 성공한 제2 피드백 상태; 및
정보의 업링크 전송이 성공하고, 상기 메시지가 피드백 데이터로 이해할 수 있는 다운링크 바이트 스트림을 포함하는 제3 피드백 상태이다.
더욱 바람직하게는, 본 실시예에서 상기 3개의 피드백 상태 이외에, ISO 표준 리저브 상태인 제4 피드백 상태 및 사설 필드 리저브 상태인 제5 피드백 상태를 더 제공하며, 리저브드 피드백 상태로서 어느 하나, 2개 또는 복수개를 포함한다. 각 피드백 상태와 부여값 사이의 대응 관계는 표 2에서 알 수 있다.
더 나아가, 피드백 상태를 나타내는 필드는 상기 제3 피드백 상태, 즉 본 실시예에서 부여값이 "0x02"에 대응하는 경우(양호한 호환성을 유지하도록 피드백 상태 필드의 부여값은 표준 Hypertext Transfer Protocol (HTTP) 프로토콜의 상태 코드 status codes를 참조하여 값을 정할 수 있음), 상기 메시지는,
현재 교환 정보를 나타내는 바이트 데이터 세그먼트, 즉 현재 교환하는 상기 다운링크 바이트 내용;
상기 메시지의 내용 포맷을 나타내며 상기 다운링크 바이트 스트림의 내용 포맷을 나타내는 필드;
상기 메시지의 내용 데이터의 길이를 나타내고 상기 다운링크 바이트 스트림의 내용 길이를 나타내는 필드;를 포함한다.
상술한 바와 같이, 본 출원에서 메시지의 전체 데이터 포맷의 구조는 아래의 교환 메시지 포맷을 나타내는 표 3을 참조할 수 있다.
Figure 112018081098065-pct00001
상기 표 3에서, Uimsbf는 무부호 정수, 즉 "unsinged integer, most significant bit first"를 나타내고, 숫자는 상기 데이터가 차지하는 비트수를 나타낸다. Bslbf는 비트 스트링, 즉 "Bit string, left bit first"를 나타낸다.
상기 표 3은 본 발명의 실시예의 바람직한 일 형태에 불과하고, 각 필드, 데이터, 내용의 길이, 위치와 포맷을 한정하기 위한 것이 아님을 유의해야 할 것이다.
본 실시예는 또한 상기 멀티미디어 전송 시스템의 정보 교환 메카니즘을 기반으로 하는 정보 데이터 교환 네트워크 전송 방법을 제공하며, 일 실시형태에서 본 실시예에 따른 메시지 데이터의 네트워크 전송 방법은 네트워크 단말기와 네트워크 서버 사이에 적용된다. 구체적으로, 아래와 같은 단계를 포함한다.
네트워크 단말기에서 메시지가 미리 정의한 교환 메시지 본체 포맷 내의 구체적인 비트 페이로드 데이터 세그먼트의 포맷 또는 자체 정의한 포맷에 따라 메시지의 "PRR_data_byte" 필드를 패킹한다(단계(a)).
네트워크 단말기가 교환 메시지 본체 포맷에 따라 메시지 전체를 패킹한다(단계(b)).
네트워크 단말기가 선정한 네트워크 통신 프로토콜 "payload" 포맷 정의에 따라 메시지를 프로토콜 "payload"에 패킹한다(단계(c)).
네트워크 단말기가 프로토콜 포맷 정의에 따라 하나 또는 복수개의 packet 네트워크 전송 데이터 패킷을 생성한다(단계(d)).
네트워크 서버가 하나 또는 복수개의 클라이언트에서 출력한 packet 데이터 패킷을 수신한 후, 데이터 패킷 프로토콜 헤더에 따라 완전한 프로토콜급 "payload" 데이터 세그먼트를 분석한다(단계(e)).
네트워크 서버가 선정한 네트워크 프로토콜 "payload" 포맷 정의에 따라 완전한 메시지 데이터 세그먼트를 분석한다(단계(f)).
네트워크 서버가 메시지 헤더의 정의에 따라 메시지의 비트 페이로드 데이터 세그먼트(즉, "PRR_data_byte" 필드에 포함된 데이터)를 분석한다(단계(g)).
네트워크 서버에서 메시지가 정의한 포맷 또는 자체 정의한 포맷에 따라 비트 페이로드 데이터 세그먼트(즉, "PRR_data_byte" 필드에 포함된 데이터)를 분석하고 해당 처리와 응답을 진행한다(단계(h)).
서버단에서 네트워크 단말기로의 통신도 상기 단계를 따른다. 상기 데이터 포맷과 적용 방법은 네트워크의 양방향 통신 요구를 만족한다.
일 실시형태에서, 본 실시예의 상기 메시지 포맷으로 사용자가 자체 정의한 json 포맷의 메시지를 전송하는 내용을 예로 하여 메시지 교환 절차를 설명한다. 본 실시예는 양호한 확장성과 원활성을 가지고 있고, 사용자가 매우 편리하게 json등 포맷을 사용하여 자신이 정의한 정보를 전송할 수 있다. 그 실제 절차는 다음과 같다.
정보 내용을 json 파일에 삽입한다. 예를 들어, 사용자가 프로그램을 클릭하여 재생하는 동안, 플레이어의 프로그래스 바를 드래깅하여 프로그램의 어느 한 시점에 바로 진입하여 시청한다. 상기 시점 정보를 업로드하여 특정한 위치부터 데이터 패킷을 획득하기 시작한다. 상기 요청에 따라 생성한 json 파일의 내용은,
{"eventType" : "request_movie_by_time", "movieID" : "123", "time" : "17:50"}이다.
상기 예에서, "PRR_type" 필드값은 "0"으로 설정하고, "POST_serial_number" 필드값은 "111"로 설정하며, "mime_type()" 필드값은 mime 표준에 따라 json 파일 유형에 대응하는 값으로 설정한다.
상기 json 파일을 bit 스트림로서 메시지의 "PRR_data_byte" 데이터 세그먼트에 삽입한 후 메시지를 송신하면 되는데, 구체적인 메시지 전송 베이스는 임의의 적합한 프로토콜과 물리 계층을 사용할 수 있다.
서버는 상기 업로드한 메시지를 수신한 후 분석하여 피드백 정보를 출력한다. 피드백 정보 내용도 json 포맷으로 편집한다. 서버가 출력하는 다운로드 메시지에 대해, 그 구체적인 값은 다음과 같이 설정한다.
"PRR_type" 필드값은 "1"로 설정하고, "Response_number" 필드값은 "111"로 설정하며, "status_number" 필드값은 "0x02"로 설정하고, "mime_type()" 필드값은 mime 표준에 따라 json 파일 유형에 대응하는 값으로 설정한다. 상기 json 파일을 bit 스트림으로서 메시지의 "PRR_data_byte" 데이터 세그먼트에 삽입한 후, 메시지를 송신한다.
상기 과정은 도 1을 참조할 수 있다.
비표준 정보 포맷을 통해 정보를 교환하는 방식은 상이한 서버와 클라이언트에 따라 끊임없이 반복하여 개발해야 한다. 본 발명에 따르면, 정보 포맷을 표준화함으로써 멀티미디어 전송 네트워크를 구축하는 복잡성을 효과적으로 낮출 수 있다.
이상은 본 발명의 일부 실시예에 불과하고, 본 발명은 다른 전송 시스템에도 적용할 수 있으며, 구체적인 서비스 요구에 따라 전송할 네트워크 교환 정보 데이터를 추출하고 정보 데이터를 메시지의 "payload" 내의 "PRR_data_byte" 데이터 세그먼트에 삽입한 후 정보 데이터를 교환하는 네트워크 전송 방법에서 설명한 단계에 따라 구현할 수 있으며, 해당 분야에서 통상의 지식을 가진 자라면 본 발명에서 설명한 기술 방안을 바탕으로 하여 쉽게 이해할 수 있음을 이해해야 할 것이다.
실시예 2
본 실시예는 프로토콜 전송 포맷이 강요한 가장 단순한 데이터 패킷에 대하여 프로토콜 포맷이 신속한 정보 교환에 적응하도록 프로토콜 포맷 헤더의 데이터 크기를 단순화하고, 신속한 메시지 교환 포맷과 신속한 양방향의 자원 요청 응답 메시지 포맷을 더 설계하여 모든 미디어 전송 시스템에 적용될 수 있도록 하는 또 다른 멀티미디어 전송 시스템의 신속한 정보 교환 메카니즘을 제공하고, 또한 상기 신속한 정보 교환에서 사용하는 데이터 포맷을 적용하여 기존 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결하는 네트워크 전송 방법을 제공한다.
이하, 일부 실시예를 제공하여 본 실시예의 세부 사항에 대해 예를 들어 설명한다.
(1) 프로토콜의 개선
본 실시예의 교환 정보의 프로토콜 포맷은 MMTP 프로토콜을 개선하여 효율적이고 신속한 네트워크 정보 교환에 적응되도록 하며, 또한 적용 범위를 모든 미디어 전송 시스템으로 확장하고 MMTP 프로토콜에만 제한되지 않도록 한다.
선정 가능한 필드 이외에, MMTP의 기존 프로토콜 전송 포맷이 강요한 가장 단순한 데이터 패킷은,
프로토콜 버전을 나타내는 필드 "V";
"packet_counter" 데이터 세그먼트의 존재 여부를 나타내는 식별 필드 "C";
"FEC"(순방향 오류 정정) 데이터 세그먼트의 존재 여부를 나타내는 식별 필드 "FEC";
확장 헤더의 데이터 세그먼트의 존재 여부를 나타내는 식별 필드 "X";
상기 페이로드 정보 내용이 랜덤 액세스 포인트(Random Access Point) 특성을 가지고 있는지를 나타내는 식별 필드 "R";
리저브드 필드 "r"과 "RES";
페이로드 정보 유형을 나타내는 식별 필드 "Type";
Packet_id 식별 필드;
Timestamp 타임스탬프 필드;
Packet_sequence_number 서열번호 식별 필드;를 포함한다.
이들의 바이트 포맷은 도 3에 나타낸 바와 같다.
본 실시예는 효율적이고 신속하게 정보를 교환하는 요구에 따라, 기존 포맷의 리저브드 필드(즉, r 및 RES 필드)를 플래그 비트로 사용하며, Packet_id, Timestamp, Packet_squence_number 등 3개의 필드를 단순화함으로써 프로토콜 포맷 헤더의 데이터 크기를 효과적으로 단순화하였다.
기존 리저브드 필드 위치 r(1 bit)을 T 식별 필드로 수정한다.
T는 timestamp_flag로서, 1로 설정하면 timestamp 필드를 사용하고 0으로 설정하면 사용하지 않는다. 교환 정보가 매우 강한 즉시성을 가지고 있을 때, 즉 클라이언트 또는 서버단이 상기 정보를 수신하자마자 바로 응답을 할 때 상기 필드를 0으로 설정할 수 있는데, 그 전제는 신뢰할 수 있는 베이스 통신 프로토콜을 제공하는 것이다.
기존 리저브드 필드 위치 RES(2 bits)를 P와 F 식별 필드(각각 1 bit)로 수정한다.
P는 packet_id_flag로서, 1로 설정하면 packet_id 필드를 사용하고 0으로 설정하면 사용하지 않는다. 페이로드 정보량이 작아 하나의 데이터 패킷에 넣어 전송할 수 있거나 또는 데이터를 나누어 패킹하여 베이스 프로토콜에 의해 구현할 때 상기 필드를 0으로 설정할 수 있는데, 그 전제는 신뢰할 수 있는 베이스 통신 프로토콜을 제공하는 것이다.
F는 fragmentation_flag로서, 1로 설정하면 packet_sequence_number 필드를 사용하고 0으로 설정하면 사용하지 않는다. 상기 필드는 일반적으로 "P" 필드와 조합하여 사용하는데, "P" 필드가 0으로 설정되는 조건을 만족할 때 상기 필드도 0으로 설정할 수 있다.
기존 MMT의 각 필수 필드를 결합하면, 단순화한 최소 데이터 헤더 포맷은 도 5에 나타낸 바와 같다.
단순화한 가장 단순한 프로토콜 포맷은 바이트수가 크게 감소되어 네트워크 전송의 속도를 향상시켰다.
호환성을 더 양호하게 유지하기 위해, 신속하게 교환하는 메시지 실체는 MMTP의 시그널링 모드에서 전송할 수 있으며, 여기서 언급한 MMT의 기존 payload의 헤더 데이터 포맷은 다음과 같다(도 7을 참조).
MMTP의 시그널링 모드의 데이터 헤더 부분은,
파편의 조합을 나타내는 필드 "f_i";
데이터 세그먼트가 하나의 시그널링만 포함하는지를 나타내는 필드 "A";
나머지 조합할 파편의 개수를 나타내는 필드 "frag_counter";
리저브드 필드 "res";
정보 길이 필드의 길이를 나타내는 필드 "H";
정보 길이를 나타내는 필드 "MSG_length";를 포함한다.
그러나, 다시 강조해야 할 것은, 본 실시예는 MMT 프로토콜의 적용 환경만에 제한되는 것이 아니라, 메시지 페이로드 데이터 세그먼트(payload) 포맷이 원활하고 정의할 수 있으므로 본 실시예의 메시지 메카니즘은 이론적으로 임의의 미디어 시스템의 정보 교환 전송에 적용될 수 있다.
(1)신속하게 교환하는 정보 본체의 포맷
신속하게 교환하는 정보 본체는,
실시간으로 교환하는 메시지의 메시지 식별 필드;
메시지의 버전 번호 필드;
메시지 길이 식별 필드;
확장 필드;
현재 메시지 페이로드(payload)를 나타내는 데이터 세그먼트;를 포함하고,
구체적인 일 실시형태는 아래의 포맷을 사용할 수 있다.
포맷
문법 값 비트수 포맷
message () {
message_id
version
length
extension
message_payload {
}
}




16
8
16/32
uimsbf
uimsbf
uimsbf
더 구체적으로, 상기 상이한 유형의 메시지 페이로드는 상이한 구체적인 포맷을 구비하며, 이에 따라 본 실시예는 다양한 메시지 요구를 원활하고 효율적으로 만족시킬 수 있음을 알 수 있다. 일 실시형태에서, 아래와 같은 메시지 페이로드의 구체적인 포맷을 사용할 수 있다.
1)실시간 교환 메시지 페이로드(payload)의 정의
실시간 교환 메시지(Real-time Interaction Message, RIC_message)는 실시간 교환 데이터를 전송한다. 상기 메시지의 주요 특점은 메시지의 데이터량이 작고 빈도가 높아 업로드 즉시성에 대한 요구가 높은 일부 환경의 요구를 만족할 수 있는 것이다. 그 범용 포맷을 미리 정의하고, 구체적인 메시지 포맷의 정의를 미리 설정하는 것도 본 실시예의 일부로 간주해야 한다.
실시간 교환 메시지 페이로드는,
현재 메시지의 시그널링 페이로드가 확장 가능한 데이터를 포함하는지를 나타내는 하나의 확장 플래그 비트 필드;
상기 메시지의 시그널링에 포함한 교환 데이터의 개수를 나타내는 필드;
현재 교환 정보의 유형을 나타내는 필드;
현재 교환 데이터의 길이를 나타내는 필드;
현재 교환 정보를 나타내는 바이트 데이터 세그먼트;
사용자가 자체 정의하거나 미래에 확장하기 위한 데이터 포맷 데이터 세그먼트;를 포함하고,
전체 데이터 포맷의 구조는 아래의 실시간 교환 메시지 포맷 테이블을 참조할 수 있다.
Figure 112018081098065-pct00002
2)자원 요청 응답 메시지 페이로드(payload)의 정의
자원 요청 응답 메시지(Resource Request/Response Message, 3R_message)의 주요 특점은 대화식 교환이고, 사용자의 요청은 시스템 응답 포맷과 유기적으로 일치한 것이다. 본 메시지는 http 프로토콜 메카니즘의 설계 사상 및 장점을 구비하며, 미디어 네트워크에서 가장 널리 적용되고 있는 클라이언트가 서버단으로부터 자원을 획득하기 위한 네트워크 교환을 새롭게 설계하였다. 이에 따라, 본 메카니즘을 지원하는 서버와 클라이언트 양자는 http 프로토콜의 인터페이스가 없더라도 멀티미디어에 대한 자원 요청 응답과 같은 경량한 교환에 적용될 수 있다. 이것은 미디어 네트워크 전송에 큰 편리를 가져다 주었다.
도 6은 자원 요청 응답 메시지의 적용 모식도이고, 그 중 자원 요청 응답 메시지는 현재 사용자가 자원을 요청하는 방법을 나타내는 자원 요청 방법 식별 필드를 포함하며, 그 값과 설명은 아래의 표를 참조한다.
값 설명
00b "REQUEST_GET"
01b "REQUEST_POST"
10b "RESPONSE_GET"
11b "RESPONSE_POST"
또한, 현재 메시지 시그널링 페이로드가 확장 가능한 데이터를 포함하는지를 나타내는 하나의 확장 플래그 비트 필드를 포함한다.
더 구체적으로, 현재 사용자가 자원을 요청하는 방법의 유형을 나타내는 필드의 부여값이 "REQUEST_GET"에 대응하는 경우,
사용자가 GET 방식을 사용하여 자원을 요청하는 URL 정보 길이 필드;
사용자가 GET 방식을 사용하여 자원을 요청하는 URL 구체 내용 필드;를 포함한다.
더 구체적으로, 현재 사용자가 자원을 요청하는 방법 유형을 나타내는 필드의 부여값이 "REQUEST_POST"에 대응하는 경우,
현재 사용자가 POST 방식을 사용하여 자원을 요청하는 데이터 유형을 나타내는 필드를 포함하며, 그 값과 설명은 아래의 표를 참조한다.
값 설명
0x0000 Asset/Asset_edit
0x0001 MPU
0x0002 MPU 헤더 데이터
0x0003 MPU 미디어 실체 데이터
0x0004 시그널링 데이터
0x0005 데이터 베이스의 데이터
0x0006 일반화 파일
0x0007~0x7FFF Reserved for ISO
0x80000~0xFFFF Reserved for private
더 구체적으로, 그 중 상기 POST 방식으로 자원을 요청하는 데이터 유형을 나타내는 필드의 부여값이 "0x0000"인 경우,요청하는 미디어 자원을 추적하고 ISO/IEC 23008-1에 의해 정의되며 요청하는 자원을 나타내는 유일한 Asset 식별자 필드;
현재 메시지가 요청하는 Asset의 편집 번호를 나타내는 필드;를 포함하고, 상이한 편집 번호는 미디어 자원의 상이한 편집 버전에 대응하며, 그에 포함되는 MPU 대응 관계는 관련 설명에서 획득할 수 있고, 그 중 완전한 버전의 edit_id 필드값은 0으로 내정하며, 프로토콜이 편집 번호 방식을 지원하지 않으면 상기 필드도 0으로 설정한다.
더 구체적으로, 그 중 상기 POST 방식으로 자원을 요청하는 데이터 유형을 나타내는 필드의 부여값이 "0x0001", "0x0002" 또는 "0x0003"인 경우,
요청하는 미디어 자원을 추적하고 ISO/IEC 23008-1에 의해 정의되며 요청하는 자원을 나타내는 유일한 Asset 식별자 필드;
구체적인 미디어 처리 유닛을 추적하고 ISO/IEC 23008-1에 의해 정의되며 미디어 처리 유닛의 미디어 자원에서의 유일한 서열번호를 나타내는 필드;를 포함한다.
더 구체적으로, 그 중 상기 POST 방식으로 자원을 요청하는 데이터 유형을 나타내는 필드의 부여값이 "0x0004"인 경우,
ISO/IEC 23008-1에 의해 정의되고 자원 집합 package를 나타내는 유일한 식별자 필드;
시그널링의 유형을 식별하고 ISO/IEC 23008-1에 의해 정의되며 상기 자원 집합과 관련된 시그널링의 정보 유형을 나타내는 유일한 식별자 필드;
시그널링의 업데이트 버전을 식별하고 ISO/IEC 23008-1에 의해 정의되며 상기 자원 집합과 관련된 시그널링 정보를 나타내는 버전 번호 필드;를 포함한다.
더 구체적으로, 그 중 상기 POST 방식으로 자원을 요청하는 데이터 유형을 나타내는 필드의 부여값이 "0x0005"인 경우,
구체적인 사용자 계정을 추적하고 사용자 계정을 나타내는 유일한 식별자 필드;
데이터 베이스의 유형을 설명하고 구체적인 값과 유형이 적용에 따라 정의할 수 있으며, 업로드하는 데이터 베이스의 유형을 나타내는 필드;
서버에서 사용자의 데이터 베이스를 유지하고 업데이트하며, 업로드하는 데이터 베이스의 데이터 버전을 나타내는 필드;
업로드하는 데이터 베이스의 데이터 세그먼트의 길이를 나타내는 필드;
업로드하는 데이터 베이스의 데이터 세그먼트 필드;를 포함한다.
더 구체적으로, 그 중 상기 POST 방식으로 자원을 요청하는 데이터 유형을 나타내는 필드의 부여값이 "0x0006"인 경우,
서버가 해당 파일 포맷에 따라 데이터를 분석하도록 하고 사용자가 업로드하는 일반화 파일 MIME의 유형을 나타내는 필드;
업로드하는 일반화 파일의 데이터 세그먼트의 길이를 나타내는 필드;
업로드하는 일반화 파일의 데이터 세그먼트 필드;를 포함한다.
더 구체적으로, 현재 사용자가 자원을 요청하는 방법의 유형을 나타내는 필드의 부여값이 "RESPONSE_GET"에 대응하는 경우,
서버의 피드백 상태를 설명하는 필드를 포함하고, 그 값과 설명은 아래의 표를 참조한다.
값 설명
0x00 요청 실패, 요청한 자원이 서버에 나타나지 않음
0x01 요청 성공
0x02 요청 성공, 요청한 응답 헤더 또는 데이터가 상기 응답에 따라 피드백
0x03 요청 성공, 요청한 응답 헤더 또는 데이터가 지정한 packet_id의 스트림 페이로드에서 피드백
0x04~0x7F Reserved for ISO
0x80~0xFF Reserved for private use
더 구체적으로, 그 중 서버의 피드백 상태를 나타내는 필드의 부여값이 "0x02"인 경우,클라이언트에 미리 알려주어 상기 자원을 소비할 수 있는지를 미리 검사하도록 하며 서버가 피드백한 사용자 요청 데이터의 MIME 유형을 나타내는 필드;
피드백 내용의 바이트 길이를 나타내는 필드;
피드백 내용을 나타내는 데이터 세그먼트 필드;를 포함한다.
더 구체적으로, 현재 사용자가 자원을 요청하는 방법의 유형을 나타내는 필드의 부여값이 "RESPONSE_POST"인 경우,
서버의 피드백 상태를 설명하는 필드를 포함하며, 그 값과 설명은 상기 표를 참조한다.
더 구체적으로, 그 중 서버의 피드백 상태를 나타내는 필드의 부여값이 "0x03"인 경우,
값이 Asset_id 값과 일일이 대응하고 ISO/IEC 23008-1에 의해 정의되며 피드백 자원이 위치하는 전송 패킷을 지시하고 전송 패킷의 번호를 나타내는 유일한 필드;
사용자가 자체 정의하거나 미래에 확장하기 위한 데이터 세그먼트;를 포함한다.
데이터 포맷 전체 구조는 아래의 자원 요청 응답 메시지 포맷 테이블을 참조할 수 있다.
Figure 112018081098065-pct00003
3)메시지 교환 절차
본 실시예에서 제공하는 정보 데이터를 교환하는 네트워크 전송 방법은 아래와 같은 단계를 포함한다.
네트워크 단말기에서 메시지가 미리 정의한 신속한 교환 메시지 페이로드 데이터 세그먼트(payload)의 포맷 또는 자체 정의한 payload 포맷에 따라 메시지 "payload" 필드를 패킹한다(단계(a)).
네트워크 단말기가 신속한 교환 메시지 본체 포맷에 따라 메시지 전체를 패킹한다(단계(b)).
네트워크 단말기가 MMT(ISO/IEC 23008-1)의 기존 프로토콜 "payload" 포맷 정의에 따라 메시지를 프로토콜 "payload"에 패킹한다(단계(c)).
네트워크 단말기가 프로토콜 포맷 정의에 따라 하나 또는 복수개의 packet 네트워크 전송 데이터 패킷을 생성한다(단계(d)).
네트워크 서버가 하나 또는 복수개의 클라이언트에서 출력한 packet 데이터 패킷을 수신한 후, 데이터 패킷 프로토콜 헤더에 따라 완전한 프로토콜급 "payload" 데이터 세그먼트를 분석한다(단계(e)).
네트워크 서버가 프로토콜 "payload" 포맷 정의에 따라 완전한 메시지 데이터 세그먼트를 분석한다(단계(f)).
네트워크 서버가 메시지 헤더 정의에 따라 메시지의 "payload" 데이터 세그먼트를 분석한다(단계(g)).
네트워크 서버가 메시지가 정의한 포맷 또는 자체 정의한 포맷에 따라 메시지의 "payload" 데이터 세그먼트를 해독하고 해당 처리와 응답을 진행한다(단계(h)).
서버단에서 네트워크 단말기로의 통신도 상기 단계를 따른다. 상기 데이터 포맷과 적용 방법은 네트워크의 양방향 통신 요구를 만족한다.
나아가, 일 실시형태에서 본 실시예에 따른 메시지 데이터의 네트워크 전송 방법은 네트워크 단말기와 네트워크 서버 사이에 적용된다.
1) 특정한 데이터를 피드백하는 실시간 교환 메시지
이하, 클라우드 데스크톱 애플리케이션에서 상기 신속한 데이터 교환 유형을 사용하여 실시간으로 서버단에 데이터를 피드백해야 하는 마우스와 키보드 등의 구체적인 전송 방법을 설명한다.
하기 방식에 따라 필드값을 결정한다.
메시지 아이디 필드를 사용하여 어느 한 특정값으로 상기 전송 데이터가 교환 데이터 전송에 적용하는 것을 나타내고;
메시지 중의 버전을 사용하여 현재 시간 데이터가 해당 시간 내에서의 서열번호를 나타내며, 하나의 메시지를 업데이트할 때마다 해당 필드값에 1을 더하고, 최대치에 도달하면 다시 0으로 리셋한다.
메시지 중의 메시지 데이터 유형을 사용하여 상이한 유형의 마우스, 키보드 등의 실시간 교환 이벤트를 나타낸다.
대응하는 교환 데이터 유형의 선택은 표 10을 참조한다.
실시간 교환 정보의 데이터 유형(interaction_data_type)
값 설명
0x0000 키보드의 하나의 키를 누르는 것을 나타냄
0x0001 키보드의 하나의 키를 놓아주는 것을 나타냄
0x0002 키보드의 지시등 키의 상태를 나타냄
0x0003 마우스의 스크린에서의 절대 위치를 나타냄
0x0004 마우스의 이동 조작을 나타냄
0x0005 마우스의 하나의 버튼을 누르는 것을 나타냄
0x0006 마우스의 하나의 버튼을 놓아주는 것을 나타냄
0x0007~0x7FFF Reserved for ISO
0x80000~0xFFFF Reserved for private
메시지 중의 교환 데이터 길이를 사용하여 현재 이벤트에 대응하는 데이터의 크기를 나타내며, 대응하는 교환 데이터의 데이터 정의는 표 11과 같다.
Figure 112018081098065-pct00004
이이서, 도 4의 구조에 따라 데이터 세그먼트를 순차적으로 삽입한다. 메시지의 "payload" 데이터 세그먼트를 완전히 삽입한 후, 상기 "메시지 교환 절차"에 따라 메시지를 송신한다.
자이로 데이터, 가속계 데이터, 자기 나침반 데이터, 조종간 데이터, 촉각 피드백 데이터, 힘 피드백 데이터와 같은 가상/현실 장비의 다양한 업링크 데이터는 모두 해당 교환 데이터 유형과 교환 데이터 포맷을 정의함으로써 미디어 시스템에서의 전송을 구현할 수 있다.
2) 본 실시예의 메시지 포맷에 의한 사용자 자체 정의한 json 포맷의 메시지 내용의 전송
본 실시예는 양호한 확장성과 원활성을 가지고 있고, 사용자가 매우 편리하게 json등 포맷을 사용하여 자신이 정의한 정보를 전송할 수 있다. 실제 절차는 다음과 같다.
표 12를 참조하여, 정의하지 않는 사설 필드 리저브 값을 선택하여 현재 메시지의 메시지 아이디 값으로 한다.
Figure 112018081098065-pct00005
정보 내용을 json 파일에 삽입한다. 예를 들어, 사용자가 프로그램을 클릭하여 재생하는 동안, 플레이어의 프로그래스 바를 드래깅하여 프로그램의 어느 한 시점에 바로 진입하여 시청한다. 상기 시점 정보를 업로드하여 특정한 위치부터 데이터 패킷을 획득하기 시작한다. 상기 요청에 따라 생성한 json 파일의 내용은,
{"eventType" : "request_movie_by_time", "movieID" : "123", "time" : "17:50"}이다.
상기 json 파일을 bit 스트림으로서 메시지의 "payload" 데이터 세그먼트에 삽입한 후, 상기 "메시지 교환 절차"에 따라 메시지를 송신한다.
비표준 정보 포맷을 통해 정보를 교환하는 방식은 상이한 서버와 클라이언트에 따라 끊임없이 반복하여 개발해야 한다. 본 실시예에 따르면, 정보 포맷을 표준화함으로써 멀티미디어 전송 네트워크를 구축하는 복잡성을 효과적으로 낮출 수 있다. 이와 동시에, 프로토콜을 개선함으로써 네트워크 정보 교환의 성능을 대폭 향상시킬 수 있다. 특히, 네트워크의 대역폭이 체증되는 경우 사용자의 만족도가 크게 향상된다.
본 실시예에서 제공하는 멀티미디어 시스템의 신속한 정보 교환 메카니즘은 주로 프로토콜 포맷이 신속한 정보 교환에 적응하도록 프로토콜 포맷 헤더의 데이터 크기를 단순화하고, 또한 메시지 교환 포맷과 교환 방법에 대해 설계하여 모든 미디어 전송 시스템에 적용될 수 있도록 한다.
이상은 본 실시예의 일부 실시예에 불과하고, 본 실시예는 다른 전송 시스템에 적용할 수도 있으며, 구체적인 서비스 요구에 따라 전송할 네트워크 교환 정보 데이터를 추출하고, 정보 데이터를 메시지의 "payload" 데이터 세그먼트에 삽입한 후 정보 데이터를 교환하는 네트워크 전송 방법에서 설명한 단계에 따라 구현할 수 있으며, 해당 분야에서 통상의 지식을 가진 자라면 본 실시예에서 설명하는 기술 방안을 바탕으로 하여 쉽게 이해할 수 있음을 이해해야 할 것이다.
상술한 2개의 실시예에서는 2가지 상이한 형식의 멀티미디어 시스템에서 정보 데이터를 교환하는 전체 네트워크 전송 방법과 메카니즘을 구현하였으며, 그 중 실시예 2는 전송 메카니즘의 구체적인 프로토콜 포맷 헤더의 데이터 크기를 단순화함으로써 Packet_id, Timestamp, Packet_squence_number 등 3개의 필드를 사용하는지의 플래그 비트를 제공하여 프로토콜 포맷 헤더의 데이터 바이트수를 작아지게 하고, 실시예 1과 실시예 2는 상이한 유형의 메시지를 설계함으로써 상이한 임무를 완성하는데, 예를 들어 실시간 교환 메시지는 교환 조작 정보를 전달하는 것이고, 자원 요청 응답 메시지는 서버와 교환을 진행하여 자원을 요청하거나 데이터를 업로드하는 것이며, 구체적인 메시지를 교환 메시지 포맷(PRR), 자원 요청 응답 메시지 포맷(3R), 실시간 교환 메시지 포맷(RIC)과 같은 포맷으로 패킹하고, 최종적으로 기존의 미디어 전송 시스템에서 효율적이고 신속한 양방향의 정보 교환 메카니즘이 결핍되는 단점을 해결한다.
실시예 3
본 실시예는 동영상 스트림의 정지 이미지를 위한 최적화 전송 메카니즘을 제공한다.
본 실시예에서, 동영상이 전송하는 MMTP 패킷 헤더, DU header와 같은 패킷 헤더 또는 시그널링에 정지 프레임 플래그 비트를 설정하여 상기 데이터 패킷에 포함한 동영상의 데이터 페이로드가 비어 있음을 지시하며, 그에 대응하는 프레임 데이터는 전 프레임과 동일하다. 새롭게 첨가한 플래그 비트는 MMTP 패킷 헤더, DU header 또는 시그널링 등 위치에 놓을 수 있고, 이하에서 2가지의 구체적인 해결 방안을 제출한다.
1． MMTP 패킷 헤더 내의 리저브드 필드에서 하나의 비트를 정지 프레임 플래그 비트로 추출하여 현재 MMTP 패킷에 대응하는 프레임 데이터가 전 프레임과 동일함을 지시한다.
기존 시스템의 호환성을 고려하여 MMTP 패킷 헤더의 리저브드 필드에서 하나의 비트를 플래그 비트로 추출하여 상기 MMTP 패킷에 대응하는 동영상 프레임 데이터가 전 프레임과 동일함을 지시한다.
MMTP 패킷 헤더의 리저브드 필드는 static_frame_flag로 정의하며, 구체적인 내용은 다음과 같다.
static_frame_flag(S)는 현재 데이터 패킷에 대응하는 프레임 데이터가 정지 프레임인지를 지시하며, 필드가 0으로 설정하면 상기 데이터 패킷에 대응하는 프레임 데이터가 정지 프레임이 아니고 페이로드가 비어 있는 않음을 나타내며, 필드가 1로 설정하면 상기 데이터 패킷에 대응하는 프레임 데이터가 정지 프레임이고 상기 데이터 패킷의 페이로드가 비어 있음을 나타낸다.
도 8에 나타낸 바와 같이, 새롭게 정의된 static_frame_flag는 MMTP 패킷 헤더에서 다섯 번째의 비트 위치에 위치한다.
이하, MMTP 패킷 헤더 내의 리저브드 필드에서 하나의 비트를 정지 프레임 플래그 비트로 추출하는 것을 예로 하여 정지 프레임 플래그 비트를 사용함으로써 전송 과정에서 대역폭과 데이터 스트림의 사용량을 절감하는 단계를 제시한다.
서버단은 코딩되지 않는 동영상 데이터의 전후 이미지를 비교하여 동영상 이미지가 정지할 때 대응하는 데이터 프레임을 획득한다(S1).
서버는 동영상 데이터를 코딩하여 코딩된 프레임 데이터를 획득한다(S2).
코딩된 데이터를 MMTP로 패킹할 때, 어느 한 프레임이 단계(S1)에서 정지 프레임으로 식별되면 해당 MMTP 패킷의 static_frame_flag(S) 필드를 1로 설정하여 상기 데이터 패킷에 대응하는 프레임 데이터가 정지 프레임이고 상기 데이터 패킷의 페이로드가 비어 있음을 나타내며, 다른 비정지 프레임의 처리 방식은 변하지 않는다(S3).
수신단은 수신한 MMTP 패킷을 분석하고, static_frame_flag(S) 필드가 0이면 상기 프레임 데이터를 디코더로 송신하며, static_frame_flag(S) 필드가 1이면 데이터를 디코더로 송신하지 않고 직접 디코더의 전 프레임의 디코딩 결과를 반복하여 이미지를 재건한다(S4).
2． DU header 내의 priority 필드를 사용하고 특정값으로 현재 MMTP 패킷에 대응하는 프레임 데이터가 전 프레임과 동일함을 나타낸다.
DU header 내의 priority 필드는 하나의 미디어 유닛 내의 상기 데이터 유닛이 포함한 동영상 프레임의 우선 순위를 설명하기 위한 것이며, 사용 시 상기 필드를 "전부 0"으로 설정하여 상기 DU header에 대응하는 프레임 데이터가 전 프레임과 동일하고 페이로드가 비어 있음을 나타낸다. priority 필드의 표준에서의 위치는 도 9에 나타낸 바와 같다.
이하, DU header 내의 priority 필드를 사용하여 플래그 비트를 나타내는 것을 예로 하여 정지 프레임 플래그 비트를 사용함으로써 전송 과정에서 사용되는 대역폭과 데이터 스트림을 절감하는 단계를 제시한다.
서버단은 코딩하지 않는 동영상 데이터의 전후 이미지를 비교하여 동영상 이미지가 정지할 때 대응하는 데이터 프레임을 획득한다(S1).
서버는 해당 동영상 코딩 방식으로 동영상 데이터를 코딩하여 코딩된 프레임 데이터를 획득한다(S2).
코딩된 데이터를 MMTP로 패킹할 때, 어느 한 프레임이 단계(S1)에서 정지 프레임으로 식별되면 해당 MMTP 패킷 중 DU header의 priority값을 "전부 0"으로 설정하고, DU payload 내용이 비어 있으며, 다른 비정지 프레임의 처리 방식이 변하지 않는다(S3).
수신단은 수신한 MMTP 패킷을 분석하고, priority 필드가 "전부 0"이 아니면 상기 프레임 데이터를 디코더로 송신하며, priority 필드가 "전부 0"이면 데이터를 디코더로 송신하지 않고 직접 디코더의 전 프레임의 디코딩 결과를 반복하여 이미지를 재건한다(S4).
상기 실시예는 본 실시예의 일부 실시형태에 불과하며, 본 실시예는 또한 시그널링 또는 패킷 헤더에 해당 정지 프레임 플래그 비트를 설정하며, 플래그 비트만 전송하고 해당 프레임 데이터를 전송하지 않는 방법을 통해 네트워크 대역폭의 사용을 절감할 수도 있으며, 이에 따라 스트리밍 동영상 전송 시의 정지 이미지 프레임에 의한 대역폭 점용과 유량 낭비의 문제를 해결하였다.
이상에서 본 발명의 구체적인 실시예를 설명하였다. 본 발명은 상기 특정한 실시형태에 제한되지 않으며, 해당 분야에서 통상의 지식을 가진 자가 본 발명의 실질적인 내용에 영향 주지 않고 특허청구범위 내에서 다양한 변형 또는 수정을 할 수 있음을 이해해야 할 것이다.

Claims (26)

  1. 메시지의 식별 코드를 나타내는 메시지 식별 필드;
    메시지의 버전 번호를 나타내는 메시지 버전 번호 필드;
    메시지의 길이를 나타내는 메시지 길이 식별 필드; 및
    메시지의 페이로드를 포함하고 나타내는 페이로드 데이터 세그먼트;를 포함하는 메시지를 사용하여 양방향의 신속한 교환을 구현하는 것을 특징으로 하고,
    상기 페이로드 데이터 세그먼트는 메시지 내용 유형 식별 필드를 포함하고,
    상기 메시지 내용 유형 식별 필드는 적어도 메시지가 서버와 클라이언트 사이에서의 업링크 또는 다운링크에 있는지를 식별하기 위한 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  2. 삭제
  3. 제1항에 있어서,
    상기 페이로드 데이터 세그먼트는 적어도 리저브 정보를 나타내는 리저브드 필드를 더 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  4. 제1항에 있어서,
    적어도 리저브 정보를 나타내고, 8비트의 정수배와 상기 메시지 내용 유형 식별 필드의 비트수 간의 비트수 차이에 따라 비트 길이가 결정되는 리저브드 필드를 더 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  5. 제1항에 있어서,
    상기 메시지 내용 유형 식별 필드는 상이한 부여값을 통해 각각 상기 업링크 또는 다운링크 상태를 나타내는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  6. 제5항에 있어서,
    상기 메시지 내용 유형 식별 필드는 부여값 0을 통해 상기 업링크 상태를 나타내고, 부여값 1을 통해 상기 다운링크 상태를 나타내는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  7. 제5항에 있어서,
    상기 메시지 내용 유형 식별 필드가 상기 업링크 상태임을 나타내는 경우,
    상기 메시지는,
    상기 메시지의 업링크 서열번호를 나타내는 메시지 업링크 서열번호 식별 필드;
    현재 교환이 업링크 상태일 때의 바이트 스트림을 포함하는 업링크 바이트 데이터 세그먼트;
    상기 업링크 바이트 데이터 세그먼트의 포맷을 나타내는 내용 포맷 필드; 및
    상기 업링크 바이트 데이터 세그먼트의 길이를 나타내는 내용 길이 필드;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  8. 제5항에 있어서,
    상기 메시지 내용 유형 식별 필드가 상기 다운링크 상태임을 나타내는 경우,
    상기 메시지는,
    상기 메시지의 다운링크 서열번호를 나타내는 메시지 다운링크 서열번호 식별 필드; 및
    피드백 상태 필드를 통해 나타내고 현재 교환이 다운링크 상태일 때의 바이트 스트림을 포함하는 다운링크 바이트 데이터 세그먼트;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  9. 제5항에 있어서,
    서열번호 식별에 의해 나타내는 다운링크 서열번호와 업링크 서열번호 사이가 서로 관련되어 있는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  10. 제8항에 있어서,
    상기 피드백 상태 필드는 상이한 부여값을 통해 적어도 3개의 피드백 상태를 대응하게 나타내며,
    상기 적어도 3개의 피드백 상태는,
    정보의 업링크 전송이 실패하고, 적어도 기 설정된 시간 내에 수신을 완성하지 못한 경우를 포함하는 제1 피드백 상태;
    정보의 업링크 전송이 성공한 제2 피드백 상태; 및
    정보의 업링크 전송이 성공하고, 상기 메시지가 다운링크 상태일 때의 바이트 스트림을 포함하는 제3 피드백 상태;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  11. 제10항에 있어서,
    피드백 상태 필드는 상기 제1 피드백 상태에서 부여값이 "0X00"이고, 상기 제2 피드백 상태에서 부여값이 "0X01"이며, 상기 제3 피드백 상태에서 부여값이 "0X02"인 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  12. 제10항에 있어서,
    상기 피드백 상태 필드는 상이한 부여값을 통해 적어도 ISO 표준 리저브와 사설 필드 리저브 중의 어느 하나 또는 2개를 포함하는 리저브드 피드백 상태를 추가로 대응하게 나타내는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  13. 제12항에 있어서,
    상기 피드백 상태 필드는 ISO 표준 리저브인 피드백 상태에서 부여값이 "0X02~0X7F"이고;
    사설 필드 리저브인 피드백 상태에서 부여값이 "0X8F~0XFF"인 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  14. 제10항에 있어서,
    상기 제3 피드백 상태에서 상기 다운링크 바이트 스트림은,
    현재 교환하는 다운링크 바이트 스트림 내용;
    상기 다운링크 바이트 스트림의 내용 포맷을 나타내는 필드; 및
    상기 다운링크 바이트 스트림의 내용 길이를 나타내는 필드;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  15. 제1항에 있어서,
    상기 페이로드 데이터 세그먼트는,
    메시지 내용 유형 식별 필드;
    메시지 서열번호 필드;
    상기 메시지와 관련되는 메시지의 서열번호를 나타내는 필드;
    피드백 상태를 나타내는 필드;
    현재 교환 정보의 바이트 데이터 세그먼트;
    상기 바이트 데이터 세그먼트의 내용 포맷을 나타내는 필드; 및
    상기 바이트 데이터 세그먼트의 내용 길이를 나타내는 필드;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  16. 제1항에 있어서,
    상기 메시지는,
    비트 길이가 16이고, 포맷이 무부호 정수인 메시지 식별 필드;
    비트 길이가 8이고, 포맷이 무부호 정수인 메시지 버전 번호 필드;
    비트 길이가 32이고, 포맷이 무부호 정수인 메시지 길이 식별 필드;
    비트 길이가 1이고, 포맷이 비트 스트링인 메시지 내용 유형 식별 필드;
    비트 길이가 7이고, 포맷이 비트 스트링인 리저브드 필드;
    비트 길이가 8이고, 포맷이 무부호 정수인 메시지 업링크 서열번호 식별 필드;
    비트 길이가 8이고, 포맷이 무부호 정수인 메시지 다운링크 서열번호 식별 필드;
    비트 길이가 16이고, 포맷이 무부호 정수인 내용 길이 필드;
    비트 길이가 8이고, 포맷이 무부호 정수인 메시지 다운링크 서열번호 식별 필드; 및
    비트 길이가 8이고, 포맷이 무부호 정수인 메시지 업링크 서열번호 식별 필드;를 포함하며,
    제3 피드백 상태에서, 상기 메시지는 내용 길이 필드의 비트 길이가 16이고 포맷이 무부호 데이터인 다운링크 바이트 스트림을 포함하며,
    상기 다운링크 바이트 스트림의 내용을 나타내고, 비트 길이가 8의 정수배이며, 포맷이 무부호 데이터인 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  17. 제16항에 있어서,
    상기 리저브드 필드의 부여값은 1111111인 것을 특징으로 하는 멀티미디어 시스템 정보 교환 메카니즘의 방법.
  18. 단말기가 기 설정된 메시지 포맷에 따라 메시지를 데이터 패킷으로 패킹하는 단계;
    데이터 패킷을 네트워크 서버로 전송하는 단계; 및
    서버가 기 설정된 메시지 포맷에 따라 데이터 패킷에 대해 페이로드 데이터를 분석하고 해당 처리와 응답을 진행하는 단계;를 포함하며,
    서버에서 단말기로의 통신은 상기 단계를 따르는 제1항, 제3항 내지 제17항 중 어느 한 항에 따른 멀티미디어 시스템 정보 교환 메카니즘의 방법을 사용하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  19. 제18항에 있어서,
    기 설정된 메시지 포맷은 국제 협정 표준 및/또는 자체 정의 표준을 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  20. 제18항에 있어서,
    상기 단말기가 기 설정된 메시지 포맷에 따라 메시지를 패킹하는 단계는,
    단말기에서 메시지가 미리 정의한 비트 페이로드 데이터 세그먼트의 포맷 또는 자체 정의한 포맷에 따라 업링크 바이트 스트림을 패킹하는 단계; 및
    단말기가 기 설정된 메시지 포맷에 따라 메시지 전체를 패킹하는 단계;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  21. 제20항에 있어서,
    비트 페이로드 데이터 세그먼트의 포맷은 업링크 바이트 스트림 데이터와 다운링크 바이트 스트림 데이터의 포맷에 기반하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  22. 제18항에 있어서,
    네트워크 단말기가 선정한 네트워크 통신 프로토콜 포맷에 따라 메시지 전체를 프로토콜 패킹하는 단계를 더 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  23. 제18항에 있어서,
    패킹 후, 단말기가 프로토콜 포맷 정의에 따라 하나 또는 복수개의 packet 데이터 패킷을 생성하는 것을 포함하는 데이터 패킷 생성 단계를 더 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  24. 제18항에 있어서,
    서버가 수신한 데이터 패킷을 처리하는 단계는,
    서버가 하나 또는 복수개의 클라이언트가 출력한 packet 데이터 패킷을 수신한 후, 데이터 패킷 프로토콜 헤더에 따라 완전한 프로토콜급 페이로드 데이터 세그먼트를 분석하는 단계를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  25. 제18항에 있어서,
    서버가 수신한 데이터 패킷을 처리하는 단계는,
    서버가 대응하는 네트워크 통신 프로토콜 포맷의 페이로드 포맷 정의에 따라 완전한 메시지를 분석하는 단계를 더 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
  26. 제18항에 있어서,
    서버가 수신한 데이터 패킷을 분석하는 단계는,
    서버가 메시지 중의 메시지 헤더의 정의에 따라 메시지의 비트 페이로드 데이터 세그먼트에 포함한 데이터를 분석하는 단계; 및
    서버가 메시지가 정의한 포맷 또는 자체 정의한 포맷에 따라 비트 페이로드 데이터 세그먼트에 포함한 페이로드 데이터를 분석하는 단계;를 포함하는 것을 특징으로 하는 멀티미디어 시스템 정보 교환 네트워크 전송 방법.
KR1020187023649A 2016-02-02 2017-01-25 멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법 KR102153611B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
CN201610074442.XA CN107026827B (zh) 2016-02-02 2016-02-02 一种用于视频流中静止图像的优化传输方法
CN201610107748.0 2016-02-02
CN201610074851.XA CN107026887B (zh) 2016-02-02 2016-02-02 一种多媒体***中快速信息交互方法及网络传输方法
CN201610074442.X 2016-02-02
CN201610074851.X 2016-02-02
CN201610107748.0A CN107135184B (zh) 2016-02-26 2016-02-26 一种多媒体***中信息交互***及网络传输方法
PCT/CN2017/072558 WO2017133611A1 (zh) 2016-02-02 2017-01-25 多媒体***信息交互机制及网络传输方法

Publications (2)

Publication Number Publication Date
KR20180137477A KR20180137477A (ko) 2018-12-27
KR102153611B1 true KR102153611B1 (ko) 2020-09-08

Family

ID=59499377

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187023649A KR102153611B1 (ko) 2016-02-02 2017-01-25 멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법

Country Status (5)

Country Link
US (1) US20230283651A1 (ko)
JP (2) JP2019508953A (ko)
KR (1) KR102153611B1 (ko)
CA (2) CA3013516C (ko)
WO (1) WO2017133611A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023075070A1 (ko) * 2021-10-29 2023-05-04 삼성전자 주식회사 스트림 데이터를 송신하고 수신하기 위한 서버, 전자 장치 및 그 동작 방법
US11936535B2 (en) 2021-10-29 2024-03-19 Samsung Electronics Co., Ltd. Server and electronic device for transmitting and receiving stream data and method for operating the same

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7218165B2 (ja) * 2018-12-07 2023-02-06 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム
CN112468513B (zh) * 2020-12-14 2022-09-23 南京中孚信息技术有限公司 一种企业网的终端管理通信方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7403488B2 (en) * 2004-02-17 2008-07-22 Mitsubishi Electric Research Labortories, Inc. Scheduling packet flows in multi-rate wireless local area networks
NZ548528A (en) * 2006-07-14 2009-02-28 Arc Innovations Ltd Text encoding system and method
CN101282169B (zh) * 2007-04-03 2013-05-08 中兴通讯股份有限公司 一种媒体接入控制消息生成方法及其传输方法
CN101296094B (zh) * 2007-04-26 2011-02-16 华为技术有限公司 检测承载事件的方法、***和装置
CN101465847B (zh) * 2007-12-21 2013-08-07 华为技术有限公司 一种mac消息传输方法和装置
US9184983B2 (en) * 2010-08-26 2015-11-10 Futurewei Technologies, Inc. Cross-stratum optimization protocol
JP2012227736A (ja) * 2011-04-20 2012-11-15 Nec Corp リソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびプログラム
KR101501344B1 (ko) * 2012-05-02 2015-03-10 삼성전자주식회사 멀티미디어 서비스 송수신 방법 및 장치
US20150032845A1 (en) * 2013-07-26 2015-01-29 Samsung Electronics Co., Ltd. Packet transmission protocol supporting downloading and streaming
CN104753804B (zh) * 2013-12-31 2019-01-08 ***通信集团公司 一种数据流传输控制方法、装置及***
JP5725235B1 (ja) * 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023075070A1 (ko) * 2021-10-29 2023-05-04 삼성전자 주식회사 스트림 데이터를 송신하고 수신하기 위한 서버, 전자 장치 및 그 동작 방법
US11936535B2 (en) 2021-10-29 2024-03-19 Samsung Electronics Co., Ltd. Server and electronic device for transmitting and receiving stream data and method for operating the same

Also Published As

Publication number Publication date
JP2019508953A (ja) 2019-03-28
CA3013516C (en) 2021-06-29
CA3115314A1 (en) 2017-08-10
JP2022058715A (ja) 2022-04-12
CA3013516A1 (en) 2017-08-10
WO2017133611A1 (zh) 2017-08-10
CA3115314C (en) 2023-06-13
KR20180137477A (ko) 2018-12-27
US20230283651A1 (en) 2023-09-07

Similar Documents

Publication Publication Date Title
JP4690400B2 (ja) Ｓａｆ同期化階層パケット構造とこれを用いるサーバシステム
KR102153611B1 (ko) 멀티미디어 시스템 정보 교환 메카니즘 및 네트워크 전송 방법
KR100927978B1 (ko) 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
KR100959574B1 (ko) 모바일 브로드캐스트／멀티캐스트 스트리밍 서버들에 의해사용되는 리치 미디어 컨테이너 형식에 대한 확장들
JP5122644B2 (ja) レーザコンテンツを使用して場面を構成するための方法及び装置
US7149770B1 (en) Method and system for client-server interaction in interactive communications using server routes
JP4554837B2 (ja) インタラクティブマルチメディアコンテンツサービスにおけるアップストリームチャネルを利用したユーザ要求の処理方法及びその装置
CN107026887B (zh) 一种多媒体***中快速信息交互方法及网络传输方法
CA2319820A1 (en) Method and system for client-server interaction in interactive communications
JP4391231B2 (ja) 複数のターミナルへのマルチメディア信号のブロードキャスト方法
CN112565670B (zh) 云会议多层视频快速平滑出图的方法
KR100991803B1 (ko) Ｓａｆ 동기화 계층 패킷 구조를 제공하는 ｓａｆ 동기화 계층 패킷 제공 시스템 및 사용자 단말
JP2002344937A (ja) 品質制御保証方法及び品質制御保証装置並びにネットワーク接続装置
Paik et al. Media-aware scheduling method for transmitting signalling message over MPEG media transport-based broadcast
CN111726347A (zh) 一种多媒体***中信息交互机制及网络传输方法
KR100940603B1 (ko) Ｓａｆ 동기화 계층 패킷 구조와 이를 제공하는 방법
Wang et al. Implementation of live video transmission in MPEG-4 3D scene

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
X091 Application refused [patent]
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant