KR101676792B1

KR101676792B1 - 데이터를 효율적으로 임베디드 압축 하기 위한 방법, 장치 및 컴퓨터 판독 가능한 기록 매체

Info

Publication number: KR101676792B1
Application number: KR1020150077484A
Authority: KR
Inventors: 박찬식; 김재문
Original assignee: 삼성전자주식회사
Priority date: 2015-06-01
Filing date: 2015-06-01
Publication date: 2016-11-16
Also published as: CN107667529A; EP3273690A1; WO2016195378A1; EP3273690A4; US20180167614A1; US10567762B2; CN107667529B

Abstract

본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축하는 방법은, 디코딩된 영상 데이터를 입력받는 단계, 상기 입력된 영상 데이터 중, 임베디드 압축할 영상 데이터의 블록 사이즈를 판단하는 단계 및 상기 판단된 블록 사이즈와, 임베디드 압축하기 위한 EC 블록 사이즈를 비교하는 단계,를 포함하고 상기 판단된 블록 사이즈가 상기 EC 블록 사이즈보다 크거나 같은 경우, 상기 입력된 영상 데이터를 임베디드 압축하는 단계를 더 포함하고, 상기 판단된 블록 사이즈가 상기 EC 블록 사이즈보다 작은 경우, 상기 입력된 영상 데이터에 대한 태그 정보를 저장하는 단계를 더 포함한다

Description

데이터를 효율적으로 임베디드 압축 하기 위한 방법, 장치 및 컴퓨터 판독 가능한 기록 매체{METHOD, APPARATUS AND COMPUTER READABLE MEDIUM FOR EFFECTIVE EMBEDDED COMPRESSION}

본 발명은 비디오 영상의 처리에 있어, 메모리 용량 및 대역폭 문제를 해결하기 위한 데이터 처리 방법인 임베디드 압축 방법에 대한 것으로, 보다 상세하게는, 기본 디코딩 된 데이터가 임베디드 블록 사이즈를 만족시키지 못하라 경우 보다 효율적으로 임베디드 압축을 수행하기 위한 방법, 장치 및 기록매체에 관한 것이다.

비디오 데이터를 처리하는 시스템은 고대역폭의 메모리 및 내부 통신 아키텍처(시스템 BUS등)를 필요로 한다. 이와 같은 과도한 메모리 접근 및 대역폭 요구는 시스템 성능을 열화시키고 전력을 소모시키는 주요 원인이 되고 있다.

이와 같은 프레임 메모리 용량 및 대역폭 문제를 해결하기 위해 다양한 기술이 적용되고 있는데, 그 중 임베디드 압축(Embedded Compression) 방법이 있다. 임베디드 압축 방법은 메모리로 저장 되는 데이터를 다시 압축하여 저장하고 그 데이터를 불러올 때 다시 압축을 풀어서 사용하는 방법이다.

그러나, 임베디드 압축을 위한 재료에 해당하는 디코딩 된 데이터가 임베디드 압축 블록 사이즈보다 작은 경우가 발생할 수 있다. 이러한 경우 임베디드 압축 블록 사이즈를 만족시킬 수 있는 충분한 양의 디코딩 된 데이터가 준비된 후 임베디드 압축을 수행하기 위해서는, 추후 임베디드 압축을 수행하기 위해서 기 수신된 디코딩 된 데이터를 메모리에 저장해 놓았다가 추가적인 디코딩 된 데이터가 수신되어 임베디드 압축이 가능한 상태가 되면 메모리로부터 저장된 데이터를 불러온다.

이와 같은 동작은 임베디드 압축을 위해 점유해야 하는 BUS 대역폭을 증가시키며 영상 시스템의 전체적인 성능을 저하시키는 요인이 될 수 있다.

본 발명은 전술한 종래 기술의 문제점을 해결하며, 디코딩 된 데이터의 사이즈가 임베디드 압축 블록 사이즈보다 작은 경우 보다 효율적으로 임베디드 압축을 수행할 수 있도록 하는 것을 그 목적으로 한다.

본 발명은 디코딩 된 데이터의 사이즈가 임베디드 압축 블록 사이즈보다 작은 경우가 발생하지 않도록 임베디드 압축 블록 사이즈를 결정하는 것을 다른 목적으로 한다.

상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 방법은, 디코딩된 영상 데이터를 입력받는 단계, 입력된 영상 데이터 중, 임베디드 압축할 영상 데이터의 블록 사이즈를 판단하는 단계 및 판단된 블록 사이즈와, 임베디드 압축하기 위한 EC 블록 사이즈를 비교하는 단계를 포함하고 판단된 블록 사이즈가 EC 블록 사이즈보다 크거나 같은 경우, 입력된 영상 데이터를 임베디드 압축하는 단계를 더 포함하고, 판단된 블록 사이즈가 EC 블록 사이즈보다 작은 경우, 입력된 영상 데이터에 대한 태그 정보를 저장하는 단계를 더 포함한다.

본 발명의 또 다른 실시예에 따르면, 판단된 블록 사이즈가 EC 블록 사이즈보다 작은 경우, 임베디드 압축할 영상 데이터를 저장하는 단계; 및 임베디드 압축 할 디코딩 된 추가 영상 데이터가 입력되면, 태그 정보에 기초하여 추가 영상 데이터를 저장하는 단계를 더 포함한다.

본 발명의 또 다른 실시예에 따르면, 태그 정보는, 코덱의 IP 코어(Intellectual Property core)로부터 수신되는 것을 특징으로 한다.

본 발명의 또 다른 실시예에 따르면, 태그 정보는, 디코딩 된 영상 데이터가 비압축 (non-compressed)인 것을 나타내는 것을 특징으로 한다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 방법은, 디코딩 된 영상 데이터를 입력받는 단계, 입력된 영상 데이터 중 임베디드 압축할 영상 데이터의 블록 사이즈를 판단하는 단계 및 판단된 블록 사이즈와, 임베디드 압축하기 위한 제 1 EC 블록 사이즈를 비교하는 단계를 포함하고, 판단된 블록 사이즈가 제 1 EC 블록 사이즈보다 크거나 같은 경우, 입력된 영상 데이터를 임베디드 압축하는 단계를 더 포함하고, 판단된 블록 사이즈가 제 1 EC 블록 사이즈보다 작은 경우, 임베디드 압축할 영상 데이터를, 판단된 블록 사이즈에 따라 결정되는, 제 2 EC 블록 사이즈로 임베디드 압축하는 단계 및 임베디드 압축된 영상 데이터 및 임베디드 압축된 데이터에 대한 태그 정보를 저장하는 단계를 더 포함한다.

본 발명의 또 다른 실시예에 따르면, 제 2 EC 블록 사이즈는, 입력된 영상 데이터의 세로 블록 사이즈에 기초하여 결정되는 것을 특징으로 한다.

본 발명의 또 다른 실시예에 따르면, 제 2 EC 블록 사이즈의 세로 블록 사이즈는, 입력된 영상 데이터가 가질 수 있는 세로 블록 사이즈들의 최대공약수인 것을 특징으로 한다.

본 발명의 또 다른 실시예에 따르면, 상기 태그 정보는, 압축되는 것을 특징으로 한다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 장치는 디코딩된 영상 데이터를 입력받는 입력부, 입력된 영상 데이터 중, 임베디드 압축할 영상 데이터의 블록 사이즈를 판단하고, 판단된 블록 사이즈와, 임베디드 압축하기 위한 EC 블록 사이즈를 비교하는 제어부 및 판단된 블록 사이즈가 EC 블록 사이즈보다 크거나 같은 경우, 입력된 영상 데이터를 임베디드 압축하고, 판단된 블록 사이즈가 EC 블록 사이즈보다 작은 경우, 입력된 영상 데이터에 대한 태그 정보를 저장하는 임베디드 압축부;를 포함하는, 영상 데이터를 임베디드 압축하는 장치.

본 발명의 또 다른 실시예에 따르면, 판단된 블록 사이즈가 EC 블록 사이즈보다 작은 경우, 임베디드 압축할 영상 데이터를 저장하고, 임베디드 압축 할 디코딩 된 추가 영상 데이터가 입력되면, 태그 정보에 기초하여 추가 영상 데이터를 저장하는 저장부를 더 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 장치는 디코딩 된 영상 데이터를 입력받는 입력부 및 입력된 영상 데이터 중 임베디드 압축할 영상 데이터의 블록 사이즈를 판단하고, 판단된 블록 사이즈와 임베디드 압축하기 위한 제 1 EC 블록 사이즈를 비교하는 제어부를 포함하고 판단된 블록 사이즈가 제 1 EC 블록 사이즈보다 크거나 같은 경우, 입력된 영상 데이터를 임베디드 압축하고, 판단된 블록 사이즈가 제 1 EC 블록 사이즈보다 작은 경우, 임베디드 압축할 영상 데이터를, 판단된 블록 사이즈에 따라 결정되는, 제 2 EC 블록 사이즈로 임베디드 압축하는 임베디드 압축부 및 임베디드 압축된 영상 데이터 및 임베디드 압축된 데이터에 대한 태그 정보를 저장하는 저장부를 포함한다.

본 발명의 또 다른 실시예에 따르면, 제 2 EC 블록 사이즈는 입력된 영상 데이터의 세로 블록 사이즈에 기초하여 결정되는 것을 특징으로 한다.

본 발명의 또 다른 실시예에 따르면, 제 2 EC 블록 사이즈의 세로 블록 사이즈는 입력된 영상 데이터가 가질 수 있는 세로 블록 사이즈들의 최대공약수인 것을 특징으로 한다.

한편, 본 발명의 일 실시예에 따르면, 전술한 방법을 실행하기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.

이 외에도, 본 발명을 구현하기 위한 다른 방법, 다른 시스템 및 상기 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공된다.

본 발명에 의하면, 디코딩 된 데이터의 사이즈가 임베디드 압축 블록 사이즈보다 작은 경우 보다 효율적으로 임베디드 압축을 수행하고, 디코딩 된 데이터의 사이즈가 임베디드 압축 블록 사이즈보다 작은 경우가 발생하지 않도록 임베디드 압축 블록 사이즈를 결정할 수 있다.

