KR100210396B1

KR100210396B1 - 주문형 비디오시스템의 셋탑유니트에서 다수의 스트림 요구방법

Info

Publication number: KR100210396B1
Application number: KR1019960035240A
Authority: KR
Inventors: 김용수
Original assignee: 전주범; 대우전자주식회사
Priority date: 1996-08-23
Filing date: 1996-08-23
Publication date: 1999-07-15
Also published as: KR19980015802A

Abstract

본 발명은 주문형 비디오(VOD)시스템의 셋탑유니트에서 다수의 스트림으로부터 특정 프로그램들을 요구하는 방법에 관한 것으로, 클라이언트가 셋탑유니트를 이용하여 전달시스템을 통해 연결된 비디오서버에게 N개의 스트림으로부터 (rStart, rStop, rScale)로 지정된 스트림들을 전달받기 위한 주문형 비디오(VOD)시스템에 있어서, 상기 셋탑유니트가 N개의 스트림 오브젝트를 지정하기 위한 콘피그화일을 설정하는 단계; 콘피그화일 설정이 끝나면 비디오서버측으로 플레이리스트명령을 전달하는 단계; 상기 플레이리스트명령에 의해 비디오서버측이 송신하는 스트림들을 수신하는 단계; 스트림 모드 디스크립터가 수신되면 스트림의 종료(end of stream)인지를 판단하여 스트림의 종료이면 스트림의 수신을 종료하는 단계를 수행하고, 상기 비디오서버가 플레이리스트명령이 수신되면 콘피그화일에 지정된 N개 스트림의 오브젝트를 전송한 후 마지막 스트림이 송신된 후 스트림 종료 정보가 포함된 스트림 디스 크립터를 송신하는 단계를 수행하여 여러개의 스트림중에서 특정부분들을 추출하여 전송받기가 용이한 효과가 있다.

Description

주문형 비디오시스템의 셋탑유니트에서 다수의 스트림 요구방법(Method of requesting multilpe streams from a video server in a STU of VOD system)

본 발명은 주문형 비디오(VOD: Video On Demand)시스템에서 비디오서버(서비스제공자)로부터 셋탑유니트(클라이언트)로 전달시스템(delivery system)을 통해 프로그램 데이타(stream)를 요구하는 방법에 관한 것으로, 특히 비디오서버와 클라이언트간의 제어명령이 정의된 디지탈 저장매체명령제어(DSMCC: Digital Storage Media Command Control)규격에서 제안된 제어명령중 플레이(Play)명령을 개량한 플레이리스트(Playlist)명령을 이용하여 다수의 스트림을 요구하는 방법에 관한 것이다.

최근, 멀티미디어 표준화를 위한 활동이 국제 표준 기관과 민간 표준화 단체들을 중심으로 활발히 진행 되고 있는 가운데, 국제 표준 기관인 ISO 와 IEC에서 정한 MPEG-2가 화상 압축 분야에서 세계 공통 표준으로 확정되어 모든 영상기기들이 이 표준에 맞추어 개발되고 있으며, 각기 다른 제어 명령어를 가진 디지탈 저장 매체들이 상대방의 데이타를 접근하려고 할 때에는 상대방의 제어 명령어로 일일이 전환해야하는 부담을 해결하기 위해 디지탈 저장 매체의 종류에 상관없이 매체에 저장된 MPEG 비트스트림을 공통적으로 관리하고 제어하는 표준안으로 DSM-CC 프로토콜(ISO/IEC 13818-6)이 제안되어 있다.

한편, 민간단체로서 디지탈 오디오/비디오 서비스의 표준화 단체인 DAVIC(Digital Audio Visual Council)에서도 이용자가 보고싶은 비디오를 원하는 시간에 통신망을 통해 받아 볼 수 있는 서비스인 주문형 비디오(VOD : Video On Demand)시스템의 세션 설정을 위한 프로토콜 스택으로 DSM-CC User-Network 접속 규격을 채택하고, 사용자간의 응용제어를 위해서 DSM-CC User to User 접속규격을 활용하고 있어서 계속해서 새로운 응용의 DSM-CC 확장 프로토콜이 개발되고 있는 형편이며, 앞으로 국제 표준으로 확정될 전망이다.

