KR19990070821A - 화상회의 시스템에서 참가자 4명까지의 비디오를 단일 비디오 스트림으로 변환하는 서버 - Google Patents

Abstract

본 출원인은 ITU-T의 H.261 비디오 압축 권고안을 따르는 컴퓨터 화상회의에서 4명까지의 참가자들의 비디오를 동시에 한 참가자의 컴퓨터에서 재생이 가능하도록 이 4개의 비디오 스트림을 하나의 비디오 스트림으로 합쳐주는 기능을 수행하는 비디오 서버를 설계하고 구현하였다.

기존의 화상회의 시스템에서는 H.261 전용 하드웨어 디코더를 사용해 동시에 하나의 비디오 스트림만 재생할 수 있다. 그러므로 3명 이상이 화상회의를 할 때 각 참가자의 화면에는 2명 이상의 상대방 참가자의 비디오가 재생되어야 하나 H.261 전용 하드웨어를 사용할 경우 한 참가자의 비디오 스트림만 재생이 가능하다. 이런 한계 때문에 ITU-T T.122 다자간 화상회의 권고안에서는 현재 발언권을 얻은 한 참가자의 비디오 스트림만을 재생하는 방식을 권고하고 있다.

그러나 본 출원인은 H.261 권고안이 지원하는 저해상도(QCIF, 176x144) 픽쳐 형식과 고해상도(CIF, 352x288) 픽쳐 형식의 계층적 구조와 H.261 권고안에 따라 생성된 비디오 스트림의 특성의 관찰을 바탕으로 서버를 두어 4개까지의 저해상도 비디오 스트림을 하나의 고해상도 스트림으로 합성하는 방식을 개발하였고, 이런 기능을 수행하는 서버의 CPU 부하를 현격하게 줄일 수 있는 알고리즘을 개발하여 구현에 성공하였다.

본 발명을 통해 랜이나 케이블 TV망을 통한 화상회의 시스템에서 4명까지의 참가자의 비디오 스트림을 각 참가자의 컴퓨터 화면에서 동시에 보면서 원활한 회의를 진행할 수 있을 것이며 이를 국내 기술로 구현함으로 그 의미가 더 크다 할 수 있다.

Description

화상회의 시스템에서 참가자 4명까지의 비디오를 단일 비디오 스트림으로 변환하는 서버

본 발명에서는 ITU-T H.261 비디오 권고안의 QCIF 비디오 스트림 4개까지를 단일 CIF 비디오 스트림으로 합성해 화상회의 참가자가 이 단일 스트림을 재생함으로써 4명까지의 참가자의 비디오를 한 컴퓨터에서 보는 것을 가능하게 하고 있다.

기존의 화상회의 시스템에서는 H.261 전용 하드웨어 디코더를 사용해 한개의 비디오 스트림을 재생할 수 있다. 그러므로 3명 이상이 화상회의를 할 때에는 각 참가자의 컴퓨터로 한명의 비디오 스트림만 재생할 수 있으므로 ITU-T T.122 권고안에서는 MCU(Multipoint Control Unit)라는 서버를 두게 해 모든 참가자들은 자신의 비디오 스트림을 MCU 서버에게 전송하고 MCU 서버에서는 현재 발언권을 얻은 한명의 참가자의 비디오를 모든 참가자들에게 전송하는 방식을 택하고 있다. 그러므로 현재의 화상회의에서는 여러 참가자 중에서 발언권을 얻은 한 사람만의 비디오를 볼 수 있는 것이다.

이렇게 H.261 전용 하드웨어 디코더만 사용하는 경우 외에 H.261 소프트웨어 디코더를 사용하는 방식의 화상회의도 있다. 그러나 이 경우 H.261 비디오 스트림을 재생하기 위해서는 펜티엄급 이상의 고성능 컴퓨터가 요구되고 펜티엄급 컴퓨터를 사용하는 경우에도 2명 이상의 비디오 스트림을 H.261 전용 하드웨어 디코더를 사용하는 수준으로 재생하는 것은 어렵다. 그러므로 H.261 소프트웨어 디코더를 사용하는 다자간 화상회의는 인터넷에서 CuSeeMe나 MBone의 vic, vat 정도로 널리 상용화되는 단계에 이르지 못하고 있다. 그에 반해 H.261 전용 하드웨어 디코더를 사용하는 화상회는 ISDN에서 이미 상용화되어 ISDN 가입자에게 서비스가 제공되고 있다.

