KR20030060984A - 오디오 신호의 인코딩 방법 - Google Patents

오디오 신호의 인코딩 방법 Download PDF

Info

Publication number
KR20030060984A
KR20030060984A KR10-2003-7007741A KR20037007741A KR20030060984A KR 20030060984 A KR20030060984 A KR 20030060984A KR 20037007741 A KR20037007741 A KR 20037007741A KR 20030060984 A KR20030060984 A KR 20030060984A
Authority
KR
South Korea
Prior art keywords
file
sub
encoding
time
sequence
Prior art date
Application number
KR10-2003-7007741A
Other languages
English (en)
Other versions
KR100838052B1 (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 KR20030060984A publication Critical patent/KR20030060984A/ko
Application granted granted Critical
Publication of KR100838052B1 publication Critical patent/KR100838052B1/ko

Links

Classifications

    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/18—Vocoders using multiple modes
    • G10L19/24—Variable rate codecs, e.g. for generating different qualities using a scalable representation such as hierarchical encoding or layered encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/167—Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Reduction Or Emphasis Of Bandwidth Of Signals (AREA)
  • Transmission Systems Not Characterized By The Medium Used For Transmission (AREA)
  • Amplifiers (AREA)
  • Signal Processing Not Specific To The Method Of Recording And Reproducing (AREA)

Abstract

통신 링크를 통해 오디오 신호를 전송하는 시스템이, 예를 들면 서로 다른 데이터 속도로, 둘이나 그 이상의 대안적인 피드들로서 신호를 발생시킨다. 상기 2개의 피드는 서로 다른 프레임 길이들의 프레임 구조를 갖는 코딩 방법을 이용해 인코딩된다. 상기 둘 사이의 스위칭을 용이하게 하기 위해, 입력 신호는 시간부분들로 개념적으로 나뉘어지며, 각각은 그것을 취하고, 전갯수의 프레임들을 구성하기 위해서 다음번(혹은 선행하는) 부분의 충분한 양을 더하고, 그것을 인코딩함으로써 코딩되는데, 그로써, 인코딩된 부분들은, 적어도 상기 피드들 중의 하나에 대해서 중첩된다. 상기 중첩은 중복된 머티리얼을 버림으로써 디코딩 상에서 소실된다.

Description

오디오 신호의 인코딩 방법{ENCODING AUDIO SIGNALS}
본 발명은 디지털로 코딩된 머티리얼(material)을 사용자에게 제시하기 위해 통신 링크를 통해서 전달하는 것에 관한 것이다.
본 발명의 한 측면에 따르면, 오디오 신호의 인코딩 방법이 제공되는데, 이 방법은
입력 신호를 연속적인 시간부분들(temporal portions)로 개념적으로 나누는 단계;
상기 입력 시간부분들을 제 1 프레임 길이를 갖는 제 1 인코딩 알로리즘을 이용해 인코딩하여, 인코딩된 시간부분들의 제 1 인코딩된 시퀀스를 생성하는 단계; 및
상기 입력 시간부분들을 제 2 프레임 길이를 이용해 인코딩하여, 인코딩된 시간부분들의 제 2 시퀀스를 생성하는 단계를 포함하며,
여기서 상기 인코딩 단계 중의 적어도 하나는, 선행하는 시간부분의 끝부분의 많은 부분 및/또는 바로 뒤따르는 시간부분의 시작부분과 함께, 하나의 입력 시간부분을 인코딩하는 단계를 포함하며, 이는 상기 하나의 시간부분으로써 정수개의 프레임들을 구성하는 것에 관한 것이다.
다른 측면에서, 본 발명은 입력 오디오 신호를 인코딩하는 방법을 제공하는데, 이 방법은
제 1 프레임 길이를 갖는 제 1 코딩 알고리즘으로 입력 신호의 연속적인 제 1 시간부분들 각각 - 여기서 이들 부분들은 정수개의 상기 제 1 프레임 길이들에 상응하며, 연접하거나 중첩됨 - 을 인코딩하여 제 1 인코딩된 시퀀스를 생성하는 단계; 및
제 2 프레임 길이를 갖는 제 2 코딩 알고리즘으로 입력 신호의 연속적인 제 2 시간부분들 각각 - 여기서 이들 부분들은 중첩되고, 정수개의 상기 제 2 프레임 길이들에 상응하며, 정수개의 상기 제 1 프레임 길이들에 상응하지 않음 - 을 인코딩하여 제 2 인코딩된 시퀀스를 생성하는 단계를 포함하며, 여기서 상기 제 2 인코딩된 시퀀스의 각각의 중첩 영역은 입력 신호의 연속적인 시간부분들에 상응하는 상기 제 1 인코딩된 시퀀스 간의 경계 혹은 시퀀스의 중첩 영역 부분들(이 경우가 발생할 수 있음)을 적어도 부분적으로 포함한다.
본 발명의 다른, 선택적인 측면들은 이하의 청구항들에서 설명되어진다.
이하의 설명과 도면들은, 본 출원과 같은 날 출원되었으며, GB 0030706.6으로부터의 우선권을 주장하고, 명칭이 "Delivery of Audio and or Video Material"(출원인의 참조번호 A26097)인, 출원진행 중인 우리의 국제 특허 출원에 포함되어 있는 것과 동일하다는 것을 주목하라.
본 발명의 몇몇 실시예가 동반되는 도면을 참조하면서 이제 설명될 것이다.
도 1은 설명될 시스템들의 전체적인 구성을 예시하는 다이어그램,
도 2는 그러한 시스템에서의 이용을 위한 터미널의 블록도,
도 3은 전형적인 인덱스 화일의 내용을 도시하고,
도 4는 서브-화일 생성의 수정된 방법을 예시하는 타이밍도, 및
도 5는 수정된 구성을 예시하는 다이어그램이다.
도 1에 도시된 시스템은 디지털로 코딩된 오디오 신호(예를 들면, 녹음된 음악이나 연설의)를 통신 네트워크를 통해서 사용자 터미널 - 여기서 해당 소리가 사용자에게 재생될 것이다 - 의 사용자에게 전달하는 것을 목적으로 갖는다. 그러나, 아래에서 좀 더 상세히 설명되는 바와 같이, 상기 시스템은 오디오 신호 대신에, 혹은 오디오 신호 외에 추가로 비디오 신호를 전달하기 위해 사용될 수도 있다. 이 예에서, 원칙적으로는 다른 디지털 링크나 네트워크가 사용될 수 있음에도 불구하고, 상기 네트워크는 인터넷이거나 하이퍼텍스트 전송 프로토콜(자세한 사항은 RFCs 1945/2068을 보시오)에 따라서 동작하는 다른 패킷 네트워크이다. 또한 상기 오디오 신호는 ISO MPEG-1 Layer III 표준("MP3 표준")을 이용하여 압축 형태로 녹음되었다고 가정한다; 그러나 이러한 특별한 포맷을 사용하는 것이 필수적인 것은 아니다. 게다가, 비록 특히 이용가능한 비트속도가 제한되거나 저장 공간이 한정된 경우에는 압축이 매우 바람직함에도 불구하고, 압축의 이용이 반드시 필요한 것은 아니다. 도 1에서, 서버(1)는 인터넷(2)을 통해서 사용자 터미널들(3) - 그것 중의 단지 하나만 도시됨 - 에 연결되어 있다. 서버(1)의 기능은 데이터 화일을 저장하고, 사용자 터미널로부터 요구되는 데이터 화일의 전달에 대한 요청을 수신하고, 그러한 요청에 응답하여 네트워크를 통해 사용자 터미널에 해당 화일을전송하는 것이다. 대개, 그러한 요청은 네트워크 전달 메커니즘(예를 들면, 하이퍼텍스트 전송 프로토콜이나 화일 전송 프로토콜에 대해 각각 http:// 혹은 file://)을 가리키는 첫번째 부분에 이어 서버의 네트워크 주소(예를 들면, www.server1.com)가 뒤따르며, 서버 주소 뒤에는 현재 요청받고 있는 화일 이름이 붙는다. 주어진 예에서 그러한 이름들은 인쇄술적인 이유로 "//" 대신에 "＼＼"가 사용되었음을 주의하라.
이들 예에서는 하이퍼텍스트 전송 프로토콜의 사용이 가정된다; 이것은 필수적인 것은 아니다. 그러나 그 프로토콜에 의해 제공되는 인증(authentication)과 보안 특성(보안 소켓 레이어(Secure Sockets Layer)와 같은)의 사용이 허용된다는 점에서 유용하다.
종래에, MP3 화일의 전달을 위한 서버는 소위 스트리머(streamer)의 형태를 취하며, 이 스트리머는, 사용자 터미널에서의 리플레이(replay) 요구에 의존하면서 데이터가 전송되는 속도에 대한 동적인 제어를 위한 프로세싱 배치를 포함하는데, 이는 패캣 손실에 기인한 에러의 마스킹을 위한 것이고, 만약 사용자 인터랙션이 허용된다면 서버와 클라이언트 간의 데이터 흐름을 제어하기 위한 것이다; 그러나 여기서 서버(1)는 그러한 단서를 포함하지 않는다. 그러므로 그것은 단지 일반적인 "웹 서버"이다.
서버(1)에 데이터 화일이 저장되는 방식이 이제 설명될 것이다. 하나의 MP3-포맷 화일이 생성되어 서버에 저장된다고 가정해 보자. 그것이 일반적으로 9분의 재생 시간을 갖는 J.S. 바흐의 토카타와 푸가 D 단조(BWV565)를 녹음한 것이라고 가정해 보자. 원래대로라면 이것은 단일 데이터 화일로 생성되어, 종래의 스트리머 상에 이러한 하나의 단일 화일로 저장될 것이다. 그러나 여기서 상기 화일은 서버(1)에 저장되기 전에 보다 작은 화일들로 나뉘어진다. 우리는 이들 작은 화일들의 각각이 고정된 재생 시간, 아마도 4초에 상응하는 크기인 것이 바람직하다고 여긴다. MP3와 같은 압축 포맷을 사용한다면, 이 경우는 상기 화일들이 실제 포함하고 있는 비트 수의 관점에서 서로 다른 크기를 가질 것이라는 것을 의미할 수 있다. 따라서, 9분의 지속시간을 갖는 상기 바흐 화일은 각각이 4초의 재생 시간을 나타내는 135개의 보다 작은 화일들로 나뉘어질 것이다. 이 예에서, 이들 화일은 원래 화일에서의 순서를 나타내는 일련 번호를 포함하는 화일명을 부여받는다. 예를 들면:
000000.bin
000001.bin
000002.bin
000003.bin
.
.
000134.bin
화일을 이와 같이 작은 서브-화일들로 분할하는 것은 일반적으로 웹 서버(1) 상으로 그 화일을 로딩하는 것을 준비하는 사람에 의해 수행될 수 있다.("서브-화일"이라는 표현은 전체 녹음을 포함하고 있는 원래 화일과 그것들을 구별하기 위해여기서 사용된다: 그러나 서버에 관계되는 한, 각각의 "서브-화일"은 여타 다른 화일과 같은 하나의 화일이라는 점이 강조되어야 한다.) 그것들을 생성하는 정확한 방식은 아래에서 좀더 충분히 설명될 것이다. 일단 생성되면, 이들 서브-화일들은 여타 다른 화일이 웹 서버 상에 로딩되는 것과 마찬가지의 종래 방식으로 서버 상에 업로딩된다. 물론 화일명은 특별한 녹음물을 식별하기 위한 문자들을 포함할 수도 있지만(서브-화일은 추가적인 정보로 또한 "태깅(tagging)"될 수 있다 - 당신이 MP3 화일을 재생할 때, 당신은 저자, 저작권 등에 대한 정보를 얻는다.), 이 예에서는 상기 서브-화일들은 특별한 녹음물에 특정된 디렉토리나 폴더 - 예를 들면 mp3_bwv565 - 내에서 서버 상에 저장된다. 따라서 하나의 서브-화일은, 요청될 때, 아래의 형식으로 요청될 수 있다:
http:＼＼www.server1.com/mp3_bwv565/000003.bin
여기서, "www.server1.com"은 서버(1)의 URL이다.
서브-화일들을 서버 상으로 로딩하는 것을 준비하는 사람이 각각의 녹음물에 대해서 링크 페이지(일반적으로 html 포맷) - 이것 또한 서버 상에 저장됨(아마 화일명은 mp3_bwv565/link.htm) - 를 생성하는 것이 또한 편리하다. 링크 페이지의 구조와 목적은 나중에 설명될 것이다.
웹 서버가, 이용가능한 녹음물들의 목록을 포함하면서 상응하는 링크 페이지들에 대한 하이퍼링크들을 갖는 하나나 그 이상의 (html) 메뉴 페이지들(예를 들면, menu.htm)을 저장하는 것이 또한 편리하다.
이제 터미널에 대해 설명하자면, 이것은 일반적으로 종래의 데스크톱 컴퓨터의 형태를 취할 수 있으나, 위에서 설명된 오디오 화일의 수신을 다룰 추가적인 소프트웨어를 갖춘 것이다. 원한다면, 터미널은 핸드헬드 컴퓨터의 형태를 취하거나, 심지어는 이동 전화 안으로 통합될 수도 있다. 그리하여, 도 2는 중앙 프로세서(30), 메모리(31), 디스크 저장장치(32), 키보드(33), 비디오 디스플레이(34), 통신 인터페이스(35), 오디오 인터페이스("사운드 카드")(36)를 갖는 그와 같은 터미널을 도시하고 있다. 비디오 전달에 대해서는, 비디오 카드가 카드(36) 대신에, 혹은 추가적으로 장착될 것이다. 디스크 저장장치에는 메모리(31) 내로 리트리빙(retrieving)되어 보통의 방식으로 프로세서(30)에 의해 수행될 프로그램들이 들어 있다. 이들 프로그램은 콜-업(call-up)과 html 페이지의 표시를 위한 통신 프로그램(37) - 즉, 넷스케이프 내비게이터나 마이크소프트 익스플로러와 같은 "웹 브라우저" - 을 포함하고, 본 발명에 대한 이 실시예에 따라 오디오 화일을 재생하는데 필요한 기능성을 제공하는 "재생기 프로그램"으로서 여기서 참조될 추가적인 프로그램(38)을 포함한다. 또한 버퍼로 할당되어 있는, 메모리(31) 중의 영역(39)이 또한 도시되어 있다. 이것은 재생되기를 기다리는 데이터를 포함하고 있는 디코딩된 오디오 버퍼이다(일반적으로 상기 버퍼의 플레이아웃 시간(playout time)은 약 10초일 수 있다). 오디오 인터페이스 혹은 사운드 카드(36)는 종래의 카드일 수 있으며, 단순히 PCM 신호를 받아서 아날로그 오디오 신호로 변환 - 예를 들면, 스피커를 통한 재생을 위해 - 하는 기능을 수행한다. 첫째로, 우리는 HTTP와 임베디드 혹은 "플러그인" 클라이언트를 사용할 때, 원하는 녹음물을 리트리빙하여 재생하기 위한 터미널의 동작에 대한 간략한 개관을 설명할 것이다.
1. 사용자는 서버(1)로부터 메뉴 페이지 menu.htm을 리트리빙하여 표시하기 위해 브라우저를 사용한다.
2. 사용자는 메뉴 페이지 내의 하이퍼링크 중의 하나를 선택하는데, 이는 브라우저로 하여금 원하는 녹음물에 대한 링크 페이지 - 이 예에서는, 화일 mp3_bwv565_link.htm - 를 서버로부터 리트리빙하여 표시하도록 한다. 이 페이지의 실제적인 표시는 중요하지 않다(다만, 시스템이 올바르게 동작하고 있다는 것을 사용자에게 확인시킬 메시지를 포함할 수 있다는 점을 제외하고). 이 페이지에 대해서 중요한 것은 이것이 프로세서(30) 내에서 제 2의 프로세스 - 이것 내에서 재생기 프로그램(37)이 실행된다 - 를 기동시킬 커맨드(혹은 "임베드 태그(embed tag)")를 포함하고 있다는 것이다. 이러한 방식으로 제 2의 프로세스를 기동시키는 것은 잘 알려진 방법이다(그러한 프로세스는 넷스케이프 시스템에서는 "플러그-인(plug-in)"으로, 마이크로소프트 시스템에서는 "액티브엑스(AcitiveX)"로 알려져 있다). 그러한 커맨드들은 제 2 프로세스로 전달될 파라미터를 또한 포함할 수 있으며, 도 1의 시스템에서 상기 커맨드는 상기 녹음물의 서버 URL을 포함하며, 이것은 상기 바흐 곡에 대해서는 http:＼＼www.server1/mp3_bwv565 일 것이다.
3. 재생기 프로그램(37)은 MP3 디코더를 포함하며, 그것의 동작은 그 자체로 종래의 것이다. 현 문맥에서 좀 더 흥미로운 것은 상기 프로그램의 제어 기능이며, 이는 아래와 같다.
4. 재생기 프로그램은 URL을 수신하면 이것에 제 1 서브-화일의 화일명을 더하여 상기 서브-화일에 대한 완전한 주소, 즉www.server1/mp3_bwv565/000000.bin 을 생성한다. 이 시스템은 상기 서브-화일들이 위에서 나타낸 방식대로 명명되어 터미널에 화일명이 알려질 필요가 없다는 사실에 기초를 두고 조직되었다는 점이 주목될 것이다. 상기 프로그램은 이러한 URL을 갖는 화일에 대한 요청 메시지를 구성해서 통신 인터페이스(35)와 인터넷(2)을 통해 서버(1)로 그것을 전송한다(URL을 IP 주소로 번역하고, 유효하지 않거나 불완전하거나 이용가능하지 않은 URL들에 대한 에러 보고를 위한 프로세스들은 종래의 것이며 따라서 설명되지 않을 것이다). 우리는 재생기 프로그램이 브라우저를 통하기 보다는 통신 인터페이스에 직접 요청을 보낼 것이라고 예상한다. 서버는 요구된 서브-화일을 전송함으로써 응답한다.
5. 재생기 프로그램은 화일로부터 이 서브-화일에 사용된 오디오 디코딩을 결정짓고, 관계된 표준(이 예에서는 MP3)에 따라 화일을 생(raw) PCM 값들로 디코딩하면서, 이 서브-화일의 재생 시간을 기록한다. 일반적으로 오디오 화일은 사용된 인코딩을 가리키는 식별자를 화일의 시작부에 포함한다. 이후, 디코딩된 오디오 데이터는 오디오 버퍼(38)에 저장된다.
6. 재생기 프로그램은 플레이아웃 시간 Tp라고 불리는 파라미터를 갖는다. 이 예에서, 이것은 10초(만약 원하다면, 사용자가 선택하게끔 만들 수 있을 것이다)로 세팅된다. 이것은 터미널이 수행하는 버퍼링의 정도를 결정한다.
7. 재생기 프로그램은 화일명을 000001.bin으로 증가시킨 후, 위의 (4)와 (5)에 설명된 바대로 이 제 2 서브-화일을 요청하고, 수신하고, 디코딩하고, 저장한다. 그것은 버퍼의 내용이 플레이아웃 시간 Tp에 도달하거나 초과할 때까지 이 프로세스를 반복한다. 버퍼 전에 디코딩이 일어난다는 것은 실제적으로 필수적인 것은 아니다. 하지만, 그것은 문제를 단순화시키는데, 왜나햐면 오디오가 생 PCM으로 디코딩되면 버퍼링된 머티리얼의 지속시간이 명시적으로 알려지기 때문이다. 그것은 만약 각각의 서브-화일들이 동일한 오디오 재생 크기라면 오디오 버퍼의 제어를 단순화시킨다.
8. 플레이아웃 문턱 Tp에 도달한 후, 디코딩된 데이터는 버퍼로부터 오디오 인터페이스(36)으로 보내지는데, 오디오 인터페이스(36)는 스피커(도시되지 않음)를 통해 소리를 재생한다.
9. 위의 (8)에서 설명된 바대로 소리를 재생하면서, 재생기 프로그램은 계속해서 버퍼의 충만상태(buffer fullness)를 감시하여, 이것이 Tp아래로 떨어질 때마다, 재생기 프로그램은 화일명을 다시 증가시키고 서버로부터 추가로 서브-화일을 얻는다. 이 프로세스는 "에러 - 화일이 발견되지 않음"이 리턴될 때까지 반복된다.
10. 이 프로세스 동안 만약 버퍼가 비어버리면, 재생기 프로그램은 단순히 추가적인 데이터가 도착할 때까지 재생을 멈춘다.
여기서 사용된 서브-화일 명명 관례 - 0부터 시작하는 숫자로된 단순한 고정 길이 시퀀스 - 는 구현하기 쉽기 때문에 선호된다. 그러나, 만약 재생기 프로그램이 제 1 서브-화일의 이름과 재생기 프로그램으로 하여금 다음번 서브-화일들을 계산할 수 있도록 하는 알고리즘을 포함하거나(혹은 전송받거나), 혹은 화일명들의 목록을 전송받는다면, 임의의 명명 관례가 사용될 수 있다.
위에서 설명된 시스템은 사용자에게 리플레이 프로세스에 개입할 어떠한 기회도 제공하지 않는다는 점이 주목될 것이다. 그리고 버퍼 언더플로우(예를 들면, 네트워크 혼잡에 기인한)의 가능성에 대한 어떠한 구제책도 제공하지 않는다. 그리하여, 이제부터 설명될 본 발명의 좀 더 복잡한 실시예인 제 2 실시예는 다음과 같은 추가적인 특징을 제공한다.
a) 서버는 서로 다른 압축률(예를 들면, 각각 8, 16, 24, 32kbit/s의 (연속된) 데이터 속도에 상응하는 압축)로 녹음된, 해당 녹음물의 둘이나 그 이상의 버전들을 저장하고, 재생기 프로그램은 그것들 사이에서 자동적으로 스위칭할 수 있다.
b) 재생기 프로그램은 제어 패널을 사용자에게 표시하며, 사용자는 이 제어 패널을 통해 재생을 시작하거나, 정지하거나, 재시작하거나(처음부터, 혹은 정지된 지점부터), (앞으로건 뒤로건) 녹음물의 다른 지점으로 점프할 수 있다.
사용자 제어는 속도-스위칭 없이 제공될 수 있고, 혹은 그 반대도 성립하기 때문에, 이들 특성들은 상호의존적이지 않음을 주목하라.
속도 스위칭을 제공하기 위해서, 화일을 서버 상에 로딩하는 것을 준비하는 사람은 동일한 PCM 화일을 서로 다른 속도에서 여러번 인코딩함으로써 여러개의 소스 화일을 준비한다. 이후 그는 이전과 마찬가지고 각각의 소스 화일을 서브-화일들로 분할한다. 이들은, 이하의 예제 구조 - 디렉토리 이름에 있는 "008k","024k"는 8kbit/s 혹은 24kbit/s 등등의 속도를 가리킨다 - 에서 처럼, 서로 다른 속도에 상응하는 분리된 디렉토리내에서 서버 상에 로딩될 수 있다.
그는 또한 인덱스 화일(예를 들면, index.htm)을 생성할 수 있는데, 이 인덱스 화일의 주요 목적은 이용가능한 데이터 속도들의 목록을 제공하는 것이다.
디렉토리 서브디렉토리 화일명
mp3_bwv565 없음 link.htmindex.htm
mp3_bwv565 008k_11_m 000000.bin000001.bin000002.bin000003.bin..000134.bin
mp3_bwv565 016k_11_m 000000.bin000001.bin000002.bin000003.bin..000134.bin
mp3_bwv565 018k_11_s 000000.bin000001.bin000002.bin000003.bin..000134.bin
mp3_bwv565 024k_11_s 000000.bin000001.bin000002.bin000003.bin..000134.bin
mp3_bwv565 032k_11_s 000000.bin000001.bin000002.bin000003.bin..000134.bin
앞에서 설명된 바와 같이, 서브-화일의 길이는 고정된 시간 길이에 상응하기때문에, 서브-화일의 수는 각 디렉토리에 대해서 동일하다. 서브디렉토리 이름은 kbit/s 단위에서의 데이터 속도(3자리 숫자)에 문자 "k"가 더해진 것을 포함한다; 이 예에서는 오디오 샘플링 속도(11.025kHz) 지시자와 모노-스테레오 플래그가 검증 목적으로 부가된다.
그리하여, 인덱스 화일은 형태에 대한 문장을 포함한다.
<! 오디오 = "024k_11_s 032k_11_s 018k_11_s 016k_11_m 008_11_m" -->
(<!-- .. --> 은 그 문장이 html 화일 내에 주석으로 끼워넣어진 것임을 나타낸다(혹은 단순한 텍스트 화일이 사용될 수도 있다).) 일반적인 인덱스 화일이 도 3에 도시되어 있으며, 여기에는 또다른 정보들이 포함되어 있다: LFI는 가장 높은 서브-화일 번호(즉, 45개의 서브-화일이 있다)이고, SL은 전체 재생 시간(178초)이다. "모드"는 "녹음"(여기에서 처럼) 혹은 "라이브"(아래에서 설명될 것임)를 가리킨다. 다른 엔트리들은 자명하거나 혹은 표준적인 html 커맨드들이다.
처음에 재생기 프로그램은 요청에 의해 시작할 것이며, 링크 화일에 명시된 디렉토리와 인덱스 화일로부터, 이용가능한 데이터 속도들의 목록을 미래의 참조를 위해서 로컬 저장한다(그것은 이 화일을 명시적으로 요청할 수 있거나 혹은 디렉토리를 명시할 수 있을 것이다: 대부분의 서버들은 화일명이 명시되지 않으면, index.htm이 디폴트가 된다). 이후, 그것은 앞서 설명된 바대로, 인덱스 화일 내에서 첫번째로 언급된 "속도" 디록토리 - 즉, 024k_11_s - 로부터 오디오 서브-화일들을 요청하기 시작한다(혹은, 터미널은 이것을 해당 터미널에 대해 로컬 세팅된 디폴트 속도로 수정함으로써 이것을 무시할 수도 있다). 이후의 프로세스는, 재생기 프로그램이 시간구간(예를 들면 30초) 동안에 평균을 취하여, 서버로부터 수신되는 실제 데이터 속도를 측정하는 것이다. 그것은 모든 URL 요청의 시간을 측정함으로써 이것을 행한다; 클라이언트와 서버 사이에 수행된 전송속도(초당 비트수)가 결정된다. 이 수치의 정확성은 요청들의 갯수가 증가할수록 개선된다. 재생기는 현재 속도와 측정된 속도를 각각 나타내는 2개의 저장된 파라미터를 보유한다.
속도 변화의 개시는 유발된다:
a) 만약 버퍼가 비고 그리고(AND) 측정된 속도가 현재 속도보다 작고 그리고(AND) 측정된 Buffer Low Percentage가 Step Down Threshold를 초과하면(아래에서 설명되듯이), 현재 속도를 줄여라; (버퍼가 이미 비어 있을 때 변화시키는 것은 사운드 카드가 어떤 것도 재생하고 있지 않기 때문에 이점이 있다. 그리고 만약 오디오 샘플링 속도, 스테레오-모노 세팅 혹은 비트 폭(샘플 당 비트수)이 변화되었다면 그것을 재구성하는 것이 필요할 것이다).
b) 만약 측정된 속도가 현재 속도뿐만 아니라 주어진 시간구간에 대해서 다음 고차 속도도 초과한다면(예를 들면, 120초: 이것은, 만약 원한다면, 사용자에 의해 조정가능하게 만들어질 수 있을 것이다), 현재 속도를 증가시켜라.
Buffer Low Percentage는 버퍼 내용물이 플레이아웃 시간의 25%보다 작음을 나타내는 시간의 퍼센트이다(즉, 버퍼가 점점 비어가고 있다). 만약 Step Down Threshold가 0%로 설정되어 있다면, 버퍼가 빌 때 시스템은 다른 조건들이 만족될 때 항상 스텝 다운한다. Step Down Threshold를 5%(이것은 우리들이 선호하는 디폴트 값이다)로 설정한다는 것은 다음을 의미한다. 즉, 만약 버퍼가 비지만 측정된 Buffer Low Percentage가 5%보다 크다면 그것은 스텝 다운하지 않을 것이다. 추가적으로 버퍼가 비는 것은 이 측정된 속도의 증가를 명백하게 야기할 것이고, 만약 그 속도가 유지될 수 없다면, Buffer Low Percentage 값이 5%를 초과한 채로 버퍼는 결과적으로 다시 비게 될 것이다. 그 값을 100%로 설정한다는 것은 클라이언트가 결코 스텝 다운하지 않을 것이라는 것을 의미한다.
실제적인 속도 변화는 단지 재생기 프로그램이 서브-화일 주소의 관련부분을 변화시킴으로써 - 예를 들면, 데이터 속도를 8에서 24kbit/s로 증가시키기 위해서 "008k"에서 "024k"로 변화시킴으로써 - , 그리고 현재 속도 파라미터를 매칭되게 변화시킴으로써 수행된다. 그 결과, 서버에 대한 다음번 요청은 더 높은(혹은 더 낮은) 속도에 대한 요청이 되고, 새로운 디렉토리로부터의 서브-화일이 수신되고, 디코딩되고, 버퍼 안으로 들어간다. 방금 설명된 프로세스는 아래의 순서도에 요약되어 있다.
사용자 터미널 서버
메뉴 페이지를 선택
http:＼＼server1.com/menu.htm을 요청
http:＼＼server1.com/menu.htm을 전송
menu.htm을 표시
메뉴로부터 아이템을 선택
(바흐)
menu.htm으로부터 하이퍼링크 URL을 추출 (mp3_bwv565/link.htm)
http:＼＼server1.com/mp3_bwv565/link.htm을 요청
http:＼＼server1.com/mp3_bwv565/link.htm을 전송
link.htm을 표시
link.htm 내에 명시된 파라미터로 link.htm 내에 명시된 제 2 프로세스 (재생기 프로그램)을 실행
Stem을 명시된 그 값으로 설정
URL=Stem+"index.htm"으로 설정
이 URL을 요청
요청받은 화일을 전송
Rate List를 index.htm에서 명시된 속도로 설정LFI를 index.htm에서 명시된 값으로 설정
StemC=Stem+"/"+RateList(아이템 1)로 설정CurrentRate=RateList(아이템 1)에서 규정된 속도로 설정RateU=리스트에서 다음번 고차 속도로 설정하거나 아무것도 없는 경우는 0으로 설정StemU=Stem+"/"+이 속도에 상응하는 속도 리스트에서의 아이템RateD=리스트에서 다음번 저차 속도로 설정하거나 아무것도 없는 경우는 0으로 설정StemD=Stem+"/"+이 속도에 상응하는 속도 리스트에서의 아이템
사용자 터미널 서버
Current Subfile=000000.bin으로 설정
J1: URL=StemC+Current Subfine로 설정
이 URL을 요청
요청받은 서브화일이 존재하면, 요청받은 서브화일을 전송; 그렇지 않으면 에러 메시지를 전송
만약 에러 메시지가 수신되면, 중지
수신된 서브화일을 디코딩
버퍼에 써 넣음
J1A: 만약 Buffer Fullness>Tp초이면 단계 J3으로 가시오
J2: Current Subfile을 증가시킴
단계 J1으로 가시오
J3: 사운드 카드를 통해 버퍼 내용물의 재생을 시작/계속
J4: 만약 Buffer Fullness<Tp이면 단계 J2로 가시오
만약 BufferFullness=0 AND Mrate<CurrentRate AND BufferLow% > Td이면 Stepdown으로 가시오
만약 Mrate>NextRate AND NextRate<>0 이면 Stepup으로 가시오
사용자 커맨드의 입력 만약 UserCommand=Pause이면:버퍼로부터의 읽기를 중지;UserCommand=Resume일 때까지 루프수행;J3로 가시오
만약 UserCommand=Jump(j%)이면:버퍼를 클리어;CurrentSubfile =Integer[(LFI+1)*j/100]으로 설정;단계 J1으로 가시오
단계 J1A으로 가시오
사용자 터미널 서버
Stepup:버퍼를 클리어RateD=RateC로 설정StemD=StemC로 설정RateC=RateU로 설정StemC=StemU로 설정RateU=리스트에서 다음번 고차 속도로 설정하거나 아무것도 없는 경우는 0으로 설정StemU=Stem+"/"+이 속도에 상응하는 속도 리스트에서의 아이템단계 J1A로 가시오
Stepdown:버퍼를 클리어RateU=RateC로 설정StemU=StemC로 설정RateC=RateD로 설정StemC=StemD로 설정RateD=리스트에서 다음번 저차 속도로 설정하거나 아무것도 없는 경우는 0으로 설정StemD=Stem+"/"+이 속도에 상응하는 속도 리스트에서의 아이템단계 J1A로 가시오
사용자 제어는 다음과 같은 옵션이 스크린 위에서 제공되는 사용자에 의해 구현되며, 아래의 옵션은 키보드 혹은 마우스와 같은 다른 입력 장치를 이용함으로써 선택할 수 있다.
a) 시작(Start): 위에서 주어진 번호 매겨진 단계를 단계 4에서부터 구현한다. 먼저 녹음물이 선택되었을 때, 그것이 자동적으로 재생을 시작하느냐 혹은 사용자로부터의 시작 명령을 요구하는가 하는 것은 선택사항이다; 실제로, 원한다면, 그 선택은 링크 화일에 추가적인 "자동재생(autoplay)" 파라미터를 추가함에 의해서 만들어질 수 있을 것이다.
b) 일시중단(Pause): 버퍼로부터 데이터를 읽는 것을 잠시 중단하라고 MP3 디코더에 명령을 내림으로써 구현됨;
c) 재개(Resume): 버퍼로부터 데이터를 읽는 것을 재개하라고 MP3 디코더에명령을 내림으로써 구현됨;
d) 점프(Jump): 녹음물 중에서 사용자가 점프하고자 하는 부분을 가리킴으로써 사용자에 의해 구현됨 - 예를 들면, 녹음물의 총 지속시간을 나타내는 표시된 막대 상의 원하는 지점에 커서를 이동시킴에 의해서; 이때 재생기는 이 지점이 막대 상의 x% 지점인가를 결정해서 필요한 다음번 서브-화일의 번호를 계산하며, 이것은 다음번 요청을 위해서 사용된다. 125개의 서브-화일을 가진 바흐 예에서 녹음물의 20% 지점에서부터 재생을 하고자 하는 요청은 26번째 서브-화일, 즉 000025.bin에 대한 요청으로 귀결될 것이다. 만약 각각의 서브-화일이 동일한 고정 시간구간에 상응한다면 이 계산은 상당히 간단해질 것이 명백하다. 점프의 경우에, 우리는 디코딩을 잠시 중단하고 버퍼를 클리어하여 새로운 요청이 즉시 수신되도록 하는 것을 선호한다. 하지만 이것이 실제로 필수적인 것은 아니다.
원래 화일을 서브-화일들로 분할하는 프로세스를 추가로 논의하는 것은 흥미롭다. 우선, 다음과 같은 점이 주목되어야만 한다. 즉, (위에서 설명된 제 1 버전에서와 같이) 만약 하나의 서브-화일 뒤에 원래 시퀀스에서 그것을 즉시 뒤따르는 서브-화일 외의 다른 서브-화일이 뒤따를 가능성이 없다면, 서브-화일들 사이의 경계들이 어디에 위치하는가는 거의 중요하지 않다. 그러한 경우, 서브-화일의 크기는 고정된 수의 비트일 수 있거나, 혹은 고정된 재생 시간 길이일 수 있다(혹은 둘 중 어느 것도 아니거나). 유일한 진짜 결정은 서브-화일들이 얼마나 커야만 하느냐하는 것이다. 점프(시간 상에서, 혹은 서로 다른 데이터 속도 사이에서)를 고려할 때, 다른 고려사항들이 있다. 많은 유형의 연설 혹은 오디오 코딩(MP3를 포함해서)으로서, 신호가 프레임들로 코딩될 때, 하나의 서브-화일은 프레임들의 전갯수를 포함해야만 한다. 속도 스위칭의 경우에, 비록 실제로 필수적인 것은 아니지만, 다음과 같은 사항이 매우 바람직하다. 즉, 서브-화일의 경계들은 각각의 속도에 대해서 동일하며, 그 결과 새로운 속도에 대해 처음 수신된 서브-화일은 이전 속도에서 마지막 서브-화일이 끝난, 녹음물의 동일 지점으로부터 계속한다. 모든 서브-화일이 동일한 고정 시간구간(예를 들면, 위에서 언급한 바와 같이 4초)을 나타내게끔 조정하는 것은 이것을 이루기 위한 유일한 방법은 아니다. 하지만 그것은 확실히 가장 편리한 방법이다. 그러나 다음의 사실을 주목하라. 사용되는 코딩 시스템에 따라서, 하나의 서브-화일이 프레임들의 전갯수를 포함해야 한다는 필요조건은 서브-화일들의 재생 지속시간이 약간씩 변할 수 있다는 것을 의미할 수 있다. 다음의 사실을 주목하라. 본 발명의 이 실시예에서, 이용가능한 데이터 속도들은, 비록 그것들이 서로 다른 정도의 양자화를 이용하고, 모노 혹은 스테레오로 인코딩하느냐에 관해서 다를지라도, 모두 동일한 오디오 샘플링을 이용하며, 결과적으로 동일한 프레임 사이즈를 이용한다. 서로 다른 프레임 크기가 이용될 때와 관련된 사항들은 아래에서 논의된다.
실제 서브-화일 길이에 관해서, 과도하게 짧은 서브-화일은 바람직스럽게는 피하여야 하는데, 왜냐하면 (a) 그것들은 더 많은 요청의 형태로 추가적인 네트워크 트래픽을 발생시키고, (b) 어떤 종류의 패킷 네트워크 - IP 네트워크를 포함해서 - 상에서 그것들은 더 작은 패킷들에 의해 전달되어야만 하여, 그 결과 요청 프로세스와 패킷 헤더의 의해 나타내어지는 오버헤드가 비례적으로 더 커진다는 점에서 낭비적이기 때문이다. 반면에, 과도하게 큰 서브-화일은 더 큰 버퍼를 필요로 한다는 점에서, 그리고 재생을 시작할 때 및/또는 점프 혹은 속도 변화가 실시되었을 추가적인 지연을 야기한다는 점에서 불리하다. 플레이아웃 시간의 30%와 130% 사이의 서브-화일 크기, 혹은 바람직하게는 플레이아웃 시간의 약 절반(위에서 제시된 예들에서처럼)이 만족스럽다는 것이 발견되었다.
서브-화일들을 변환하는 실제 프로세스는 논의된 기준에 따라서 프로그래밍된 컴퓨터에 의해 구현될 수 있다. 아마도 분리된 컴퓨터 상에서 이것을 하는 것이 편리할 것이며, 그 분리된 컴퓨터로부터 서브-화일들이 서버로 업로딩될 수 있을 것이다.
부가될 수 있는 또다른 정교화는 보안성을 증가시키기 위해 좀 더 복잡한 서브-화일 명명 관례로 대체하는 것인데, 이것은 허가받지 않은 사람이 서브-화일들을 복사하고 다른 서버 상으로 제공하는 것을 좀 더 어렵게 함으로써 가능해진다. 한 가지 예는 의사-랜덤 시퀀스 발생기를 사용하여 화일명들을 발생시키는 것인데, 예를 들면 다음과 같은 형태의 화일명들을 생성하는 것이다:
01302546134643677534543134.bin
94543452345434533452134565.bin
...
이 경우, 재생기 프로그램은 똑같은 의사-랜덤 시퀀스 발생기를 포함할 것이다. 서버는 첫번째 화일명이나 혹은 아마도 4자리 숫자의 "씨드(seed)"를 전송하고, 이후 재생기에 있는 상기 발생기는 자신을 동기화시키고, 요구되는 서브-화일이름들을 올바른 시퀀스로 발생할 수 있을 것이다.
속도-스위칭에 관한 위에서 제시된 예에서, 사용된 모든 데이터 속도들은 동일한 프레임 크기를 가졌는데, 구체적으로 그것들은 11.025KHz에서 샘플링된 PCM 오디오의 MP3 코딩을 사용했고, 1152개 샘플의 (PCM) 프레임 크기를 사용했다. 만약 서로 다른 프레임 크기들을 갖는 MP3 (혹은 다른) 녹음물들 사이에서 속도 스위칭을 이루기를 원하다면, 하나의 서브-화일이 프레임들의 전갯수를 포함해야한다는 필요조건에 기인한 문제가 발생하는데, 이는 그렇게 되면 프레임 경계들이 일치하지 않기 때문이다. 이 문제는 서브-화일들을 생성하는 데 대한 다음과 같은 수정된 과정에 의해 해결될 수 있다. 특히 다음과 같은 사실이 주목되어야 한다. 즉, 이 과정은 속도 스위칭이 필요한 어떤 상황에서도 사용될 수 있으며, 위에서 논의된 특별한 전달 방법에 한정되는 것은 아니다.
도 4는 오디오 샘플들의 시퀀스를 도시하고 있으며, (그림에서) 경계 표시 B1, B2 등에 의해 4초 길이의 세그먼트들의 윤곽이 그려져 있다. 11.025KHz에서 각각의 세그먼트에는 44,100개의 샘플들이 있다.
1. 경계 B1에서 시작하여 MP3 서브-화일을 생성하기 위해 프레임 별로 오디오를 인코딩하되, 적어도 4초의 총 지속시간을 갖는 프레임들의 전갯수가 인코딩될 때까지 계속함. 프레임 크기가 1152개 샘플일 때, 4초는 38.3개의 프레임에 상응하며, 그리하여 39개의 프레임을 나타내며 4.075초의 총 지속시간을 나타내는 서브-화일 S1이 실제로 인코딩될 것이다.
2. 같은 방식으로 경계 B2에서 시작하여 오디오를 인코딩함.
3. 매번 4초 경계에서 시작하면서 반복함. 그리하여, 이런 식으로 일단의중첩된서브-화일들이, 코딩되는 전체 오디오 시퀀스에 대해서 발생된다. 마지막 세그먼트(이것은 당연히 4초보다 짧은 것이다)는 물론 뒤따르는 것이 아무것도 없고 0이 패딩될 것이다(즉, 묵음).
다른 프레임 크기들을 이용하는 다른 데이터 속도들의 코딩은 동일한 방식으로 진행된다.
터미널에서, 제어 메커니즘은 변화되지 않지만, 디코딩과 버퍼링 프로세스는 수정된다:
1. 서브-화일 S1을 수신함;
2. 서브-화일 S1을 디코딩함;
3. 디코딩된 오디오 샘플들의처음 4초만을 버퍼에 써 넣음(나머지들은 버림);
4. 서브-화일 S2를 수신함;
5. 서브-화일 S2을 디코딩함;
6. 디코딩된 오디오 샘플들의 처음 4초만을 버퍼에 써 넣음;
7. 서브-화일 S3 등등에 대해 계속함...
이런 식으로, 모든 속도에 대한 서브-화일 집합들이 원래 PCM 샘플 시퀀스 내의 동일한 지점에 상응하는 서브-화일 경계를 갖는 것이 확실해 진다.
그리하여, 마지막 것을 제외하고 각각의 4초 구간은, 인코딩에 앞서, 서브-화일의 크기를 MP3 프레임들의 전갯수로 맞추기 위해서 다음번 4초 구간으로부터의오디오 샘플들로 "패딩"한다. 원한다면, 패딩 샘플들은 후행하는 4초 구간의 시작부분 대신에(혹은, 뿐만 아니라) 선행하는 4초 구간의 끝부분으로부터 취해질 수 있을 것이다.
MP3 표준은 ("비트 저장소(bit reservoir)"로 알려져 있는 안(scheme)에 의해) 어떤 정보를 하나의 오디오 프레임에서 다른 데로 전달하는 것을 가능하게 한다는 점을 주목하라. 현 맥락에서, 이것은 하나의 서브-화일 내에서는 수용가능하지만, 서브-화일들간에는 수용불가능하다. 그러나, 상기 표준은, 당연히, 하나의 녹음물의 끝부분이나 시작부분에서 그러한 전달을 허용하는 것은 아니기 때문에, 이 문제는 마치 각각의 서브-화일이 단일 녹음물인 것처럼 각각의 서브-화일을 분리하여 인코딩함으로써 쉽게 해결된다.
샘플링 속도의 변화(및 실제로, 모노와 스테레오 동작 사이의 스위칭)는 오디오 인터페이스(36)의 동작에 대해서 약간의 실제적인 관련을 갖는다. 종래의 많은 사운드 카드들은, 비록 다른 세팅 범위에서 동작할 수 있음에도 불구하고, 샘플링 속도를 변화시키기 위해서는 재설정을 필요로 하며, 이는 필연적으로 오디오 출력 상에서의 중단을 야기한다. 그리하여 추가적인 수정에서, 우리는 고려된 최고의 샘플링 속도에서 사운드 카드가 계속적으로 동작할 수 있음을 제안한다. 재생기 프로그램이 버퍼에 보다 낮은 샘플링 속도로 데이터를 공급할 때, 이후 이 데이터는 버퍼 전 혹은 후에서 이러한 최고의 속도로 업-샘플링된다. 유사하게, 만약 사운드 카드가 항상 스테레오 모드로 동작하고 있다면, 디코딩된 모노 신호는 평행하게 공급되어 사운드 카드 입력의 좌우 채널 모두에 공급될 수 있다. 다시금, 디코딩된 신호의 샘플 당 비트수가 카드에 의해 예상된 것보다 작다면, 비트수는 0을 패딩함으로써 증가될 수 있다.
아래 방향으로의 자동 데이터 속도 스위칭에 대해 앞에서 논의된 기준이 버퍼 언더플로우의 경우에서만 속도 감소를 상정(그러므로 출력에서의 중단을 초래하면서)했다는 것을 상기하면서, 우리는 다음과 같은 사실을 주목한다. 즉, 이 수정으로써 그러한 중단을 피할 수 있으며, 그리하여, 대부분의 경우에 언더플로우를 예상하고 그것을 피하는 기준을 주목한다. 이 경우, 위에서 언급된 3개의 AND 조건 중 첫번째 것(측, 버퍼가 비는 경우)은 생략될 것이다.
동일한 원리가 비디오 녹화물, 혹은 당연히, 사운드 트랙을 동반한 비디오 녹화물의 전달에 적용가능할 것이다. 단지 하나의 녹화물만 있는 보다 간단한 버전에서, 시스템은 단지 화일이 비디오 화일(예를 들면, H.261 혹은 MPEG 포맷)이고 재생기 프로그램이 비디오 디코더를 통합하고 있다는 점에서만 오디오 버전과 다르다. 화일을 서브-화일들로 분할하는 방식은 바뀌지 않는다.
오디오의 경우에서와 마찬가지로, 이미 설명된 제어 메커니즘에 의해 선택된, 서로 다른 데이터 속도에 상응하는 둘이나 그 이상의 녹화물이 있을 수 있다. 또한, 이미 설명된 사용자 제어 설비의 연장에 의해 선택될 수 있는 고속 전진(fast forward)이나 고속 후진(fast reverse)과 같은 서로 다른 리플레이 모드에 상응하는 추가적인 녹화물들이 공급될 수 있다. 다시금, 화일 및 디렉토리 명명법에 대한 체계적인 관례가 뒤따를 수 있으며, 그 결과 재생기 프로그램은 서브-화일 주소를 정정함으로써 (예를 들면) 고속 전진 커맨드에 응답할 수 있다.
그러나, 비디오 녹화물의 전달은 만약 스위칭이나 점프가 허용된다면 화일 분할과 관련해서 추가적인 관련성을 갖는다. 한 화면의 각각의 프레임이 독립적으로 코딩되는 녹화물인 경우에 있어서, 하나의 서브-화일이 한 화면의 프레임들의 전갯수를 포함한다는 것으로 충분하다. 그러나, 만약 압축이 인터-프레임(inter-frame) 기술을 포함한다면, 실제 사용에 있어 상황은 더 복잡하다. 그러한 시스템들 중의 약간은(예를 들면 MPEG 표준) 독립적으로 코딩된 프레임들("인트라-프레임들(intra-frames)")과 예측적으로 코딩된 프레임들(predictively coded frames)의 혼합을 생성한다; 이 경우, 각각의 서브-화일은, 바람직하게는, 인트라-프레임과 더불어 시작하여야 한다.
인트라-프레임들을 자주, 규칙적으로 포함하는 것을 제공하지 않는 ITU H.261 표준과 같은 인터-프레임 코딩 시스템의 경우에, 이것은 불가능하다. 이것은 왜냐하면 - 속도-스위칭을 예로 들자면, 만약에 어떤 이가 보다 낮은 비트속도(bit-rate) 녹화물의 서브-화일 n+1이 뒤따르는 보다 높은 비트속도 녹화물의 서브-화일 n을 요청한다면, 보다 낮은 비트속도 서브-화일의 첫번째 프레임은 보다 낮은 속도 녹화물의 서브-화일 n의 디코딩된 마지막 프레임을 이용해서 인터-프레임 베이시스 상에서 코딩되었을 것이며, 터미널은 물론 이것에 대한 처분권을 갖지 못한다 - 그것이 보다 높은 속도 녹화물의 서브-화일 n의 디코딩된 마지막 화일을 갖기 때문이다. 그러므로, 디코더의 심각한 미스트랙킹(mistracking)이 발생할 것이다.
보통 재생과 고속 재생 모드 사이의 스위칭인 경우에, 상황은 실제적으로는다소간 다르다. 예를 들어, 보통 재생 속도의 5배 빠르기로 고속 전진 재생을 하는 경우, 단지 매 5번째 프레임마다 인코딩이 행해진다. 결과적으로, 인터-프레임 상관관계는 많이 감소하고, 인터-프레임 코딩은 매력이 떨어지게 되어, 고속 재생 시퀀스를 인트라-프레임으로 인코딩하는 것이 일반적으로 선호될 것이다. 그리하면, 인트라-프레임은 어려움 없이 디코딩될 수 있기 때문에, 보통 재생으로부터 고속 재생으로의 스위칭은 아무 문제도 주지 않는다. 그러나, 보통 재생으로 돌아갈 때, 미스트랙킹 문제가 다시 발생하는데, 왜냐하면 그때 터미널에는 예측적으로 코딩된 프레임이 제공되는데, 이때 터미널은 이 프레임에 대해서 선행 프레임을 갖지 않기 때문이다.
어느 경우에나, 문제는 우리의 국제 특허 출원 No. WO98/26604(미국 특허 제 6,002,440호)에서 설명된 원리를 이용하면 해결될 수 있다. 이것은 선행 시퀀스의 마지막 프레임과 새 시퀀스의 첫번째 프레임 사이의 간극을 메우는, 프레임들의 중간 시퀀스의 인코딩을 포함한다.
이것의 동작이 고속 전진 동작의 맥락에서 이제 설명될 것이다(고속 되감기는 비슷하지만 역상황임). 이 예에서, 9분짜리 비디오 시퀀스가 H.261 표준에 따라서 96kbit/s로 인코딩되었고, 전체 H.261 인프라-프레임들에서 보통 속도의 5배로 인코딩되었다고 가정한다. 그리고 결과적인 화일들은 각각 4초짜리 서브-화일들로 분할되었다고 가정한다. 여기서, 4초는 원래 비디오 신호의 지속시간을 가리키는 것이지 고속 전진 재생 시간을 가리키는 것은 아니다. 위에서 채택된 것과 유사한 명명법 관례를 따를 때, 서브-화일들은 아래와 같을 것이다.
디렉토리 서브디렉토리 화일명
mpg_name 096k_x1 000000.bin
000001.bin
...
000134.bin
096k_x5 000000.bin
...
000134.bin
여기서, "이름"은 특별한 녹화물을 식별하기 위한 이름이며, "x1"은 보통 속도를 가리키며, "x5"는 보통 속도의 5배, 즉 고속 전진을 가리킨다.
보통 재생으로부터 고속 전진으로 스위칭하는 것은 단지 재생기 프로그램이, 고속 전진 시퀀스를 가리키는 서브-화일 주소를 수정하는 것이 필요할 뿐이다. 예를 들면,
mpg_name/096k_x1/000055.bin을 요청
의 다음에는
mpg_name/096K_x5/000056.bin을 요청
이 뒤따른다.
보통 재생으로 다시 스위칭하기 위한 메워주는 시퀀스(bridging sequence)를 만들기 위해서, 각각의 가능한 천이마다 메워주는 서브-화일을 만드는 것이 필요하다. 위에서 언급된 우리의 국제 특허 출원에서 설명된 바와 같이, 3개나 4개 프레임들의 시퀀스가 일반적으로 메워주기(bridging)에 충분하다. 그리하여, 간단한 구현 방법은 단지 4개 프레임 시간구간의 메워주는 서브-화일들을 만드는 것이다 - 예를 들면,
디렉토리 서브디렉토리 화일명
mpg_name 096K_5>1 0000001.bin
...
000133.bin
그리하여, 스위칭은 다음과 같은 일련의 요청들에 의해 이루어진다:
mpg_name/096k_x5/000099.bin을 요청
mpg_name/096k_5>1/000099.bin을 요청
mpg_name/096k_x1/000100.bin을 요청
메워주는 서브-화일은 다음과 같이 발생된다:
●서브-화일 99의 마지막 프레임의 디코딩된 버전을 얻기 위해 고속 전진 시퀀스를 디코딩함(초당 25 프레임에서, 이것은 원래 비디오 신호의 프레임 100,000이 될 것이다).
●서브-화일 100의 첫번째 프레임(즉, 프레임 100,001)의 디코딩된 버전을 얻기 위해 보통 시퀀스를 디코딩함. 이 하나의 프레임을 H.261 인터-프레임 코딩을 이용해서, 디코딩된 프레임 100,000 - 시작 참조 프레임으로서 - 에 기초하여, 4번 재인코딩함.
●그리하여, 디코더가 고속 전진 서브-화일의 디코딩을 끝마칠 때, 메워주는 서브-화일에 앞서서 그것은 프레임 100,000을 재구성할 것이며, 보통(x1) 프레임을 디코딩할 준비가 될 것이다. 그런데, 이 과정에서 동일 프레임을 여러번 인코딩하는 이유는, 만약 단지 한 번만 인코딩한다면 H.261의 양자화 특성 때문에 열악한 화질이 만들어질 것이기 때문이다.
정확히 동일한 프로세스가 속도-스위칭에 대해서도 사용될 수 있다(비록 여기서는 메워주는 서브-화일들이 양 방향 모두에서 필요함에도 불구하고). 그러나 다음과 같은 사항이 주목될 것이다. 즉, 위에서 설명된 바와 같이, 메워주는 서브-화일은 4개 프레임 지속시간 - 즉, (초당 25 프레임에서) 160ms - 동안 화면을 멈추게하는 것으로 귀결된다. 고속 재상에서 보통 재생으로의 스위칭에서 이것은 수용가능하다 - 실제로, 이 시점에서 버퍼를 클리어하는 것을 아마도 선택할 것이다. 그것은 속도-스위칭에 대해서 주관적으로 수용가능할 수도 있고 불가능할 수도 있을 것이다. 따라서, 대안은 4초짜리 메워주는 시퀀스를 구성하는 것일 것이다. 그리하여 일련의 요청은 다음과 같을 것이다.
mpg_name/096k_x1/000099.bin
mpg_name/096/128_x1/000100.bin
mpg_name/128k_x1/000101.bin
이 경우, 메워주는 서브-화일은 다음의 두 가지 방법 중 하나에 의해 구성될 것이다. 즉, 참조 프레임으로서, 디코딩된 96kbit/s 프레임 100,000으로 시작해서, 디코딩된 128kbit/s 시퀀스의 디코딩된 5번째 프레임을 4번 재코딩하거나, 혹은 참조 프레임으로서, 디코딩된 96kbit/s 프레임 100,000으로 시작해서, 디코딩된 128kbit/s 시퀀스의 처음 4개 프레임을 코딩함으로써 메워주는 서브-화일은 구성될 것이다. 두 경우 모두에서, 메워주는 서브-화일의 남아있는 96개 프레임은 128kbit/s 서브-화일의 복사본일 것이다.
전달될 화일들은 "녹음(녹화)물들"이라고 참조되었다. 그러나, 전달이 개시되기 전에 전체 오디오 혹은 비디오 시퀀스가 인코딩될 - 혹은 심지어는 존재할 - 필요는 없다. 그리하여 컴퓨터는 다음과 같은 과정을 제공받을 수 있을 것이다. 즉, 라이브 피드(live feed)를 수신하고, 선택된 코딩안을 사용해 그것을 코딩하며, 서브-화일들을 "작동 중에(on the fly)" 발생시키고, 그것들을 서버에 업로딩함으로써 그 결과, 일단 몇몇 서브-화일들이 서버 상에 존재하면, 전달이 개시될 수 있을 것이다.
이러한 전달 시스템의 한가지 응용은 도 5에 도시된 바와 같은 음성-메시징 시스템을 위한 것일 수 있으며, 도 5에는 서버(1), 네트워크(2), 터미널(3)이 다시 도시되어 있다. 음성-메시징 인터페이스(4)는 전화를 수신하고 - 예를 들면, 공중교환전화망(PSTN)을 통해서 -, 메시지를 녹음하며, 그것을 인코딩하고, 그것을 서브-화일들로 분할하며, 그것들을 서버(1)로 업로딩 - 그것들은 앞에서 설명된 방식으로 액세스될 수 있다 - 하는 기능을 수행한다. 선택적으로 제 2 인터페이스(6)가 제공될 수 있는데, 이것은 터미널(3)과 유사한 방식으로 작동하지만 PSTN을 통해 원격 전화(5)에 의해 원격 제어되는데, 이때 원격 전화에는 리플레이된 오디오 신호가 전송된다.
동일한 시스템이 라이브 오디오(혹은 비디오) 피드를 위해서 사용될 수 있다. 그것은 어느 의미에서는 여전히 "녹음(녹화)된(recorded)" 것이다 - 차이점은 녹음(녹화)이 끝나기 전에 전달과 리플레이가 시작된다는 점에 주로 있다. 비록 당연히 적어도 하나의 서브-화일이 녹음(녹화)되고 서버(1)로 로딩될 때까지 사용자가 기다려야만 한다는 점에서 내재적인 지연이 있음에도 불구하고.
시스템은 위에서 설명된 바대로 진행할 수 있을 것이며, 사용자가 가장 원할 것 같은 것이 지금 리플레이가 시작, 즉, 가장 최근에 생성된 서브-화일로 리플레이가 시작되는 것인 반면에 리플레이가 처음부터 시작할 것이라는 사실을 제외한다면 꽤 만족스러울 것이다.
긴 오디오 시퀀스가 있을 때 저장장치에 저장하기 위해서, 보다 오래된 서브-화일들을 제거하는 것을 선택할 수 있다: 연속적인 피드(즉, 하루에 24시간)의 상황에서 이것은 불가피하고, 더욱이 서브-화일 이름들을 재사용하는 것이 필요할 것이다(우리의 원형 시스템에서 우리는 000000.bin에서 009768.bin까지 사용하고 이후 다시 000000.bin에서 시작한다). 그리하여 보다 오래된 서브-화일들이 항상 새로운 것들로 겹쳐쓰여 진다. 전달이 가장 최근의 서브-화일로써 시작하는 것을 확실히 하는 간단한 방법은, 재생기 프로그램으로 하여금 적절한 서스-화일을 요청함으로써 시작하도록 추가적인 커맨드를 인덱스 화일에 포함하는 것일 것이다. 그러나, 이것은 인덱스 화일이 매우 자주 - 이상적으로는 새로운 서브-화일이 생성될 때마다 - 수정되어야만 한다는 단점이 있다. 그러므로, 우리는 다음과 같이 재생기 프로그램이 스타팅 서브-화일을 발견하기 위해서 서버를 스캔하도록 하는 방법을 제안한다. 인덱스 화일에서, 모드(Mode) 파라미터는 재생기 프로그램이 이 방법을 개시하도록 하기 위해서 "라이브"로 세팅된다. LFI는 저장될 수 있는 최대한의 서브-화일수 - 말하자면, 9768 - 를 가리키도록 설정된다. 이 방법은 다음과 같은 단계를 포함하며, (종래의 기술과 같이) 각각의 서브-화일의 "마지막 수정" 시간과 날짜가 결정되어 진 것을 전제로 한다. HTTP 프로토콜을 이용할 때, 이것은 HEAD 요청을 이용함으로써 이루어질 수 있는데, 이 HEAD 요청은 요청된 서브-화일의 전달로 귀결되지 않고, 서브-화일이 서버에 쓰여진 시간이나 혹은 서브-화일이 존재하지 않을 경우는 0을 가리키는 헤더 정보의 전달로 귀결된다. 이 시간은 GetURL(LiveIndex)로서 아래에서 나타내어지며, 여기서 LiveIndex는 질문되어지는 서브-화일의 시퀀스 번호이다. 주석은 "//" 뒤에 있다.
1 LFI=9768 // index.htm 화일로부터 읽음
LiveIndex=LFI/2
StepSize=LFI/2
LiveIndexModifiedAt=0; // 시간의 시작
10 ThisIndexWasModifiedAt=GetURL(LiveIndex);
20 If(StepSize=1)[If(StepSize==1)이었음]
{
// LiveIndexModifiedAt은 화일이 쓰여진 시간이나, 혹은 아무
// 화일도 발견되지 않았다면 0을 포함함. LiveIndex는 인덱스를
// 포함함.
goto 30 [FINISH이었음]
}
StepSize=StepSize/2
if(ThisIndexWasModifiedAt>LiveIndexModifiedAt)
{
LiveIndexModifiedAt=ThisIndexesModifiedAt;
LiveIndex=LiveIndex+StepSize
}
else
{
LiveIndex=LiveIndex-StepSize
}
Goto 10
30 FINISH
LiveIndex를 발견한 후에, Tp(플레이아웃 시간)를 뒤로 물리고(step back), 그곳으로부터 오디오 버퍼를 채우는 요청을 시작하는 것이 사려깊은 일이다. 재생은 보통의 방식으로 시작할 수 있을 것이다.
일단 녹음이 실제로 끝났을 때, 인덱스 화일은, 원한다면 모드가 "녹음(recorded)"으로 설정되도록 수정될 수 있으며, 임의의 길이의 파라미터들도 설정되도록 수정될 수 있다.
원한다면, 재생기 프로그램은 인덱스 화일이 "라이브" 모드에서 "녹음" 모드로 변화했는지를 알아보기 위해, 그리고 만약 그렇다면 "녹음" 모드 재생으로 스위칭하기 위해 주기적으로 체크할 수 있다.
"최신의" 서브-화일을 식별하는 간단하고 훨씬 빠른 방법이 이제 아래에서 설명될 것인데, 이는 무엇보다도 단일하고 연속적인 서브-화일 번호부여 시퀀스를 가정한다는 것에서 출발한다.
1. 터미널은 첫번째 서브-화일(예를 들면, 000000.bin)에 대한 HEAD 요청을 실시한다.
2. 서버는 이 화일의 헤더를 전송함으로써 응답하고, 상기 화일이 마지막으로 수정된 시간과 날짜(MODTIME)와, 이 응답이 전송된 시간과 날짜(REPLYTIME) - 이 둘은 모두 표준적인 http. 필드임 - 를 포함한다.
3. 터미널은 이 둘을 감산함으로써 경과시간(ELTIME)을 계산하고(ELTIME=REPLYTIME-MODTIME), 이것을 서브-화일의 재생 시간구간(이 예에서는 4초)으로 나누어 LIVEINDEX=ELTIME/4를 얻는다.
4. 터미널은 이 인덱스를 갖는 서브-화일의 화일명을 계산한다.
5. 터미널은 이 화일명으로 HEAD 요청을 실시하고, 필요하다면 0(화일이 발견되지 않음)을 수신할 때까지, 뒤따르는 각각의 화일명으로 HEAD 요청을 실시한다. 이때, 0을 수신하면, 터미널은 발견된 최신의 서브-화일을 "Current sub-file"로 간주한다.
6. 터미널은 앞에서 제시된 순서도의 J1: 지점에서 시작하여 화일들을 요청하기 시작한다.
이 방법은 이전에 제시된, 주기적으로 번호가 부여된 서브-화일들에 대한 방법보다 상당히 더 빠르다. 보다 오래된 서브-화일들은 스타팅 서브-화일이 보관되는 한, 저장 필요량을 감소시키기 위해서 삭제될 수 있다. 그러나, 이 방법은 화일명 재사용(주기적 주소들)을 수용하기 위해서 수정될 수 있는데, 하지만 이는 다음과 같은 것을 요구할 것이다. 즉,
(i) 스타팅 서브-화일명(예를 들면, 000000.bin)은 재사용되지않는다. 그리하여, 단계 2에서 헤더 정보를 공급하는 것이 항상 가능해진다. 그러므로, 009768.bin에서 끝날 때, 서브-화일 009768.bin 다음에는 서브-화일 000001.bin이 뒤따를 것이다.
(ii) 단계 3에서 계산된 LIVEINDEX는 Modulo 9768(즉, ELTIME/4를 9768로 나누었을 때의 나머지)로 취해진다.
(iii) 서브-화일 삭제는 항상 새로운 서브-화일들의 생성을 이끄는데, 그리하여 가장 새로운 서브-화일과 삭제되지 않은 가장 오래된 서브-화일 사이에 약간의 화일명들은 존재하지 않는다. 이는 예상되는 "화일이 발견되지 않음" 응답이 단계 5에서 일어나도록 하기 위해서이다.
재생 동작이 녹음 동작보다 다소간 더 빠르거나 혹은 더 늦게 작동할 위험이 있을 수 있다. 이를 방지하기 위해, 다음과 같은 것이 마련될 수 있다. 즉, 재생기 프로그램은 수신하는 각각의 서브-화일을 체크하여 그것이 이전 것보다 더 늦은 시간이 표시되어 있는지의 여부를 확인한다: 만약 그렇지 않다면, 그 서브-화일은 버려지고, 반복된 요청이 아마도 3번 수행되며, 만약 이들 요청들이 성공하지 못한다면 인덱스 화일의 체크가 뒤따를 것이다.
만약 재생이 녹음 프로세스보다 뒤처진다면, 이것은 재생기 프로그램이 때때로, 현재 요청되고 있는 것들보다 더 최근의 서브-화일들이 상당히 많이 존재하느냐를 서버에서 체크함으로써 식별될 수 있다. 그리고 만약 그러한 서브-화일이 존재한다면, "따라잡기(catching up)" 프로세스를 개시함으로써 - 예를 들면, 정기적으로 적은 양의 데이터를 버림으로써 - 식별될 수 있다.