이러한 주문형 비디오(VOD)시스템의 구성장치로는 가입자 단말기(STU)와 전송시스템(DS) 및 서비스 공급 시스템(SPS)으로 구성되고, DSM-CC프로토콜이 구현되는 환경과 비교해보면 가입자 단말기(STU)는 클라이언트에, 전송(DS)시스템은 네트워크에, 서비스 공급시스템(SPS)은 서버에 해당된다. 그리고 DSM-CC 프로토콜에는 DSM-CC 사용자망(User to Network) 프로토콜과 DSM-CC 사용자간(User to User) 프로토콜이 있는데, 사용자망(User to Network)는 사용자(즉, 서버 또는 클라이언트)와 네트워크간에 메시지를 주고 받음으로써 클라이언트로부터 원하는 서버를 찾아가서 연결을 하여 자원을 할당받아 세션을 설정하거나, 세션을 제어운영하고, 자원을 해제하여 연결을 끊는 프로토콜을 제공한다. 사용자망(User to Network) 상의 연결이 이루어지고 나면, 사용자간(User to User)의 연결이 이루어져서 클라이언트와 서버간의 통신이 가능해진다.

상기에 언급한 세션(session)이란, 가입자 단말기인 클라이언트가 서비스제공자인 서버로부터 어떤 서비스를 제공받기 위해서는 해당 서비스를 지원해주는 자원들이 필요하게 되는데, 예컨데 자원들로는 채널, 대역폭, ATM연결등이 있으며, 바로 이러한 자원들을 묶어서 관리하는 기능을 제공하는 것을 말한다.

즉, 세션설정은 클라이언트와 서버간의 정보교환통로를 만드는 작업이라 할 수 있고, 세션설정이 완료된 후에야 비로소 클라이언트와 서버간의 정보교환이 이루어져서 서버로부터 서비스를 제공받을 수 있게 되는 것이다.

따라서 이와 같은 세션설정이 이루어진 후에 DSM-CC의 User to User 접속 프로토콜에 따라 서버에 서비스를 요구하거나 서버로부터 서비스를 제공받을 수 있다. 여기서, DSM-CC User to User 접속 프로토콜에서 제공하는 접속명령은 기본(Base), 억세스(Access), 디랙토리(Directory), 스트림(Stream), 화일(File), 및 서비스 게이트웨이 접속 군으로 분류된 후 서비스의 특성에 맞도록 각 군별로 세부명령을 규정하고 있고, 이 접속명령들은 객체관리그룹 접속정의언어(OMG IDL: Object Management Group Interface Definition Language)로 기술되어 있다. 이 OMG IDL은 ISO/IEC 14750으로 표준화되어 있다.

이와 같은 접속명령중에서 MPEG 비디오 서비스와 밀접한 스트림(stream)군에는 VCR제어와 유사한 동작을 제어하는 명령들(primitives)이 정의되어 있는데, 예컨대 스트림 일시정지(DSM Stream pause), 스트림 재개(DSM Stream resume), 스트림상태(DSM Stream status), 스트림리셋(DSM Stream reset), 스트림 점프(DSM Stream jump), 스트림 플레이(DSM stream play: 이하, play라한다) 등이 OMG IDL로 정의되어 있다. 여기서 플레이(play)명령은 클라이언트가 서버로 특정한 스트림의 전송을 요구하는 것인데, 시작(rStart), 종료(rStop), 스케일(rScale)과 같은 파라미터를 가지고 있으며, 이의 동작을 IDL로 기술하면 다음 표1과 같다.

[표 1]

play(rStart, rStop, rScale)명령