H.261 전용 하드웨어 디코더를 사용하는 경우 참가자 컴퓨터에 부하를 거의 주지 않고 비디오 스트림을 재생할 수 있다. 그러나 하드웨어를 사용하기 때문에 동시에 한 비디오 스트림만을 재생할 수 있다는 한계가 있다. 그렇기 때문에 기존의 화상회의에서는 발언권을 얻은 한 참가자의 비디오만을 선택적으로 재생하거나 아니면 소프트웨어 디코더를 사용하는 경우가 있지만 전자의 경우 화상회의 참가자가 3명 이상일 때 원활한 화상회의가 어렵다는 점과 발언권 부여 여부를 결정하고 해당 스트림을 전송하는 MCU 서버가 요구된다는 문제가 있다. 후자의 경우에는 참가자 컴퓨터의 성능에 따라 재생할 수 있는 비디오의 수에 한계가 있고 재생 성능 또한 하드웨어 디코더를 사용하는 것에 비해 못미친다.

본 발명에서는 소프트웨어 디코더를 사용하지 않고도 4명까지의 비디오를 참가자의 컴퓨터에서 H.261 전용 하드웨어 디코더를 통해 재생가능하게 한다(도 1 참고). 각 참가자는 H.261 권고안의 QCIF 픽쳐 형식에 맞추어 자신의 비디오를 생성해 본 발명에서 개발한 비디오 서버로 전송한다. 이 비디오 서버에서는 QCIF 픽쳐 형식의 비디오 스트림 4개까지를 하나의 CIF 픽쳐 형식의 비디오 스트림으로 변환을 한다. 이때, QCIF 픽쳐 형식에서의 한 픽쳐(프레임)의 크기가 CIF 픽쳐 형식에서의 한 픽쳐 크기에 비해 가로, 세로 모두 반밖에 되지 않으므로 4개의 QCIF 픽쳐를 하나의 CIF 픽쳐로 나타내는 것이 가능하다(도 2 참고).

그러나 4개의 QCIF 비디오 스트림을 하나의 CIF 스트림으로 합치기 위해서는 해결해야할 과제들이 많이 있다. 우선, H.261 비디오 스트림은 바이트-정렬이 안되어 있는 비트 레벨의 스트림이다(도 3 참고). 그러므로 이 연속적인 스트림에서 한 정지 화면에 해당하는 픽쳐를 찾는 것은 매우 어렵고 컴퓨터에 많은 부하를 준다. 다음, QCIF 형식의 비디오 스트림에서 실시간으로 하나의 픽쳐에 해당하는 정보의 시작과 끝을 찾은 후 H.261에서 사용하는 압축/복원 방식에 따라 디코딩해 원래 영상 정보를 얻은 후, 이를 다시 CIF 형식으로 인코딩하는 것은 현재의 펜티엄급 컴퓨터에서도 거의 불가능하다. 특히, 4개의 QCIF 스트림에서 각각 한 픽쳐를 찾아내 각각 디코딩을 통해 영상 정보를 구하고 이를 다시 CIF 형식으로 인코딩하는 것은 불가능하다. 또한 문제되는 것은 H.261 스트림의 고정 비트율 특성상 각 QCIF 스트림에서의 프레임율이 일정하지 않다는 것이다. 그러므로 예를 들어 한 QCIF 스트림에서 픽쳐가 초당 20개 발생하고 다른 QCIF 스트림에서는 픽쳐가 초당 10개 발생한다면 새로 생성되는 CIF 스트림도 최소한 초당 20개의 픽쳐를 가져야 첫 QCIF 스트림에 대한 모든 정보가 전달이 될 것이다. 이렇게 각각의 QCIF 스트림의 프레임율이 다를 경우 이들을 합쳐서 생성하는 CIF 스트림의 프레임율을 결정하기 어렵다는 문제가 있다.

다음 항목에서는 위에서 언급한 두 개의 문제, 서버에서 QCIF 스트림들을 디코딩한 다음 원래 영상 정보를 얻은 후 다시 CIF 스트림으로 인코딩해야 하는 문제와 각각의 QCIF 스트림의 프레임율이 서로 다를 경우의 문제를 해결한 비디오 서버에 대해서 설명을 한다.

도 1 은 4개의 QCIF 비디오가 합쳐진 단일 CIF 비디오를 재생하는 화면

도 2 은 H.261 권고안의 QCIF 팩쳐 형식과 CIF 픽쳐 형식의 계층적 구조를 나타내는 그림

