* 개요

 - Dynamic Adaptive Streaming over HTTP는 클라이언트에게 네트워크 상황에 맞추어 적합한 비디오 화질을 선택하여 서비스받는 기술을 의미 한다.

 - 유튜브를 사용할 때 네트워크 환경에 따라 영상화질을 변화 시킬 수 있는 것이 그 예시


* 기본 동작

 1. DASH 서버는 비디오를 다양한 비트 rate로 구분하여 인코딩을 한다.

 2. 인코딩 된 비디오 데이터들을 세그먼트(또는 chunk) 단위로 분할해 놓는다.

 3. 클라이언트는 자신의 네트워크 상황에 맞추어서 비트 rate 적용 알고리즘을 수행, 네트워크 가용 대역폭을 계산하고 이를 기반으로 비디오 세그먼트의 비트 rate를 계산한다.

 4. 계산된 rate를 토대로 서버로부터 이에 따른 비디오 서비스를 받는다.


- DASH는 MP4, MPEG-2 Trankport Stream을 지원, DRM을 명시하지 않았지만 ISO/IEC 23001-7: Common Encryption 표준에 명시된 모든 DRM 기술을 지원한다.


참조 : 

http://donghoson.tistory.com/48

https://www.html5rocks.com/ko/tutorials/eme/basics/


  클라우드 서비스는 데이터 저장소를 사용자의 로컬이 아닌 서버에 두고, 네트워크 통신을 활용해 서버의 데이터를 이용하는 것을 의미한다. 이러한 시스템이 데이터가 마치 구름처럼 떠있고 이를 필요시마다 활용하기에 "구름"을 은유적으로 표현하여 이러한 명칭을 쓰게 되었다. 클라우드는 그 활용 용도에 따라 크게  IaaS, PaaS, SaaS 등 3가지로 구분 지을 수 있다. 이에 대한 설명은 다음과 같다.


◐ IaaS (Infrastructure as a Service)

  IaaS는 PaaS, Saas의 기반이 되어주는 기술이다. 기본적인 클라우드의 형태를 갖추기 위해서는 IP, 네트워크, OS, 스토리지 등 다양한 구성요소가 요구된다. 이러한 체계를 모두 갖추고 실질적으로 데이터를 입출력 할 수 있는 기반이 되는 형태를 IaaS라 한다.


◐ PaaS (Platform as a Service)

  IaaS를 기반으로 개발자가 별도의 플랫폼을 설계하거나 제작 할 필요 없이, 서비스를 개발 할 수 있는 환경을 제공하는 클라우드 서비스다. 이러한 형태의 클라우드는 관련된 응용 프로그램을 개발 할 수 있는 API를 함께 제공하고 있다. 관련된 서비스는 네이버 API, 구글 API, 아마존의 EC2와 같은 서비스를 예로 들 수 있다.


◐ SaaS (Software as a Service)

  다양한 응용프로그램을 클라우드 형태로 서비스하는 것을 의미한다. 예를들어, 한글과컴퓨터의 넷피스 24, MS의 Office 365와 같은 서비스처럼, 클라우드 상에 업로드 된 데이터를 웹 기술을 통해 접근하여 편집, 저장 할 수 있다. 이러한 서비스의 경우 스토리지 용량에 대해 유연하게 대처 할 수 있을 뿐만 아니라, 백업과 같은 관리 및 내부적인 시스템 처리에 대해 사용자가 별도로 신경써야 할 부분이 없다.


http://draw.io


알고리즘에 대한 순서도, 시스템 설계, DB 스키마를 설계 내용을 시각적으로 표현해주는 웹사이트다.


조작하는 방법도 몇번만 다루어보면 간단하게 익힐 수 있다.


무엇보다도 별도로 설치 할 필요 없이 그냥 네트워크만 연결되어 있다면 어디서든 마음껏 만들 수 있다는 것이 큰 장점인 것 같다.

라이브러리와 프레임워크를 혼용하여 사용하는 경우가 많다.

이유는 아마 그 차이에 대해 명확하게 정의된 것이 없기 때문에 그런것이다.

자료를 찾아보니 굳이 명확히 구분을 짓고자 한다면 다음과 같은 특징들을 잡을 수가 있었다.


- 프레임워크는 틀, 골격의 의미로 라이브러리를 내포 할 수 있다.

- 내가 만든 소스코드에서 부르게 되면 라이브러리, 반대로 내가 만든 소스코드가 불려가 동작하게 된다면 프레임워크이다.

- 라이브러리는 연장/기능을 담은 집합, 프레임워크는 이런 연장들의 사용방식 및 API, 규칙, 절차에 대한 명세


풀어서 정리하자면, 라이브러리는 내가 그냥 가져다 사용 할 수 있는 모듈이며 수정이 용이하다.

그렇기 때문에 내가 라이브러리를 가져다 쓴다고 생각 할 수 있다.

프레임워크는 이미 정해진 명세, 규칙이기 때문에 수정이 어렵다.

소스코드를 짤때 이 규칙을 토대로 프레임워크를 사용하므로, 프레임워크가 명시한 대로 사용 할 수 있을 뿐이다.

그래서 내가 짠 소스코드는 프레임워크에 의존하여 동작하게 하게 된다.


http://imcreator.tistory.com/7

위 링크에서 이 질문에 대한 답을 명확히 이해 할 수 있었다.

모듈은 가장 상위에 위치하는 구현의 단위,

컴포넌트는 런타임 엔티티를 참조하는 단위라고 생각하면

금방 그 차이를 이해 할 수 있을거라고 생각된다.

따라서 모듈과 컴포넌트는 상위와 하위관계를 명확히 구분짓기 어렵고

서로 다른 개념으로 바라보아야 한다고 생각한다.

그렇기 때문에 모듈 1000개가 모여 하나의 컴포넌트가 될 수도있고,

컴포넌트 1000개가 모여서 하나의 모듈을 구성 지을 수도있다.


쉽게 설명해서, 모듈이란 실질적으로 구현이 된 단위를 의미한다.

자료구조, 알고리즘 등 이를 제공하는 인터페이스라고도 할 수 있을 것이다.


반면, 컴포넌트는 실제적으로 동작하고있는 엔티티로써

활동중인 독립적인 단위를 중점적으로 보고 있다.


상위에 있는 링크에서는 서버와 클라이언트의 예로 설명하고 있다.

1개의 서버에게 서비스를 제공받는 100개의 클라이언트가 존재한다고 가정하자.

위에 설명한 내용으로 모듈, 컴포넌트의 개수를 각각 세어보면

서버가 구현된 모듈 1개, 클라이언트가 구현된 모듈 1개이므로

이 시스템 인프라의 총 모듈 개수는 2개이다.

컴포넌트의 경우 실제 동작하고 있는 엔티티를 의미하므로 총 101개가 된다.

+ Recent posts