도 1 은 비디오 코덱을 이용하여 영상 데이터를 처리하는 시스템을 개략적으로 도시한다.
도 2 는 임베디드 압축 엔진을 포함하는, 비디오 코덱을 이용하여 영상 데이터를 처리하는 시스템을 개략적으로 도시한다.
도 3 은 도 2 의 시스템에서, 임베디드 압축 엔진, 디코더 및 메모리의 세부 블록도를 도시한다.
도 4 는 화면 내 예측 부호화를 설명하기 위한 도면이다.
도 5 는 인-루프(in-loop) 필터 방식이 적용된 디코더의 블록 다이어그램을 도시한다.
도 6 은 HEC의 디블록킹 필터의 에지 필터링 방법에 대한 순서도이다.
도 7 은 하나의 CTU 내에서 필터링이 적용될 수평 에지 경계의 예를 도시한 도면이다.
도 8 은 하나의 픽쳐 내에서 각 블록들의 크기 및 필터링 된 데이터가 탑-다운(top-down) 처리 방식에 의해 임베디드 압축되는 순서를 나타낸 도면이다.
도 9 는 임베디드 압축을 위한 디코딩 된 데이터 사이즈가 임베디드 압축 사이즈보다 작은 경우의 처리 방법을 나타내는 도면이다.
도 10 은 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.
도 11 은 본 발명의 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.
도 12 는 본 발명의 일 실시에에 다른 임베디드압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.
도 13 은 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.
도 14 는 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.
도 15 는 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.
도 16 은 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법을 도시한다.
도 17 은 본 발명의 일 실시예에 따른 임베디드 압축 장치의 세부 구성도이다.

후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다.

이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.

도 1 은 비디오 코덱을 이용하여 영상 데이터를 처리하는 시스템을 개략적으로 도시한다.

코덱은 부호화기(인코더)와 복호화기(디코더)를 통칭하며, 영상 데이터는 송신 장치의 인코더(encoder, 500)에서 인코딩되어 유무선 통신망(400)을 통해 수신장치로 전송된다. 입력된 영상 데이터는 변 환, 양자화 및 엔트로피 코딩 과정을 통해 인코딩되며, 엔트로피 코딩을 통해 생성된 인코더(500)의 최종 출력 데이터는 비트스트림의 형태가 된다.

통신망(400)은 송신 장치의 인코더(500)와 수신 장치의 디코더(200)를 연결하는 역할을 수행한다. 즉, 통신망(400)은 데이터를 송수신할 수 있도록 접속 경로를 제공하는 통신망을 의미한다. 즉, 본 발명의 일 실시예에 따른 통신망(400)은 유선 통신이나 무선 통신과 같은 통신 양태를 가리지 않고 구성될 수 있으며, 근거리 통신망(LAN; Local Area Network), 도시권 통신망(MAN; Metropolitan Area Network), 광역 통신망(WAN; Wide Area Network) 등 다양한 통신망으로 구성될 수 있다. 바람직하게는, 본 명세서에서 말하는 통신망(400)은 공지의 인터넷 또는 월드와이드웹(WWW; World Wide Web)일 수 있다. 그러나, 통신망(400)은, 굳이 이에 국한될 필요 없이, 공지의 유무선 데이터 통신망, 공지의 전화망 또는 공지의 유무선 텔레비전 통신망을 그 적어도 일부에 있어서 포함할 수도 있다.

수신 장치의 디코더 (decoder, 200)는 인코딩된 영상 데이터의 비트스트림이 수신되면 수신된 비트스트림을 엔트로피 디코딩하고, 역양자화 및 역변환(미도시)하여 영상을 복원한다. 이와 같은 복원 영상(reconstructed image)은 추가적으로 필터링 과정을 거치게 되는데, 이와 같은 필터링을 거치면 영상의 주관적 화질이 향상되는 효과가 있다.

필터링 된 복원 영상은 DPB(Decoded Picture Buffre, 미도시)에 필터 단위로 저장되며, 이후 디코딩 될 영상의 움직임 예측 과정에서 DPB에 저장된 픽처를 참조한다.

디스플레이(600)는 DPB에 저장된 디코딩 된 픽쳐(decoded picture)를 디스플레이 한다.

한편, 디스플레이는 영상 데이터를 수신하는 재생 장치의 디스플레이부를 포함하며, 디스플레이는 저해상도 소형 화면에서 고해상도 대형 화면으로 발전하고 있으며, 이에 따라 인코더 및 디코더에서 처리해야 하는 영상 데이터의 양이 증가하고 있다.

따라서 HEVC (High Efficiency Video Coding)이나 AVS (Audio Video coding Standard) 등 새로 제정되는 표준 코덱은 이전의 H.264/AVC (Advanced Video Coding) 등에 비해 좋은 압축 성능을 목표로 하고 있다. 실제로 HEVC는 H.264/AVC에 비해 동일 비트율에서 약 두 배의 주관적 코딩효율을 가지는 것으로 알려져 있다.

HEVC 개발의 주요 목표 중 하나는 UHD (Ultra High Definition)급 영상을 효율적으로 인코딩하는 것이다. 이를 위해 예측, 양자화, 그리고 변환을 수행하는 화소 범위의 최대 크기가 H.264/AVC에서는 16x16 사이즈 블록이었으나 HEVC에서는 64x64 사이즈 블록으로 증가하였고, 관련 코딩 도구들의 알고리즘 역시 고해상도 영상에서 좋은 코딩효율을 달성하도록 설계되었다.

UHD와 같은 고화질의 영상의 처리를 위한 입력 영상의 데이터 양 뿐만 아니라, 인코딩 및 디코딩을 위한 참조 영상의 데이터 양 역시 증가한다. 비디오 영상 압축을 위한 하드웨어 구조는 일반적으로 입력 영상과 참조 영상들을 저장하기 위해 외부에 공유 가능한 프레임 메모리를 사용하는데, UHD와 같은 고해상도 비디오의 디코딩은 많은 양의 메모리 접근을 발생시킨다.

디코딩 시스템은 고대역폭의 메모리 및 내부 통신 아키텍처(시스템 BUS등)를 필요로 한다. 이와 같은 과도한 메모리 접근 및 대역폭 요구는 시스템 성능을 열화시키고 전력을 소모시키는 주요 원인이 되고 있다.

도 2 는 임베디드 압축 엔진을 포함하는, 비디오 코덱을 이용하여 영상 데이터를 처리하는 시스템을 개략적으로 도시한다.

도 2 의 시스템은 도 1 의 시스템과 전체적으로 유사하나, 도 1 의 시스템과는 달리 비트스트림을 디코딩하고 디코딩 된 픽쳐를 디스플레이하는 단계 사이에 임베디드 압축을 수행한다는 차이가 있다.

영상 데이터는 송신 장치의 인코더(encoder, 500)에서 인코딩되어 유무선 통신망(400)을 통해 수신장치로 전송된다. 입력된 영상 데이터는 변 환, 양자화 및 엔트로피 코딩 과정을 통해 인코딩되며, 엔트로피 코딩을 통해 생성된 인코더(500)의 최종 출력 데이터는 비트스트림의 형태가 된다.

통신망(400)은 송신 장치의 인코더(500)와 수신 장치의 디코더(200)를 연결하는 역할을 수행하며, 전용선, LAN, VAN, 인트라넷, 사설 전화망, 공중 전화망, PSTN 망 및 이들의 상호 조합을 포함하며, 도 1 에 도시된 각 네트워크 구성 주체가 서로 원활하게 통신을 할 수 있도록 하는 포괄적인 의미의 데이터 통신망으로, 유선 인터넷, 무선 인터넷 및 모바일 무선 통신망을 포함한다.

수신 장치의 디코더(200)는 인코딩된 영상 데이터의 비트스트림이 수신되면 수신된 비트스트림을 엔트로피 디코딩하고, 역양자화 및 역변환(미도시)하여 영상을 복원한다. 복원 영상은 추가적으로 필터링 과정을 거치게 되며 필터에서 출력된 디코딩 된 픽쳐는 임베디드 압축 엔진(100)으로 전송된다.

임베디드 압축 엔진(100)은 디코딩 된 픽쳐를 블록 단위로 임베디드 압축하여 메모리(미도시)에 저장하고, 디코더(200) 또는 디스플레이(600)의 요청이 있는 경우 압축된 블록 데이터를 풀어 디코더(200) 또는 디스플레이(600)로 전달한다.

디스플레이(600)는 임베디드 압축 엔진(100) 또는 디코더(200)로부터 수신된 영상 신호를 스크린 등을 통해 디스플레이 한다.

임베디드 압축 엔진의 입력 신호는 디코더의 최종 처리 단계인 아웃풋 필터의 출력으로, 비디오 코덱 특성상 아웃풋 필터는 주변 블록의 경계값을 이용해 데이터를 처리하므로 임베디드 압축 역시 블록 싱크를 맞춰 진행할 수 없고 블록간에 걸쳐 임베디드 압축을 진행하게 된다.

한편, 임베디드 압축에는 손실 압축(lossy compression)과 무손실 압축(lossless compression)이 있다.

이 중 손실 압축은 압축률이 고정되므로 압축된 데이터의 크기가 일정하고, 외부 메모리의 접근 횟수뿐만 아니라 사용하는 메모리의 크기도 줄일 수 있다. 손실 압축의 경우에는 일정한 메모리 대역을 보장할 수 있는 반면, 영상의 손실을 발생시킨다. 더욱이 참조 영상으로 사용할 프레임이 손실되므로, 영상이 인코딩 될수록 에러가 확산되어 그 손실은 더욱 심각해지는 문제가 있다.

반면 무손실 압축은 저장해야 하는 참조 영상의 손실은 없는데 반해, 압축된 데이터의 크기가 일정하지 않은 가변 압축 방식이므로 일정한 메모리 대역을 가질 수 없어서 별도의 태그 정보를 이용해야 한다. 무손실 압축의 가변 압축 성질에 의해, 무손실 압축을 사용할 경우 외부 메모리의 대역폭은 줄어들 수 있으나 사용하는 메모리의 크기는 줄어들지 않는다.