도 3 은 H.261 비디오 스트림의 구조

도 4 는 4개의 QCIF 픽쳐를 하나의 CIF 픽쳐로 합성하는 원리

도 5 는 QCIF, CIF, 그리고 새로 생성된 CIF 비디오 스트림의 구조를 나타내는 그림

도 6 은 4개의 QCIF 스트림을 하나의 CIF 스트림으로 변환하는 서버의 구조

H.261에서의 픽쳐 구조를 살펴보면 QCIF 형식의 경우 3개, CIF 형식의 경우 12개의 GOB(Group of Blocks)라는 단위로 이루어져있음을 볼 수 있다(도 2 참고). 하나의 GOB는 가로 176에 세로 48로 8448개의 픽셀에 대한 정보를 H.261 권고안의 이산여현변환(Discrete Cosine Transformation)을 통해 인코딩된 형태로 저장하고 있다. QCIF 픽쳐의 경우 CIF 픽쳐에 비해 해상도가 낮기 때문에 3개의 GOB만으로 모든 영상 정보를 나타내며 CIF 픽쳐의 경우 해상도가 높으므로 12개의 GOB를 사용한다. H.261 권고안에서 QCIF와 CIF의 차이가 오로지 한 픽쳐에 해당하는 GOB 수의 차이라는 점을 감안하면 서버에서 꼭 QCIF 스트림을 디코딩하여 원래 영상 정보를 복원한 후 다시 이들을 CIF 스트림으로 인코딩할 필요 없이 인코딩되어 있는 GOB 단위로 재배치하여 전송함으로써 4개의 QCIF 비디오 스트림을 하나의 CIF 스트림으로 합칠 수 있다. 이를 위해 서버에서는 입력으로 들어오는 4개의 QCIF 스트림을 각각 GOB 단위로 분리하고 임시로 저장하였다가 CIF 스트림에서의 GOB로 GOB 헤더를 변경하여 전송할 수 있다(도 4 참고).

앞에서 언급한 H.261 권고안의 특성을 이용해, 4개의 QCIF 스트림에서 각각 한 픽쳐에 해당하는 3개의 GOB를 분리해서 이 12개의 GOB를 CIF 픽쳐 형식에 맞게 재배치해 전송함으로써 H.261 인코딩/디코딩 과정을 거치지 않고도 서버에서 4개의 QCIF 스트림을 하나의 CIF 스트림으로 변경할 수 있다.

다음으로 해결한 문제는 여러 QCIF 스트림의 프레임율이 서로 다르고 또 일정하지 않은 경우이다. 비디오 서버에서 생성하는 CIF 픽쳐 형식의 스트림은 픽쳐 당 12개의 GOB가 요구된다. 그러나 각 QCIF 스트림의 프레임율은 일정하지 못하고 서로 다르다. 가장 프레임율이 높은 QCIF 스트림의 모든 프레임을 보내기 위해서는 CIF 스트림도 같은 율로 생성해야한다. 이때 다른 QCIF 스트림은 프레임율이 낮아 전송할 프레임이 없다면 하나의 완전한 CIF 스트림을 만들 수가 없다는 문제가 발생한다. 해결책 하나로 낮은 프레임율의 QCIF 스트림의 경우 전에 보낸 픽쳐를 한번 더 반복해서 전송하는 방법이 있을 수 있지만 프레임율은 수시로 변하기 때문에 이런 방식은 구현이 어렵고 또 반복해서 같은 픽쳐에 대한 정보를 여러번 보내게 되면 사용하는 대역폭이 쓸데없이 늘어난다는 문제가 있다. 이 프레임율 문제를 해결하기 위해 서버에서는 12개의 GOB를 모두 전송하지 않고 각 QCIF 스트림에서 한 픽쳐를 구성하는 3개의 GOB가 서버에 도착했을 때 각 GOB 헤더의 번호를 CIF 픽쳐에서의 GOB 위치에 따라 바꾸어주고 헤더를 CIF 형식으로 변환해 전송해준다. 현재 정보가 없는 9개의 GOB에 대해서는 GOB 헤더들만 전송하여 H.261 전용 하드웨어 디코더에서 올바른 H.261 권고안의 CIF 스트림으로 인식하게 한다. 도 5의 경우를 예로 들어 설명하면, 첫 스트림은 일반적인 QCIF 스트림을 보이고 있다. 이 스트림의 픽쳐 헤더에는 QCIF 형식이라고 표시되어 있고 이를 이어 3개의 GOB가 각각 GOB 헤더와 함께 전송된다. 각 GOB 헤더는 현재 GOB의 번호를 포함하고 있다. 두 번째 스트림은 일반적인 CIF 스트림으로 픽쳐 헤더에 CIF 형식이라고 표시되어 있고 다음에 12개의 GOB 헤더, GOB 데이터 쌍이 따른다. 가장 아래의 스트림은 한 QCIF 스트림을 CIF 스트림으로 변경한 스트림의 예인데 이 경우는 화면의 왼쪽 하단에 나타나는 경우이다. CIF 픽쳐에서 왼쪽 하단에 해당되는 GOB는 GOB 7, 9, 11번이므로 (도 2 참고) 원래 QCIF 픽쳐에서의 GOB 1, 3, 5번을 각각 7, 9, 11번으로 변경하고 해당사항이 없는 GOB의 자리에는 GOB 헤더만을 표시해 일반적인 CIF 형식을 유지한다.

