KR101977516B1 - 미디어 배포 및 관리 플랫폼 - Google Patents

미디어 배포 및 관리 플랫폼 Download PDF

Info

Publication number
KR101977516B1
KR101977516B1 KR1020177008117A KR20177008117A KR101977516B1 KR 101977516 B1 KR101977516 B1 KR 101977516B1 KR 1020177008117 A KR1020177008117 A KR 1020177008117A KR 20177008117 A KR20177008117 A KR 20177008117A KR 101977516 B1 KR101977516 B1 KR 101977516B1
Authority
KR
South Korea
Prior art keywords
video
user
destination
block
distribution channel
Prior art date
Application number
KR1020177008117A
Other languages
English (en)
Other versions
KR20170038088A (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
Application filed by 유스튜디오, 인크. filed Critical 유스튜디오, 인크.
Publication of KR20170038088A publication Critical patent/KR20170038088A/ko
Application granted granted Critical
Publication of KR101977516B1 publication Critical patent/KR101977516B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234309—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482—Interaction with lists of selectable items, e.g. menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04842—Selection of displayed objects or displayed text elements
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • 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/23614—Multiplexing of additional data and video streams
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2543—Billing, e.g. for subscription services
    • H04N21/2547—Third Party Billing, e.g. billing of advertiser
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6547—Transmission by server directed to the client comprising parameters, e.g. for client setup

Landscapes

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

Abstract

본 발명의 실시예는 "비디오 라이프사이클(video lifecycle)"의 관리를 간소화한다. 실시예는, 비디오 공개, 비디오 업데이팅, 비디오 미공개, 비디오에 관한 통계의 검색, 비디오 처리 인가, 비디오의 유효성확인, 비디오 메타데이터 처리, 비디오 트랜스코딩, 및/또는 비디오 전송 등의 기술적 단계들을 추상화함으로써 비디오 공개 프로세스를 능률화하는 하나 이상의 모듈을 포함한다. 다른 실시예들이 본 명세서에서 설명된다.

Description

미디어 배포 및 관리 플랫폼{MEDIA DISTRIBUTION AND MANAGEMENT PLATFORM}
미디어 배포 및 관리 플랫폼에 관한 것이다.
배포 플랫폼(예를 들어, YouTube®, Netflix®, 및 iTunes®)의 성공은 비디오 콘텐츠의 소비를 더욱 간소하게 했다. 그러나, 그 콘텐츠를 생성, 배포, 및/또는 관리하는 것은 복잡한 프로세스로 남아 있다. 동시에, 비디오의 편재성(ubiquity)은, 소셜 네트워크, 모바일 장치 등을 이용하는 신흥 시청자들(emerging audiences)을 활용하기 위하여 비디오 전략들(video strategies)을 병합(또는 강화)하기 위한 조직을 요구한다. 지속적으로 이동하는 기술적 요건과 결합되어, 비디오를 생성하고 성공적으로 전달하는 프로세스는 기존의 브랜드와 신참자 모두에 대해 사람과 기술의 투자를 요구한다. 비디오 "라이프 사이클(life cycle)"을 관리하는 것은 복잡하다.
비디오 "라이프 사이클(life cycle)"을 관리하는 것은 복잡하다.
본 발명의 실시예는 "비디오 라이프사이클(video lifecycle)"의 관리를 간소화한다. 실시예는, 비디오 공개, 비디오 업데이팅, 비디오 미공개, 비디오에 관한 통계의 검색, 비디오 처리 인가, 비디오의 유효성확인, 비디오 메타데이터 처리, 비디오 트랜스코딩, 및/또는 비디오 전송 등의 기술적 단계들을 추상화함으로써 비디오 공개 프로세스를 능률화하는 하나 이상의 모듈을 포함한다. 다른 실시예들이 본 명세서에서 설명된다.
본 발명의 실시예는 "비디오 라이프사이클(video lifecycle)"의 관리를 간소화한다.
본 발명의 실시예의 피쳐 및 이점들은, 첨부된 청구항, 하나 이상의 예시적 실시예의 이하의 상세한 설명, 및 대응하는 도면으로부터 명백해질 것이다.
도 1은 본 발명의 실시예의 공개(publishing) 작업흐름도를 포함한다.
도 2는 본 발명의 실시예의 업데이팅(updating) 작업흐름도를 포함한다.
도 3은 본 발명의 실시예의 미공개(unpublishing) 작업흐름도를 포함한다.
도 4는 본 발명의 실시예의 통계 수집 작업흐름도를 포함한다.
도 5는 본 발명의 실시예의 더 상세한 인가(authorization) 작업흐름도를 포함한다.
도 6은 본 발명의 실시예의 더 상세한 메타데이터 유효성확인 작업흐름도를 포함한다.
도 7은 본 발명의 실시예의 더 상세한 트랜스코딩(transcoding) 작업흐름도를 포함한다.
도 8은 본 발명의 실시예의 더 상세한 전송 작업흐름도를 포함한다.
도 9는 본 발명의 실시예의 그래픽 사용자 인터페이스(GUI)를 포함한다;
도 10은 본 발명의 실시예의 배포 작업흐름도를 포함한다.
도 11은 본 발명의 실시예를 구현하기 위한 시스템을 포함한다.
이하의 설명에서, 수 많은 특정한 상세사항이 개시되지만 본 발명의 실시예는 이들 특정한 상세사항없이도 실시될 수 있다. 공지된 회로, 구조, 및 기술은 본 설명의 이해를 흐리게 하지 않기 위하여 상세히 도시되지 않았다. "실시예", "다양한 실시예" 등은, 이와 같이 기술된 실시예(들)가 특정한 피쳐, 구조 또는 특성을 포함할 수 있지만, 모든 실시예가 반드시 그 특정한 피쳐, 구조, 또는 특성을 포함하는 것은 아니라는 것을 나타낸다. 일부 실시예들은 다른 실시예들에 대해 설명된 피쳐들 중 일부 또는 전부를 갖거나, 아무것도 갖지 않을 수도 있다. "제1", "제2", "제3" 등은 공통의 대상을 기술하며 참조되고 있는 유사한 대상들의 상이한 사례들을 나타낸다. 이러한 형용사들은 이와 같이 기술된 대상들이, 시간적으로, 공간적으로, 순위에서 또는 기타 임의의 방식으로 주어진 순서대로 있어야 한다는 것을 암시하는 것은 아니다. "접속된"은, 요소들이 서로 직접 물리적 또는 전기적으로 접촉한다는 것을 나타내고, "결합된"은 요소들이 서로 협력 또는 상호작용한다는 것을 나타내지만, 이들은 직접 물리적 또는 전기적으로 접촉하거나 접촉하지 않을 수도 있다. 또한, 상이한 도면들 내의 동일한 또는 유사한 부분들을 가리키기 위해 유사한 또는 동일한 번호들이 사용될 수 있지만, 이렇게 하는 것이 유사한 또는 동일한 번호를 포함하는 모든 도면들이 단일 또는 동일한 실시예를 구성한다는 것을 의미하는 것은 아니다. 때때로 여기서는 설명이 수 개의 상이한 도면들을 한꺼번에 포괄한다. 명료성을 위해, 도면들은 컴포넌트들을 포함하고, 여기서 컴포넌트들의 최상위 자릿수는 그 컴포넌트를 포함하는 도면을 나타낸다(예를 들어, 요소 3XX는 도 3에서 발견될 것이고 요소 4XX는 도 4에서 발견될 것이다).
본 발명의 실시예는 "비디오 라이프사이클" 등의 관리를 간소화한다. 실시예는, 비디오 공개, 비디오 업데이팅, 비디오 미공개, 비디오에 관한 통계의 검색, 비디오 처리 인가, 비디오의 유효성확인, 비디오 메타데이터 처리, 비디오 트랜스코딩, 및/또는 비디오 전송 등의 기술적 단계들을 추상화(abstracting)함으로써 비디오 공개 프로세스를 능률화하는 하나 이상의 모듈을 포함한다.
비디오 라이프 사이클
본 발명의 실시예의 관점에서, 비디오 라이프사이클은 적어도 4개의 프로세스: 공개, 업데이팅, 미공개, 및 통계 검색을 수반한다. 이들 프로세스들 모두는 이전 프로세스들의 일부 조합을 허용하는 하나 이상의 "목적지": 배포 플랫폼과 나란히 발생한다. (예를 들어, 일부 목적지는 공개와 미공개만을 지원하고 통계를 보고하거나 최종 사용자가 비디오를 업데이트하는 것을 허용하지 않는다.) 실시예는 사용자가, 프로세스들 중 하나를 시작하기 이전에, 소정 프로세스가 개시되고 나면, 또는 양쪽 모두에서, 하나 이상의 목적지를 인가하는 것을 허용한다.
공개 프로세스는 "비디오 파일"이 이용가능한 순간에 시작된다. 이 파일은, 카메라 또는 프로덕션으로부터의 편집되지 않은 컷(cut)과 같은 단순한 것, 협력자 또는 클라이언트로부터의 승인을 요구하는 마무리된 편집, 배포 준비된 최종 버전, 또는 이들 사이의 임의의 단계일 수 있다.
클라이언트 애플리케이션 또는 최종 사용자는 다양한 방식으로 본 발명의 실시예에 비디오 파일을 제공할 수 있다: 비디오 파일은, 하드 드라이브, DVD-ROM, 또는 테이프 포맷 등의 물리적 저장 매체를 통해 전달될 수 있다. 대안으로서 비디오 파일은, HTTP 또는, FTP 등의 기타의 네트워크 프로토콜을 이용해 네트워크를 통해 전달될 수 있다. 마지막으로, 실시예가 파일에 대한 로컬 액세스를 가진다면, 로컬 파일 경로가 제공될 수 있다.
이 때, 실시예에서 비디오는 개별 목적지 플랫폼에 따라 팩키징된다. 최종 사용자가 선택하는 각각의 목적지에 대해, 실시예는 적절한 다음 단계들을 판정할 수 있다. 비디오는 하나 이상의 요구되는 포맷으로의 트랜스코딩을 요구할 수 있다. 비디오 파일은 네트워크를 통한 전달(예를 들어, 파일 전송 프로토콜(FTP), 콘텐츠 전달 네트워크(CDN), 애플리케이션 프로그램 인터페이스(API) 등)을 요구할 수 있다. 마지막으로, 최종 목적지는 최종 제공자에 의해 명령된 다양한 순열의 비디오 메타데이터로 채워질 수 있다. 이 프로세스는, 달라지는 API 요건, 비디오 지원 갭(gap), 및 네트워크 고장에 대한 세심한 주의를 요구한다.
일단 비디오가 하나 이상의 목적지 플랫폼에 공개되고 나면, 메타데이터와 비디오 파일 그 자체 모두는 업데이트될 자격이 있을 수 있다. 예를 들어, 최종 사용자가 비디오의 제목을 변경하기로 결정한다면, 실시예는 메타데이터를 재팩키징하고 전달 규격을 통해 재제출한다. 실시예는, 최종 사용자의 계정 타입에 기초하여 변동할 수 있는 각각의 목적지 플랫폼에 대한 업데이트가능한 자원 목록을 관리할 수 있다.
많은 목적지 플랫폼은 비디오와 사용자 상호작용에 대한 통계를 추적한다. 예를 들어, 비디오가 재생될 때마다, YouTube®는 "시청(view)" 카운트를 증가시킨다. 이들 목적지 중 일부는 (API 또는 월별 보고 등의) 이들 통계를 검색하기 위한 방법을 포함한다. 이러한 경우 실시예는, 실시예의 최종 사용자가 사용자 상호작용을 비교하고 어느 목적지가 양호하게(또는 불량하게) 수행되고 있는지를 판정할 수 있도록, 이들 통계를 검색하고 목적지들에 걸쳐 값들을 정규화할 수 있다. 특정한 메트릭의 중요성은 각 사용자의 성공의 해석에 의존할 수 있다.
결국, 비디오는 (콘텐츠 오류로 인해 또는 단순히 더 이상 관련없다는 이유로) 목적지 플랫폼으로부터의 제거를 요구할 수 있다. 실시예는 지원하는 임의의 목적지로부터의 비디오의 제거(또는 "미공개")를 지원할 수 있다.
비디오는 보관(archival)을 요구할 수도 있다. 사용자는 임의의 미래의 배포가 이전의 기술적 제한으로 인해 시달리지 않도록 가장 높은 가능한 비디오 품질이 보존되기를 원할 수 있다. 예를 들어, 제1 세대 Apple®의 "AppleTV®" 제품은 (720P라 알려진) 720 화소의 수직 해상도를 갖는 프로그레시브 비디오(progressive video)만을 지원했다. 그러나, 최근 버전의 AppleTV®은 (1080P라 알려진) 1080 화소의 높은 해상도를 지원한다. 원본 비디오 품질을 저장함으로써, 실시예는 미래에도 역시 최고 품질이 전달될 수 있도록 보장한다.
시스템 추상화(SYSTEM ABSTRACTION)
실시예는 다양한 기저 시스템을 추상화한다. AppleTV® 예를 참조할 때, 비디오 전달 요건(video delivery requirement)들은 빈번하게 변한다. 5년전의 주류였던 포맷과 표준(예를 들어, FLV, Flash, RTMP)은 미래에는 덜 적절할 수 있고, 새로운 배포 포맷과 플랫폼(예를 들어, MPEG DASH, HLS, OTT 등)이 빈번하게 부상하고 있다. 따라서, 실시예는 최종 사용자가 기저 시스템 요건에 대한 지식을 갖지 않고도 ("공개" 또는 "업데이트" 등의) 간소화된 동작들을 용이하게 수행할 수 있게 하는 ("비디오" 또는 "목적지" 등의) 추상화된 자원의 시스템을 제공한다. 예를 들어, 실시예는 비디오의 공개 또는 업데이팅하는 것의 "묵시적" 부분으로서 비디오 파일을 트랜스코딩하는 것(하나의 비디오를 또 다른 비디오로 재압축 또는 재팩키징하는 것)을 숨기기로 선택할 수 있다.
실시예는 (예를 들어, 클라우드 저장, FTP 전달, CDN 등의 기술들을 활용할 수 있는) 저장층으로부터의 비디오 라이프사이클을, (모든 지원되는 플랫폼 요건, API, 및 트랜스코드 상세사항을 병렬 시리즈(parallel series)의 목적지들로 추상화할 수 있는) 공개층으로, (각 플랫폼으로부터의 청중 메트릭(audience metrics)을 집계할 수 있는) 통계층으로 간소화하는 자원들의 결합해제된 인터페이스에 해당한다. 이 추상화는 HTTP-기반의 REST API 등의 네트워크 기술을 이용함으로써 클라이언트 애플리케이션에 대한 프로그램 인터페이스 또는 그래픽 애플리케이션을 통해 최종 사용자에게 드러날 수 있다.
공개 작업흐름(PUBLISH WORKFLOW)
도 1은 본 발명의 실시예에서 비디오를 목적지에 공개하기 위한 프로세스 작업흐름을 포함한다. 블록(100)에서, 최종 사용자(또는 API의 클라이언트 애플리케이션)은 비디오 파일을 실시예에 제공한다. 이 파일은 목적지에 의한 사용을 위해 트랜스코딩되어야 하는 고품질 마스타 파일(master file)일 수 있다. 최종 사용자는 이 파일을, HTTP-기반의 API 또는 FTP, 또는 심지어 디지털 테이프 포맷 등의 네트워크 프로토콜을 이용하여, 로컬 액세스를 통해 클라이언트 애플리케이션에 제공할 수 있다.
블록(101)에서, 실시예는 비디오에 대한 특성(들)을 판정한다. 예를 들어, 실시예는 업로드된 비디오로부터 정보를 추출하여 데이터베이스 또는 다른 파일-기반의 저장 시스템 내에 저장한다. 이 정보는, 예를 들어 및 제한없이, 파일 타입(예를 들어, MPEG-4 Part 14 컨테이너), 비디오 코덱(예를 들어, H.264/AVC, MPEG 2 등), 비디오 코덱 프로파일(예를 들어, 메인, 베이스라인 등), 오디오 코덱(예를 들어, MP3, PCM 등), 비디오 지속기간, 비디오 해상도, 프레임 레이트, 비디오 압축 비트 레이트, 오디오 압축 비트 레이트, 및 공개 및 기타의 프로세스에 필요한 기타의 정보를 포함하는 그룹으로부터 선택된 특성에 관련될 수 있다.
블록(102)에서, 실시예는 공개에 이용될 하나 이상의 목적지에 대해 최종 사용자 또는 클라이언트 애플리케이션에게 촉구할 수 있다. 클라이언트 애플리케이션에서, 이것은 사용자가 하나 이상의 원하는 목적지를 "클릭" 또는 기타의 방식으로 표시할 수 있는 하나 이상의 그래픽 사용자 인터페이스 작업흐름일 수 있다. 블록(103)에서, 선택된 각 목적지에 대한 공개 요건이, 데이터베이스, 구성 파일, 외부 API, 또는 적절한 기타의 장소로부터 수집될 수 있다. 이들 요건은, 트랜스코드 포맷(들), 메타데이터 요건, 인증 요건 등을 포함할 수 있지만, 이것으로 제한되지 않는다.
블록(104-107)은 선택된 목적지(들)가 인가되었는지를 판정한다. 하나 이상의 목적지가 인가되어 있지 않고, 인가될 수 있다면, 인가 프로세스가 이용된다. 프로세스(104)는 목적지가 현재 인가되어 있는지를 판정하며, 외부 API와 대조하여 크리덴셜(credential)을 유효성확인하는 것, 데이터베이스로부터 정보를 추출함으로써 스케쥴링된 인증 태스크의 결과를 확인하는 것, 또는 목적지의 능력에 의해 결정되는 기타의 방법을 포함할 수 있다. 프로세스(105)는 프로세스(104)의 결과를 파싱(parse)하고 최종 사용자 또는 클라이언트 애플리케이션이 인가가능하다는 것(예를 들어, 외부 목적지의 인증 서비스가 응답하고 있다는 것, 애플리케이션 제한에 도달하지 않았다는 것 등)을 보장한다. (프로세스(106)에 대한 추가 상세사항을 위해 인가 작업흐름을 참조한다.) 블록(107)에서, 인가의 결과가 확인된다: 인가 프로세스가 성공적이면, 실시예는 블록(108)으로 계속된다. 그렇지 않다면, 실시예는 요청을 처리하지 못하거나, 최종 사용자 또는 클라이언트 애플리케이션에게 다시 한번 인가를 시도할 것을 촉구할 수 있다.
블록(108)은, (블록(101)에서 수집되었고 최종 사용자 또는 클라이언트 애플리케이션으로부터 수집된) 비디오에 대한 메타데이터가 제공되었고 유효성확인되었다는 것을 보장한다. (추가 상세사항을 위해 유효성확인 작업흐름을 참조한다.) 이 단계에 대해 요구되는 메타데이터 요건은 블록(103)으로부터 수집되었다. 일단 각 비디오와 목적지 조합에 대해 메타데이터가 유효성확인되고 나면, 이것은 전송에 이용될 준비가 된 것이다.
블록(109)은 최종 목적지에 의해 요구되는 임의의 트랜스코딩을 캡슐화(encapsulate)한다. (YouTube® 등의) 일부 목적지는 광범위한 입력 비디오 파일을 지원하는 반면, 다른 목적지는 특정한 컨테이너 포맷, 비디오 및 오디오 코덱, 해상도, 및 비디오 압축의 다른 양태를 요구한다. 예를 들어 Hulu®은 현재, HD 자료에 대해 30-50 Mbps MPEG-2 비디오 스트림을 포함한 MPEG-2 프로그램 스트림 파일을 요구한다. 사용자 또는 클라이언트 애플리케이션이 하나 이상의 목적지의 트랜스코드 요건과 정합하지 않는 비디오 파일을 제공한다면, 전송으로 진행하기 이전에 추가의 트랜스코드가 생성될 수 있다. (추가 상세사항을 위해 트랜스코드 작업흐름을 참조한다.) 트랜스코딩 후에, 결과 파일들은 전송 뿐만 아니라 미래의 이용을 위해 저장될 수 있다.
일단 적절한 트랜스코드(들)가 생성되고 나면, 실시예는 최종 사용자 또는 클라이언트 애플리케이션에게 임의의 추가적 요구되는 파일을 요청하기 위해 블록(110-115)을 채용할 수 있다. 일부 목적지는, 썸네일 이미지, 대안적 언어 오디오 스트림, 또는 문서를 포함한 그러나 이것으로 제한되지 않는 보충 파일을 요구한다. 블록(110)은 블록(103)에서 수집된 목적지 요건을 검사하고 임의의 추가적인 파일이 필요한지를 판정한다. 추가로, 실시예는 사용자에게 촉구하지 않고 소정의 요구되는 추가 파일을 생성할 수도 있다.
사용자 또는 클라이언트 애플리케이션이 파일(들)을 제공해야 한다면, 블록(111)은 요구되는 파일을 제공하기 위한 방법을 갖는 그래픽 인터페이스 또는 클라이언트 애플리케이션으로 사용자에게 촉구하는 것을 포함한다. 일단 실시예가 추가 파일에 액세스하고 나면, 보관(archival) 및 변환을 위해 이들을 분석 및 저장할 수 있다(블록 112). 원본 파일을 저장하는 것은 고품질 비디오 마스타를 저장하는 것과 유사한 목적의 역할을 한다: 임의의 미래의 변환은 더 높은 품질의 소스 파일로부터 혜택을 입는다.
비디오 파일과 매우 유사하게, 목적지는 (블록(113)에서 판정되는) 추가 파일들이 전송될 수 있기 전에 변환될 것을 요구할 수 있다. 이것은, 이미지 변환(PNG에서 JPEG으로), 오디오 압축(PCM에서 MP3으로), 또는 문서 변환(Microsoft® Word®에서 PDF로)을 포함하지만 이것으로 제한되는 것은 아니다. 만일 이것이 요구된다면, 블록(114)은 하나 이상의 변환된 파일로 이어져야 한다. 실시예는 이들 변환을 수행하기 위해 제3자 변환 툴 또는 전용 소프트웨어 라이브러리를 이용할 수 있다.
실시예는 블록(115)에서 미래의 이용을 위해 변환된 파일을 저장할 수 있다. 실시예는, 로컬 파일 저장소, 네트워크 저장소, 또는 클라우드 저장 파트너, 예를 들어, Amazon®, Rackspace® 등을 이용할 수도 있다. 이들 파일들은 임의의 미래의 공개 또는 업데이팅 동작이 기존의 변환된 파일을 이용할 수 있도록 목적지와 비디오를 참조하여 저장될 수 있다.
블록(116)은 팩키징 및 전송 단계를 식별한다. 각 목적지는 파일(들) 및 메타데이터를 전송하는 고유한 방법을 제공할 수 있다. 추가로, 각 비디오에 대한 메타데이터는 전송될 수 있기 이전에 각 목적지에 대해 변환될 필요가 있을 수도 있다. (추가 상세사항을 위해 전송 작업흐름을 참조한다.) 전송이 성공적이면, 실시예는 블록(117)에서 목적지로부터 반환된 임의의 정보를 수집 및 저장할 수 있다. 이 정보는, 업데이팅, 통계 검색, 및 미공개 등의 미래의 프로세스에 이용될 수 있다.
실시예는, 최종 사용자 또는 클라이언트 애플리케이션, 및 공개가 마무리되는데 필요할 수 있는 임의의 최종 단계에 임의의 성공 정보를 전송할 수 있다. 예를 들어, Apple® iTunes® 팟캐스트(podcast)는 iTunes® 클라이언트 애플리케이션에서 피드 제출(feed submission)을 요구한다. 실시예는 최종 단계로서 iTunes 스토어에 제출하기 위해 피드 URL을 최종 사용자에게 제공할 수 있다.
(블록(105 및 107)으로 표시된 바와 같이) 공개 동작의 임의의 일부가 실패한다면, 실시예는 블록(118)에서 공개 동작을 거부하고 블록(117)과 유사한 직렬화 및 전송 전략을 이용하여 실패 정보를 클라이언트 애플리케이션 또는 최종 사용자에게 반환할 수 있다.
업데이트 작업흐름(UPDATE WORKFLOW)
도 2는 본 발명의 실시예에서 하나 이상의 목적지 상의 공개된 비디오를 업데이트하기 위한 프로세스를 포함한다. 블록(201)에서, 최종 사용자 또는 클라이언트 애플리케이션은, 비디오 마스타 파일을 교체하는 것, 비디오 메타데이터를 업데이트하는 것, 또는 추가 파일을 교체하는 것을 포함한 그러나 이것으로 제한되지 않는 비디오의 양태를 업데이트한다.
블록(202)에서, 블록(103)처럼, 실시예는, 데이터베이스, 구성 등으로부터 모든 목적지 요건을 수집할 수 있다. 추가로, 실시예는, 공개된 비디오의 현재 상태를 판정하기 위하여 (외부 목적지 id, URL 등의) 공개된 정보를 수집할 수 있다.
목적지와 상호작용하기 위해 인가가 요구된다면, 블록(203-206)은 104-107과 유사한 인증 작업흐름을 수행한다. 블록(203)은 블록(202)으로부터의 요건을 검사함으로써 목적지에 대해 인가가 요구되는지를 확인하고, 이전의 동작으로부터의 임의의 저장된 크리덴셜을 검사하기 위해 (목적지가 제공한다면) 네트워크 API를 통해 목적지와 역시 통신할 수 있다. 일부 목적지는 크리덴셜을 무효화하거나 서비스를 디스에이블할 수 있기 때문에, 블록(204)은 목적지가 실제로 인가될 수 있는지를 확인한다. 블록(205)은 인가를 수행하고, 필요하다면 최종 사용자 또는 클라이언트 애플리케이션에게 크리덴셜을 요구한다. (추가 상세사항을 위해 인가 작업흐름을 참조한다.) 인가가 실패한다면, 업데이트 요청은 실시예에 의해 거부되거나 사용자는 또 다른 인가 시도에 대해 촉구받을 수 있다.
블록(207)은 108과 유사한 유효성확인 작업흐름을 수행한다. 실시예는 비디오 메타데이터 또는 목적지 요건에 관한 어떠한 변경도 업데이트 프로세스를 무효화하지 않는다는 것을 보장하기 위해 블록(207)을 구현할 수 있다. (추가 상세사항을 위해 유효성확인 작업흐름을 참조한다.)
(파일 콘텐츠를 비교하고, 데이터베이스 등으로부터 이전에 저장된 값들을 검색하는 등에 의해 실현될 수 있는) 블록(208)에 의해 판정되는 바와 같이 비디오 파일이 변경되었거나, 목적지에 대한 트랜스코드 요건이 변경되었다면, (재)트랜스코딩이 요구될 수 있다. 블록들(209 및 210)은 목적지에 대한 트랜스코드(들)를 업데이트하기 위한 작업흐름을 식별한다. (YouTube®처럼) 일부 목적지는 비디오 콘텐츠를 교체하는 것을 지원하지 않지만, 블록(210)을 행하는 것들에 대해서는 블록(109)과 동일한 트랜스코딩 작업흐름을 참조한다. (추가 상세사항을 위해 트랜스코드 작업흐름을 참조한다.)
목적지가 새로운 추가 파일을 요구하거나, (블록(208)과 유사한 방식으로 블록(211)에서 판정되는 바와 같이) 임의의 이전에 제공된 추가 파일이 변경되었다면, 블록(212-214)은 블록(113-115)과 유사한 파일 변환 작업흐름을 정의한다. 블록(212)에 의해 결정되는 바와 같이 목적지 구성에 의해 파일 변환이 허용된다고 가정하면, 블록(213)은 최종 사용자 또는 클라이언트 애플리케이션에 의해 제공된 후에 실시예에 의해 저장된 임의의 원본 파일을 변환한다. 블록(214)은 전송과 미래의 이용을 위해 임의의 (재)변환된 파일들을 저장한다. 어떠한 파일도 변경되지 않았고 목적지가 어떠한 추가 파일도 요구하지 않는다면, 실시예는 공개 프로세스 동안에 저장된 변환된 파일을 이용할 수 있다.
일단 업데이트된 메타데이터가 유효성확인되고, 목적지가 인가되었고, 파일들이 목적지 구성에 따라 준비되고 나면, 블록(215)은 블록(116)과 유사한 전송 작업흐름을 수행한다. (추가 상세사항을 위해 전송 작업흐름을 참조한다.) 한가지 차이점은, 목적지의 API 또는 서비스 엔드포인트 상의 업데이트 인터페이스는 공개 동작과는 상이한 동작을 요구한다는 것이다. 예를 들어, 목적지가 HTTP-기반의 REST API를 제공한다면, 초기 공개 동작은 POST 요청이 자원 컨테이너에 제출될 것을 요구했을 수 있는 반면, 업데이트 동작은 PUT 요청이 POST 요청에 의해 반환된 자원 URL에 제출될 것을 요구할 수 있다. 추가로, 메타데이터는 공개 동작과는 상이한 팩키징 구조를 업데이트 동작에 대해 요구할 수 있다.
업데이트 프로세스가 성공이면, 블록(216)은, 실시예가 미래의 프로세스에서의 이용을 위한 데이터베이스 또는 기타의 파일-기반의 저장소에 임의의 업데이트된 정보를 저장할 수 있다고 식별한다. 임의의 추가 단계가 있다면, 실시예는 그 정보를 최종 사용자 또는 클라이언트 애플리케이션에 반환할 수 있다.
(블록(204 및 206)으로 표시된 바와 같이) 임의의 지점에서 업데이트 프로세스가 실패했다면, 실시예는 블록(217)에서 업데이트 프로세스를 거부하고 최종 사용자 또는 클라이언트 애플리케이션에게 실패 정보를 반환할 수 있다.
미공개 작업흐름(UNPUBLISH WORKFLOW)
도 3은 본 발명의 실시예에서 목적지로부터 비디오를 제거하기 위한 방법을 포함한다. 블록(301)에서, 최종 사용자 또는 클라이언트 애플리케이션은 비디오가 목적지로부터 제거(또는 "미공개")될 것을 요청한다. 블록(302)은, 103 및 202와 유사하게, 요청된 동작을 수행하는데 요구되는 임의의 목적지 구성 또는 비디오 메타데이터를, 데이터베이스, 구성 파일 등으로부터 수집한다.
목적지가 미공개에 대한 인가를 요구한다면, 블록(303-306)은 블록(203-206 및 104-107)과 유사한 동작을 수행한다. (추가 상세사항을 위해 인가 작업흐름을 참조한다.) 인가가 요구되지만 실패한다면, 실시예는 제거 요청을 거부하고 추가의 인가 시도에 대해 최종 사용자 또는 클라이언트 애플리케이션에게 촉구할 수 있다.
블록(307)은 목적지 엔드포인트 또는 API가 제거 요청을 통보받을 수 있는 지점을 식별한다. 각각의 목적지는 하나 이상의 통보 방법을 요구할 수 있다. 예를 들어, (YouTube® 또는 Vimeo®처럼) 목적지가 HTTP-기반의 API를 채용한다면, DELETE 요청이 자원 URL에 발부될 수 있다. 그러나, 목적지가 iTunes® 팟캐스트와 같은 피드를 모니터링한다면, 실시예는 그 피드로부터 엔트리를 제거할 것만을 요구받고 목적지는 피드를 파싱한 다음에 목적지로부터 비디오를 제거할 것이다. 제거 정보를 전송하는 특정한 방법(들)이 블록(302) 동안에 수집된다.
많은 목적지들이 사용자 인터페이스 또는 API를 제공하기 때문에, 본 발명의 실시예는 비디오가 목적지로부터 이미 제거되었다면 수동 성공(passively succeed)을 선택할 수 있다. 예를 들어, 최종 사용자가 YouTube®에 로그인하여 비디오를 제거한 다음, 제거 요청을 실시예에 발부하면, 실시예는 그 비디오가 여전히 YouTube®에 존재하는지를 확인할 수 있다. 존재하지 않는다면, 실시예는 목적지 상에 비디오 "없음(missing)"으로 인한 에러를 내는 것 대신에 제거의 다음 국면으로 진행할 수 있다.
블록(308-310)은 공개 및 업데이트 프로세스 전체를 통해 생성된 임의의 여분 자원을 제거하기 위하여 구현될 수 있다. 예를 들어, 실시예가 블록(109, 112, 115, 210, 또는 214)에서 파일을 저장했다면, 이들 파일들은 저장소로부터 제거될 필요가 있다. 블록(308)은 이들 파일들이 비디오들 또는 목적지들에 걸쳐 공유되고 있는지를 판정하는 단계를 포함한다(예를 들어, 2개의 목적지가 동일한 트랜스코드를 공유하고 있지만, 그 비디오가 한 목적지로부터만 제거되었다면, 트랜스코드는 삭제될 필요가 없을 수 있다). 일단 파일이 제거에 대해 확정되었다면, 실시예는 실제의 제거 프로세스를 위해 블록(309)으로 진행할 수 있다. 저장의 방법에 따라, 이것은 로컬 저장소로부터의 파일의 단순한 삭제 또는 Amazon®의 S3 또는 Rackspace®의 CloudFiles 등의 클라우드 저장소 솔루션으로부터 파일을 제거하기 위한 일련의 네트워크 동작을 포함할 수 있다. 추가로, 블록(310)에서, 실시예는 필요하다면 구성 파일 또는 데이터베이스 등의 저장소로부터 임의의 공개된 정보를 제거할 수 있다.
제거 동작이 성공적이면, 실시예는 블록(311)에서 성공 정보 또는 (필요하다면) 임의의 추가 단계를 최종 사용자 또는 클라이언트 애플리케이션에 전송할 수 있다. 그렇지 않다면, 실시예는 블록(312)에서 제거 동작을 거부하고 최종 사용자 또는 클라이언트 애플리케이션에게 실패 정보를 전송할 수 있다.
통계 검색 작업흐름(STATISTICS RETRIEVAL WORKFLOW)
도 4는 본 발명의 실시예에서 목적지로부터 통계를 검색하기 위한 방법을 포함한다. 블록(401)에서, 최종 사용자 또는 클라이언트 애플리케이션은 공개된 비디오에 대한 통계를 요청한다. 이 요청은, 시간 범위, ("재생" 또는 "인쇄부수(impressions)" 등의) 특정한 통계, 지리적 데이터, 참여 데이터(engagement data), 또는 요구된다면 추가 메트릭을 포함할 수 있다. 추가로, 요청은, GUI에서 인터페이스 요소를 통해 파라미터를 선택하고, HTTP-기반의 API를 통해 JSON-직렬화된 파라미터를 제공하는 등에 의해 개시될 수 있다.
블록(402)은, 302, 202 및 103과 같이, 구성 파일, 데이터베이스 등으로부터 목적지 구성 및 비디오 정보를 추출한다. 이 목적지 구성은 목적지에 의해 지원되는 특정한 메트릭 뿐만 아니라 (OAuth, BasicAuth, 또는 사전-공유된 크리덴셜을 포함한 그러나 이것으로 제한되지 않는) 인증 방법을 식별해야 한다. 추가로, (비디오 id 또는 자원 URL 등의) 목적지와 통신하는데 요구되는 임의의 정보가 수집될 수 있다.
블록(403)에서, 실시예는 사용자가 요청한 값들이 아직 이용가능하지 않다는 것을 보장하기 위해 저장되었을 수도 있는 임의의 기존 값들을 검색할 수 있다. 이들 값들은, 파일 구조로, 메모리캐싱(memcached) 등의 메모리-기반의 캐싱 솔루션으로, MySQL 등의 관계형 데이터베이스로, 또는 기타 임의의 저장 방법으로 저장될 수 있다. 이들 값들은 최종 사용자 또는 클라이언트 애플리케이션에 의한 이전 통계 요청으로 인해, 또는 Unix-스타일 운영 체제에서의 크론 잡(cron job) 등의 오프라인의 정기적인 프로세스 동안에, 검색되었을 수도 있다.
값들이 시스템 내에 아직 존재하지 않는다면, 실시예는 통계를 얻는 2개의 주요 방법들간에 선택할 수 있다. (실시예가 목적지 구성에서 표시할 수도 있는) 블록(404)에 의해 판정되는 바와 같이 목적지가 API 또는 서비스 엔드포인트를 제공한다면, 실시예는 인가를 진행할 수 있다. (API 엔드포인트와 대조하여 크리덴셜을 이용하고, 데이터베이스에 저장된 이전의 유효성확인 속성을 검증하는 등에 의해) 블록(405)에서 목적지가 이미 인가되어 있는지를 판정한 후에, 이전 동작(304-306, 204-206, 및 105-107)과 동일한 방식으로 블록(406-408)에서 인가가 진행된다. (추가 상세사항을 위해 인가 작업흐름을 참조한다.) 일단 인가되고 나면, 블록(409-410)에서 목적지에게 원하는 값들이 요청될 수 있다. 요청의 특정한 상세사항은 목적지마다 달라질 수 있다: 예를 들어, YouTube®은 HTTP-기반의 API를 제공하고 여기서 국가들에 걸친 비디오 "시청"의 세세한 분류가 요청될 수 있고 특정한 시간 범위에 걸쳐 집계될 수 있다. 결과는 압축해제된 다음 파싱될 수 있는 ZIP 아카이브로 팩키징된 CSV로서 저장된다. 그러나, 다른 플랫폼들은 (Javascript-개시된 브라우저 요청에 대한 JSON 응답 등의) 대안적 방법을 통한 총 시청 횟수만을 제공할 수 있다. 실시예는 클라이언트 애플리케이션 또는 최종 사용자의 요청을 이행하기 위하여 목적지의 엔드포인트로의 하나 이상의 요청에서의 통계를 요청하는 것을 선택할 수 있다. 블록(409)은, JSON으로 된 요청 데이터를 직렬화하는 것, HTTP 요청 팩키지를 형성하는 것 등을 나타내는 반면, 블록(410)은, (반환 JSON을 파싱하는 것, ZIP 아카이브(들) 내부의 CSV로부터 값을 추출하는 것 등의) API로부터의 응답의 실제의 전송과 직렬화해제(deserialization)를 나타낸다.
목적지가 API를 노출하지 않고, 대신에 블록(411)에서 목적지 구성을 조사함으로써 결정되는 바와 같이 대안적 집계를 요구한다면, 실시예는 블록(412-414)을 구현할 수 있다. 예를 들어, iTunes®은 얼마나 많은 팟캐스트가 시청되었는지를 판정하기 위한 방법을 노출하지 않지만, 실시예가 CDN 또는 기타의 네트워크 서버를 통해 트랜스코드를 서빙(serve)한다면, iTunes® 클라이언트를 통해 파일이 다운로드된 횟수를 판정하기 위해 파싱될 수 있는 로그 파일들이 존재할 수 있다.
이전의 집계로부터 데이터가 이용가능하지 않다면 비디오 정보는 집계 프로세스가 적절한 정보를 추출할 수 있는 방식으로 팩키징될 수 있다(블록 412). 일단 팩키지가 형성되고 나면, 블록(413)에서 적절한 집계 프로세스가 수행된다. 예를 들어 iTunes® 팟캐스트의 경우, 블록(413)에서의 로그 파싱 동작이 어느 네트워크 요청이 "재생"을 구성하는지를 판정할 수 있도록 하나 이상의 트랜스코드 URL이 제공될 수 있다. 추가로, (사용자가 시청할 수 있었던 비디오의 퍼센트를 운반할 수 있는) 전송된 바이트수, (봇(bot) 또는 기타의 자동화된 뷰어들을 필터링 아웃하기 위한) 사용자 에이전트 등의 요청의 다른 속성들 뿐만 아니라 요청의 타입이 분석될 수 있다(많은 미디어 클라이언트가 비디오가 존재하는지를 확인하기 위해 HEAD 요청을 이용하지만, 이것이 사용자가 비디오를 다운로드했거나 시청했다는 것을 의미하지는 않기 때문이다).
일단 요청된 값들이 로그 파일 등의 대안적 소스로부터 추출되고 나면, 블록(413)에서 실시예는 집계 프로시져의 마지막 부분으로서 미래의 요청을 위해 이들을 저장하는 것을 선택할 수 있다. 추가로, 실시예는, 최종 사용자 또는 클라이언트 애플리케이션에 대한 통계 요청이 고속이도록 보장하기 위해 오프라인의 스케쥴링된 방식으로 전체의 통계 요청 또는 집계 작업흐름을 수행할 수 있다.
이전 집계로부터 데이터가 이용가능하다면(블록 414), 블록(413)에서 수행된 임의의 저장소에 의해 이용된 동일한 저장 위치로부터 값들이 추출될 수 있다.
블록(415)에서, 통계는 통계 검색 프로세스로부터 반환된 값들에 따라 정규화를 요구할 수도 있다. 예를 들어, 한 목적지는 "참여(engagement)" (사용자가 시청한 비디오의 일부) 값들을 타임스탬프로 제공할 수 있는 반면, 또 다른 목적지는 값들을 퍼센트로 제공한다. 시간-기반의 값들은, 다음 단계에서 집계를 수행하기 위하여, 비디오의 알려진 지속기간을 이용하여 퍼센트 값으로 변환될 수 있다.
블록(416)에서, 정규화된 값들은 제공된 파라미터에 따라 집계될 수 있다. 한 예에서, 최종 사용자 또는 클라이언트 애플리케이션은 시간 범위에 걸친 각 목적지에 대한 총 시청 횟수를 요청할 수 있다. 비디오 A가 목적지 B 상에서 12회 시청되었고 목적지 C에서 48회 시청되었으며, 비디오 D가 목적지 B에서 10회 시청되었고 목적지 C에서는 시청되지 않았다면, 실시예가 목적지 B에 대한 22회의 시청과 목적지 C에 대한 48회의 시청을 반환하는 식으로 값들이 합산될 수 있다. 시청은 대안으로서 비디오, 시간 등에 의해 집계될 수도 있다.
블록(417)에서 실시예는 값들을 최종 사용자 또는 클라이언트 애플리케이션에 반환할 수 있다. 이것은, GUI 애플리케이션의 시각적 그래픽 표현, HTTP API에 대한 JSON-직렬화된 응답, 또는 필요하다면 기타의 방법일 수 있다.
블록(206 또는 208) 등의 임의의 이전 프로세스에 의해 실패가 표시된다면, 블록(418)에서 실시예는 전체의 통계 요청을 거부하고 실패 정보를 클라이언트 애플리케이션 또는 최종 사용자에게 반환할 수 있다.
인가 작업흐름
도 5는 본 발명의 실시예에 대한 인가 작업흐름을 상세히 기술한다. 인가는 목적지마다 상당히 다를 수 있지만, 표준은 인가 프로세스를 패턴화하는 것을 도울 수 있다. 블록(501)에서, 목적지 구성 및 기존의 목적지 메타데이터를 이용하여, 실시예는 최종 사용자 또는 클라이언트 애플리케이션에 대한 최적의 인가 방법을 선택할 수 있다. 흔한 HTTP-기반의 인가 방법은, OAuth, BasicAuth, 및 사전-공유된 크리덴셜이다. (FTP 또는 기타의 TCP-기반의 시스템 등의) 전달 메커니즘에 결부된 대안적 인가 방법이 역시 목적지에 의해 이용될 수 있다. 전용 인증 방법도 역시 흔하다.
일단 적절한 인증 방법이 결정되고 나면, 블록(502)은 최종 사용자 또는 클라이언트 애플리케이션으로부터 어떠한 추가 정보가 요구되는지를 판정하기 위해 제공된 구성 및 목적지 정보를 분석할 것을 요구할 수 있다. 만일 그렇다면, 블록(503)은 정보가 취득될 수 있기 이전에 최종 사용자가 별도의 인증 서비스를 방문해야 하는지를 식별한다. 이것은 OAuth 등의 인증 방법에서 요구되고, 여기서 사용자는 자신을 대신하여 애플리케이션이 목적지와 상호작용하는 것을 명시적으로 허용해야 한다. 표준 OAuth 구현에서, 사용자는 목적지에 의해 제공된 웹 사이트로 리디렉트(redirect)되어야 하므로, 블록(504)에서 실시예는 사용자에게 임시 인증 게이트웨이 인터페이스를 제공할 수 있다. 이것은, 위치 헤더 또는 대안적 리디렉트 방법을 이용하여 사용자를 목적지에 리디렉트할 수 있는(블록 506) 웹 페이지로 HTTP를 통해 최종 사용자를 서빙 및 디렉팅(directing)하는 것(블록 505)을 포함한다. 추가로, 임시 서비스는 목적지가 사용자를 다시 임시 인증 게이트웨이로 리디렉트할 때 성공 또는 실패 정보를 추출할 수도 있다. (리디렉트 동안에 목적지에 의해 제공된 값을 검사함으로써 블록(507)에 의해 판정되는 바와 같이) 동작이 성공적이면, 인가 시도로부터의 크리덴셜이 추출될 수 있고 지속적 이용을 위해 저장될 수 있다(블록 508).
목적지가 사용자를 외부 인증 서비스로 보낼 것을 요구하지 않지만 여전히 (BasicAuth HTTP 서비스 또는 FTP 계정을 위한 사용자이름 및 패스워드 등의) 추가 크리덴셜을 요구한다면, 실시예는 클라이언트 애플리케이션에게 이러한 크리덴셜을 요청하거나 최종 사용자가 기재(populate)할 그래픽 인터페이스를 제공할 수도 있다. 예를 들어, 실시예는 블록(509)에서 최종 사용자가 크리덴셜을 수집하기 위한 하나 이상의 그래픽 인터페이스를 제공하거나, 크리덴셜을 실시예에 운반하기 위해 클라이언트 애플리케이션에게 HTTP-기반의 API가 이용가능하게 될 수도 있다. 블록(510)은 최종 사용자가 요청된 크리덴셜을 (대개는 그래픽 인터페이스에) 능동적으로 제공하는 것을 나타내고, 블록(511)은 그래픽 인터페이스가 실시예 그 자체가 아니라 외부 클라이언트 애플리케이션에 의해 제공되고 있는 경우 클라이언트 애플리케이션이 (API 또는 대안적 방법을 통해) 크리덴셜을 실시예에 전달하는 것을 포함할 수 있다.
일단 외부 서비스로부터 또는 클라이언트 애플리케이션/그래픽 인터페이스로부터 크리덴셜이 수집되고 나면, 목적지는 추가의 유효성확인 단계를 요구할 수 있다. 이것은, 목적지 구성 또는 기타의 제공된 요건을 분석함으로써 블록(512)에서 판정된다. 추가의 유효성확인이 필요하다고 여겨지면, 이것은 블록(513)에서 수행될 수 있다. 예를 들어, OAuth 구현은 종종 애플리케이션과의 최종 사용자의 상호작용과 비동기로 동작을 수행하기 위하여 영구적 토큰용의 임시 액세스 코드를 전송할 것을 요구한다. BasicAuth에서, 추가 유효성확인은 단순히, 크리덴셜이 유효하고 애플리케이션이 목적지에 적절한 호출을 행하도록 인가되어 있다는 것을 보장하기 위한 인증된 요청일 수도 있다.
(513에서 유효성확인 단계의 결과를 분석함으로써 블록(514)에서 판정되는 바와 같이) 인가 또는 유효성확인 단계가 성공적이지 않으면, 실시예는 인가 요청을 거부할 수 있다(블록 515). 이것은, 그래픽 애플리케이션의 에러 메시지, 클라이언트 애플리케이션에 의한 HTTP-기반의 API 요청에 대한 JSON-직렬화된 응답 등일 수 있다. 대안으로서, 실시예는 목적지를 인가하기 위한 또 다른 시도를 사용자에게 제공할 수 있다.
일단 인가가 성공적이면, 실시예는 미래의 이용을 위해 크리덴셜을 저장할 수 있다(블록 516). 크리덴셜은 로컬 파일, 데이터베이스 등에 저장될 수도 있다. 실시예는 추가 보안을 위해 저장 이전에 이들 값들을 암호화할 수도 있다.
필요하다면, 인가 작업흐름은 블록(517)에 의해 식별되는 바와 같이 (공개, 업데이팅 등의) 외부 프로세스에 의한 이용을 위한 크리덴셜을 반환할 것을 요구할 수도 있다.
메타데이터 유효성확인 작업흐름(VALIDATE METADATA WORKFLOW)
도 6은 본 발명의 실시예에서의 메타데이터 유효성확인 작업흐름을 상세히 기술한다. 목적지는 비디오가 적절히 저장되고 디스플레이된다는 것을 보장하기 위해 다양한 순열의 메타데이터를 요구할 수 있고, 실시예는 사용자 경험의 편의성과 메타데이터의 목적지 승인 모두를 보장하기 위해 정규화된 메타데이터의 유효성확인을 요구할 수 있다.
블록(601)은, 실시예의 앞서 언급된 프로세스 또는 기타의 작업흐름 중 임의의 것에 의한, 유효성확인 작업흐름의 개시를 식별한다. 수행될 유효성확인의 방법(들)을 판정하기 위해, 임의의 목적지 구성 및 요건에 추가하여, (목적지-특정 및 비디오-특정 양자일 수 있는) 유효성확인될 메타데이터가 제공될 수 있다.
블록(602)은 제공된 비디오 메타데이터와 공개 및 업데이트 동작들에서 수집된 목적지 구성의 비교를 요구한다. 이 비디오 메타데이터는 비디오 파일 자체로부터 추출되었거나(예를 들어, 한 방법은 메타데이터 저장을 지원하는 다양한 컨테이너 포맷을 통해서일 수도 있다), 그래픽 인터페이스 또는 클라이언트 애플리케이션을 통해 최종 사용자에 의해 제공되었을 수도 있다. 예를 들어, 기본 메타데이터 요건은 일반적으로 비디오 "제목", "설명", 한 세트의 "태그" 또는 "키워드" 뿐만 아니라 저자 정보를 포함한다(그러나 이것으로 제한되지 않는다). 목적지 구성은, 실시예 내부의 분류법에 의해 식별되는, 요구되는 및 선택사항적인 메타데이터 필드 세트를 나타낼 수 있다. 추가로, 목적지 그 자체는 메타데이터를 요구할 수도 있다. 예를 들어, 실시예는 iTunes® 팟캐스트를 목적지로서 이용가능하게 할 수도 있다. 팟캐스트는, 제목, 생성자, 하나 이상의 카테고리, 설명, 및 기타의 필드를 요구한다.
(블록(603)에 의해 판정되는 바와 같이) 목적지 메타데이터가 유효하지 않거나 추가의 값을 요구한다면, 실시예는 클라이언트 애플리케이션에게 추가 크리덴셜에 대한 요청으로 응답하거나 목적지 구성에 기초하여 최종 사용자에게 그래픽 인터페이스를 제공할 수 있다(블록 604). 예를 들어, 목적지 구성이 "저자"에 대한 추가 메타데이터 필드를 나타낸다면, 이것은 또한 그 값이 "문자열"이어야 한다는 것을 나타낼 수 있다. 이것은 사용자가 완료하기 위한 적절한 인터페이스 요소들을 그래픽 인터페이스가 디스플레이할 수 있게 한다.
일단 클라이언트가 새로운/업데이트된 메타데이터를 제공하고 나면(블록 605), 이것은 블록(606)에서 목적지 구성에 따라 유효성확인될 수 있다. 제공된 저자가, 예를 들어, 그 길이가 148 캐릭터이고 유니코드(Unicode) 캐릭터를 포함하고, 목적지가 유니코드를 허용하지 않고 127 캐릭터 미만을 요구한다면, 실시예는 블록(603 및 604)을 통해 귀환함으로써 유효한 메타데이터를 제공할 또 다른 기회를 클라이언트 애플리케이션 또는 최종 사용자에게 촉구할 수 있다.
이 프로세스는 모든 목적지 메타데이터가 공급되고 유효할 때까지 반복된다. 그 다음, 실시예는 비디오 메타데이터와 유사한 처리를 수행할 수 있다(블록 607-610). 공개 또는 업데이팅되고 있는 각각의 비디오에 대해, 최종 사용자는 (블록(608)에서 클라이언트 애플리케이션에 의해 요청되고 블록(609)에서 최종 사용자에 의해 제공되는) 목적지 구성이 예상하는 요구된 비디오 메타데이터 모두를 제공할 수 있다. 추가로, 목적지 메타데이터처럼, 제공된 각각의 값은 블록(610)에서 목적지의 구성과 대조하여 유효성확인되어 그 값이 일단 목적지의 엔드포인트에 전송되고 나면 거부되지 않을 것임을 보장할 수 있다.
실시예는 모든 비디오 메타데이터를 간소화된 모델의 정규화된 메타데이터로 제약하여 가장 간단한 사용자 경험을 보장할 수 있다. 이것은, 시스템 내의 어떠한 제목도 모든 목적지들에 걸쳐 가장 짧은 허용된 제목보다 길게 될 수 있을 것을 요구할 것이지만, 유효성확인에 의해 요구되는 보정의 발생을 감소시킬 것이다.
일단 모든 목적지와 비디오 메타데이터가 유효성확인되고 나면, 실시예는, 블록(611)에 의해 식별되는 바와 같이, 미래의 이용을 위해 로컬 파일, 데이터베이스 등에 값들을 저장할 수 있다. 이것은, 목적지에 대한 메타데이터 요건이 변하거나 최종 사용자가 메타데이터를 변경하지 않는 한 미래의 업데이트 프로세스를 간소화한다.
그 다음, 실시예는, 이전의 동작들과 유사한 직렬화 및 전송 전략을 따름으로써 블록(612)에서 (공개 또는 업데이팅 등의) 유효성확인된 메타데이터를 외부 프로세스에 반환할 수 있다.
트랜스코드 작업흐름(TRANSCODE WORKFLOW)
도 7은 본 발명의 실시예에서의 비디오를 트랜스코딩하기 위한 프로세스를 상세히 기술한다. 트랜스코딩은 배포에 있어서 보다 기술적인 프로세스들 중 하나이며, 동시에, 많은 최종 사용자들이 특정한 비디오 포맷 및 속성에 대한 지식이 없다는 사실로 인해 추상화를 위한 강력한 후보이다. 후속해서, 실시예는, 최종 사용자가 프로세스에 대해 결정을 내릴 필요가 없도록 트랜스코딩을 시스템의 묵시적 양태화 할 수 있다.
블록(700)은, 실시예가 목적지의 구성으로부터 목적지에 대한 트랜스코드 요건을 추출할 수 있다는 것을 나타낸다. 이 구성은, 컨테이너 또는 캡슐화 포맷, 파일 크기, 비디오 압축 포맷, 비디오 지속기간, 비디오 해상도, 프레임 레이트, 비디오 압축 프로파일, 비디오 압축 비트 레이트, 스캔 타입, 오디오 압축 포맷, 오디오 샘플 레이트, 오디오 압축 비트 레이트, 오디오 채널 등을 포함한 그러나 이것으로 제한되지 않는, 허용가능한 트랜스코드를 나타내는 속성 임계치 어레이(an array of attribute thresholds)를 포함해야 한다.
트랜스코딩 중인 비디오 파일에 대한 정보를 추출한 후에, 실시예는, 블록(701)에서 그 비디오 파일이 트랜스코딩될 수 있다는 것을 보장할 수 있다. 비디오 파일은, 다양한 이유들: 임의의 요구되는 트랜스코드에 대해 파일의 품질이 너무 낮거나, 비디오 파일에 필요한 오디오 트랙(들)이 빠져 있거나, 비디오가 실시예에 의해 이용되는 트랜스코딩 소프트웨어에 의해 판독될 수 없거나, 너무 많은 비디오 또는 오디오 트랙이 존재하거나 등으로 인해, 트랜스코딩되지 못할 수도 있다. (mediainfo 또는 ffmpeg 등의) 다양한 애플리케이션은, 목적지에 대한 특정한 트랜스코드 프로파일에 대한 그 적용성을 판정하기 위하여, 파일로부터 미디어 메타데이터를 추출하는 능력을 제공한다. 비디오 파일이 트랜스코딩되지 못한다면, 실시예는 트랜스코딩 요청을 거부할 수 있다(블록 702).
(목적지 요건 또는 기타의 제공된 구성을 파싱함으로써 블록(703)에서 판정될 수 있는) 목적지에 의해 요구되는 모든 트랜스코드에 대해, 실시예는 원본 비디오를 처리하여 트랜스코딩 소프트웨어에 어떤 파라미터를 제공할지를 판정할 수 있다. 각각의 트랜스코드는, 최종 트랜스코드가 순응해야 하는 특정한 속성을 식별하는, 트랜스코드 "템플릿"에 대응한다. 블록(704)에서, 목적지 요건을 파싱함으로써 한번 더 이들 템플릿들 각각은 컴파일될 수 있다. 그 다음, 블록(705)에서 원본 미디어 파일로부터 추출되거나 스트리밍될 수 있는 주 비디오 트랙은, 블록(706)에서, 트랜스코딩되어야 하는지의 여부를 판정하기 위해 트랜스코드 템플릿과 비교될 수 있다. 예를 들어, 비디오 파일에 H.264 비디오 트랙, 1920x1080의 해상도, 10 Mbps의 비트 레이트, 및 30 fps의 프로그레시브 프레임 레이트가 제공되어 있지만, 트랜스코드 템플릿이 1280x720 해상도의 H.264 비디오 트랙을 요구한다면, 그 비디오 트랙은 템플릿의 규격으로 트랜스코딩되어야 한다. 그러나, 목적지가 1920x1080 H.264를 허용하는 제2 트랜스코드 템플릿을 가진다면, 비디오 트랙은 제2 탬플릿을 위해 트랜스코딩되지 못할 수도 있다. 실시예에 대한 목적지 구성은, 특정한 값 대신에, 비트레이트 또는 프레임 레이트 임계치, 허용가능한 해상도 범위 등을 정의할 수 있다. 많은 경우에, 특히, (Apple®의 AppleTV® 등의) 목적지가 재생을 위한 특정한 하드웨어 환경에 의존하는 경우에, 트랜스코드 템플릿 구성과 정합하지 않는 단일 속성은 트랜스코딩을 요구한다.
비디오 트랙에 대한 트랜스코딩이 요구된다면, 실시예는 이용되고 있는 특정한 트랜스코딩 소프트웨어에 대한 새로운 트랜스코드 요건을 팩키징할 수 있다. 트랜스코드 템플릿의 요건에 기초하여, 특정한 트랜스코딩 소프트웨어도 역시 요구될 수 있다. 목적지와 매우 비슷하게, 상이한 트랜스코딩 애플리케이션들은 새로운 트랜스코드를 요청하는 다양한 방법들을 가진다. 일부는 네트워크-기반의 API를 노출시키고, 일부는 명령어가 인수(arguments)를 통해 실행파일(executable)에 제공되는 실행가능한 바이너리들이며, 다른 것들은 이전에 구성된 트랜스코드 프로파일에 기초하여 트랜스코딩을 개시하기 위해 공유된 폴더를 이용한다. 실시예는 매우 다양한 소스 파일과 트랜스코드 템플릿을 처리하기 위하여 다양한 트랜스코딩 솔루션들을 통합할 것을 선택할 수도 있다. 블록(707)의 결과는 트랜스코드 템플릿 규격에 순응하는 비디오 트랙이어야 한다.
어떠한 트랜스코딩도 요구되지 않는다면, 블록(708)에서 비디오 트랙 정보가 복사된다. 이것은 오디오와 비디오의 독립적 트랜스코딩을 가능케 하며, 최종 파일은 마지막 단계로서 "리먹싱(remuxed)"(개개의 오디오 및 비디오 트랙이 단일의 파일로 결합)될 것이다.
일단 비디오 트랙이 생성되고 나면, 오디오 트랙(들)에 대해 유사한 프로세스가 채용될 수 있다. 트랜스코드 템플릿에 기초하여, 오디오 트랙이 추출되거나 스트리밍된 다음(블록 709), 트랜스코딩이 필요한지를 알아보기 위해 분석되고 트랜스코드 템플릿 요건과 비교된다(블록 710). 속성들(오디오 샘플 레이트, 채널 수, 오디오 압축 포맷, 오디오 압축 비트레이트 등)은 상당히 상이할 수 있지만, 프로세스는 동일하다: 오디오 트랙이 트랜스코드 템플릿 요건과 정합하지 않는다면, 실시예에 의해 이용되고 있는 트랜스코딩 소프트웨어에 대해 트랜스코딩 명령어가 팩키징될 수 있고 목적지의 트랜스코드 템플릿 요건에 순응하는 새로운 오디오 트랙이 생성된다(블록 711). 그 외의 경우, 블록(712)에서, 적절한 오디오 트랙(들)이 복사되어 이전 단계들로부터의 비디오 트랙과 결합된다.
블록(713)에서, 비디오 트랙 및 오디오 트랙이 트랜스코드 템플릿에 의해 표시된 캡슐화 포맷을 이용하여 단일의 파일로 결합된다. 이것은, MPEG-4 Part 14 파일, 또는 MPEG-2 프로그램 스트림(Program Stream), WebM 컨테이너 파일(container file) 등일 수 있다.
일단 파일이 생성되고 나면, (블록 714에서 목적지 구성을 조사함으로써 판정되는 바와 같이) 목적지에 의해 파일이 적절히 이용될 수 있도록 보장하기 위해 추가 단계들이 필요할 수 있다. 예를 들어, (피드-기반의 목적지 또는 웹 재생기에서 종종 이용되는) HTTP 프로그레시브 스트리밍(Progressive Streaming)에 대해 MPEG-4 파일이 의도된다면, ("moov" 원자(atom)에 포함된) 비디오 파일 인덱스 정보는, 다운로드를 완료하기 이전에 비디오 파일이 재생을 개시할 수 있도록 파일의 시작 부근으로 이동되어야 한다. 파일이 완료된 것으로 간주되기 이전에 블록(715)에서 이 동작 및 다른 동작이 요구될 수 있다.
일단 트랜스코드가 마무리되고 나면, 이것은 저장될 수 있다(블록 716). 실시예는 미래의 더 빠른 업데이트 동작을 위해 트랜스코드를 저장할 수 있다. 추가로, 일부 목적지는 트랜스코드 템플릿을 공유할 수 있다: 트랜스코드가 저장되고 비디오가 동일한 트랜스코드 템플릿을 요구하는 목적지에 공개된다면, 전체의 트랜스코드 작업흐름은 바이패싱될 수 있고 대신에 기존의 트랜스코드가 이용된다. 트랜스코드 외에도, 블록(717)에서 실시예는 트랜스코드 파라미터 뿐만 아니라, 피드(feeds) 등의 다른 환경에서 이용될 수 있는 파일 크기와 같은 임의의 추가적 메타데이터를 저장할 수 있다.
모든 트랜스코드가 생성된 후에, 블록(718)에서, 실시예는 트랜스코드(들)의 위치 뿐만 아니라 임의의 트랜스코드 파라미터 또는 추가 메타데이터를 외부 프로세스에 반환할 수 있다.
전송 작업흐름(TRANSMIT WORKFLOW)
도 8은 본 발명의 실시예에서의 목적지 전송 작업흐름을 상세히 기술한다. 공개 요청의 전송 또는 기존 비디오의 업데이팅은 다양한 프로토콜 및 목적지 요건과의 상호작용을 요구하며, 최종 사용자와 클라이언트 애플리케이션에 대한 자원에 걸쳐 고수준 추상화를 유지하면서 특정한 전송 로직을 캡슐화하는 것을 포함한다.
메타데이터 및 파일들이 목적지로의 전송에 준비되어 있을 때, 블록(801)에서 실시예는 메타데이터를 목적지-특정 언어로 변환할 수 있다. 예를 들어, YouTube®, Blip®, 및 DailyMotion® 각각은 고유한 카테고리 시스템을 유지한다. 실시예는 비디오에 관한 정규화된 카테고리 선택을 그 목적지에 의해 지원되는 특정한 카테고리로 변환하되, "Automotive"와 같은 총칭적 카테고리가 Blip® 상에서 카테고리 번호 "29" 및 YouTube® 상에서 "Autos & Vehicles"가 되도록 변환할 수 있다.
각각의 목적지는 변환된 메타데이터 및 파일을 전송하는 하나 이상의 방법을 요구할 수 있다. 목적지가 (목적지 구성을 분석함으로써 블록(802)에서 판정되는 바와 같이) API를 제공한다면, API의 특정한 동작들은 적절한 순서로 수행되어야 한다. 예를 들어, 비디오를 HTTP API에 제출하는 것은 먼저 세션-기반의 토큰과 크리덴셜을 교환하는 것을 요구할 수 있다(블록 803). 이것은 URL-인코딩된 형태 값으로서의 크리덴셜을 제공하는 간단한 POST 동작일 수 있다. 일단 토큰이 취득되고 나면, 각각의 HTTP 요청은 헤더에서 또는 URL의 일부로서 그 토큰을 이용해야 한다. 목적지는 하나 이상의 트랜스코딩된 비디오 파일의 바이트들을 업로드하기 위해 PUT 요청을 요구할 수 있다. 일단 비디오 파일(들)이 업로드되고 나면, 목적지는 그 목적지 상의 비디오를 나타내는 고유 id를 반환할 수 있다. 그 다음, "제목", "설명", "태그", 및 "카테고리"에 대한 값들을 갖는 JSON으로서 메타데이터를 직렬화함으로써 메타데이터를 업데이트하기 위해 추가의 POST 요청이 이용될 수 있다. 이 프로세스를 통해, 제출되고 있는 메타데이터의 직렬화(블록 804)와, 직렬화된 및/또는 원시 트랜스코딩된 비디오 데이터의 전송(블록 805) 양쪽 모두가 수행된다.
블록(806)은, 목적지의 API가 전송된 메타데이터를 수락하는지를 판정한다. 이것은, HTTP 서비스의 상태 코드를 확인하는 것(예를 들어, 200은 종종 성공적인 동작을 나타낸다), (직렬화된 성공/실패 정보가 전달될 수 있는) 응답 몸체부(response body), (실시예에 의해 야기된 웹 서비스를 통해) HTTP 콜백을 수락하는 것, 또는 기타의 방법을 포함할 수 있다. 전송이 성공적이면, 응답 정보는, 미래의 업데이트, 미공개, 및 통계 검색 동작들을 위해 실시예에 의해 저장될 수 있다(블록 807).
(블록 808에서 판정되는) 목적지가 트랜스코드(들)의 ZIP 아카이브, 썸네일 이미지(thumbnail image), 및 XML-직렬화된 메타데이터 등의 팩키징된 파일의 전달을 요구한다면, 실시예는 관련된 전송 프로세스를 수행할 수 있다. 최종 팩키징된 콘텐츠를 제출하는데 요구되는 임의의 크리덴셜은, 블록(809)에서, 이전의 인증 단계로부터 또는 최종 사용자 또는 클라이언트 애플리케이션에게 촉구함으로써 수집될 수 있다. 현재의 예에서, 블록(801)에서 제공된 메타데이터는, 트랜스코딩된 비디오 및 필요하다면 임의의 추가 파일들과 함께 압축될 수 있는 XML 파일을 생성하기 위해 변환될 수 있다(블록 810). 마지막으로, 목적지에 제공된 크리덴셜을 이용함으로써, 최종 팩키징된 콘텐츠는 목적지에 제출될 수 있다(블록 811). 파일 전달은, 사용자이름, 패스워드, 및 FTP 호스트가 크리덴셜이 되는 FTP, 또는 OAuth 또는 BasicAuth 크리덴셜이 이용되는 HTTP 등의 프로토콜을 통해서일 수 있다. 마지막으로, 물리적 하드 드라이브 등의 대안적 전달 방법이 요구될 수 있고, 이 방법은 적절한 목적지에 전송되기 이전에 팩키징된 파일과 임의의 추가의 매니페스트 파일(manifest file)을 목적지 드라이브에 복사하는 것을 포함한다.
팩키징된 파일이 올바르게 전달되었다고 판정될 수 있다면(블록 812), 실시예는 전송 요청에 실패하거나 필요하다면 전송 방법 처리를 계속할 수 있다. 예를 들어, 목적지의 FTP 서버가 ZIP 아카이브의 실패된 전송을 보고한다면, 실시예는 임의의 추가적인 전송 동작을 중단하고 그 요청을 거부하기로 선택할 수 있다. 대안으로서, 아카이브가 성공적으로 복사되었다면, 실시예는 전송 동작의 진행을 계속할 수 있다.
목적지가 웹 사이트 또는 RSS 피드 등의 호스팅된 엔드포인트를 요구한다면(블록 813), 실시예는 이 콘텐츠를 호스팅하기 위해 웹 서비스를 구현할 수 있다. 이 웹 서비스는, PHP, Ruby, Java, HTML, 자바 스크립트 등의 다양한 언어와 기술로 구현될 수 있다. 이들 기술을 이용함으로써, 실시예는 블록(801)에서 판정된 목적지-특정 언어로부터의 메타데이터를 그 웹 서비스의 필요한 구조로 변환할 수 있다. 예를 들어, 표준 RSS 피드는 대개, RFC 822에 따라 "공개된" 날짜와 시간을 디스플레이해야 하는 <pubDate> 요소를 구현한다. 실시예는 원래의 공개 날짜와 시간을 간단한 타임스탬프로서 저장했을 수도 있고, 이 경우 이것은 피드에서 이용될 수 있기 이전에 변환될 수 있다. 그 다음, 선택된 특정한 기술은 변환된 메타데이터를 요구되는 RSS의 "취향(flavor)"에 의해 결정되는 적절한 XML로 포맷할 수 있다(블록 814).
메타데이터를 포맷하는 것 외에도, 호스팅된 엔드포인트는 전달되고 있는 트랜스코드의 지속적 전달과 보관을 보장하기 위해 CDN 또는 클라우드 저장소 등의 외부 서비스를 요구할 수 있다(블록 815). 블록(816)에서, 포맷된 메타데이터(예를 들어, 최종 RSS 파일 또는 웹 페이지)는 목적지에 의해 판정되는 적절한 프로토콜(HTTP, SSL을 통한 HTTP 등)을 통해 전송될 수 있다. Apache, IIS®, 및 기타의 HTTP 서버 등의 추가 소프트웨어가 웹 서비스 컴포넌트를 전송하기 위해 다양한 용량으로 이용될 수 있다.
일단 목적지의 API가 통보받고, 팩키징된 파일들이 전달되었고, 및/또는 호스팅된 엔드포인트가 구성되었고 서빙중이면, 실시예는 공개, 미공개, 또는 통계 검색 등의 미래의 동작들을 가능케하기 위하여 공개된 정보를 저장할 수 있다(블록 817). 공개 동작이 성공하지 않았다면(무효한 인증 크리덴셜, 무효한 메타데이터, 네트워크 문제 등) 전송 요청이 실패할 수 있다(블록 819). 그 외의 경우 실시예는 블록(818)에서 목적지 API 또는 기타의 전송 단계로부터 검색된 (목적지에 대한 고유 비디오 id, 비디오 자원 URL 등의) 성공적 전송 정보를 반환할 수 있다.
배포 흐름(DISTRIBUTION FLOW)
도 10은 본 발명의 실시예에서의 콘텐츠 배포를 위한 방법을 포함한다. 프로세스(1000)에서, (단일의 물리적 모듈의 메모리에 포함된, 분산형 컴퓨터 시스템에서 많은 물리적 모듈의 메모리에 걸쳐 분산된 등의) 적어도 하나의 머신 판독가능한 매체는 컴퓨팅 장치에서 실행될 때 컴퓨팅 장치로 하여금 이하에서 설명되는 바와 같은 방법을 수행하게 하는 명령어들을 포함한다.
블록(1005)에서, 컴퓨팅 장치(예를 들어, 데스크탑, 서버, 노트북, 울트라북, 랩탑, 모바일 전화, 스마트폰, 분산형 컴퓨팅 클러스터 등)는 비디오를 수신한다. 실시예는 비디오를 제1, 제2, 및 제3 배포 채널에 배포하기 위한 옵션을 사용자에게 동시에 제공하는 단일 인스턴스(즉, 단일 페이지)의 GUI를 디스플레이할 수 있다. 예를 들어, 도 9에서, GUI(900)는 6개의 상이한 채널: 채널 905(YouTube®), 906(Blinkx®), 907(Boxee®), 908(hulu®), 909(Roku®), 910(Sony Bravia®)에 대한 그래픽 요소의 부분들을 포함한다. GUI(900)를 통해 공급된 사용자 입력(예를 들어, 사용자가 배포 채널을 "클릭"하거나 또는 기타의 방식으로 선택하는 것)에 응답하여, 실시예는, 예를 들어, 비디오가 제1 및 제2 배포 채널(905, 906)에 배포되지만 제3 배포 채널(907)에는 배포되지 않을 것인지를 판정한다.
실시예에서, 블록(1010)은 비디오에 대한 제1 및 제2 특성을 판정한다. 예를 들어, 실시예는 업로드된 비디오로부터 정보를 추출 및 저장한다. 이 정보는, 예를 들어, 제한없이, 파일 타입(예를 들어, MPEG4(HD), Windows Media(HD), Apple ProRes(SD) 등), 컨테이너 타입, 비디오 지속기간, 비디오 해상도, 프레임 레이트, 비디오 압축 비트 레이트, 및 오디오 압축 비트 레이트를 포함하는 그룹으로부터 선택되는 제1 및 제2 특성에 관한 것일 수 있다. 제1 및 제2 특성은, 파일에 대한 메타데이터 등의 메타데이터와, 반드시는 아니지만 비디오의 콘텐츠를 분석함으로써 판정될 수 있다(그러나 반드시 그런 것은 아니다). 제1 및 제2 특성은, 비디오 제목, 키워드, 설명, 및 비디오 카테고리 등의 정규화된 방식(API 사용자 입력)으로 보안된 메타데이터에 의해 판정될 수 있다(그러나 반드시 그런 것은 아니다). 이 특성은 비디오 프리이지미(preimage)(예를 들어, 비디오로부터의 비디오 콘텐츠의 선택된 프레임)에 관한 것일 수 있다.
블록(1010)은 추출된/분석된 정보에 기초하여 비디오를 조사하여 플랫폼(예를 들어, 플랫폼을 지원하기 위한 프로세서 기반의 시스템의 대표 예에 대해 도 11을 참조)이 비디오를 지원하는지를 판정하는 것을 포함할 수 있다. 예를 들어, GUI(900)는 비디오를 제1, 제2, 및 제3 배포 채널(905, 906, 907) 뿐만 아니라 제4 배포 채널(908)(예를 들어, hulu®)에 비디오를 배포하기 위한 옵션을 사용자에게 동시에 제공할 수 있다. GUI(900)를 통해 공급된 사용자 입력에 응답하여, 실시예는 사용자가 비디오를 제4 배포 채널에 배포하기를 원하는지를 판정할 수 있다. 그러나, 플랫폼은, 비디오를, 비디오에 대한 판정된 특성들 중 하나를 분석하는 것에 응답하여 제4 배포 채널(908)에 대응하는 제4 포맷을 갖는 트랜스코딩된 제4 비디오로 트랜스코딩하지 않기로 결정할 수 있다. 예를 들어, 비디오에 대한 파일 포맷 또는 압축 방식은, 비디오가 채널(908)에 순응하도록 트랜스코딩될 수 없게 하는 방식일 수 있다.
임의의 비호환성을 해결하기 위해, 플랫폼은 사용자로부터 더 많은 정보를 구하여 이전에 선택된 채널(905, 906)에서의 빈 공간(void) 또는 문제를 채울 수 있다. 예를 들어, 한 실시예의 프로세스의 이 시점에서 플랫폼은 비디오 파일, 비디오에 관한 정보(예를 들어, 파일과 함께 업로드되었던 메타데이터, 파일이 업로드된 후에 파일로부터 도출된 메타데이터, 및 파일과 함께 업로드된 또는 이로부터 도출된 기타의 데이터)를 포함한다. 예를 들어, GUI(900)를 통해 공급된 사용자 입력에 응답하여, 플랫폼은 (이제는 채널 905, 906이 바람직하고 기타의 채널들은 바람직하지 않다는 것을 알고) 제1 채널(905)에 대해 어떤 제1 추가 채널 정보가 필요한지 그리고 제2 채널(906)에 대해 어떤 제2 채널 정보가 필요한지를 판정할 수 있다. 제1 채널 정보는 제2 채널 정보와 같지 않을 수도 있다. 예를 들어, 제1 채널 정보는, 사용자 크리덴셜(예를 들어, 사용자이름, 패스워드), 피드 제목, 파일 포인터, 및 비디오로부터의 대표 프레임 중 하나를 포함할 수 있다. 채널(906)은 파일 포인터를 필요로 하지 않을 수 있으므로, 채널(906)만이 선택되었다면 플랫폼은 이러한 정보를 위해 사용자를 귀찮게 하지 않을 것이다.
현재 연구중인 예에서(사용자가 채널(905, 906)을 통해 비디오를 배포하기로 선택한 예), 실시예는 비디오가 플랫폼과 호환된다고(또는 그와 있을 수 있거나 그러할 가능성이 있다고) 판정할 수 있다. 따라서, 블록(1020)에서(블록 1015는 이하에서 더 논의된다), 플랫폼은 트랜스코딩이 정말로 필요한지를 판정한다. 예를 들어, 업로드된 비디오는 채널들(905, 906) 중 어느 하나에 대해 트랜스코딩을 필요로 하지 않을 수 있고 비디오는 단순히 이들 채널을 통해 전달될 수 있다(블록 1025). 그러나, 트랜스코딩이 필요하다면 블록(1030)에서 이 트랜스코딩이 발생한다. 플랫폼은 비디오를 제1 배포 채널(채널 905)에 대응하는 제1 포맷을 갖는 트랜스코딩된 제1 비디오로 트랜스코딩한다. 플랫폼은 또한, 비디오를 제2 배포 채널(채널 906)에 대응하는 제2 포맷을 갖는 트랜스코딩된 제2 비디오로 트랜스코딩한다. 제1 포맷(예를 들어, MPEG-2)은 제2 포맷(예를 들어, H.264)과 같지 않을 수 있다. 실시예는, (예를 들어) 비호환성에 기초하여 또는 사용자가 채널에 배포하기를 원하지 않아서, 비디오를 제3 배포 채널(907)에 대응하는 제3 포맷을 갖는 트랜스코딩된 제3 비디오로 트랜스코딩하지 않기로 선택할 수 있다. 이것은 모든 가능한 채널 포맷들로의 비이성적인 강제적 트랜스코딩(brute force transcoding)에 비해 노력을 절감시켜 준다.
채널(905, 906)에 대한 트랜스코딩은 "트랜스코드 큐(transcode queue)"를 이용할 수도 있다. 비디오는 엔빌로프 변경(예를 들어, Windows 미디어 파일을 YouTube/채널(905)에 적절한 새로운 오디오 및 새로운 비디오를 갖는 엔빌로프로 변경)을 통해 포맷0으로부터 (채널(905)에 대응하는) 포맷1로 트랜스코딩될 수 있다. 이 트랜스코딩은 원하는 채널에 대응하는 트랜스코더(예를 들어, Rhozet®)를 통해 처리되는 비트 레이트를 조절하는 것을 더 포함할 수 있다. 채널(906)에 관하여, 비디오는 H.264로부터 FFMPEG 또는 MPEG-2로의 엔빌로프 변경을 통해 포맷0으로부터 (채널(906)에 대응하는) 포맷2로 트랜스코딩될 수 있다.
사용자에 의해 선택된 채널로의 트랜스코딩 후에, 블록(1035)은 제1 메타데이터(예를 들어, 파일에 대한 키워드, 비디오에 대한 설명, 비디오에 대한 압축 레이트, 비디오에 대한 재생 시간의 지속기간)와 트랜스코딩된 제1 비디오를 제1 컨테이너 내로 팩키징하고 제2 메타데이터와 트랜스코딩된 제2 비디오를 제2 컨테이너 내로 팩키징한다; 그리고, 제1 컨테이너를 제1 채널에 공개하고, 제2 컨테이너를 제2 채널에 공개한다(블록 1040). 공개는 채널별로 달라질 수 있다. 예를 들어, 채널(905)의 경우, 플랫폼은 파일을 단순히 공급할 수 있지만 채널(906)(또는 어떤 다른 채널)의 경우, 파일은 피드를 통해 이용가능하게 될 수 있는 반면, 채널(907)의 경우 플랫폼은 단순히 그 파일을 호스팅하는 URL을 제공할 수 있다(그러나, 그 파일을 직접 채널에 공급하지 못할 수 있다).
블록(1045)에서, 이 방법은 공개된 제1 컨테이너에 대한 제1 메트릭 데이터와 공개된 제2 컨테이너에 대한 제2 메트릭 데이터를 수신하는 단계를 포함한다; 여기서, 제1 메트릭 데이터는 제2 메트릭 데이터와는 상이하게 포맷된다. 이 메트릭 데이터는 (채널 905에 의해 공급되고, 히트수/일별 시간을 공급하지 않는) 히트수/평일과 (채널 906에 의해 공급되고, 히트수/평일을 공급하지 않는) 히트수/일별 시간 등의 통계를 포함할 수 있다. 다른 메트릭 데이터는, 예를 들어, 재생의 평균 지속기간(예를 들어, 사용자는 평균 10%의 비디오를 시청하거나 평균이 90%에 근접한다)을 포함할 수 있다. 이 데이터를 액세스하는 것은, 프로세스 초기에 플랫폼이 사용자에게 채널들(905, 906) 각각에 대한 사용자의 ID(예를 들어, 계정 크리덴셜)를 질의하여(블록 1010) 비디오를 그 채널에 업로드한 후에도 플랫폼이 그 채널에 "테더링되어(tethered)" 있도록 허용하기 때문에 가능할 수 있다.
블록(1050)은 제1 및 제2 메트릭 데이터를 제1 및 제2 메트릭 데이터 양쪽 모두에 대응하는 공통의 정규화된 데이터로 정규화하는 것을 포함한다. 예를 들어, 사용자에게 채널(905)이 히트수/평일을 가지며 채널(906)이 히트수/일별 시간을 갖는다는 것만을 보여주는 것 대신에, 플랫폼은 채널(905)과의 더 양호한 비교를 위해 채널(906)에 대해 일별 히트수를 보여주도록 데이터를 정규화할 수도 있다. 이 데이터에 의해 사용자는 한 채널에 대한 비디오 개발(developing)(그러나 다른 채널은 아님)이 의미가 있는지를 각 채널의 유효성(예를 들어, 시청자들이 큰 폭으로 채널(905)을 선호하는 것으로 보인다면 채널(906)에 대해 비디오 포맷에 왜 시간을 보내야 하는지)에 기초하여 결정할 수 있다.
또한, 플랫폼은 채널(905, 906)에 테더링되어 있기 때문에, 사용자는 배포된 비디오를 용이하게 업데이트 또는 관리할 수 있다. 예를 들어, 블록(1010)에서 취득된 ID 정보를 이용하여, 사용자는 이들 채널들에 액세스하여 비디오를 업데이트(예를 들어, 이전 비디오에 5분의 비디오 콘텐츠를 추가, 검색을 위한 키워드의 추가 등의 비디오에 관련된 데이터를 업데이트), 비디오를 제거하는 등을 할 수 있다.
이제 블록(1015)에 중점을 둔다. 블록(1015)에서, 이 방법은, 사용자 입력에 응답하여, 제1, 제2, 및 제3 프로세서 기반의 시스템(예를 들어, 서버, 워크스테이션 등)을 포함하는 하드웨어 그룹으로부터, 제1 및 제2 프로세서 기반의 시스템을 선택하지만, 제3 프로세서 기반의 시스템은 선택하지 않는다. 예를 들어, 사용자는 단일의 짧은 비디오 파일을 업로드했을 수 있고 단순히 그 비디오를 채널(905)에 업로드하기를 원한다. 이것은 비교적 적은 컴퓨팅 자원을 요구할 수 있으므로 단일 프로세서 기반의 시스템이 그 제작물을 처리하도록 통제될 수 있다. 그러나, 또 다른 예에서 사용자는, 8개의 상이한 채널에 배포될 필요가 있는 30개의 비디오(각각의 파일은 수 메가바이트의 데이터를 포함함)를 포함하는 영업 교육용 비디오 시리즈를 업로드하기를 원하는 대기업일 수 있다. 이것은 훨씬 더 많은 컴퓨터 자원을 요구할 수 있다. 따라서, 플랫폼은 이 부하를 인식하고 비디오 제작물을 처리하기 위해 더 큰 양의 자원을 선택할 수 있다. 이것의 많은 부분이 병렬로 발생하여 사용자는 소정 비디오를 채널(905)에 공개하면서 그 비디오(또는 다른 비디오)를 채널(906)에 공개할 수 있다. 따라서, 실시예에서, 이 방법은, 비디오를 제1 프로세서 기반의 시스템을 통해 트랜스코딩된 제1 비디오로 트랜스코딩하면서 병렬로 그 비디오를 제2 프로세서 기반의 시스템을 통해 트랜스코딩된 제2 비디오로 트랜스코딩하는 단계를 포함한다. 트랜스코딩은 동시에 발생할 수 있다.
따라서, 실시예는 프로세스를 개시 및 추적하기 위한 사용자 인터페이스에 의한 다중-포맷 비디오 및 메타데이터 입수(ingest), 다중-포맷 인코딩 및 다중-플랫폼 공개를 위한 단일의 구성가능한 프로세스를 포함한다. 실시예는, 웹사이트, iptv 시스템, 모바일 장치 등에서는 적절히 렌더링되지 않아 비디오 소유자가 수동적 단계들을 통해 각각의 파일을 별도로 처리하는데 시간과 돈을 소비하게 하는 비디오 및 메타데이터의 문제를 해결한다. 또한, 실시예에서 포맷은 클라우드에서 이루어지므로, 시간 절감 및 병렬 머신 처리에서 상당한 이점이 있어서, 비디오 소유자가 비디오와 메타데이터를 포맷하기 위해 해야 하는 하드웨어 및 소프트웨어 투자를 극적으로 감소시킨다.
실시예는, (1) 협력, (2) 조직 및 팩키징, (3) 공개 및 배포, 및/또는 (4) 테더링된 측정 및 분석 등의 동작을 처리하는 플랫폼을 제공한다.
(1) 협력에 관하여, 비디오를 생성하는 것은 협력적 노력일 수 있다. 비디오 자산은 조직에 걸쳐 분산될 수 있다. 플랫폼의 실시예는 소정 팀이 함께 일하고 활동(예를 들어, 비디오 편집, 오디오 파일, 메타데이터, 및 그래픽)을 추적하기 위한 공유된 공간을 제공한다. 플랫폼은 프로세스를 정규화하고 자산을 한 장소에 유지하는 것을 허용한다. 플랫폼은 또한, 복수의 생성자 및 벤더로부터, 직접, 사용자에게 "가상 스튜디오"처럼 보이는 것 내로의, 다양한 포맷과 코덱 방식의 입수를 위한 조율과 정규화를 허용한다. 사용자는 그 브라우저, FTP 등을 통해 간단히 업로드한다. 비디오 콘텐츠는 많은 움직이는 부분을 갖는 복잡한 것일 수 있다. 실시예는, 비디오 입수에 관한 실시간의 지능형 유효성확인을 적용하여 비디오의 모든 올바른 부분들이 온전하다는 것을 보장하고, 이상적이지 않은 자산이 플랫폼의 비디오 라이브러리에 들어가는 것을 방지한다. 사용자는, 생성자, 파트너, 및/또는 공동작업자의 선택된 그룹과 비디오를 공유할 수 있다. 사용자는, 전자메일 링크를 통해, 사용자 자신의 사이트 상의 임베딩가능한 재생기, 또는 (플랫폼에 의해 호스팅되는) "사설 스크리닝 룸(private screening room)"을 통해, 사적으로 이렇게 할 수 있다. 사설 스크리닝 공간에서 호스팅되는 동안, 사용자는 동료, 고객 또는 파트너와 가편집(rough cut)을 반복할 수 있다. 사용자는, 비디오가 릴리스되기 전에 필요한 승인을 사용자가 얻을 수 있도록 액세스와 허용을 관리할 수 있다.
(2) 조직 및 팩키징에 관하여, 일단 비디오가 생성되고 나면, 플랫폼의 실시예는 사용자의 파일들에 대한 조직된 홈(organized home)(예를 들어, 파일들이 사용자의 팀/파트너에게 이용가능하고 액세스가능한 단일의 장소)을 생성한다.
비디오 메타데이터는 매우 다양하고 플랫폼의 실시예는 각각의 목적지(즉, 채널)에 대해 정확한 정보와 이미지를 포착 및 맵핑함으로써 메타데이터 혼동(chaos)을 간소화한다. 복수의 목적지/채널에 걸친 비디오 발견을 위한 메타데이터의 관리와 최적화는 시간 소모적이며 복잡하지만 플랫폼은 사용자가 한 장소에서 효율적으로 관리하고, 업데이트하며 테스팅하는 것을 허용한다. 실시예는 사용자가 비디오를 지속적인 버킷들(즉, "컬렉션들(collections)") 내로 조직화하는 것을 허용한다.
(3) 공개 및 배포에 관하여, 비디오의 공개 및 배포는 간단한 피드 이상을 요구한다. 단일 비디오 재생기 내에서 작업흐름을 관리하는 것은 충분히 곤란한 것일 수 있지만, 복수의 비디오, 복수의 목적지, 및 많은 상이한 포맷 및 메타데이터 요건을 추가하여 혼합하는 것은 더욱 복잡성을 가중시킨다. 실시예는 온라인 및 오프라인의 공개 및 배포 프로세스로부터의 작업과 복잡성을 오프로드(off-load)하는 것을 돕는다.
실시예는 많은 목적지 포인트에 신속하게 고품질 비디오를 전달한다. 실시예는 많은 개방된 목적지에 자동접속할 수 있고, 아무런 기존의 관계도 없는 다른 배포 파트너에게 전달하는 능력을 가진다.
많은 목적지 상에서의 최적의 수행을 위해 비디오를 트랜스코딩하는 것은 인코딩 소프트웨어와 코덱 요건에서의 지속적인 변경을 필요로 할 수 있다. 실시예는, 클라우드를 통해, 요구에 따라(on demand) 비디오를 전달한다. 품질, 속도 및 중복성은 실시예에 대한 성공 인자이다. 실시예는 비디오가 신속하게 전달되는 것을 보장하기 위해 CDN과 함께 동작한다.
실시예는, 다양한 모바일 장치, 웹 브라우저 또는 소셜 미디어 사이트에 비디오를 전달한다. 실시예는 엔드포인트에 적합화된 지능형 재생기를 제공하여, (예를 들어) HTML5, Flash 또는 QuickTime 간에 동적으로 이동한다. 재생기는, 사용자의 브랜드, 웹사이트 설계, ad 네트워크 또는 심지어 CDN과 정합하도록 맞춤화될 수 있다.
(4) 테더링된 측정 및 분석에 관하여, 단 하나의 목적지 상의 단 하나의 비디오의 성공을 측정하는 것은 부담스러울 수 있다. 상이한 통계들과 함께 복수 비디오와 복수 목적지를 추가하면, 부담이 증가된다. 실시예는 복수의 목적지/채널에 걸쳐 비디오 통계(메트릭)를 집계한다. 실시예는 공개된 목적지에 걸쳐 비디오에 대한 콘텐츠 성능 통계를 수집 및 집계함으로써 메트릭 추적의 이러한 부담을 경감한다. 이렇게 하는 것은, 사용자가, 비디오 부하로부터 재생으로의 변환, 가장 많이 시청되거나 공유된 비디오 뿐만 아니라 선호되는 시간 길이를 포함한, 그 비디오 투자가 어떻게 수행되고 있는지를 이해할 수 있게 한다. 사용하기-쉬운 보고 인터페이스(reporting interface)는 사용자가 결과의 내보내기와 시청의 최적화를 허용한다. 사용자는 비지니스 전략을 더 양호하게 맵핑하기 위해 목적지 또는 비디오 컬렉션의 성능을 비교할 수 있다.
실시예들은 많은 상이한 시스템 타입들에서 구현될 수 있다. 이제 도 11을 참조하면, 본 발명의 실시예에 따른 시스템(예를 들어, 서버, 데스크탑, 분산형 클러스터, 태블릿, 노트북, 모바일 컴퓨팅 장치, 스마트폰, PDA(personal digital assistant))의 블록도가 도시되어 있다. 멀티프로세서 시스템(1100)은 포인트-대-포인트 인터커넥트 시스템이고, 포인트-대-포인트 인터커넥트(1150)를 통해 결합된 제1 프로세서(1170)와 제2 프로세서(1180)를 포함한다. 프로세서들(1170 및 1180) 각각은 멀티코어 프로세서일 수 있다. 용어 "프로세서"란, 레지스터 및/또는 메모리로부터의 전자적 데이터를 처리하여 그 전자적 데이터를 레지스터 및/또는 메모리에 저장될 수 있는 다른 전자적 데이터로 변환하는 임의의 장치 또는 장치의 일부를 말할 수 있다. 제1 프로세서(1170)는 메모리 제어기 허브(MCH; memory controller hub)와 포인트-대-포인트(P-P) 인터페이스를 포함할 수 있다. 유사하게, 제2 프로세서(1180)는 MCH와 P-P 인터페이스를 포함할 수 있다. MCH들은, 프로세서들을, 각각의 프로세서에 국지적으로 부착된 메인 메모리(예를 들어, DRAM(dynamic random access memory))의 일부일 수도 있는, 각각의 메모리, 즉, 메모리(1132) 및 메모리(1134)에 결합시킬 수 있다. 제1 프로세서(1170)와 제2 프로세서(1180)는, 각각, P-P 인터커넥트를 통해 칩셋(1190)에 결합될 수 있다. 칩셋(1190)은 P-P 인터페이스를 포함할 수 있다. 또한, 칩셋(1190)은 인터페이스를 통해 제1 버스(1116)에 결합될 수 있다. 다양한 입력/출력(I/O) 장치(1114)는, 제1 버스(1116)를 제2 버스(1120)에 결합시키는 버스 브릿지(1118)와 더불어, 제1 버스(1116)에 결합될 수 있다. 예를 들어, 키보드/마우스(1122), 통신 장치(1126), 및 한 실시예에서는 코드(1130)를 포함할 수도 있는 디스크 드라이브나 기타의 대용량 저장 장치 등의 데이터 저장 유닛(1128)을 포함한 다양한 장치들이 제2 버스(1120)에 결합될 수 있다. 코드는, 메모리(1128, 1132, 1134), 네트워크를 통해 시스템(1100)에 결합된 메모리 등을 포함한, 하나 이상의 메모리에 포함될 수 있다. 또한, 오디오 I/O(1124)가 제2 버스(1120)에 결합될 수 있다.
실시예들은 코드로 구현될 수 있고 명령어를 수행하도록 시스템을 프로그램하는데 이용될 수 있는 명령어들을 저장하고 있는 저장 매체 상에 저장될 수 있다. 저장 매체는, 플로피 디스크, 광 디스크, 고체 상태 드라이브(SSD), 콤팩트 디스크 판독 전용 메모리(CD-ROM), 재기록가능한 콤팩트 디스크(CD-RW), 및 광자기 디스크를 포함한 임의 타입의 디스크, ROM(read-only memory), DRAM(dynamic random access memory), SRAM(static random access memory) 등의 RAM(random access memory), EPROM(erasable programmable read-only memory), 플래시 메모리, EEPROM(electrically erasable programmable read-only memory) 등의 반도체 장치, 자기 또는 광 카드, 또는 전자적 명령어를 저장하기에 적합한 기타 임의의 타입의 매체를 포함할 수 있지만, 이것으로 제한되지 않는다.
본 발명의 실시예들은, 본 명세서에서 명령어, 함수, 프로시져, 데이터 구조, 애플리케이션 프로그램, 구성 설정, 코드 등의 데이터를 참조하여 설명될 수 있다. 데이터가 머신에 의해 액세스될 때, 머신은, 여기서 더 상세히 설명되는 바와 같이, 작업을 수행하고, 추상 데이터 타입을 정의하며, 로우-레벨 하드웨어 컨텍스트를 확립하고, 및/또는 다른 동작들을 수행함으로써 응답할 수 있다. 데이터는 휘발성 및/또는 비휘발성 데이터 저장소에 저장될 수 있다. 용어 "코드" 또는 "프로그램"은, 애플리케이션, 드라이버, 프로세스, 루틴, 메쏘드, 모듈, 및 서브프로그램을 포함한, 광범위한 컴포넌트와 컨스트럭트를 포괄하며, 처리 시스템에 의해 실행될 때, 원하는 동작이나 동작들을 수행하는 명령어의 임의의 컬렉션을 말할 수 있다. 또한, 대안적 실시예는, 개시된 동작들 전부보다 적은 수의 동작을 이용하는 프로세스들, 추가의 동작들을 이용하는 프로세스들, 상이한 시퀀스의 동일한 동작들을 이용하는 프로세스들, 및 여기서 개시된 개별 동작들이 결합, 세분, 또는 기타의 방식으로 변경되는 프로세스들을 포함할 수 있다. 한 실시예에서, 제어 로직이라는 용어의 사용은, 트랜지스터, 레지스터, 또는 프로그래머블 로직 장치(1135) 등의 기타의 하드웨어와 같은, 하드웨어를 포함한다. 그러나, 또 다른 실시예에서, 로직은 또한 소프트웨어 또는 코드(1131)를 포함한다. 이러한 로직은, 펌웨어 또는 마이크로코드(1136) 등의 하드웨어와 통합될 수도 있다. 프로세서 또는 제어기는, 본 분야에 공지된 광범위한 제어 로직 중 임의의 것을 나타내도록 의도된 제어 로직을 포함할 수 있으므로, 마이크로프로세서, 마이크로제어기, FPGA(field-programmable gate array), ASIC(application specific integrated circuit), PLD(programmable logic device) 등으로서 역시 구현될 수 있다.
여기서 사용될 때 모듈이란, 임의의 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합을 말한다. 종종 별개의 것으로 예시된 모듈 경계는 통상적으로 변동하며 잠재적으로 중첩할 수 있다. 예를 들어, 제1 및 제2 모듈은, 잠재적으로는 일부 독립된 하드웨어, 소프트웨어, 또는 펌웨어를 유지하면서, 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합을 공유할 수 있다. 한 실시예에서, 로직이라는 용어의 사용은, 트랜지스터, 레지스터, 또는 프로그래머블 로직 장치 등의 기타의 하드웨어와 같은 하드웨어를 포함한다. 그러나, 또 다른 실시예에서, 로직은 또한, 펌웨어 또는 마이크로코드 등의, 하드웨어와 통합된 코드 또는 소프트웨어를 포함한다.
통상의 기술자라면, 일반적으로, 여기서 사용된, 특히 첨부된 청구항(예를 들어, 첨부된 청구항의 본문)에서 사용된 용어는 일반적으로 "개방형(open)" 용어로서 의도된 것임을 이해할 것이다(예를 들어, 용어 "포함하는(including)"은 "~을 포함하지만 이것으로 제한되지 않는"으로서 해석되어야 하고, 용어 "갖는(having)"은 "적어도 ~을 갖는"으로서 해석되어야 하며, 용어 "포함한다(include)"는 "~을 포함하지만 이것으로 제한되지 않는다"로서 해석되어야 하는 등등이다). 또한, 통상의 기술자라면, 특정한 개수의 서술된 청구항 기재(introduced claim recitation)를 의도한 경우, 그러한 의도는 청구항에서 명시적으로 기재될(recite) 것이고, 이와 같은 기재(recitation)가 없을 경우 그러한 의도는 없다는 것을 이해할 것이다. 예를 들어, 이해를 돕기 위해, 이하의 첨부된 청구항들은 청구항 기재를 서술하는(introduce) 서두 구절 "적어도 하나" 및 "하나 이상의"의 사용을 포함할 수 있다. 그러나, 이러한 구절의 사용은, 부정 관사 "한(a 또는 an)"에 의한 청구항 기재의 서술은, 그렇게 서술된 청구항 기재를 포함하는 어떤 특정한 청구항을, 바로 그 청구항이 서두 구절 "하나 이상의" 또는 "적어도 하나의"와 "한(a 또는 an)"과 같은 부정 관사를 포함하더라도, 단 하나의 그러한 기재만을 포함하는 발명으로 제한한다는 것을 암시하는 것으로 해석되어서는 안 된다(예를 들어, 부정 관사 "한(a 및/또는 an)"은 통상적으로 "적어도 하나의" 또는 "하나 이상의"를 의미하는 것으로 해석되어야 한다); 청구항 기재를 서술하는데 이용되는 정관사의 사용에 대해서도 마찬가지이다. 또한, 특정한 개수의 서술된 청구항 기재가 명시적으로 기재되더라도, 통상의 기술자라면, 그러한 기재는 통상적으로 적어도 기재된 개수를 의미하는 것으로 해석되어야 한다는 것을 이해할 것이다(예를 들어, 다른 수식어가 없는 "2개의 기재"라는 기본적인 기재는 통상적으로 적어도 2개의 기재 또는 2개 이상의 기재를 의미한다). "A, B, 또는 C 등 중의 적어도 하나"와 유사한 관례가 사용되는 경우, 일반적으로 이러한 구성(construction)은 통상의 기술자가 그러한 관례를 이해한다는 의미로 의도된 것이다(예를 들어, "A, B, 또는 C 중 적어도 하나를 갖는 시스템"은 A 단독, B 단독, C 단독, A와 B 함께, A와 C 함께, B와 C 함께, 및/또는 A와 B와 C 함께 등등을 갖는 시스템을 포함하지만 이것으로 제한되지 않는다). 또한, 2개 이상의 대안적 용어를 제시하는 사실상 임의의 분리성 단어 및/또는 구절은, 상세한 설명에서건, 청구항에서건, 도면에서건, 이들 용어들 중 하나, 용어들 중 어느 하나, 또는 양쪽 용어 모두를 포함할 가능성을 고려하는 것으로 이해되어야 한다는 것을 통상의 기술자라면 이해할 것이다. 예를 들어, 구절 "A 또는 B"는, "A", 또는 "B", 또는 "A와 B"의 가능성을 포함하는 것으로 이해될 것이다.
본 발명의 실시예들이 제한된 개수의 실시예에 관하여 설명되었지만, 통상의 기술자라면 그로부터의 수 많은 수정과 변형을 이해할 것이다. 첨부된 청구항들은 본 발명의 실시예들의 진정한 사상과 범위 내에 드는 이러한 모든 수정 및 변형을 포괄하고자 한다.

Claims (5)

  1. 명령어들을 포함하는 적어도 하나의 머신 판독가능한 매체로서,
    상기 명령어들은 컴퓨팅 장치에서 실행될 때 상기 컴퓨팅 장치로 하여금.
    비디오를 수신하는 단계;
    그래픽 사용자 인터페이스(GUI; graphical user interface)를 디스플레이하는 단계;
    상기 GUI를 통해 공급된 사용자 입력에 응답하여, 상기 비디오가 제1 및 제2 배포 채널들에 배포되지만 제3 배포 채널에는 배포되지 않을 것이라고 판정하는 단계;
    상기 비디오의 제1 및 제2 특성을 판정하는 단계 - 상기 제1 및 제2 특성은, 파일 타입, 컨테이너 타입(container type), 비디오 지속기간, 비디오 해상도, 프레임 레이트, 비디오 압축 비트 레이트, 및 오디오 압축 비트 레이트를 포함하는 그룹으로부터 선택됨 -;
    상기 사용자 입력에 응답하여, 상기 제1 배포 채널에 대하여 어떤 제1 채널 정보가 필요한지, 그리고 상기 제2 배포 채널에 대하여 어떤 제2 채널 정보가 필요한지를 판정하는 단계;
    상기 제1 배포 채널에 대하여 어떤 제1 채널 정보가 필요한지, 그리고 상기 제2 배포 채널에 대하여 어떤 제2 채널 정보가 필요한지를 판정하는 것에 응답하여, 상기 사용자로부터 상기 제1 및 제2 채널 정보를 요청하는 단계;
    상기 사용자 입력 및 상기 비디오의 제1 및 제2 특성을 판정하는 것에 응답하여, 상기 비디오를 상기 제1 배포 채널에 대응하는 제1 포맷을 갖는 트랜스코딩된 제1 비디오로 트랜스코딩(transcoding)하고; 상기 비디오를 상기 제2 배포 채널에 대응하는 제2 포맷을 갖는 트랜스코딩된 제2 비디오로 트랜스코딩하고; 상기 비디오를 상기 제3 배포 채널에 대응하는 제3 포맷을 갖는 트랜스코딩된 제3 비디오로는 트랜스코딩하지 않는 단계 - 상기 제1 포맷은 상기 제2 포맷과 같지 않음 -;
    상기 사용자 입력에 응답하여, 제1 메타데이터와 상기 트랜스코딩된 제1 비디오를 제1 컨테이너 내에 팩키징하고, 제2 메타데이터와 상기 트랜스코딩된 제2 비디오를 제2 컨테이너 내에 팩키징하는 단계;
    상기 사용자 입력에 응답하여, 상기 제1 컨테이너를 상기 제1 배포 채널에 공개하고, 상기 제2 컨테이너를 상기 제2 배포 채널에 공개하는 단계; 및
    상기 제1 컨테이너를 상기 제1 배포 채널에 공개하고, 상기 제2 컨테이너를 상기 제2 배포 채널에 공개하는 것에 응답하여, 상기 공개된 제1 컨테이너에 대한 제1 메트릭 데이터와 상기 공개된 제2 컨테이너에 대한 제2 메트릭 데이터를 수신하고, 상기 제1 및 제2 메트릭 데이터를 상기 제1 및 제2 메트릭 데이터 양쪽 모두에 대응하는 공통의 정규화된 데이터로 정규화하는 단계
    를 포함하는 방법을 수행하게 하고,
    (a) 상기 제1 채널 정보는 상기 제2 채널 정보와 같지 않고, (b) 상기 제1 채널 정보는 사용자 이름, 패스워드, 피드 제목, 파일 포인터, 및 상기 비디오로부터의 대표 프레임 중 하나를 포함하고,
    상기 제1 메트릭 데이터는 상기 제2 메트릭 데이터와는 상이하게 포맷되는, 적어도 하나의 머신 판독가능한 매체.
  2. 제1항에 있어서,
    상기 제1 포맷은 제1 비트 레이트를 포함하고, 상기 제2 포맷은 상기 제1 비트 레이트와 같지 않은 제2 비트 레이트를 포함하는, 적어도 하나의 머신 판독가능한 매체.
  3. 제1항에 있어서,
    상기 방법은,
    상기 제1 및 제2 배포 채널에 대한 메타 데이터 요건들을 판정하는 단계;
    상기 제1 및 제2 배포 채널에 대한 메타 데이터 요건들을 판정하는 것에 응답하여, (a) 상기 제1 배포 채널에 특정한 메타 데이터 정보를 상기 사용자로부터 수신하고, (b) 상기 메타 데이터 정보의 유효성확인을 실패하는 단계; 및
    상기 메타 데이터 정보의 유효성확인을 실패하는 것에 응답하여, 상기 제1 배포 채널에 특정한 추가 메타 데이터 정보를 상기 사용자에게 촉구하는 단계
    를 포함하는, 적어도 하나의 머신 판독가능한 매체.
  4. 제3항에 있어서,
    상기 방법은,
    상기 사용자 입력에 응답하여, 상기 사용자가 상기 제1 및 제2 배포 채널에 콘텐츠를 배포하도록 인가되었다고 판정하는 단계
    를 포함하고,
    상기 사용자가 상기 제1 배포 채널에 콘텐츠를 배포하도록 인가되었다고 판정하는 단계는, 상기 사용자 입력에 응답하여, (a) 상기 사용자가 상기 제1 배포 채널에 콘텐츠를 배포하도록 인가되었다고 판정하기 위하여 제1 인증 방법을 사용하도록 판정하는 단계 - 상기 제1 인증 방법은 상기 제1 배포 채널에 대응하지만 상기 제2 배포 채널에는 대응하지 않음 -; 및 (b) 상기 사용자에게, 상기 제1 인증 방법 및 상기 제1 배포 채널에 특정한 추가 인증 크레덴셜들을 촉구하는 단계를 포함하고,
    상기 사용자가 상기 제2 배포 채널에 콘텐츠를 배포하도록 인가되었다고 판정하는 단계는, 상기 사용자 입력에 응답하여, (a) 상기 사용자가 상기 제2 배포 채널에 콘텐츠를 배포하도록 인가되었다고 판정하기 위하여 상기 제1 인증 방법과 같지 않은 제2 인증 방법을 사용하도록 판정하는 단계 - 상기 제2 인증 방법은 상기 제2 배포 채널에 대응하지만 상기 제1 배포 채널에는 대응하지 않음 - 를 포함하는, 적어도 하나의 머신 판독가능한 매체.
  5. 제3항에 있어서,
    상기 GUI는 상기 비디오를 상기 제1, 제2 및 제3 배포 채널에 배포하기 위한 옵션들을 상기 사용자에게 동시에 제공하는, 적어도 하나의 머신 판독가능한 매체.
KR1020177008117A 2012-12-21 2013-12-20 미디어 배포 및 관리 플랫폼 KR101977516B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/725,454 US8826332B2 (en) 2012-12-21 2012-12-21 Media distribution and management platform
US13/725,454 2012-12-21
PCT/US2013/076769 WO2014100524A1 (en) 2012-12-21 2013-12-20 Media distribution and management platform

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020157019898A Division KR20150100838A (ko) 2012-12-21 2013-12-20 미디어 배포 및 관리 플랫폼

Publications (2)

Publication Number Publication Date
KR20170038088A KR20170038088A (ko) 2017-04-05
KR101977516B1 true KR101977516B1 (ko) 2019-05-10

Family

ID=50976325

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020157019898A KR20150100838A (ko) 2012-12-21 2013-12-20 미디어 배포 및 관리 플랫폼
KR1020177008117A KR101977516B1 (ko) 2012-12-21 2013-12-20 미디어 배포 및 관리 플랫폼

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020157019898A KR20150100838A (ko) 2012-12-21 2013-12-20 미디어 배포 및 관리 플랫폼

Country Status (10)

Country Link
US (6) US8826332B2 (ko)
EP (1) EP2936825A4 (ko)
JP (2) JP6273292B2 (ko)
KR (2) KR20150100838A (ko)
CN (1) CN105144737B (ko)
AU (1) AU2013361219B2 (ko)
BR (2) BR112015015062A2 (ko)
CA (1) CA2896175C (ko)
MX (1) MX346658B (ko)
WO (1) WO2014100524A1 (ko)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9819984B1 (en) 2007-03-26 2017-11-14 CSC Holdings, LLC Digital video recording with remote storage
US9165134B2 (en) * 2011-03-08 2015-10-20 Telefonica, S.A. Method for providing authorized access to a service application in order to use a protected resource of an end user
US9106921B2 (en) * 2012-04-24 2015-08-11 Vixs Systems, Inc Configurable transcoder and methods for use therewith
US8826332B2 (en) * 2012-12-21 2014-09-02 Ustudio, Inc. Media distribution and management platform
US9602850B2 (en) * 2013-08-06 2017-03-21 Verizon Patent And Licensing Inc. Metadata validation
EP3103239B1 (en) 2014-02-07 2023-10-11 Oracle International Corporation Cloud service custom execution environment
US9529658B2 (en) 2014-02-07 2016-12-27 Oracle International Corporation Techniques for generating diagnostic identifiers to trace request messages and identifying related diagnostic information
SG11201605659SA (en) * 2014-02-07 2016-08-30 Oracle Int Corp Mobile cloud service architecture
US9529657B2 (en) 2014-02-07 2016-12-27 Oracle International Corporation Techniques for generating diagnostic identifiers to trace events and identifying related diagnostic information
SG11201605786SA (en) 2014-03-31 2016-10-28 Oracle Int Corp Infrastructure for synchronization of mobile device with mobile cloud service
US10297163B2 (en) 2014-08-29 2019-05-21 Accenture Global Services Limited On-demand learning system
US20160124987A1 (en) * 2014-10-30 2016-05-05 Microsoft Corporation Access control based on requestor location
US10223363B2 (en) 2014-10-30 2019-03-05 Microsoft Technology Licensing, Llc Access control based on operation expiry data
US9747636B2 (en) 2014-12-08 2017-08-29 Bank Of America Corporation Enhancing information security using an information passport dashboard
US10063661B2 (en) 2015-01-14 2018-08-28 Oracle International Corporation Multi-tenant cloud-based queuing systems
US20160323351A1 (en) 2015-04-29 2016-11-03 Box, Inc. Low latency and low defect media file transcoding using optimized storage, retrieval, partitioning, and delivery techniques
US11328590B2 (en) * 2015-10-29 2022-05-10 InterNetwork Media, LLC System and method for internet radio automatic content management
US9973547B1 (en) * 2016-02-09 2018-05-15 Vecima Networks Inc. Method and systems for adaptively managing hypertext transfer protocol sessions in a content delivery network
US10171410B2 (en) 2016-03-28 2019-01-01 Microsoft Technology Licensing, Llc Cross-mode communiation
US10587708B2 (en) 2016-03-28 2020-03-10 Microsoft Technology Licensing, Llc Multi-modal conversational intercom
EP3436935A1 (en) 2016-03-28 2019-02-06 Oracle International Corporation Pre-formed instructions for a mobile cloud service
US11487512B2 (en) 2016-03-29 2022-11-01 Microsoft Technology Licensing, Llc Generating a services application
US10250894B1 (en) * 2016-06-15 2019-04-02 Gopro, Inc. Systems and methods for providing transcoded portions of a video
US20180063205A1 (en) * 2016-08-30 2018-03-01 Augre Mixed Reality Technologies, Llc Mixed reality collaboration
US10701377B2 (en) 2016-09-14 2020-06-30 Amazon Technologies, Inc. Media storage
US10904329B1 (en) 2016-12-30 2021-01-26 CSC Holdings, LLC Virtualized transcoder
CN106791931B (zh) * 2017-01-05 2019-11-15 上海浦东软件园汇智软件发展有限公司 一种数据流转码的方法及设备
CN106921662B (zh) * 2017-03-01 2020-01-03 北京牡丹电子集团有限责任公司数字电视技术中心 实时流连接生命周期管理方法
US11270023B2 (en) 2017-05-22 2022-03-08 International Business Machines Corporation Anonymity assessment system
US10447615B2 (en) * 2017-06-19 2019-10-15 Live Nation Entertainment, Inc. Enhanced real-time linking methods and systems
US11470131B2 (en) 2017-07-07 2022-10-11 Box, Inc. User device processing of information from a network-accessible collaboration system
KR102044191B1 (ko) * 2018-05-02 2019-11-13 오픈스택 주식회사 전송제어 매트릭스를 이용한 영상 인코딩 장치 및 그 동작 방법
KR102063574B1 (ko) * 2018-09-18 2020-01-09 주식회사 에벤에셀케이 클라우드 기반 문서발송 방법, 장치, 및 이에 대한 컴퓨터프로그램
US10992960B2 (en) * 2019-02-06 2021-04-27 Jared Michael Cohn Accelerated video exportation to multiple destinations
CN111225249B (zh) * 2019-10-21 2022-05-17 视联动力信息技术股份有限公司 一种编码数据处理方法及装置
US11528307B2 (en) * 2020-06-30 2022-12-13 Avid Technology, Inc. Near real-time collaboration for media production
US11284165B1 (en) 2021-02-26 2022-03-22 CSC Holdings, LLC Copyright compliant trick playback modes in a service provider network
CN114979714B (zh) * 2022-07-29 2022-11-01 中关村科学城城市大脑股份有限公司 视频转码播放方法、装置、电子设备和计算机可读介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008269614A (ja) * 2000-12-22 2008-11-06 Sony Corp 提供装置および方法

Family Cites Families (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002077868A (ja) * 2000-08-31 2002-03-15 Sony Corp コンテンツ配信の予約方法、コンテンツ配信方法、予約管理装置およびプログラム格納媒体
JP2004512785A (ja) 2000-10-24 2004-04-22 アイボール　ネットワークス　インコーポレイテッド Ｄｃｔに基づくスケーラブルなビデオ圧縮
US20020194301A1 (en) * 2000-11-01 2002-12-19 Hiroki Morii Information distribution system
US7089309B2 (en) * 2001-03-21 2006-08-08 Theplatform For Media, Inc. Method and system for managing and distributing digital media
US20070089151A1 (en) * 2001-06-27 2007-04-19 Mci, Llc. Method and system for delivery of digital media experience via common instant communication clients
US20030028884A1 (en) * 2001-08-03 2003-02-06 Swart William D. Video and digital multimedia aggregator content availability notification system and method
US8711923B2 (en) 2002-12-10 2014-04-29 Ol2, Inc. System and method for selecting a video encoding format based on feedback data
US8108342B2 (en) 2007-09-10 2012-01-31 Robert Salinas Methods and systems of content mobilization, mobile search, and video editing through a web interface
KR100556826B1 (ko) 2003-04-17 2006-03-10 한국전자통신연구원 Ｍｐｅｇ-4 기반의 양안식 3차원 동영상을 서비스하기 위한 인터넷 방송 시스템 및 그 방법
CN100458747C (zh) * 2003-10-31 2009-02-04 索尼株式会社 用于确定计算机的连接速度的方法
DE10358338A1 (de) * 2003-12-12 2005-07-14 Siemens Ag Verfahren zum Ersatzschalten von räumlich getrennten Vermittlungssystemen
US7404204B2 (en) * 2004-02-06 2008-07-22 Hewlett-Packard Development Company, L.P. System and method for authentication via a single sign-on server
KR101136713B1 (ko) 2004-02-18 2012-04-19 주식회사 케이티 웹서비스를 이용한 멀티 트랜스코딩 서비스 방법
JP4706318B2 (ja) 2005-04-20 2011-06-22 日本電気株式会社 コンテンツ閲覧システム及びそれに用いるコンテンツアップロード方法並びにコンテンツ配信方法
JP4805606B2 (ja) 2005-05-11 2011-11-02 株式会社エヌ・ティ・ティ・ドコモ 映像アップロードシステム、録画サーバ、及び映像アップロード方法
WO2007044621A2 (en) * 2005-10-07 2007-04-19 Roe River Corporation Systems and methods for uploading and downloading files in a distributed network
US20070140255A1 (en) * 2005-12-21 2007-06-21 Motorola, Inc. Method and system for communication across different wireless technologies using a multimode mobile device
US8607287B2 (en) * 2005-12-29 2013-12-10 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20070162487A1 (en) * 2005-12-30 2007-07-12 Razorstream, Llc Multi-format data coding, managing and distributing system and method
CN101467453B (zh) * 2006-06-15 2011-12-07 索尼株式会社 信息处理装置以及信息处理方法
US8695031B2 (en) 2006-08-02 2014-04-08 Concurrent Computer Corporation System, device, and method for delivering multimedia
US20090006335A1 (en) 2006-10-26 2009-01-01 Videokeyhole.Com, Inc. System And Method For Distributing Multimedia Information
US8301658B2 (en) 2006-11-03 2012-10-30 Google Inc. Site directed management of audio components of uploaded video files
US9294822B2 (en) * 2006-11-23 2016-03-22 Mirriad Advertising Limited Processing and apparatus for advertising component placement utilizing an online catalog
US20080155230A1 (en) 2006-12-21 2008-06-26 General Instrument Corporation Method and System for Providing Simultaneous Transcoding of Multi-Media Data
US7743116B2 (en) 2007-05-28 2010-06-22 Apple Inc. Method and user interface for accessing groups of media assets
US8881186B2 (en) 2007-07-12 2014-11-04 Yahoo! Inc. Method and system for improved media distribution
US20090037967A1 (en) 2007-08-01 2009-02-05 Oren Barkan Video upload system
US20090259971A1 (en) * 2007-09-21 2009-10-15 Scott Rankine Media mashing across multiple heterogeneous platforms and devices
US20090094652A1 (en) 2007-10-03 2009-04-09 Eatlime, Inc. Methods and Apparatus for Simultaneous Uploading and Streaming of Media
US8392591B2 (en) 2007-12-28 2013-03-05 Cellspinsoft Inc. Automatic multimedia upload for publishing data and multimedia content
JP4506876B2 (ja) 2008-05-22 2010-07-21 ソニー株式会社 アップロード装置、サーバ装置、アップロードシステム及びアップロード方法
JP2010033341A (ja) 2008-07-29 2010-02-12 Kyocera Corp 携帯無線端末、無線通信方法、およびコンテンツ参照システム
CN201247590Y (zh) 2008-08-01 2009-05-27 鸿富锦精密工业（深圳）有限公司 可自动切换显示模式的电子相框
US8321906B2 (en) 2008-09-11 2012-11-27 At&T Intellectual Property I, Lp Method and system for a transcoder
US20100269144A1 (en) * 2009-04-17 2010-10-21 Tandberg Television, Inc. Systems and methods for incorporating user generated content within a vod environment
US8171564B2 (en) * 2009-04-17 2012-05-01 Ericsson Television Inc. Systems and methods for one-to-many secure video encryption
KR101567518B1 (ko) 2009-04-28 2015-11-09 삼성전자주식회사 사용자 조작 정보 전달을 위한 통신방법 및 이를 적용한 전자장치
US8819559B2 (en) 2009-06-18 2014-08-26 Cyberlink Corp. Systems and methods for sharing multimedia editing projects
US8136142B2 (en) * 2009-07-02 2012-03-13 Ericsson Television, Inc. Centralized content management system for managing distribution of packages to video service providers
CA2824754A1 (en) 2009-09-26 2011-03-31 Disternet Technology Inc. System and method for micro-cloud computing
US7921150B1 (en) 2009-10-23 2011-04-05 Eastman Kodak Company Method for viewing videos on distributed networks
KR20110047399A (ko) * 2009-10-30 2011-05-09 삼성전자주식회사 컨텐츠 업로드 서비스를 제공하는 서버, 단말기 및 컨텐츠 업로드 방법
US10264029B2 (en) * 2009-10-30 2019-04-16 Time Warner Cable Enterprises Llc Methods and apparatus for packetized content delivery over a content delivery network
US8897377B2 (en) 2009-12-31 2014-11-25 Broadcom Corporation Transcoding multiple media elements for independent wireless delivery
WO2011163422A2 (en) * 2010-06-22 2011-12-29 Newblue, Inc. System and method for distributed media personalization
US8464304B2 (en) 2011-01-25 2013-06-11 Youtoo Technologies, LLC Content creation and distribution system
US20120204201A1 (en) 2011-02-03 2012-08-09 Bby Solutions, Inc. Personalized best channel selection device and method
US20120254925A1 (en) 2011-04-01 2012-10-04 VideoGenie, Inc. Computer systems and methods for video capturing, managing, and/or sharing
US9201895B2 (en) * 2011-06-03 2015-12-01 Apple Inc. Management of downloads from a network-based digital data repository based on network performance
US9571433B2 (en) * 2011-09-12 2017-02-14 Panasonic Intellectual Property Management Co., Ltd. Communication device, relay server for relaying data from communication device, and communication system including them
US9525900B2 (en) * 2011-09-15 2016-12-20 Google Inc. Video management system
EP2759126B8 (en) * 2011-09-18 2021-03-31 Touchtunes Music Corporation Digital jukebox device with karaoke and/or photo booth features, and associated methods
US9432704B2 (en) 2011-11-06 2016-08-30 Akamai Technologies Inc. Segmented parallel encoding with frame-aware, variable-size chunking
US9087178B2 (en) * 2012-04-25 2015-07-21 Convivial Corporation System and method for posting content to network sites
US8311382B1 (en) 2012-05-09 2012-11-13 Youtoo Technologies, LLC Recording and publishing content on social media websites
US8826332B2 (en) 2012-12-21 2014-09-02 Ustudio, Inc. Media distribution and management platform

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008269614A (ja) * 2000-12-22 2008-11-06 Sony Corp 提供装置および方法

Also Published As

Publication number Publication date
CN105144737A (zh) 2015-12-09
US20230421823A1 (en) 2023-12-28
US9501212B2 (en) 2016-11-22
JP2016509772A (ja) 2016-03-31
JP6461384B2 (ja) 2019-01-30
AU2013361219A1 (en) 2015-07-23
CA2896175C (en) 2018-10-30
US20150058731A1 (en) 2015-02-26
MX2015008181A (es) 2015-09-25
US20140181864A1 (en) 2014-06-26
US8826332B2 (en) 2014-09-02
BR112015015062A2 (pt) 2017-07-11
MX346658B (es) 2017-03-28
US20220232268A1 (en) 2022-07-21
US20170070760A1 (en) 2017-03-09
JP6273292B2 (ja) 2018-01-31
US11570491B2 (en) 2023-01-31
AU2013361219B2 (en) 2016-08-11
EP2936825A1 (en) 2015-10-28
US20200374572A1 (en) 2020-11-26
WO2014100524A1 (en) 2014-06-26
JP2018088682A (ja) 2018-06-07
US11303941B2 (en) 2022-04-12
CA2896175A1 (en) 2014-06-26
US10771825B2 (en) 2020-09-08
KR20150100838A (ko) 2015-09-02
BR112015015053A2 (pt) 2017-07-11
CN105144737B (zh) 2019-05-07
KR20170038088A (ko) 2017-04-05
EP2936825A4 (en) 2016-11-09

Similar Documents

Publication Publication Date Title
KR101977516B1 (ko) 미디어 배포 및 관리 플랫폼
US9852762B2 (en) User interface for video preview creation
US8695054B2 (en) Ingesting heterogeneous video content to provide a unified video provisioning service
US10999340B2 (en) Cloud-based video delivery
US9749136B2 (en) Method for watermarking content
US11785232B2 (en) Media storage
US11916992B2 (en) Dynamically-generated encode settings for media content
US11657851B2 (en) System and device for remote automatic editor
US10854241B2 (en) Generation of media diff files
US20240340326A1 (en) Playback aware video packaging

Legal Events

Date Code Title Description
A107 Divisional application of patent
E701 Decision to grant or registration of patent right