현재 일반적으로 사용하는 임베디드 압축의 압축율은 약 2:1 내지 4:1 로 블록 단위 압축을 수행한다.

도 3 은 도 2 의 시스템에서, 임베디드 압축 엔진(100), 디코더(200) 및 메모리(300)의 세부 블록도를 도시한다.

도 3 의 디코더(200)는, HEVC 디코더인 경우를 가정하며 메인 프로파일에 포함된 핵심 부호화 기술들을 포함하고 있다. HEVC 는 이전의 압축 표준들과 같이 블록 단위의 부호화를 수행하며, 블록 단위의 예측 신호를 만들기 위해 H.264/AVC와 유사한 화면 내 예측 및 움직임 예측 기술이 이용된다.

HEVC의 인코더에서 예측한 영상이 블록 단위로 양자화되어 손실된 화소 값으로 인하여 블록화 현상이 발생한다. 블록화 현상을 줄이기 위해 HEVC에서는 H.264/AVC의 후처리 필터인 디블록킹 필터(deblocking filter)에, 추가적으로 샘플 적응적 오프셋(Sample Adaptive Offset, SAO), 적응적 루프 필터 기술(ALF, Adaptive Loop Filter)을 사용함으로서 화질이 개선되고 부호화 효율이 향상된다.

HEVC는 H.264/AVC 하이 프로파일 대비 약 43%의 비트 감소를 보이지만, 움직임 보상(Motion Compenstaion, MC)과정에서 8-탭 필터, 디블록킹 필터, 샘플 적응적 오프셋, 적응적 루프 필터 등 후처리 필터의 사용으로 인해 복호화기의 계산량이 증가된다.

앞서 언급한 바와 같이 인코더의 최종 출력 데이터의 형태는 비트스트림이므로, 디코더의 입력 역시 비트스트림이 된다. 디코더(200)의 아웃풋 필터를 통과한 디코딩 된 영상 데이터는, 시스템 버스(901)를 통해 EC 엔진(100)으로 전달되며, EC 엔진(100)에서 M x N 블록 사이즈로 임베디드 압축된다.

도 3 의 임베디드 압축 엔진(100)은 하드웨어로 구현되거나 또는 소프트웨어를 통해 구현될 수 있으며, 또한 임베디드 압축 엔진(100)은 디코더(200)에 포함된 형태로 구현될 수도 있다.

EC 엔진(100)에서 M x N 블록 사이즈로 임베디드 압축된 영상 데이터는 다시 시스템 버스(902)를 통해 메모리(300)로 전달된다.

메모리로 전달된 임베디드 압축된 영상 데이터는 DPB(Decoded Picture Buffer)로 저장되며, 이 때 메모리(300)가 DDR RAM(Double Data Rate Random Access Memory)라면 랜덤 액세스(random access)가 보장될 수 있다.

임베디드 압축의 경우, 압축 효율을 위해 주로 M x N 블록 단위의 압축을 진행하며, M x N 블록 단위로 압축 후 그 결과의 비트양(데이터양)는 손실, 무손실 임베디드 압축 여부에 따라 고정 혹은 가변적이다.

손실 임베디드 압축의 압축률이 고정이라면 각 M x N 블록 단위로 압축된 비트량을 따?? 보낼 필요가 없으며, “M x N 임베디드 압축 결과 비트양 = M x N x bit-depth x 압축률”이 된다.

반면, 무손실 임베디드 압축의 경우라면 임베디드 압축의 결과 비트양은 가변 길이를 갖게 되며 따라서 각 M x N 블록 사이즈의 임베디드 압축 결과에 대한 태그(tag) 정보를 따로 관리해야 한다. 이러한 태그 정보는 임베디드 압축된 데이터와 같은 영역에 저장되거나 혹은 태그 정보만을 위한 독립적인 영역에 저장되어 고정된 태그 비트로 관리된다. 따라서, 임베디드 압축된 데이터를 읽을 때는, 태그 정보로부터 먼저 비트량 정보를 읽은 뒤 해당 비트량만큼을 읽게 된다.

일반적으로 태그 정보에 대해서는 별도의 압축을 수행하지 않지만, 영상의 데이터 사이즈가 큰 경우에는 관리해야 하는 태그 정보의 양이 늘어나기 때문에 필요에 따라 태그 정보 역시 압축되어 저장될 수 있다. 압축되어 저장된 태그 정보는, 임베디드 압축된 데이터를 읽기 위해 저장된 태그 정보를 호출할 때 압축을 푸는 과정이 추가된다.

실험에 의하면 임베디드 압축 방법을 사용한 경우 움직임 보상 및 복원(reconstruction) 비율이 임베디드 압축을 사용하지 않은 경우에 비해 AVS 2.0 디코더에서 66%로 낮아짐이 확인된 바 있다.

도 4 는 화면 내 예측 부호화를 설명하기 위한 도면이다.

도 4 는 인코더에서 화면 간 예측 부호화를 수행하기 위해 다른 블록의 데이터를 이용하는 특징을 나타내고 있으며, 그 결과 디코더의 필터는 블록간에 걸쳐 필터링을 수행하게 된다.

HEVC를 예로 들어 설명하면, 동영상은 시간에 따른 정지영상의 집합으로 구성되며 인코더에서는 한 장의 정지 영상 단위로 영상 데이터를 입력받고 처리하는데, 입력된 정지 영상은 블록 단위로 분할된다. 이 때 분할된 블록이 CTU(Coding Tree Unit)로 인코딩의 기본 단위가 되며 인코더는 분할 된 각 CTU에 대해서 순차적으로 인코딩을 수행한다.

HEVC 인코더는 각 CTU를 보다 효과적으로 인코딩하기 위해 CU(Coding Unit)로 분할하여 인코딩할 수 있다. 이 때, 각 CU 내에서 보다 정확한 예측을 위해서 CU를 다시 PU(Prediction Unit)로 나눌 수 있다. 각각의 이름에서 알 수 있듯이 CU는 코딩이 수행되는 블록의 단위이며 PU는 예측을 수행하는 블록의 단위이다.

HEVC 코덱은 화면 간 예측과 화면 내 예측의 두가지 모드를 이용하며, 화면 간 예측 부호화는 공간적 중복성을 제거하여 데이터의 양을 줄이는 압축 방법이다. 영상 내에서 공간적으로 가까운 거리의 화소값들 간에는 큰 유사성을 가지므로 현재 부호화를 진행하려고 하는 블록의 주변에 이미 재구성 되어 있는 샘플들을 참조하여 현재 블록을 공간적으로 예측하는 것이다.

화면 내 예측에서 말하는 주변의 참조 샘플은 원 영상의 픽셀 값이 아닌 예측과 복원으로 재구성된 픽셀 값으로 후처리 필터링이 적용되기 이전의 값이며, 부호화 및 복원된 값이므로 부호화기 및 복호화기의 참조 샘플로 사용될 수 있다.

도 4 는 하나의 픽쳐를 일정한 크기의 CTU로 나눈 모습이다. 이렇게 나누어진 CTU들은 좌측 상단부터 우측 하단까지 순서대로 부호화가 진행된다. 부호화가 끝난 CTU는 재구성되어 부호화기 및 복호화기에서 같은 방식으로 DPB에 저장되며, 이후 다음 CTU를 부호화할 때 참조된다.

예를 들어, 도 4 는 8번째 CTU를 부호화할 때의 참조 구조 및 DPB의 상태를 나타낸다. 어둡게 표시한 곳은 아직 부호화가 진행되지 않은 곳을 의미하며, 밝은 부분은 부호화가 진행되어 재구성된 CTU들이 DPB에 저장된 모습을 나타낸다. 8번째 CTU에 대한 화면 내 예측은 점선으로 표시된 부분을 참조하여, CTU에 대한 화면 내 예측을 수행한다. 즉, CTU3, CTU4, CTU7 및 CTU12의 경계값들을 참조 샘플로 이용하는 것이다.

도 4 와 같은 경우, CTU3, CTU4 및 CTU7는 부호화가 진행되어 재구성된 CTU이므로 그 값들을 참조 샘플로 이용할 수 있지만, CTU12의 경우 아직 부호화가 진행되지 않았으므로 참조 샘플이 없다. 이와 같이 참조 샘플이 없는 경우라면, 패딩을 통해 참조 샘플을 채운다.

하나의 CTU는 여러 개의 CU로, 하나의 CU는 다시 여러 개의 PU로 분할될 수 있으며, 구체적인 화면 내 예측 방법 및 방향은 각 PU의 예측 모드 및 각 CU의 모드에 따라 달라질 수 있으나 자세한 설명은 생략한다.

이와 같이 위의 블록의 데이터 처리를 위해 아래 블록의 데이터를 이용하는 비디오 코덱 인코더 특성에 의해 디코더의 필터는 블록간에 걸쳐 필터링을 수행하게 된다.

도 5 는 인-루프(in-loop) 필터 방식이 적용된 디코더의 블록 다이어그램을 도시한다.

역변환 과정을 거친 복원 픽쳐는 양자화 에러로 인해 블록킹 열화(blocking artifact) 및 링잉(ringing) 현상이 발생될 수 있으며, 이로 인해 복원된 영상의 주관적 화질이 저하되는 문제가 발생한다. 이러한 주관적 화질 저하 문제는 양자화를 사용하는 모든 비디오 코덱에서 발생되는 문제로 이를 개선하기 위한 다양한 알고리즘들이 개발되어 왔으며, 대표적으로 복원된 픽쳐에 필터링을 수행함으로써 주관적 화질을 향상시키는 방법이 있다.

이러한 필터링 방식은 필터링 된 픽쳐를 화면간 예측 모드에서 참조 픽쳐로 사용하는지 여부에 따라 후처리 필터 방식과 도 5 의 인-루프(in-loop) 필터 방식으로 나뉜다.