Claims (5)

  1. 오디오 신호를 인코딩하는 방법에 있어서,
    입력 신호를 연속적인 시간부분들(temporal portions)로 개념적으로 나누는 단계;
    상기 입력 시간부분들을 제 1 프레임 길이를 갖는 제 1 인코딩 알로리즘을 이용해 인코딩하여, 인코딩된 시간부분들의 제 1 인코딩된 시퀀스를 생성하는 단계; 및
    상기 입력 시간부분들을 제 2 프레임 길이를 이용해 인코딩하여, 인코딩된 시간부분들의 제 2 시퀀스를 생성하는 단계를 포함하며,
    상기 인코딩 단계 중의 적어도 하나는, 복수의 선행하는 시간부분의 끝부분 및/또는 바로 뒤따르는 시간부분의 시작부분과 함께, 하나의 입력 시간부분을 인코딩하는 단계를 포함하며, 상기 하나의 시간부분으로써 정수개의 프레임들을 구성하는 것을 특징으로 하는 오디오 신호 인코딩 방법.
  2. 제 1 항에 있어서,
    제 1 및 제 2 인코딩 알고리즘은 각각의 서로 다른 출력 데이터 속도에 상응하는 것을 특징으로 하는 오디오 신호 인코딩 방법.
  3. 제 1 항 또는 제 2 항에 있어서,
    인코딩된 시간부분들의 하나의 시퀀스를 하나의 입력에 피딩(feeding)하는 단계를 포함하고, 스위칭 커맨드에 응답하여, 인코딩된 시간부분들의 다른 시퀀스가 공급된 출력을 스위칭하는 단계를 포함하며, 이때 스위칭은 하나의 인코딩된 시간부분과 다음번 것 사이의 경계에서 일어나는 것을 특징으로 하는 오디오 신호 인코딩 방법.
  4. 오디오 신호를 전송하는 방법에 있어서,
    제 1 항 내지 제 3 항 중 어느 한 항의 방법을 이용해서 신호를 인코딩하는 단계;
    분리된(discrete) 부분들을 디코딩하는 단계; 및
    상기 끝 및/또는 시작에 상응하는 디코딩된 신호의 상기 부분을 버리는 단계를 포함하는 것을 특징으로 하는 오디오 신호 전송 방법.
  5. 입력 오디오 신호를 인코딩하는 방법에 있어서,
    제 1 프레임 길이를 갖는 제 1 코딩 알고리즘으로 입력 신호의 연속적인 제 1 시간부분들 각각 - 여기서 이들 부분들은 정수개의 상기 제 1 프레임 길이들에 상응하며, 연접(contiguous)하거나 중첩됨 - 을 인코딩하여 제 1 인코딩된 시퀀스를 생성하는 단계; 및
    제 2 프레임 길이를 갖는 제 2 코딩 알고리즘으로 입력 신호의 연속적인 제 2 시간부분들 각각 - 여기서 이들 부분들은 중첩되고, 정수개의 상기 제 2 프레임길이들에 상응하며, 정수개의 상기 제 1 프레임 길이들에 상응하지 않음 - 을 인코딩하여 제 2 인코딩된 시퀀스를 생성하는 단계를 포함하며, 상기 제 2 인코딩된 시퀀스의 각각의 중첩 영역은 입력 신호의 연속적인 시간부분들에 상응하는 상기 제 1 인코딩된 시퀀스 간의 경계 혹은 시퀀스의 중첩 영역 부분들(이 경우가 발생할 수 있음)을 적어도 부분적으로 포함하는 것을 특징으로 하는 입력 오디오 신호 인코딩 방법.