module DSM{

interface Stream: Base,Access{

void play(

in AppNPT rStart,

in AppNPT rStop,

in Scale)

raises(MPEG_DELIVERY,BAD_START,BAD_STOP,BAD_SCALE);

};

여기서, rStart는 스트림중 전송을 요구하는 시작위치를 지정하는 파라미터이고, rStop 전송을 요구하는 스트림의 마지막을 지정하는 파라미터이며, rScale은 플레이의 속도(rate)와 방향(reverse 혹은 forward)을 지시하는 파라미터이다.

그런데, play명령을 이용하여 여러개의 스트림중에서 특정부분들을 추출하여 전송받기 위해서는 제3도에 도시된 바와 같이, Play명령을 여러번 반복해야 한다. 즉, 클라이언트가 play(rStart1, rStop1, rScale1)으로 스트림1에 대해서 rStart1부터 rStop1까지의 내용을 전송해 주길 서버로 요구하면, 서버는 해당 MPEG 비트스트림을 전송해준 후, 스트림 모드 디스크립터(stream mode descriptor)를 통해 전송이 종료된 것(end of stream)을 알려주었고, 이어서 클라이언트가 play(rStart2, rStop2, rScale2)으로 스트림2에 대해서 rStart2부터 rStop2까지의 내용을 전송해 주길 서버로 요구하면, 서버는 해당 MPEG 비트스트림을 전송해준 후, 스트림 모드 디스크립터를 통해 전송이 종료된 것(end of stream)을 알려주었으며, 다른 비트스트림에 대해서 연속적으로 요구할 경우에도 동일한 절차를 반복해야 했다.

도 4는 플레이명령을 반복하여 여러 스트림으로부터 특정한 부분들을 전송받는 흐름을 도시한 것이다. 먼저 파라미터들을 초기화한 후, 첫번째 play(rStart, rStop, rScale)명령을 서버로 전송하고, 이어서 MPEG 비트스트림을 수신하면서 스트림 모드 디스크립터(stream mode descriptor)가 수신되길 기다린다(S1,S2,S3). 스트림 모드 디스크립터가 스트림의 종료(end of stream)를 나타내면, 마지막 스트림인지를 확인하여 아니면 파라미터(rStart, rStop, rScale)를 갱신하여 다시 플레이명령(play)을 서버로 전송한다. 이러한 과정을 반복하다가 마지막 스트림이면 전체 과정을 종료한다(S4,S5,S6).

이와 같이 play명령을 반복하여 전송할 경우에는 이전에 보낸 play명령의 수행이 끝나지 않은 상태에서 새로운 play명령이 서버측으로 전달되면, 수행중이던 play명령을 중지하고 다시 새로운 play명령을 수행하므로, play 명령을 반복하여 이용할 경우에는 이전 play명령의 수행이 완료되는 것을 확인한 후 새로운 play명령을 전달해야 했기 때문에 매우 불편하였다.

또한, 각 play명령의 아규먼트로 전달되는 파라미터는 각 play명령을 보낼 때까지 계속 보존되어야 하기 때문에 이를 저장하기 위한 저장자원이 요구되고, 모든 play명령이 수행완료될 때까지 흐름제어절차를 계속 가지고 있어야 하므로 멀티프로세싱처리를 위한 프로그래밍작업이 복잡하게 되는 문제점이 있다.

이에 본 발명은 상기와 같은 문제점을 해소하기 위하여 Play명령을 반복 이용하지 않고서도 여러개의 스트림중에서 특정부분들을 추출하여 전송받을 수 있도록 하는 VOD시스템의 셋탑유니트에서 다수의 스트림 요구방법을 제공하는데 그 목적이 있다.

상기와 같은 목적을 달성하기 위하여 본 발명의 방법은, 클라이언트가 셋탑유니트를 이용하여 전달시스템을 통해 연결된 비디오서버에게 N개의 스트림으로부터 (rStart, rStop, rScale)로 지정된 스트림들을 전달받기 위한 주문형 비디오(VOD)시스템에 있어서, 상기 셋톱유니트가 N개의 스트림 오브젝트를 지정하기 위한 콘피그화일을 설정하는 단계; 콘피그화일 설정이 끝나면 비디오서버측으로 플레이리스트명령을 전달하는 단계; 상기 플레이리스트명령에 의해 비디오서버측이 송신하는 스트림들을 수신하는 단계; 스트림 모드 디스크립터가 수신되면 스트림의 종료(end of stream)인지를 판단하여 스트림 종료이면 수신을 종료하는 단계를 수행하고, 상기 비디오서버가 플레이리스트명령이 수신되면 콘피그화일에 지정된 N개 스트림의 오브젝트를 전송한 후 마지막 스트림이 송신된 후 스트림 종료 정보가 포함된 스트림 디스 크립터를 송신하는 단계를 수행하는 것을 특징으로 한다.

도 1은 본 발명이 적용될 수 있는 DAVIC참조모델을 도시한 개념도,

도 2는 I-CATV시스템에 적합한 셋탑유니트의 예,

도 3은 종래에 play명령을 반복하여 다수의 스트림으로부터 데이타를 전달받는 과정을 도시한 시퀀스도,

도 4는 종래에 play명령을 반복하여 다수의 스트림으로부터 데이타를 전달받는 과정을 도시한 흐름도,

도 5는 본 발명에 따른 시퀀스도,

도 6a는 본 발명에 따라 클라이언트측에서 처리하는 흐름을 도시한 흐름도,

도 6b는 본 발명에 따라 서버측에서 처리하는 흐름을 도시한 흐름도이다.

* 도면의 주요부분에 대한 부호의 설명

10 : 정보제공자시스템 20 : 전달시스템

30 : 클라이언트 31,100 : 네트웍 인터페이스 유니트(NIU)

200 : 셋탑유니트

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 자세히 설명하기로 한다.

도 1은 DAVIC에서 정의한 서비스제공자에서부터 사용자까지의 시스템 전체의 참조모델의 기능 블럭도이다.

DAVIC 참조모델은 시스템 개체(system entity), 정보흐름(information flow), 참조점(reference point) 및 인터페이스(interface)에 대한 정의로 이루어져 있는데, 시스템 개체는 정보를 보유하여 서비스를 제공하는 서비스제공자(SPS, 즉 서버:10)와 이를 전달하는 전달시스템(DS:20), 오디오/비디오 서비스를 최종적으로 사용하는 클라이언트(30)로 구성된다.

정보흐름은 MPEG-2 트랜스포트 스트림으로 규정한 오디오-비디오 비트 스트림이 전달되는 주 서비스흐름(S1), 주 서비스흐름을 제어하거나 응용프로그램을 다운로딩받을 수 있도록 제어하는 응용제어흐름(S2), 주 서비스 흐름(S1)과 응용제어흐름(S2)에 대한 세션을 설정/해제하는 세션 설정/해제 흐름(S3), 세션의 접속을 제공하기 위한 연결 프로토콜로 이루어진 연결 설정/해제 흐름(S4), 및 관리평면흐름(S5)으로 정의되어 있다. 또한 참조점은 시스템 외부와의 인터페이스를 나타내는 참조점들(A1~A11)과 가입자시스템 내에서만 존재하는 참조점(A0, RP2, RP3, RP4, RP7등)으로 나누어지는데, A9 참조점은 서비스 제공자(10)와 전달시스템(20)과의 인터페이스를 ATM을 기본으로 정의하고 있고, A1 참조점은 서비스 사용자인 클라이언트(SUS:30)와 전달시스템(20)과의 접속을 정의한 것인데 다양한 매체를 지원할 수 있도록 정의되어 있다.

도 1을 참조하면, 서비스제공자(SPS:10)는 객체 개념을 바탕으로 서비스를 표현하고, 개방형시스템(OSI)모델을 이용하여 정의된 서비스 요소의 집합을 나타내고 있다. 즉, 서비스제공자(10)는 서비스정보부(content service element), 응용제어정보부(application service element), 세션제어부(session control function), 스트림서비스부(stream service element), 네트웍제어부(network control function), 서비스게이트웨이부(service gateway element), 네트웍접속부(network interface function)로 이루어져 클라이언트(30)가 요구하는 서비스를 제공한다.

클라이언트(SUS:30)는 셋톱유니트(STU)와 그 주변장치로 구성되며, A1인터페이스를 통해 전달시스템(20)에 접속된다. 셋탑유니트(STU)는 4개의 STU 기본장치와 네트웍접속유니트(NIU)로 구성되며, 이들간의 인터페이스는 A0 인터페이스로 정의되어 있다. 여기서 서비스처리부(product entity)는 실제 사용자가 요구한 서비스정보를 서버로부터 수신하여 이를 사용자에게 출력해주는 역할을 하며 주서비스흐름(S1)을 담당하고, 응용처리부(application entity)는 응용서비스를 수용하거나 창출하는 역할을 하며 모든 응용 서비스 제어흐름(S2)을 처리한다. 동작환경처리부(environment entity)는 응용서비스 프로그램들이 동작할 수 있는 환경(세션설정, 품질등급(QoS))을 조성하는 역할을 하며, 세션 설정/해제 흐름(S3)을 담당한다. 연결처리부(connectivity entity)는 셋탑유니트(STU)와 네트웍접속유니트(NIU)를 통한 통신망과의 오류없는 상호정보 교환기능을 하며, 연결 설정/해제 흐름(S4)을 담당한다.

여기서, 네트웍접속유니트(NIU)는 셋탑유니트(STU)의 통신망처리장치로서 다양한 통신망( 예컨대, ATM망, FTTC, HFC, ADSL, 위성통신망등)과 셋탑유니트(STU)를 연결하여 주는 부분으로서, 통신망관련정보를 모두 처리한다. 셋탑유니트(STU)는 서버에 접속하여 각종 응용서비스를 제공받게 되는데, 실제 서버로부터 제공되는 사용자용 데이타는 멀티미디어 타이틀 형태가 될 것이다. 멀티미디어 타이틀에는 비디오, 오디오 등의 스트림외에도 이들을 적절히 제어하기 위한 컴퓨터 프로그램이 포함된다. 이와 같이 DAVIC관련 기술은 정보과확회지 제13권 제10호(1995년10월) 페이지31~45에 디지탈 AV서비스기술의 표준화동향이라는 제목으로 양재우외 1인이 자세히 기술한 바 있으며, 전자공학회지 제22권7호(1995년7월) 디지탈 영상서비스기술 특집편에서도 자세히 설명되어 있다.

한편, 본 발명이 적용되기에 적합한 CATV 가입자 단말기는 제2도에 도시된 바와 같이, 네트워크와 연결되어 데이타 송수신을 담당하는 네트워크 인터페이스유니트(NIU:100)와, MPEG-2신호를 NTSC신호로 변환하여 TV로 송출하는 셋톱유니트(STU:200)로 구성되며, 이들 하드웨어를 동작시키기 위한 운영체계와 응용 프로그램들이 부가된다.

일반적으로 광.동축 혼합형(Hybrid Fiber Coaxial Network)의 CATV망을 이용한 대화형 CATV 서비스 시스템은 기존에 설치된 CATV망을 활용하여 아날로그 CATV서비스를 수용하고, 멀티미디어 서비스를 제공하기 위하여 450MHz∼750MHz의 300MHz 대역에 디지탈로 압축된 MPEG2 영상 데이타를 전송하되 주파수 대역분할을 아날로그 전송과의 호환성을 고려하여 6MHz 대역으로 가정한다( 따라서 300MHz 대역은 50채널을 수용할 수 있다). 이 경우 6MHz 채널당 약 38Mbps로 전송할 수 있으므로 4Mbps MPEG2신호를 기준으로 할때 기존 아날로그 1채널당 8∼9개의 영상 데이타를 전송할 수 있다( 통상, 7개의 MPEG2 비트 스트림을 전송한다).

도 2에 있어서, 가입자 단말기(30)의 셋-톱-유니트(STU:200)는 네트워크 인터페이스 유니트(NIU)와 인터페이스를 위한 NIU인터페이스부(201)와; 수신된 비트 스트림의 암호를 해제하는 암호해독부(decryption engine:202); MPEG2 비트 스트림을 수신하는 MPEG-2 트랜스 포트부(203); MPEG-2 비트 스트림에서 오디오 데이타를 디코딩하는 MPEG2 오디오 디코더(204); MPEG-2 비트 스트림에서 비디오 데이타를 디코딩하는 MPEG2 비디오 디코더(206); 그래픽 제어부(208); 디코딩된 비디오 데이타를 NTSC영상신호로 엔코딩하는 NTSC엔코더(209); 디스크램블러(210); 디스크램블링된 베이스밴드 영상신호(baseband video)를 채널3 또는 채널4의 RF로 변조하는 RF변조기(211); 소정의 소프트웨어에 따라 시스템을 제어하는 프로세서(213); 타이머(212); DMA제어기(211); 스마트 리더(SMART reader:215); IR블러스터(IR blaster:216); PCM-CIA(217); RS-232(218); 키보드(219); 디스플레이(214); 메모리(205, 207, 221, 222, 223, 224); 전원부(220)등이 구비되어 있다. 여기서 키보드(219), 디스플레이(214), 각종 입출력 포트들은 CATV망을 가입자와 인터페이스해주기 위한 맨머신인터페이스(MMI)수단이 된다.

이와 같이 구성되는 셋 톱 유니트(200)는 아날로그 CATV 수신기능, 아날로그 유료채널 디스크램블링기능, 디지탈 영상 및 음성신호 복원 및 NTSC디코딩, 가상 VCR기능(Play, Pause, Rewind, fast Forward등), 온 스크린 디스플레이, 및 인터페이스기능 등을 수행한다. 여기서 디스크램블러는 수신조건을 만족하는 가입자만이 정상적인 수신을 할 수 있도록 하고 조건을 만족하지 못하는 가입자의 수신을 방지하는 것이고, PC/MCIA 포트는 RS-232포트를 사용하지 않는 디바이스를 인터페이스하기 위한 포트로서 최대 전송속도는 약 22Mbps정도이고 이 포트를 통해 외부기기와 접속할 수 있다.

이와 같은 CATV단말기를 이용하여 주문형 비디오시스템을 구현할 경우에 클라이언트인 CATV단말기가 서버에 play명령을 이용하여 특정 스트림 전송을 요구할 수 있다. 이때 여러 스트림으로부터 특정 부분들의 스트림을 한꺼번에 요구할 경우에 종래에는 play명령을 반복해서 사용했으나 본 발명에서는 플레이리스트(PlayList)명령에 의해 간단하게 동일한 기능을 구현할 수 있다. 여기서 본 발명에 따른 플레이리스트 명령을 OMG IDL로 기술하면 다음 표2와 같다.

[표 2]

Playlist명령

module DSM {

struct playConfig{

Object obj;

AppNPT rStart;

AppNPT rStop;

Scale rScale;

typedef sequencePlayConfig PlayConfigList;

interface Stream: Base, Access{

void playList(

in PlayConfigList rPlayConfigList)

raises(MPEG_DELIVERY, BAD_START, BAD_STOP, BAD_SCALE);

};

도 5는 본 발명에 따른 플레이리스트명령을 이용하여 여러 스트림으로부터 특정한 부분들의 전송을 요구한 것을 나타낸 도면이다.

도 5에 도시된 바와 같이, 클라이언트(본 발명의 실시예에서 셋탑유니트 혹은 CATV 단말기등을 이용하여)가 playList(rPlayConfiglist)명령을 이용하여 서버에게 스트림의 전송을 요구하면, 서버는 콘피그화일(rPlayConfiglist)에서 지정하는 바에 따라 제1 스트림의 해당 데이타를 전송하고, 이어서 제2 스트림의 해당 데이타를 전송하며, 데이타 전송이 끝나면 스트림 모드 디스크립터(stream mode descriptor)를 전송한다. 이때 콘피그화일(rplayConfiglist)에는 rStart, rStop, rScale 파라미터에 대한 값들을 지정하고 있고, 화일로써 한번에 서버측으로 전달하면 서버측에서 이 화일의 지정 파라미터에 따라 순차적으로 스트림을 전송해준다. 또한 종래에는 하나의 스트림에 의한 데이타전송이 끝나면 스트림 모드 디스크립터를 보낸 후 다음 스트림에 대한 데이타를 전송하였으나 플레이리스트(PlayList)에 의한 스트림전송에서는 콘피그화일(rPlayConfiglist)에 의해 지정된 모든 스트림에 대한 데이타를 전달한 후 마지막에 한번 스트림 모드 디스크립터(stream mode descript)를 보낸다.

도 6a는 플레이리스트(playList)명령을 수행하기 위하여 클라이언트측에서 처리하는 동작 흐름을 도시한 도면이고, 도 6b는 서버측에서 처리하는 흐름을 도시한 도면이다.

도 6a에 도시된 바와 같이, 클라이언트측에서 대상 스트림들을 모두 오픈한 후 n=1부터 N번째까지 콘피그화일(rPlayConfiglist)에 n번째 (rStart, rStop, rScale)파라미터를 삽입하고, n=마지막 스트림번호(N)인지를 확인하여 아니면 n을 1증가시키고, 다음 스트림에 대한 파라미터를 설정한다(S11, S12, S13, S14, S15). 이와 같이 콘피그화일(rPlayConfiglist)에 대한 설정이 끝나면, 플레이리스트(play(rPlayConfiglist))명령을 서버측으로 전달하고, 스트림 모드 디스크립터가 수신되기를 기다린다(S16,S17). 스트림 모드 디스크립터(stream mode descriptor)가 수신되면, 스트림의 종료(end of stream)인지를 확인하여 스트림의 종료이면 수신을 종료한다(S17,S18).

이와같은 PlayList(rPlayConfiglist)명령을 수신하면, 서버측은 도 6b에 도시된 바와 같이, n에 대해 1로 초기화한 후 콘피그화일(rPlayConfigList)의 1부터 N까지의 스트림 오브젝트에 대해서 play(rStart, rStop, rScale)명령을 수행한 후, n=마지막(N) 이면 스트림 모드 디스크립터를 송신하고, 아니면 n을 증가시킨 후 다음 스트림 오브젝트에 대해서 play(rStart, rStop, rScale)명령을 수행한다(S21~S25).

이상에서 살펴본 바와 같이 본 발명에 따라 셋탑유니트에서 playlist명령을 사용하여 다수의 스트림 오브젝트에 대해서 연속적인 전송을 서버로 요구할 수 있으므로 여러개의 스트림중에서 특정부분들을 추출하여 전송받기가 용이한 효과가 있다.

Claims

클라이언트가 셋탑유니트를 이용하여 전달시스템을 통해 연결된 비디오서버에게 N개의 스트림으로부터 (rStart, rStop, rScale)로 지정된 스트림들을 전달받기 위한 주문형 비디오(VOD)시스템에 있어서,

상기 셋톱유니트가 N개의 스트림 오브젝트를 지정하기 위한 콘피그화일을 설정하는 단계; 콘피그화일 설정이 끝나면 비디오서버측으로 플레이리스트명령을 전달하는 단계; 상기 플레이리스트명령에 의해 비디오서버측이 송신하는 스트림들을 수신하는 단계; 스트림 모드 디스크립터가 수신되면 스트림의 종료(end of stream)인지를 판단하여 마지막이면 종료하는 단계를 수행하고, 상기 비디오서버가 플레이리스트명령이 수신되면 콘피그화일에 지정된 N개 스트림의 오브젝트를 전송한 후 마지막 스트림이 송신된 후 스트림 종료 정보가 포함된 스트림 디스 크립터를 송신하는 단계를 수행하는 것을 특징으로 하는 주문형 비디오(VOD)시스템의 셋탑유니트에서 다수의 스트림 요구방법.