후처리 필터 방식이란, 디코더에서 출력된 복원 픽쳐에 필터링을 수행한 후 필터링 된 픽쳐를 디스플레이 하는 방식이다. 이와 같은 후처리 필터 방식은 디코더 외부에서 별도로 필터링이 수행되며 단지 비디오 디코더의 출력물인 복원 영상에 대해서 디스플레이 직전에 필터링을 수행하는 것이다.

이와 달리 도 5 와 같은 인-루프 필터 방식은 필터링 기술 자체가 표준으로 디코더 내에 포함되어 있다. 특히 인-루프 필터 방식은 복원된 필쳐에 필터링을 적용한 후, 이를 출력할 뿐 아니라 DPB에도 삽입함으로써 화면 간 예측 모드에서 필터링 된 픽쳐가 참조 픽쳐로 사용될 수 있도록 한다.

이와 같이 필터링이 적용된 픽쳐를 화면 간 예측 모드에서 참조 픽쳐로 사용하기 때문에 필터링에 의한 주관적 화질 뿐만 아니라 화면 간 예측 모드에서 부호화 효율도 향상된다. 이는 블록킹 열화나 링잉 현상이 있는 복원 픽쳐를 참조 픽쳐로 사용하는 경우보다 필터링이 적용된 픽쳐를 참조 픽쳐로 사용할 때, 좀 더 정확한 움직임 예측 및 보상이 가능하기 때문이다.

그러나 인-루프 필터링 방식은 주관적 화질과 부호화 효율을 향상시키는 장점을 갖지만, 인코더와 디코더의 복원 픽쳐에 필터링을 수행하는 과정에서 추가적인 계산을 요구한다. 특히, 디블록킹 필터는 필터링을 수행할 때 메모리에 저장되어 있는 복원된 픽셀들을 로드한 후 필터링을 수행하고 필터링이 수행된 픽셀을 다시 메모리에 저장하므로 잦은 메모리 접근을 야기한다.

또한, 디블록킹 필터는 필터링 연산 과정 자체도 복잡하여 이러한 연산 복잡도 및 메모리 접근에 대한 오버헤드로 인해 디코더에서 높은 복잡도를 갖는다.

HEVC에서는 양자화 에러로 인한 화질 열화 문제를 해결하기 위하여 디블록킹 필터, SAO (Sample Adaptive Offset Filter)의 두 가지 인-루프 필터를 사용한다.

도 5 에서 디블록킹 필터는 복원된 픽쳐에서 블록킹 열화를 제거하기 위해 사용되고, SAO는 링잉 현상을 제거하기 위하여 사용된다. 두 종류의 인-루프 필터 중 디블록킹 필터가 먼저 복원 픽쳐에 적용되고, 디블록킹 필터가 적용된 픽쳐에 다시 SAO가 적용된다.

도 6 은 HEC의 디블록킹 필터의 에지 필터링 방법에 대한 순서도이다.

HEVC는 블록 단위로 예측, 변환 및 양자화를 수행하므로 블록 경계에서 복원 픽셀 값의 불연속이 발생할 수 있다. 따라서 블록 경계에서 발생하는 블록킹 열화를 제거하기 위해서는 기본적으로 모든 PU 또는 TU의 블록 경계에 대해서 필터링을 수행해야 한다. 하지만, HEVC는 디블록킹 필터링의 연산 복잡도를 고려하여 8 x 8 블록 경계에 위치하는 PU 또는 TU의 경계에서만 필터링을 수행한다.

블록킹 열화는 수직 에지와 수평 에지 모두에서 발생되며 이러한 복원 픽셀의 불연속을 제거하기 위해서는 픽쳐 내의 수직 에지와 수평 에지 각 방향에 대해서 필터링을 수행해야 한다. H.264/AVC는 매크로블록 단위로 먼저 수직 에지들에 대해 수평 방향으로 필터링(610)을 수행한 후 수평 에지에 대해 수직 방향으로 필터링(630)을 수행하였다.

이와 달리 HEVC 디블록킹 필터는 도 6 과 같이 현재 복원하는 픽쳐의 모든 블록 경계 중 먼저 수직 에지에 대해서 수평 방향으로 필터링을 수행하고 그 다음 수평 에지에 대해 수직 방향으로 필터링을 수행한다.

이와 같은 필터링 구조는 디블록킹 필터의 병렬처리를 쉽게 한다는 장점을 갖는다.

도 7 은 하나의 CTU 내에서 필터링이 적용될 수평 에지 경계의 예를 도시한 도면이다.

도 7 은 32 x 32 CTU가 네 개의 16 x 16 CU로 분할되어 코딩 된 경우에 HEVC 디블록킹 필터링이 수행될 수평 에지 경계의 위치에 대해서 나타낸 것이다.

도 7 에서 CU#1은 16 x 16 CU가 16 x 16 PU와 16 x 16 TU로 분할된 경우의 예로, CU 내부는 PU와 TU의 경계가 존재하지 않는다. 따라서 CU#1의 위쪽 수평 에지 경계에서만 필터링이 수행된다. 여기서, CU의 경계는 PU와 TU의 경계이면서 8 x 8 블록 경계 위에 위치하므로 항상 필터링이 수행된다.

CU#2는 16 x 16 CU가 8 x 16 크기의 두 개의 PU로 분할되었고, 쿼드-트리 형태의 4 x 4 TU로 분할된 경우에 대한 예이다. 이 경우 PU 또는 TU의 최소 경계는 4 x 4 블록 단위로 존재하지만, 앞서 언급한 것처럼 HEVC의 디블록킹 필터는 8 x 8 블록 경계 위의 PU 또는 TU에만 필터링을 수행하므로 도 7 의 CU#2에서 굵은 선으로 표시된 부분만이 필터링이 수행될 수평 에지 경계에 해당한다.

CU#3과 CU#4도 마찬가지로, 동일한 방식으로 필터링이 적용될 에지 경계가 선택된다.

도 7 에서 알 수 있는 바와 같이, 하나의 CTU에 필터링을 수행할 때 제일 하단의 에지에 대해서는 필터링이 수행되지 않는다. 하나의 CTU를 기준으로 제일 하단의 에지는 아래쪽 CTU의 제일 상단의 에지 경계가 필터링될 때 함께 필터링 되기 때문이다.

도 7 은 CTU 내에서 수평 에지에 대해서만 설명했지만, 수직 에지에 대해서도 동일하게 8 x 8 블록 경계에 위치하는 PU 경계와 TU 가 필터링을 수행할 경계로 결정된다. 또한 수평 에지와 마찬가지로 하나의 CTU에 필터링을 수행할 때 제일 우측의 에지에 대해서는 필터링이 수행되지 않는다. 하나의 CTU를 기준으로 제일 우측의 에지는 오른쪽 CTU의 제일 좌측의 에지 경계가 필터링 될 때 함께 필터링 되기 때문이다.

HEVC와 같은 비디오 코덱에서는 에지 경계를 처리하기 위해 인접 블록의 데이터가 필요하기 때문에, 우측 에지 경계를 필터링 하기 위해서는 우측 인접 블록의 데이터가 필요하고 하단 에지 경계를 필터링 하기 위해서는 하단 인접 블록의 데이터가 필요하다. 따라서, CTB의 제일 우측 에지 경계는 우측 인접 CTB가 수신된 이후 우측 인접 CTB의 제일 좌측 수직 에지 경계를 처리할 때 필터링되고, CTB의 제일 하단 에지 경계는 하단 인접 CTB가 수신된 이후 하단 인접 CTB의 제일 상단 수평 에지 경계를 처리할 때 필터링 되는 것이다.

도 8 은 하나의 픽쳐 내에서 각 블록들의 크기 및 필터링 된 데이터가 탑-다운(top-down) 처리 방식에 의해 임베디드 압축되는 순서를 나타낸 도면이다.

하나의 픽쳐 내에서 CTB의 필터링은 도 8 에 도시된 바와 같이 첫번째 블록 행의 제일 좌측 CTB 인 CTB 1 부터 우측으로 진행되며 첫번째 블록 행인 CTB 1 부터 CTB 5 에 대한 처리가 끝나면 다시 두번째 행의 좌측 CTB인 CTB 6 부터 우측으로 진행된다.

이와 같은 CTB의 처리 순서를 고려할 때, 우측 인접 CTB는 시간적으로 연속해서 필터링되므로 우측 에지 경계는 데이터 수신 지연이 거의 발생하지 않는다. 그러나 하단 에지 경계의 경우, 첫번째 블록 행이 다 처리된 후 두번째 블록 행의 처리가 시작되므로 하단 인접 블록들은 데이터 수신 지연이 발생한다.

영상의 전체 크기가 커질수록 또는 코딩 트리 블록의 크기가 작아질수록 하나의 블록 행을 처리하기 위한 시간이 길어지므로, 이와 같은 하단 인접 블록의 데이터 수신 지연은 커지게 된다. 영상의 전체 크기가 커질수록 또는 코딩 트리 블록의 크기가 작아질수록 아래쪽 경계값을 획득하기 위해 기다려야 하는 시간은 길어진다.

도 7 에서 설명한 바와 같이 하나의 CTB를 기준으로 제일 우측 에지 경계와 제일 하단 에지 경계는 그 CTB가 처리될 때 필터링 되지 않으며, 그 결과 필터링 된 블록의 사이즈는 원래 CTB의 사이즈보다 작아진다.

도 8 을 예로 들어 설명하면 CTB의 세로 사이즈(810) 보다 필터링 된 블록의 세로 사이즈(820)가 작아지는 것이다. 도 8 에서 CTB의 세로 사이즈(810)가 2N인 경우라면 필터링 된 블록의 세로 사이즈(820)는 2N 보다 작은 (2N ? α) 가 된다. 이 때, α 의 크기는 필터링의 종류나 참조 영역의 크기에 따라 달라지며 α 는 0 ~ 2N 의 정수이다.