KR1020037007741A 2000-12-15 2001-11-19 오디오 신호의 인코딩 방법 KR100838052B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP00311275.2 2000-12-15
EP00311275A EP1215663A1 (en) 2000-12-15 2000-12-15 Encoding audio signals
PCT/GB2001/005082 WO2002049008A1 (en) 2000-12-15 2001-11-19 Encoding audio signals

Publications (2)

Publication Number Publication Date
KR20030060984A true KR20030060984A (ko) 2003-07-16
KR100838052B1 KR100838052B1 (ko) 2008-06-12

Family

ID=8173454

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020037007741A KR100838052B1 (ko) 2000-12-15 2001-11-19 오디오 신호의 인코딩 방법

Country Status (11)

Country Link
US (1) US7222068B2 (ko)
EP (2) EP1215663A1 (ko)
JP (1) JP4270868B2 (ko)
KR (1) KR100838052B1 (ko)
CN (1) CN1217317C (ko)
AT (1) ATE347729T1 (ko)
AU (2) AU2002215122B2 (ko)
CA (1) CA2429735C (ko)
DE (1) DE60125061T2 (ko)
ES (1) ES2277954T3 (ko)
WO (1) WO2002049008A1 (ko)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002353343A1 (en) 2002-01-18 2003-07-30 Koninklijke Philips Electronics N.V. Audio coding
US9323571B2 (en) * 2004-02-06 2016-04-26 Intel Corporation Methods for reducing energy consumption of buffered applications using simultaneous multi-threading processor
US20050185541A1 (en) * 2004-02-23 2005-08-25 Darren Neuman Method and system for memory usage in real-time audio systems
US7594254B2 (en) * 2004-03-22 2009-09-22 Cox Communications, Inc System and method for transmitting files from a sender to a receiver in a television distribution network
US20070223660A1 (en) * 2004-04-09 2007-09-27 Hiroaki Dei Audio Communication Method And Device
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
DE102004047069A1 (de) * 2004-09-28 2006-04-06 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und Verfahren zum Ändern einer Segmentierung eines Audiostücks
DE102004047032A1 (de) * 2004-09-28 2006-04-06 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und Verfahren zum Bezeichnen von verschiedenen Segmentklassen
US8370514B2 (en) 2005-04-28 2013-02-05 DISH Digital L.L.C. System and method of minimizing network bandwidth retrieved from an external network
US8683066B2 (en) * 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
JP4639966B2 (ja) * 2005-05-31 2011-02-23 ヤマハ株式会社 オーディオデータ圧縮方法およびオーディオデータ圧縮回路並びにオーディオデータ伸張回路
CN101231850B (zh) * 2007-01-23 2012-02-29 华为技术有限公司 编解码方法及装置
US8428953B2 (en) * 2007-05-24 2013-04-23 Panasonic Corporation Audio decoding device, audio decoding method, program, and integrated circuit
EP2131590A1 (en) * 2008-06-02 2009-12-09 Deutsche Thomson OHG Method and apparatus for generating or cutting or changing a frame based bit stream format file including at least one header section, and a corresponding data structure
JP2009294603A (ja) * 2008-06-09 2009-12-17 Panasonic Corp データ再生方法、データ再生装置及びデータ再生プログラム
US8321401B2 (en) 2008-10-17 2012-11-27 Echostar Advanced Technologies L.L.C. User interface with available multimedia content from multiple multimedia websites
US9510029B2 (en) 2010-02-11 2016-11-29 Echostar Advanced Technologies L.L.C. Systems and methods to provide trick play during streaming playback
US9942593B2 (en) * 2011-02-10 2018-04-10 Intel Corporation Producing decoded audio at graphics engine of host processing platform
CN103117958B (zh) * 2013-01-08 2015-11-25 北京百度网讯科技有限公司 网络数据包聚集方法、系统及装置
US20170193632A1 (en) * 2014-05-27 2017-07-06 Huawei Technologies Co., Ltd. Media file processing method and apparatus
CN105429983B (zh) * 2015-11-27 2018-09-14 刘军 采集媒体数据的方法、媒体终端及音乐教学系统
CN115497487A (zh) * 2022-09-09 2022-12-20 维沃移动通信有限公司 音频信号处理方法、装置、电子设备及可读存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2140850C (en) * 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US5835495A (en) * 1995-10-11 1998-11-10 Microsoft Corporation System and method for scaleable streamed audio transmission over a network
US6118790A (en) * 1996-06-19 2000-09-12 Microsoft Corporation Audio server system for an unreliable network
US6124895A (en) * 1997-10-17 2000-09-26 Dolby Laboratories Licensing Corporation Frame-based audio coding with video/audio data synchronization by dynamic audio frame alignment
US5903872A (en) * 1997-10-17 1999-05-11 Dolby Laboratories Licensing Corporation Frame-based audio coding with additional filterbank to attenuate spectral splatter at frame boundaries
CN1253017C (zh) * 1997-12-15 2006-04-19 松下电器产业株式会社 用于把视频目标记录在光盘上的记录设备及其方法
US6061655A (en) * 1998-06-26 2000-05-09 Lsi Logic Corporation Method and apparatus for dual output interface control of audio decoder
US6366888B1 (en) * 1999-03-29 2002-04-02 Lucent Technologies Inc. Technique for multi-rate coding of a signal containing information