앞에서 설명한 바와 같이 서버에서는 4개까지의 QCIF 스트림을 입력 받으며 각 QCIF 스트림에서 한 픽쳐에 해당하는 3개의 GOB를 모두 전송받은 후 이 3개의 GOB를 가지고 픽쳐 헤더를 CIF 형으로 변경해주고 GOB 헤더드을 최종 화면에서의 위치에 따라 변경하고 나머지 GOB의 자리에는 GOB 헤더들만을 전송한다. 이 새로운 CIF 스트림을 전송받는 참가자 컴퓨터에서는 정보가 있는 GOB에 대해서만 디코딩을 하여 화면에 재생을 해주고 이번 CIF 픽쳐에 GOB가 없는 부분에 대해서는 아무 작업을 하지 않고 이미 화면에 뿌려져있는 영상을 놔둠으로써 참가자 컴퓨터에서는 4개의 QCIF가 합성된 하나의 CIF 픽쳐를 볼 수 있게된다.

위에서 생성한 CIF 스트림은 각 픽쳐마다 3개만의 GOB 데이터가 있고 9개의 GOB에대해서는 GOB 헤더만이 있지만 H.261 권고안을 따르는 디코더는 없는 GOB에 대해서 오류가 있어서 재생을 안한다고 생각하고 이미 화면에 뿌려진 정보를 그대로 유지한다. 이렇게 생성한 스트림이 나다기연(주)의 화상회의 디코더 NDAV4와 스탠포드 대학의 PVRG64 소프트웨어 디코더에서 재생되는 것을 확인하였다. 또한 참가자의 수가 4명 이하인 경우에도 문제없이 작동하는 것을 확인할 수 있었다. 예를 들어 참가자가 3명인 경우 서버에서 생성되는 CIF 스트림을 재생하면 4개의 화면 중 한 화면에만 아무런 영상이 나오지 않고 나머지 3개의 화면은 정상적으로 재생된다.

마지막으로 도 6에서는 위의 기능을 수행하는 서버의 구조를 보이고 있다. 4개의 소켓으로 각각 하나의 QCIF 스트림을 입력 받아 병렬로 각 QCIF 스트림에서 한 픽쳐에 해당하는 3개의 GOB를 받은 다음 이 3개의 GOB를 재생될 화면에서의 위치에 따라 적절하게 GOB 헤더들을 추가하고 픽쳐 헤더를 CIF 형식으로 바꾸어 각 참가자들에게 전송을 해준다.

본 발명에서 설계하고 구현한 비디오 서버를 사용함으로써 화상회의를 할때 4명까지 참가자의 비디오를 모든 참가자의 컴퓨터에서 H.261 전용 하드웨어 디코더를 통해 원활히 재생할 수 있다. 본 발명을 통해 랜이나 케이블 TV망 같은 고속 데이터 전송망과 저렴한 H.261 전용 하드웨어 디코더를 사용해 일반 컴퓨터에서도 원활한 다자간 화상회의를 할 수 있을 것으로 예상한다.

Claims (2)

1. 4개의 H.261 QCIF 픽쳐를 서버에서 인코딩 및 디코딩을 하지 않고 하나의 CIF 픽쳐로 합성하는 방식.
2. 서버에서 각각의 QCIF 스트림에서의 픽쳐 헤더를 CIF로 변경한 후 QCIF 스트림의 GOB 헤더를 재생될 화면의 위치에 따라 변경하고 나머지 GOB 자리에는 GOB 헤더만을 포함시켜 CIF 픽쳐를 생성하는 방법.