도 9 는 임베디드 압축을 위한 디코딩 된 데이터 사이즈가 임베디드 압축 사이즈보다 작은 경우의 처리 방법을 나타내는 도면이다.

일반적으로, 임베디드 압축을 위한 EC 블록의 크기는 CTB의 크기보다 작으며, 설명의 편의를 위해 CTB의 세로 픽셀 사이즈(910)는 2N이고 임베디드 압축을 위한 EC 블록의 세로 픽셀 사이즈(930)는 N인 경우를 가정한다.

첫번째 블록 행만 필터링 된 상태라면, 필터링 된 블록의 세로 사이즈(920)는 (2N ? α)가 되므로, 임베디드 압축을 위한 첫번째 블록 행에 해당하는 ECB1 ~ ECB10 의 경우 임베디드 압축을 위한 필터링 된 데이터가 준비되어 있는 상태이다.

따라서, 첫번째 블록행에 대해서는 세로 사이즈 N의 임베디드 압축을 수행할 수 있다. 임베디드 압축이 가능한 ECB1 ~ ECB10는 임베디드 압축 엔진에서 임베디드 압축을 수행하고, 임베디드 압축 된 데이터를 블록 단위로 메모리에 저장한다.

그러나 두번째 블록행의 경우, 임베디드 압축을 위한 재료에 해당하는 필터링 된 데이터가 준비되어있지 않은 경우가 발생할 수 있다. 예를 들어 필터링 속도보다 임베디드 압축 속도가 빠른 경우, ECB10의 임베디드 압축이 완료되었으나 CTB6에 해당하는 필터링 된 데이터가 준비되지 않은 경우가 생길 수 있는 것이다.

이러한 경우라면, ECB11의 하단에 해당하는 일부 데이터가 부족하게 되어 바로 임베디드 압축을 수행할 수 없으며, 추후 CTB6의 데이터가 준비된 이후 임베디드 압축을 수행하게 된다. 추후 임베디드 압축을 수행하기 위해서 기 수신된 필터링 된 데이터를 메모리에 저장해 놓았다가 다음 행의 필터링 된 데이터가 수신되어 임베디드 압축이 가능한 상태가 되면 메모리로부터 저장된 데이터를 불러온다.

불러온 데이터와 다음 행의 데이터를 조합하여 ECB의 데이터가 모두 준비되면 임베디드 압축 엔진에서 ECB11 ~ ECB20 에 대해 순서대로 임베디드 압축을 수행하고, 임베디드 압축된 데이터를 블록 단위로 메모리에 저장한다.

앞서 언급한 바와 같이 4K@60p 영상의 복원에 8 x 8 임베디드 압축을 사용하는 경우, M x N 블록의 데이터가 준비되지 못한 이유로 데이터를 저장하고 다시 읽어들여야 하는 데이터양은 HEVC 4:2:2 12bit 에서 1초당 1GByte,AVS2.0 4:2:0 10bit에서 약 879MByte 가 된다. 이와 같은 현상은 임베디드 압축을 위해 점유해야 하는 BUS 대역폭을 증가시키며 영상 시스템의 전체적인 성능을 저하시키는 요인이 될 수 있다.

이 때, 데이터가 저장되는 메모리로 DDR을 이용할 경우 랜덤 액세스가 보장되어 처리 속도가 높아질 수 있으며 임베디드 압축 된 데이터가 저장되는 메모리와 임베디드 압축을 위해 대기하는, 필터링 된 데이터가 저장되는 메모리는 별개로 존재할 수 있다.

디코더 출력에 임베디드 압축을 사용하는 주 목적은 대량의 데이터가 메모리에 접근하는 과정에서 발생하는 시스템 BUS 대역폭을 줄이기 위함이다. 하지만, 고정된 블록 사이즈로 임베디드 압축을 하는 경우 위와 같은 부가적인 문제로 인해 오히려 시스템 BUS 대역폭을 더 많이 사용하게 되고 결과적으로 임베디드 압축 효율이 떨어지게 된다.

본 발명의 일 실시예에 따르면 디코더에서 필터링 된 출력 데이터에 대해서 임베디드 압축 처리 블록 단위인 M x N 가 되지 않아 메모리에 임시로 저장했다 불러와야 하는 데이터 부분, 영상 데이터(M x N1)을 DDR에 쓰고 읽는 반복적인 과정이 생략된다.

도 10 은 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.

임베디드 압축 엔진에 디코딩 된 영상 데이터가 입력되면(1010), 입력된 영상 데이터 중에서 M x N의 EC 블록 단위로 임베디드 압축 할 영상 데이터의 블록 사이즈를 판단한다(1030).

고정된 M x N 블록 사이즈로 임베디드 압축을 하는 경우, 데이터양은 M x N 블록 사이즈가 되어야 한다. 그러나, 실제 영상 신호의 복호화 과정을 고려하면, 임베디드 압축을 위한 M x N 블록의 데이터가 항상 준비되는 것은 아니다.

이 때, 좌우측의 인접한 픽셀 블록은 연속하여 수신되므로 임베디드 압축할 영상 데이터 중 블록 좌우에서 디코딩 된 영상 데이터가 부족한 경우는 거의 발생하지 않지만, 하단의 인접한 픽셀 블록이 미처 수신되지 않은 경우에는 임베디드 압축할 영상 데이터 중 블록 하단에서 디코딩 된 영상 데이터가 부족한 상황이 발생할 수 있다. 따라서 디코딩 된 영상 데이터 중 임베디드 압축 할 영상 데이터의 세로 블록 사이즈 N1 과 EC 블록 단위 M x N의 세로 블록 사이즈인 N을 비교한다. (1050).

단계 1050 의 비교 결과, 임베디드 압축할 영상 데이터의 세로 블록 사이즈 N1이 EC 블록의 세로 블록사이즈인 N보다 작지 않다면, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비된 것이므로 EC 엔진은 디코딩 된 영상 데이터를 M x N 블록 사이즈로 임베디드 압축한다(1070). 임베디드 압축 된 영상 데이터는 저장부에 저장되고(1072), 저장된 영상 데이터에 대한 태그 정보 역시 저장된다(1074). 태그 정보는 임베디드 압축을 풀기 위해 메모리에서 읽어올 임베디드 압축 된 데이터의 양 및 메모리 내에 저장된 위치를 확인하기 위해 사용된다.

앞서 언급한 바와 같이 일반적으로 태그 정보에 대해서는 별도의 압축을 수행하지 않지만, 영상의 데이터 사이즈가 큰 경우에는 관리해야 하는 태그 정보의 양이 늘어나기 때문에 필요에 따라 태그 정보 역시 압축되어 저장될 수 있다. 압축되어 저장된 태그 정보는, 임베디드 압축된 데이터를 읽기 위해 저장된 태그 정보를 호출할 때 압축을 푸는 과정이 추가된다.

임베디드 압축은 손실(lossy) 또는 비손실(lossless) 압축 모두 가능하며 비손실 압축 결과 데이터는 가변 사이즈를 가지므로, 압축을 풀기 위해 저장된 압축 데이터를 읽어오는 과정에서 태그 정보가 필요하나, 손실 압축이라면 압축된 결과 데이터는 고정된 사이즈를 가지므로 태그 정보는 따로 필요없으므로 저장된 영상 데이터에 대한 태그 정보를 저장하는 1074 단계는 생략될 수 있다.

여기서 저장부는 도 2에 도시된 메모리(300) 또는 DPB(301, 302,…)일 수 있으며, 이 때 메모리(300)가 DDR RAM(Double Data Rate Random Access Memory)이라면 랜덤 액세스(random access)가 보장될 수 있다.

단계 1050 의 비교 결과, 임베디드 압축할 영상 데이터의 세로 블록 사이즈 N1이 EC 블록의 세로 블록사이즈인 N보다 작지 않다면, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비되지 않았으므로, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비될 때까지 입력된 영상 데이터를 보관한다(1090).

비디오 코덱의 경우, 임베디드 압축하여 저장할 데이터는 코덱, 구체적으로 디코더의 최종 아웃풋 필터까지 다 처리된 데이터이어야 한다. 그러나 비디오 코덱의 종류에 따라 필터 탭수가 다를 뿐 아니라 필터 특성상 블록 싱크를 맞춰 필터링을 수행하지 못하고 블록간에 걸쳐 필터링을 수행하므로 임베디드 압축을 위한 M x N 블록의 데이터가 준비되지 못하는 경우가 발생한다.

비디오 디코더의 출력 필터가 블록간에 걸쳐 필터링을 수행하는 것은, 블록 처리 순으로 볼 때, 위의 블록의 아래쪽 데이터(픽셀)의 인코딩을 위해 아래 블록의 데이터를 이용하는 비디오 인코딩 특성에 의한 것이다.

처리중인 행의 영상 블록들의 디코딩이 완료되면 다음 행의 영상 블록들의 디코딩이 시작되고, EC 엔진에는 추가 영상 데이터가 입력된다(1092). 추가 영상 데이터가 입력되면 EC 엔진은 보관중인 영상 데이터를 호출하고(1094), 임베디드 압축할 영상 데이터의 블록 사이즈를 다시 판단한다(1030).

따라서, M x N 블록 사이즈의 임베디드 압축을 위해 다시 일부 데이터를 저장해야 하는 경우가 생기게 되며 이는 임베디드 압축을 위해 이용하는 BUS 대역폭을 증가시키게 된다.

현재 4K@60p 영상의 복원에 8 x 8 임베디드 압축을 사용하는 경우, M x N 블록의 데이터가 준비되지 못한 이유로 데이터를 저장하고 다시 읽어들여야 하는 데이터양은 HEVC 4:2:2 12bit 에서 1초당 1GByte,AVS2.0 4:2:0 10bit에서 약 879MByte 가 된다.

도 11 은, 본 발명의 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.

도 11 의 실시예에서, 임베디드 압축을 위한 임베디드 압축 블록(ECB)의 가로사이즈는 M(1150), 세로 사이즈는 N(1110)으로 각각 고정되어 있으며, 첫번째 ECB행(1110)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있으며 두번째 ECB행(1130)은 블록 세로 사이즈의 데이터가 부족하여 (N-α)만이 채워져 있는 상태(1131)를 가정한다. 이 때, 0<α<N의 정수이다.