Also Published As

Publication number Publication date
ES2277954T3 (es) 2007-08-01
CN1217317C (zh) 2005-08-31
WO2002049008A1 (en) 2002-06-20
JP4270868B2 (ja) 2009-06-03
KR100838052B1 (ko) 2008-06-12
US20040030547A1 (en) 2004-02-12
ATE347729T1 (de) 2006-12-15
CN1481547A (zh) 2004-03-10
CA2429735A1 (en) 2002-06-20
JP2004516505A (ja) 2004-06-03
CA2429735C (en) 2008-08-26
EP1342231A1 (en) 2003-09-10
AU1512202A (en) 2002-06-24
DE60125061T2 (de) 2007-06-06
DE60125061D1 (de) 2007-01-18
AU2002215122B2 (en) 2007-10-25
EP1215663A1 (en) 2002-06-19
EP1342231B1 (en) 2006-12-06
US7222068B2 (en) 2007-05-22

Similar Documents

Publication Publication Date Title
KR100908954B1 (ko) 오디오 또는 비디오 자료의 전송방법 및 장치
KR100838052B1 (ko) 오디오 신호의 인코딩 방법
AU2002220927B2 (en) Transmission and reception of audio and/or video material
AU2002220927A1 (en) Transmission and reception of audio and/or video material
AU2002215122A1 (en) Encoding audio signals
US10459943B2 (en) System and method for splicing media files
JP4360513B2 (ja) ビデオの連続的フィードを配信するためのシステム
JP4936592B2 (ja) インプログレスビデオフィードへの非順次アクセスのための方法および装置
EP2475149B1 (en) Method for streaming multimedia data over a non-streaming protocol
JP4942246B2 (ja) 媒体の同時のエンコードおよびタグ付けを行なうための方法および装置
US8762351B2 (en) Real-time or near real-time streaming with compressed playlists
US8639832B2 (en) Variant streams for real-time or near real-time streaming to provide failover protection
EP3300372B1 (en) Updating a playlist for streaming content
JP2007529121A (ja) ストリーミングメディアの疎（ｓｐａｒｓｅ）キャッシング
WO1998037699A1 (en) System and method for sending and receiving a video as a slide show over a computer network
WO2002049342A1 (en) Delivery of audio and/or video material
GB2348069A (en) Representation of a slide-show as video

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130523

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20140522

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20150528

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20160526

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20170525

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20180525

Year of fee payment: 11

FPAY Annual fee payment

Payment date: 20190523

Year of fee payment: 12