첫번째 ECB 행(1110)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있는 상태이므로 임베디드 압축 엔진 EC(x)에서 M x N 사이즈로 임베디드 압축이 수행된다. M x N 사이즈로 임베디드 압축된 데이터는 메모리의 압축 데이터 영역(301, Compressed data)에 저장되며, 태그 정보가 저장되는 영역(305, Tag)에는 해당 블록의 데이터는 임베디드 압축되었음을 나타내는 정보와 압축 된 데이터의 사이즈 등을 저장한다.

두번째 ECB행(1130)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있지 않고, (N-α)만이 준비되어 있는 상태(1131)이므로 M x N 사이즈의 임베디드 압축을 할 수 없다. 이와 같은 경우 도 12 에 도시된 것과 같은 본 발명의 일 실시예에 따르면, 추가 데이터가 수신되어 M x N 사이즈의 데이터가 준비되는 것을 기다린 후 임베디드 압축이 수행되지 않고 기 수신되어 있는 M x (N-α) 사이즈의 데이터가 로우 데이터 형태로 메모리의 로우 데이터 영역(303, Raw Data)에 저장되며 태그 정보가 저장되는 영역(305, Tag)에는 해당 블록의 데이터는 압축되지 않았음을 나타내는 정보와 압축되지 않은 데이터의 사이즈 등을 저장한다.

이후, 추가 데이터가 입력되어 두번째 ECB행(1130)의 아랫쪽 M x α의 데이터(1133)가 채워지면, 수신되어 있는 M x α 사이즈의 데이터가 로우 데이터 형태로 메모리의 로우 데이터 영역(303, Raw Data)에 저장되며 태그 정보가 저장되는 영역(305, Tag)에는 해당 블록의 데이터는 압축되지 않았음을 나타내는 정보와 압축되지 않은 데이터의 사이즈 등을 저장한다.

두번째 ECB행(1130)의 데이터가 로우 데이터 형태로 메모리에 저장될 때, AXI 프로토콜을 이용할 수 있는데, AXI 프로토콜은 기존의 온칩(on-chip) 버스(bus) 프로토콜에 비해, 고속/고성능 시스템에 적합한 버스 프로토콜이다.

AXI 프로토콜은 읽기(read), 쓰기(write), 어드레스(address), 쓰기 응답(write response) 등에 관한 채널(channel)이 각각 분리되어 독립적으로 동작하고, 멀티플-아웃스탠딩 어드레스(multiple-outstanding address), 쓰기 데이터 인터리빙(write data interleaving) 등의 트랜잭션(transaction) 특징을 가진다.

AXI 프로토콜은 데이터 읽기 채널과 쓰기 채널이 분리되어 있으므로 데이터를 읽으면서 동시에 데이터를 쓰는 것이 가능하여, AXI 프로토콜을 이용하면 시스템 버스의 쓰루풋(throughput)을 증가시킬 수 있다.

또한, AXI 프로토콜은 멀티플-아웃스탠딩 어드레스 특징에 의해 어드레싱 순서와 상관없이 처리가 가능한 아웃-오브-오더(out-of-order) 트랜잭션을 수행하므로, AXI 프로토콜을 이용하면 시스템 성능이 개선된다.

도 11 에서 태그 정보는 IP를 통하여 관리되는 것으로 도시되어 있으나, 앞서 언급한 바와 같이 전부 또는 일부의 태그 정보는 EC를 통해 관리될 수도 있다. 여기서 IP 는 코덱의 IP 코어(Intellectual Property core)로, 임베디드 압축 엔진에 데이터를 전달하는 코덱 내의 특정 모듈 또는 코어를 의미한다. 대표적인 IP 코어로는 코덱의 최종 처리단계인 포스트 필터(post filter)가 있으나 이에 한정되지는 않는다.

도 12 는 본 발명의 일 실시에에 다른 임베디드압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.

도 10 에 도시된 방법에서는, 임베디드 압축을 위한 데이터가 EC 블록 사이즈인 M x N보다 작은 경우 임베디드 압축을 하지 않고 추가데이터가 입력되어 임베디드 압축을 위한 데이터가 EC 블록 사이즈인 M x N를 만족시킬 때까지 대기하며, 이를 위해 입력된 영상 데이터를 보관(1050)하고 추가 영상 데이터가 입력되면(1052) 보관된 영상 데이터를 호출(1054)한다. 이와 같이 대량의 데이터를 읽고 쓰는 과정이 반복되면, 시스템 BUS에 대한 접근이 증가하여 시스템 BUS 대역폭을 더 많이 사용하게 되고 결과적으로 임베디드 압축 효율이 낮아지게 된다.

도 12 에 도시된 본 발명의 일 실시예에 따른 영상 데이터를 임베디드 압축하는 방법에서는, 임베디드 압축을 위한 M x N 블록의 데이터가 준비된 경우라면, 도 10 에 개시된 방법과 마찬가지 과정이 수행된다.

임베디드 압축 엔진에 디코딩 된 영상 데이터가 입력되면(1210), 입력된 영상 데이터 중에서 M x N의 EC 블록 단위로 임베디드 압축 할 영상 데이터의 블록 사이즈를 판단한다(1230).

고정된 M x N 블록 사이즈로 임베디드 압축을 하는 경우, 데이터 양은 M x N 블록 사이즈가 되어야 한다. 그러나, 실제 영상 신호의 복호화 과정을 고려하면, 임베디드 압축을 위한 M x N 블록의 데이터가 항상 준비되는 것은 아니다.

전술한 바와 같이, 블록 좌우 데이터가 부족한 경우는 거의 발생하지 않으나, 블록 하단의 데이터가 부족한 경우가 발생할 수 있다. 따라서, 디코딩 된 영상 데이터 중 임베디드 압축 할 영상 데이터의 세로 블록 사이즈 N1 과 EC 블록 단위 M x N의 세로 블록 사이즈인 N을 비교한다(1250).

단계 1250의 비교 결과, 임베디드 압축할 영상 데이터의 세로 블록 사이즈 N1이 EC 블록의 세로 블록사이즈인 N보다 작지 않다면, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비된 것이므로 EC 엔진은 디코딩 된 영상 데이터를 M x N 블록 사이즈로 임베디드 압축한다(1270). 임베디드 압축 된 영상 데이터는 저장부에 저장되고(1272), 저장된 영상 데이터에 대한 태그 정보 역시 저장된다(1274). 태그 정보는 임베디드 압축을 풀기 위해 메모리에서 읽어올 임베디드 압축 된 데이터의 양 및 메모리 내에 저장된 위치를 확인하기 위해 사용된다.

여기서 저장부는 도 2 에 도시된 메모리(300) 또는 DPB(301, 302,…)일 수 있으며, 이 때 메모리(300)가 DDR RAM(Double Data Rate Random Access Memory)이라면 랜덤 액세스(random access)가 보장될 수 있다.

단계 1250 의 비교 결과, 임베디드 압축할 영상 데이터의 세로 블록 사이즈 N1이 EC 블록의 세로 블록사이즈인 N보다 작지 않다면, 입력된 M x N1 사이즈의 영상 데이터를 메모리에 저장한다(1290). 이 때, 수신된 M x N1 사이즈의 데이터는 로우 데이터(raw data) 형태로 저장되며, 로우 데이터 형태로 저장된 영상 데이터에 대한 태그 정보가 메모리에 저장된다(1292). 저장된 영상 데이터에 대한 태그 정보는 저장된 영상 데이터의 크기 및 저장된 위치에 대한 정보를 포함한다.

디코딩 된 영상 데이터가 추가로 입력되면, 추가 입력된 M x (N-N1) 사이즈의 영상 데이터를 로우 데이터 형태로 메모리에 저장한다(1294). 추가 입력된 영상 데이터를 저장할 때, 이미 저장되어 있는 영상 데이터에 대한 태그 정보에 기초하여 추가 입력된 영상 데이터가 저장될 위치가 결정된다.

도 10 에 개시된 방법과는 달리, 도 12 에 개시된 방법에서는, 추후 영상 데이터가 추가로 입력되어 임베디드 압축 사이즈인 M x N 을 만족하는지 여부를 확인하지 않는다. 또한 영상 데이터가 추가로 입력되어도 임베디드 압축을 수행하지 않고 수신된 M x N1 사이즈의 데이터를 로우 데이터(raw data) 형태로 바로 메모리에 저장한다.

임베디드 압축은 데이터의 용량을 줄여 데이터의 보관 및 처리를 용이하게 하기 위한 것을 목적으로 수행된다. 하지만, 도 10 에 개시된 방법과 같이, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비되지 않은 경우, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비될 때까지 입력된 영상 데이터를 보관하고 추가 영상 데이터가 입력되면 보관중인 영상 데이터를 호출하는 방식은 데이터를 읽고 쓰는 과정에서 오히려 시스템 부하를 야기시키며 전체적인 시스템 성능을 저하시킬 수 있다.

앞서 언급한 것과 같이 4K@60p 영상의 복원에 8 x 8 임베디드 압축을 사용하는 경우, M x N 블록의 데이터가 준비되지 못하여 데이터를 저장하고 다시 읽어들여야 하는 데이터양은 HEVC 4:2:2 12bit 에서 1초당 1GByte,AVS2.0 4:2:0 10bit에서 약 879MByte 가 된다.

도 12 에 개시된 방법과 같이, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비된 경우라면 임베디드 압축을 수행하여 메모리에 저장하고, M x N 블록 임베디드 코딩을 위한 데이터가 모두 준비되지 않은 경우라면 블록 사이즈만 맞추어 로우 데이터를 메모리에 저장하도록 함으로써 데이터를 읽고 쓰는 과정을 줄여 시스템 성능이 개선될 수 있다.

이 때, IP가 입력된 영상 데이터를 메모리에 직접 저장하고 EC 엔진에는 해당 데이터는 압축되지 않았다는 정보만을 전달하여, EC 엔진이 태그 정보를 관리하도록 할 수 있다. 또는, IP가 입력된 영상 데이터와 태그 정보를 EC 엔진에 전달하고 EC 엔진이 영상 데이터 및 태그 정보를 직접 메모리에 저장하도록 할 수 있다.

IP 또는 EC 엔진은 저장된 태그 정보에 기초하여 이미 저장되어 있는 영상 데이터의 크기 및 압축 여부 등을 판단할 수 있으며, 판단된 영상 데이터의 크기 및 압축 여부 등에 기초하여 추가 영상 데이터를 저장한다.

도 13 은 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.

도 13 의 실시예에서, 임베디드 압축을 위한 임베디드 압축 블록(ECB)의 가로사이즈는 M(1350), 세로 사이즈는 N(1310)으로 각각 고정되어 있으며, 첫번째 ECB행(1310)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있으며 두번째 ECB행(1330)은 블록 세로 사이즈의 데이터가 부족하여 (N-α)만이 채워져 있는 상태(1331)를 가정한다. 이 때, 0<α<N의 정수이다.

첫번째 ECB 행(1310)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있는 상태이므로 임베디드 압축 엔진 EC(x)에서 M x N 사이즈로 임베디드 압축이 수행된다. M x N 사이즈로 임베디드 압축된 데이터는 메모리의 압축 데이터 영역(301, Compressed data)에 저장되며, 태그 정보가 저장되는 영역(305, Tag)에는 해당 블록의 데이터는 임베디드 압축되었음을 나타내는 정보와 압축 된 데이터의 사이즈 등을 저장한다.

두번째 ECB행(1330)은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있지 않고, 위쪽의 (N-α) 픽셀에 해당하는 디코딩 된 데이터만 준비되어 있는 상태(1331)이므로 M x N 사이즈의 임베디드 압축을 할 수 없다. 이와 같은 경우 도 12 에 도시된 것과 같은 본 발명의 일 실시예와는 달리 도 13 에 개시된 실시예에서는, 두번째 ECB 행(1331 및 1333)과 같이 데이터의 일부만이 존재하여 M x N 사이즈로 임베디드 압축을 할 수 없는 경우라 하여도 임베디드 압축 엔진으로 데이터를 전달한다.

구체적으로, 임베디드 압축엔진은 전달된 데이터의 사이즈를 판단하여 블록 사이즈가 임베디드 압축 사이즈인 M x N 을 만족시키지 못하면, 임베디드 압축을 하지 않는 것으로 판단하고 전달된 데이터를 로우 데이터 형태로 메모리의 로우 데이터 영역(303)에 직접 저장한다.

따라서, 두번째 ECB 행(1330)에 해당하는 1331은 블록 사이즈가 M x (N-α)로 임베디드 압축 사이즈인 M x N 을 만족시키지 못하므로, 임베디드 압축 엔진(100)은 해당 데이터에 대해서는 임베디드 압축을 하지 않는 것으로 판단하고 전달된 데이터를 로우 데이터 형태로 메모리의 로우 데이터 영역(303)에 직접 저장한다.

이후, 두번째 ECB 행(1330)의 하단에 해당하는 데이터 1333이 입력되면, 1333은 블록 사이즈가 M x α로 임베디드 압축 사이즈인 M x N 을 만족시키지 못하므로, 임베디드 압축 엔진(100)은 1333의 데이터에 대해 1331의 데이터와 마찬가지로 임베디드 압축을 하지 않는 것으로 판단하고 전달된 데이터를 로우 데이터 형태로 메모리의 로우 데이터 영역(303)에 직접 저장한다.

이 때, IP 모듈에서는 태그 정보가 저장되는 영역(305, Tag)에는 1331 및 1333에 해당하는 블록의 데이터는 압축되지 않았음을 나타내는 정보와 압축되지 않은 데이터의 사이즈 등을 저장한다.

도 13 에서 태그 정보는 IP를 통하여 관리되는 것으로 도시되어 있으나, 앞서 언급한 바와 같이 전부 또는 일부의 태그 정보는 임베디드 압축 엔진을 통해 관리될 수도 있다.

도 14 는 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 데이터 처리 과정을 도시한다.

도 14 에서는, EC엔진(100)과 메모리(300)만 도시되어 있으나 임베디드 압축을 위한 픽쳐 구성, 코딩 트리 블록 및 임베디드 압축 블록은 도 13 과 같은 경우를 가정한다. 그러나, 도 13 의 실시예에서는, 임베디드 압축 블록의 가로사이즈는 M(1350), 세로 사이즈는 N(1310)으로 각각 고정되어 있는데 반데 도 14 의 실시예에서는 임베디드 압축 블록의 사이즈가 가변적인 경우를 가정한다.

특히, 임베디드 압축 블록의 세로 사이즈(N)가 가변적인 경우를 가정한다. 이는, 앞서 언급한 바와 같이, HEVC와 같은 영상 코덱에서 영상 데이터는 블록 단위로 처리되며, 블록의 아래쪽 데이터의 처리를 위해 아래 블록의 데이터를 이용하는 비디오 코덱 특성상 블록의 아래쪽 데이터의 처리 및 수신이 지연되는 경우가 발생하기 때문이다.

도 14 의 실시예에서, 첫번째 ECB행은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있으며 두번째 ECB행은 블록 세로 사이즈의 데이터가 부족하여 (N-α)만이 채워져 있는 상태를 가정한다. 이 때, 0<α<N의 정수이다.

첫번째 ECB 행은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있는 상태이므로 임베디드 압축 엔진 EC1(x)에서 M x N 사이즈로 임베디드 압축이 수행된다. M x N 사이즈로 임베디드 압축된 데이터는 메모리의 압축 데이터 영역(301)에 저장되며, 태그 정보가 저장되는 영역(305)에는 해당 블록의 데이터는 임베디드 압축되었음을 나타내는 정보와 압축 된 데이터의 사이즈 등을 저장한다.

두번째 ECB 행은 블록 세로 사이즈 N에 해당하는 데이터가 모두 채워져 있지 않고, (N-α)만이 준비되어 있는 상태이지만, 도 14 의 실시예에서는 ECB의 블록 세로 사이즈를 가변적으로 임베디드 압축할 수 있으므로 두번째 행의 데이터 중 위쪽의 (N-α) 픽셀에 해당하는 디코딩 된 데이터에 대해서는 임베디드 압축 엔진 EC2(x)에서 M x (N-α) 사이즈로 임베디드 압축이 수행된다. M x (N-α) 사이즈로 임베디드 압축된 데이터는 메모리의 압축 데이터 영역(301)에 저장되며, 태그 정보가 저장되는 영역(305)에는 해당 블록의 데이터는 임베디드 압축되었음을 나타내는 정보와 압축 된 데이터의 사이즈 등을 저장한다.

이후, 두번째 ECB 행의 하단 α 픽셀에 해당하는 디코딩된 데이터가 입력되면, 임베디드 압축 엔진(100)은 이 데이터에 대해 임베디드 압축 엔진 EC2(x)를 통해 M x α 사이즈로 임베디드 압축을 수행한다. M x α 사이즈로 임베디드 압축된 데이터 역시 메모리의 압축 데이터 영역(301)에 저장되며, 태그 정보가 저장되는 영역(305)에는 해당 블록의 데이터는 임베디드 압축되었음을 나타내는 정보와 압축 된 데이터의 사이즈 등을 저장한다.

도 14 에서 태그 정보는 IP를 통하여 관리되는 것으로 도시되어 있으나, 도 13 과 마찬가지로 전부 또는 일부의 태그 정보는 임베디드 압축 엔진을 통해 관리될 수도 있다.

도 15 는 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법의 흐름도를 도시한다.

도 15 에 도시된 본 발명의 일 실시예에 따른 영상 데이터를 처리하는 방법에서는, 고정된 블록 사이즈로 임베디드 압축을 수행하는 것이 아니라 도 14 의 실시예와 같이 가변적인 블록 사이즈로 임베디드 압축을 수행한다.

디코딩 된 영상 데이터가 입력(1510)되면, 임베디드 압축 할 영상 데이터의 사이즈를 판단(1530)한다.

하나의 픽처에 대한 영상 데이터의 처리는 좌에서 우로, 위에서 아래로 진행하는 탑-다운 방식으로 진행되므로, 디코딩 된 데이터의 세로 픽셀 사이즈 N1 에 기초하여 임베디드 압축 블록 사이즈를 결정(1550)하게 된다.

앞서 언급한 바와 같이, HEVC와 같은 비디오 코덱에서 영상 데이터는 블록 단위로 처리되며, 블록의 아래쪽 데이터의 처리를 위해 아래 블록의 데이터를 이용하는 비디오 코덱 특성상 블록의 아래쪽 데이터의 처리 및 수신이 지연되는 경우가 발생하기 때문이다.

도 15 의 실시에에서는, 임베디드 압축 블록 사이즈, 특히 임베디드 압축 블록의 세로 사이즈가 가변적이므로 디코딩 된 데이터의 세로 픽셀 사이즈 N1에 무관하게 M x N1으로 임베디드 압축(1570)을 수행한다.

임베디드 압축이 완료되면, 임베디드 압축 된 영상 데이터는 저장부에 저장되고(1590), 저장된 영상 데이터에 대한 태그 정보 역시 저장된다(1592). 태그 정보는 임베디드 압축을 풀기 위해 메모리에서 읽어올 임베디드 압축 된 데이터의 양 및 메모리 내에 저장된 위치를 확인하기 위해 사용된다.

만일, 임베디드 압축 할 데이터의 세로 픽셀 사이즈 N1 이 임베디드 압축 블록의 세로 사이즈의 최대값 Nmax 보다 크다면, M x Nmax 의 블록 사이즈로 임베디드 압축을 수행하고 N1 = N1 ? Nmax 로 갱신한 후, 단계 1510 부터 1592 까지의 과정을 반복한다.

이상의 실시예에서는 디코딩 된 데이터의 세로 픽셀 사이즈에 기초하여 가변적으로 임베디드 압축 블록 사이즈를 결정하는 방법에 대해 개시하였다.

디코딩 된 데이터의 세로 픽셀 사이즈가 N1 일 때, 임베디드 압축 블록의 세로 사이즈를 N1으로 결정하는 경우, 이와 같이 완전히 가변적으로 임베디드 압축 블록의 사이즈를 결정하기 위해서는 이론적으로 임베디드 압축 블록의 최대 세로 사이즈만큼의 임베디드 압축 엔진이 필요하다는 단점이 있다.

도 16 은 본 발명의 또 다른 일 실시예에 따른 임베디드 압축 엔진을 포함하는, 영상 데이터를 처리하는 시스템에서, 영상 데이터를 임베디드 압축하는 방법을 도시한다.

도 16 의 실시예에서는, 디코더 아웃풋 필터에서 출력되는 데이터의 블록 사이즈는 비디오 코덱의 종류에 따라 정해진 값을 가지는 특징을 이용함으로써 보다 효율적으로 영상 데이터를 임베디드 압축하는 방법을 개시한다.

도 16 의 디코더(200)에서는 데이터가 인코딩 된 코덱의 종류에 따라 디코딩 과정에서 역시 세 종류의 코덱을 이용하는 경우를 가정한다. 디코더 아웃풋 필터에서 출력되는 데이터의 블록 사이즈는 비디오 코덱의 종류에 따라 정해진 값을 가지므로 코덱 1 을 이용해 데이터를 디코딩 하는 경우 아웃풋 필터의 출력 데이터의 블록 사이즈가 M1 x N1, 코덱 2 를 이용해 데이터를 디코딩 하는 경우 아웃풋 필터의 출력 데이터의 블록 사이즈가 M2 x N2, 코덱 3 을 이용해 데이터를 디코딩 하는 경우 아웃풋 필터의 출력 데이터의 블록 사이즈가 M3 x N3 이라 할 수 있다.

이 때, 임베디드 압축 블록 사이즈를 M x N 으로 결정할 때, M 은 M1, M2 및 M3 의 최대공약수로, N 은 N1, N2 및 N3 의 최대 공약수로 결정한다면, 코덱의 종류에 무관하게 하나의 임베디드 압축 엔진을 이용할 수 있으며 보다 효율적으로 임베디드 압축을 수행할 수 있다.

이와 같은 경우라면, 임베디드 압축을 위한 데이터 사이즈가 부족한 경우가 발생하지 않을 수 있다.

도 17 은 본 발명의 일 실시예에 따른 임베디드 압축 장치의 세부 구성도이다.

도 17 에 도시된 바와 같이, 본 발명의 일 실시예에 따른 임베디드 압축 장치(100)는 임베디드 압축부(110), 입력부(120), 출력부(130), 저장부(140) 및 제어부(150)를 포함한다.

임베디드 압축부(110)는, 입력부(120)에서 전달된 디코딩 된 영상 데이터를 블록 단위로 임베디드 압축하고, 임베디드 압축된 영상 데이터를 출력부로 전달한다.

입력부(120)는, 디코더의 아웃풋 필터 출력 데이터를 입력받고, 입력받은 데이터를 임베디드 압축부(110)로 전달한다.

출력부(130)는, 임베디드 압축된 영상 데이터를 임베디드 압축부(110)로부터 전달받고 출력함으로서 임베디드 압축된 영상 데이터가 DPB(미도시)에 저장될 수 있도록 한다.

저장부(140)는, 실시예에 따라 필요한 경우 제어부(150)에서 결정된 임베디드 압축 블록 사이즈등을 저장할 수 있다.

제어부(150)는, 임베디드 압축 장치(100) 전체의 동작을 제어하며, 디코더 아웃풋 필터 출력 데이터가 효율적으로 임베디드 압축 될 수 있도록, 임베디드 압축부(110), 입력부(120), 출력부(130) 및 저장부(140)를 제어한다.

이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.

이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.

따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

100: 임베디드 압축 엔진
200: 디코더
300: 메모리
400: 통신망
500: 인코더
600: 디스플레이

Claims

영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 방법에 있어서,
디코딩된 영상 데이터를 입력받는 단계;
상기 입력된 영상 데이터 중, 임베디드 압축 대기 영상 데이터의 블록 사이즈를 판단하는 단계; 및
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈와, 임베디드 압축 단위인 EC 블록 사이즈를 비교하는 단계;를 포함하고
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 크거나 같은 경우, 상기 입력된 영상 데이터를 임베디드 압축하는 단계;를 더 포함하고,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 작은 경우, 상기 입력된 영상 데이터에 대한 태그 정보를 저장하는 단계;를 더 포함하는,
영상 데이터를 임베디드 압축하는 방법.
제 1 항에 있어서,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 작은 경우,
a) 상기 임베디드 압축 대기 영상 데이터를 저장하는 단계; 및
b) 임베디드 압축되어야 할 디코딩 된 추가 영상 데이터가 입력되면, 상기 태그 정보에 기초하여 상기 추가 영상 데이터를 저장하는 단계;를 더 포함하는,
영상 데이터를 임베디드 압축하는 방법.
제 1 항에 있어서,
상기 태그정보는, 코덱의 IP 코어(Intellectual Property core)로부터 수신되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 방법.
제 1 항에 있어서,
상기 태그 정보는, 상기 디코딩 된 영상 데이터가 비압축 (non-compressed)인 것을 나타내는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 방법.
영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 방법에 있어서,
디코딩 된 영상 데이터를 입력받는 단계;
상기 입력된 영상 데이터 중, 임베디드 압축 대기 영상 데이터의 블록 사이즈를 판단하는 단계; 및
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈와, 임베디드 압축 단위인 제 1 EC 블록 사이즈를 비교하는 단계;를 포함하고
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 제 1 EC 블록 사이즈보다 크거나 같은 경우, 상기 입력된 영상 데이터를 임베디드 압축하는 단계;를 더 포함하고,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 제 1 EC 블록 사이즈보다 작은 경우,
a) 상기 임베디드 압축 대기 영상 데이터를, 상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈에 따라 결정되는, 제 2 EC 블록 사이즈 단위로 임베디드 압축하는 단계; 및
b) 상기 임베디드 압축된 영상 데이터 및 상기 임베디드 압축된 데이터에 대한 태그 정보를 저장하는 단계;를 더 포함하는,
영상 데이터를 임베디드 압축하는 방법.
제 5 항에 있어서,
상기 제 2 EC 블록 사이즈는,
상기 입력된 영상 데이터의 세로 블록 사이즈에 기초하여 결정되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 방법.
제 6 항에 있어서,
상기 제 2 EC 블록 사이즈의 세로 블록 사이즈는,
상기 입력된 영상 데이터가 가질 수 있는 세로 블록 사이즈들의 최대공약수인 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 방법.
제 1 항 또는 제 5 항 중 어느 한 항에 있어서,
상기 태그 정보는, 압축되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 방법.
영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 장치에 있어서,
디코딩된 영상 데이터를 입력받는 입력부;
상기 입력된 영상 데이터 중, 임베디드 압축 대기 영상 데이터의 블록 사이즈를 판단하고, 상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈와, 임베디드 압축 단위인 EC 블록 사이즈를 비교하는 제어부; 및
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 크거나 같은 경우, 상기 입력된 영상 데이터를 임베디드 압축하고,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 작은 경우, 상기 입력된 영상 데이터에 대한 태그 정보를 저장하는 임베디드 압축부;를 포함하는,
영상 데이터를 임베디드 압축하는 장치.
제 9 항에 있어서,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 EC 블록 사이즈보다 작은 경우,
a) 상기 임베디드 압축 대기 영상 데이터를 저장하고,
b) 임베디드 압축되어야 할 디코딩 된 추가 영상 데이터가 입력되면, 상기 태그 정보에 기초하여 상기 추가 영상 데이터를 저장하는 저장부;를 더 포함하는,
영상 데이터를 임베디드 압축하는 장치.
제 9 항에 있어서,
상기 태그정보는, 코덱의 IP 코어(Intellectual Property core)로부터 수신되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 장치.
제 9 항에 있어서,
상기 태그 정보는, 상기 디코딩 된 영상 데이터가 비압축 (non-compressed)인 것을 나타내는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 장치.
영상 데이터를 임베디드 압축(Embedded Compression, EC)하는 장치에 있어서,
디코딩 된 영상 데이터를 입력받는 입력부; 및
상기 입력된 영상 데이터 중 임베디드 압축 대기 영상 데이터의 블록 사이즈를 판단하고, 상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈와 임베디드 압축 단위인 제 1 EC 블록 사이즈를 비교하는 제어부;를 포함하고
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 제 1 EC 블록 사이즈보다 크거나 같은 경우, 상기 입력된 영상 데이터를 임베디드 압축하고,
상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈가 상기 제 1 EC 블록 사이즈보다 작은 경우, 상기 임베디드 압축 대기 영상 데이터를, 상기 판단된 임베디드 압축 대기 영상 데이터의 블록 사이즈에 따라 결정되는, 제 2 EC 블록 사이즈 단위로 임베디드 압축하는 임베디드 압축부; 및
상기 임베디드 압축된 영상 데이터 및 상기 임베디드 압축된 데이터에 대한 태그 정보를 저장하는 저장부;를 포함하는,
영상 데이터를 임베디드 압축하는 장치.
제 13 항에 있어서,
상기 제 2 EC 블록 사이즈는,
상기 입력된 영상 데이터의 세로 블록 사이즈에 기초하여 결정되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 장치.
제 14 항에 있어서,
상기 제 2 EC 블록 사이즈의 세로 블록 사이즈는,
상기 입력된 영상 데이터가 가질 수 있는 세로 블록 사이즈들의 최대공약수인 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 장치.
제 9 항 또는 제 13 항 중 어느 한 항에 있어서,
상기 태그 정보는, 압축되는 것을 특징으로 하는,
영상 데이터를 임베디드 압축하는 장치.
제 1 항에 따른 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체.