"9조(블록체인)"의 두 판 사이의 차이

cdc wiki
이동: 둘러보기, 검색
(→‎완료작품의 평가)
(→‎결과 및 평가)
 
(같은 사용자의 중간 판 34개는 보이지 않습니다)
116번째 줄: 116번째 줄:
 
- Windows10 운영체제
 
- Windows10 운영체제
  
−
- C++ 프로그래밍 언어
+
- .NET Framework
  
 
- Amazon Web Service
 
- Amazon Web Service
124번째 줄: 124번째 줄:
  
 
===개념설계안===
 
===개념설계안===
−
*기기 구성도
+
*개념설계
 +
[[파일:개념설계.jpg|가운데]]
 +
클라이언트가 서버에 게임에 대한 계산요청을 전송하면 서버는 해당 계산을 대신 수행한 결과를 영상으로 클라이언트에게 전송한다. 이때 효율적인 실시간 영상 전송을 위해 다양한 압축기술을 활용한다. 게임을 진행하면서 클라이언트가 키보드나 마우스 동작과 같은 명령을 입력하면 서버는 이를 인식하고 그에 대한 알맞는 계산을 수행한다.
 +
 
 +
 
 +
===사용 관련 기술 및 알고리즘===
 +
*실시간 스트리밍 기술
 
[[파일:흐름.png|가운데]]
 
[[파일:흐름.png|가운데]]
 
OBS Studio는 단순히 영상을 녹화, 방송하는 툴이다. 내부에서 영상 화질이나 bitrate, audio 및 압축 기법을 설정할 수 있으며 촬영된 영상을 RTMP 방식으로 AWS medialive에 보낸다. RTMP는 미리 데이터를 다운 받지 않고 시청하고 있는 프레임만 전송하는 기법으로, 이미 시청한 데이터는 폐기한다. OBS Studio에서 AWS medialive로 영상을 인코딩해서 전송하는데 H.264 코덱을 사용하지 않고 X.264를 사용해서 전송한다. 굳이 X.264를 사용한 이유는 X.264가 H.264에 비해 인코딩 성능이 앞서고 영상 압축시에 소모하는 자원이 H.264에 비해 적어서 저사양 장비를 가지고 있는 Client가 사용하기 더 적합할 것으로 예상되었기 때문이다.
 
OBS Studio는 단순히 영상을 녹화, 방송하는 툴이다. 내부에서 영상 화질이나 bitrate, audio 및 압축 기법을 설정할 수 있으며 촬영된 영상을 RTMP 방식으로 AWS medialive에 보낸다. RTMP는 미리 데이터를 다운 받지 않고 시청하고 있는 프레임만 전송하는 기법으로, 이미 시청한 데이터는 폐기한다. OBS Studio에서 AWS medialive로 영상을 인코딩해서 전송하는데 H.264 코덱을 사용하지 않고 X.264를 사용해서 전송한다. 굳이 X.264를 사용한 이유는 X.264가 H.264에 비해 인코딩 성능이 앞서고 영상 압축시에 소모하는 자원이 H.264에 비해 적어서 저사양 장비를 가지고 있는 Client가 사용하기 더 적합할 것으로 예상되었기 때문이다.
130번째 줄: 136번째 줄:
 
AWS mediapackage는 AWS medialive에서 생성된 output 영상들을 뿌려주는 역할을 한다. 이때 여러 output 영상들을 HLS 방식으로 Client에게 서비스 할수 있게 m3u8의 확장자를 지닌 여러개의 URL을 생성해준다. HLS는 하나의 영상을 시간단위로 조각낸 ts파일을 재생목록 파일인 m3u8과 함께 HTTP를 통해 전송하는 방식으로 별도의 영상변형을 요구하지 않아 서버 비용이 절약된다. 이렇게 생성된 URL을 이용해 웹에서 동작이 가능해진다.
 
AWS mediapackage는 AWS medialive에서 생성된 output 영상들을 뿌려주는 역할을 한다. 이때 여러 output 영상들을 HLS 방식으로 Client에게 서비스 할수 있게 m3u8의 확장자를 지닌 여러개의 URL을 생성해준다. HLS는 하나의 영상을 시간단위로 조각낸 ts파일을 재생목록 파일인 m3u8과 함께 HTTP를 통해 전송하는 방식으로 별도의 영상변형을 요구하지 않아 서버 비용이 절약된다. 이렇게 생성된 URL을 이용해 웹에서 동작이 가능해진다.
  
−
===사용 관련 기술 및 알고리즘===
 
−
*SLAM 도식
 
−
**[[파일:9조_슬램도식.png]]
 
−
**1. Tracking: 매 프레임마다 카메라의 위치 파악, 키프레임 삽입 시기 결정
 
−
**2. Local Mapping: 키프레임 처리 및 local BA 실행 등 map point, key frame 최적화
 
−
**3. Loop Closing: 카메라가 루프를 그렸는지 확인 및 오차 수정
 
−
**Epipolar Geometry에 의하면 임의의 두 지점에서 찍은 영상의 매칭점 쌍들은 Epipolar Constraint에 의해 관계되어있기 때문에 두 이미지와 대응되는 최소 5개의 매칭 쌍을 알면 행렬 형태의 두 이미지 간의 기하학적 관계 정보를 알 수 있다. 또한 삼각측량을 이용해 두 이미지 평면 사이의 기하학적 관계와 매칭 쌍이 주어지면 이로부터 원래의 3D 공간좌표를 알 수 있다. SLAM은 해당 기하학적 원리를 이용한다.
 
  
−
*ORB-SLAM 알고리즘 설명
+
===상세설계 내용===
−
**ORBSLAM은 PTAM (Parallel Tracking and Mapping) 방식으로 Tracking, Local Mapping, Loop Closing 작업을 3개의 스레드을 이용하여 병렬처리한다. 이러한 방식은 작업들 간의 종속성을 제거한다. 비교적 연산 로드가 적은 카메라 tracking은 모든 영상프레임에 적용하여 실시간성을 추구, 맵 갱신은 주요 키프레임에만 적용하되 시간이 오래 걸리더라도 정밀한 알고리즘을 사용하여 정확도를 추구한다.
+
====SW 특징====
−
**Tracking은 매 프레임마다 카메라의 위치를 알아내고, key frame을 결정한다. 먼저 ORB 특징점을 추출한다. 만약 이전 프레임에서 tracking이 성공했다면 constant velocity model을 사용해 카메라 위치를 추정하고 이전 프레임에서 관측된 맵 포인트에서 검색해본다. 만약 충분한 양의 결과가 나오지 않으면 더 넓은 범위에서 검색한다. 만약 tracking이 실패했다면 프레임에서 Place Recognition을 통해 연관된 key frame을 검색하고 카메라의 위치를 추정한다. 위치 추정과 특징점 매칭이 끝나면 해당 프레임을 맵에 투영한다. 마지막으로 해당 프레임을 key frame으로 여길 것인지 결정하는데, 가장 최근의 key frame 삽입이나 global relocalization으로부터 20프레임 이상 시간 차이가 나고, 기존 맵과의 최단 거리가 특정 임계값 이하, 50개 이상의 특징점을 추적, 그리고 reference key frame과 공유하는 포인트가 90% 이하라면 key frame으로 저장될 수 있다.
+
*Microservice
−
**Local Mapping 단계에서는 얻었던 key frame을 이용하여 맵 포인트를 생성한다. 먼저 Tracking 결과로 얻은 key frame을 삽입한다. 이 때 covisibility graph, spanning tree, bags of words도 함께 업데이트한다. 다음으로 추적성과 삼각측량이 잘못되지 않았는지 맵 포인트들을 검사한 뒤, 연결된 key frame에서 얻은 triangulating ORB를 사용해 새로운 맵 포인트를 생성한다. 만약 ORB가 매칭되지 않으면 다른 key frame에서 매칭시켜본다. 매칭은 epipolar constraint를 만족해야 한다.(이론적으로 서로 다른 두 시점에서 획득한 두 이미지에 대해 5개 이상의 매칭쌍이 있으면 두 카메라 시점 사이의 3차원 관계 및 매칭점들의 3D 위치를 복원할 수 있음을 이용) local bundle adjustment를 수행하여 맵 상의 3차원 포인트들을 key frame에 투영시킨 위치와 해당 영상 프레임에서 실제 관측된 위치의 차이가 최소화되도록 위치를 조정한다. 마지막으로 중복되는 key frame을 검사하고 제거하는 과정을 통해 검사할 key frame이 줄어들면서 좀 더 효율적으로 동작하도록 한다.
+
마이크로서비스란 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로, 애플리케이션을 상호 독립적인 최소 구성 요소로 분할한다. 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀리식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 동일한 작업을 수행하기 위해 함께 작동한다. 이러한 각각의 구성 요소 또는 프로세스가 마이크로서비스이다. 이러한 소프트웨어 개발 접근 방식은 세분화, 경량화되어 있으며 유사한 프로세스를 다수의 애플리케이션 간에 공유할 수 있다는 특징이 있다. 이는 클라우드 네이티브 모델 구현을 위해 애플리케이션 개발을 최적화하는 데 필요한 주요 구성 요소이다.
−
**Loop Closing 단계에는 마지막 key frame으로 loop를 검사하고 닫는 작업을 수행함으로써 map의 오차를 줄인다. 먼저 loop 후보를 검색한다. 현재 key frame에서 bag of words를 이용해 유사도를 구하고 제일 낮은 점수를 임계점으로 잡는다. 이제 recognition database에서 방금 구한 임계점보다 낮은 key frame들과 현재 프레임과 직접 연결된 key frame을 버린다. 이를 통해 후보를 구한다. 다음으로 similarity transformation을 계산한다. 다음으로 루프를 융합한다. 중복된 맵 포인트를 융합하고 covisibility graph에 새로운 edge를 삽입한다. 마지막으로 효율적으로 loop를 닫기 위해 pose graph optimazation을 한다.
+
 
 +
여기서 마이크로서비스 기반 인프라를 사용하려는 이유가 무엇인지를 파악해야 한다. 단순히 개발자의 목표는 고품질 소프트웨어를 보다 신속하게 제공하는 것이다. 마이크로서비스는 이 목표를 실현하기 위한 수단이 되며, 이때 고려해야 할 사항이 있다. 바로 애플리케이션을 마이크로서비스로 분할하는 것만으로는 충분하지 않다는 사실이다. 애플리케이션을 관리하고 오케스트레이션하며 여기서 생성되고 수정되는 데이터를 처리해야 한다.
 +
 
 +
*Container
 +
Linux 컨테이너는 시스템의 나머지 부분과 격리된 프로세스 세트. 이러한 프로세스를 실행하는 데 필요한 모든 파일은 고유한 이미지에서 실행되므로, Linux 컨테이너는 개발 단계에서 테스트, 프로덕션에 이르기까지 이식성과 일관성을 유지할 수 있다. 따라서 전통적인 테스트 환경을 복제하는 개발 파이프라인보다 훨씬 더 빠른 배포를 실현할 수 있다.
 +
 
 +
컨테이너란, 애플리케이션을 개발하고 있다고 가정해 보자.노트북으로 작업하며 특정하게 설정된 환경을 사용하고 있다. 이때 다른 개발자들의 환경 설정은 약간 다를 수 있다. 현재 개발 중인 애플리케이션은 이 설정을 사용하고 특정 라이브러리, 종속성 및 파일에 의존하고 있으며, 그런 한편 회사는 자체 설정과 지원 파일 세트에 준하여 표준화된 개발 및 프로덕션 환경을 갖추고 있다. 이때, 서버 환경을 재구축하는 부가적인 작업 없이 가능한 로컬에서 이러한 환경을 에뮬레이션하려고 한다. 그렇다면 어떻게 이러한 환경 전체에서 애플리케이션이 작동되게 하고, 품질 검사를 통과하고, 큰 문제나 수정 없이 애플리케이션을 배포할 수 있을까에 대한 답은 바로 '컨테이너'를 사용하는 것입니다.
 +
 
 +
====SW 기능====
 +
*스트리밍
 +
1. API를 사용하여 Azure Media Services v3에서 라이브 스트림
 +
LiveEvents는 Azure Media Services에서 라이브 스트리밍 콘텐츠를 처리하는 작업을 담당한다. LiveEvent는 라이브 인코더에 제공할 입력 엔드포인트(수집 URL)를 제공한다. LiveEvent는 라이브 인코더에서 라이브 입력 스트림을 수신하여 하나 이상의 StreamingEndpoints를 통해 스트리밍하는 데 사용할 수 있도록 한다. 또한 LiveEvents는 스트림을 추가로 처리하고 배달하기 전에 미리 보고 유효성을 검색하는 데 사용되는 미리 보기 엔드포인트(미리 보기 URL)을 제공한다.
 +
 
 +
2. Amazon App 2.0에서 라이브 스트림
 +
Amazon AppStream 2.0은 완전관리형 애플리케이션 스트리밍 서비스이다. AppStream 2.0을 통해 중앙에서 데스크톱 애플리케이션을 관리하고 모든 컴퓨터의 브라우저로 안전하게 제공할 수 있다. 하드웨어 또는 인프라를 구매, 프로비저닝 및 운영할 필요 없이 전 세계 모든 사용자로 손쉽게 확장할 수 있다. AppStream 2.0은 AWS상에 구축되었으므로 가장 보안에 민감한 조직을 위해 설계된 데이터 센터 및 네트워크 아키텍처를 활용할 수 있다. 애플리케이션이 특정 사용 사례에 최적화된 가상 머신(VM)에서 실행되고 각 스트리밍 세션이 네트워크 상태에 맞춰 자동으로 조정되므로, 각 사용자는 GPU 집약적 3D 디자인 및 엔지니어링 애플리케이션을 비롯하여 자신의 애플리케이션에서 원활하고 응답성이 뛰어난 경험을 할 수 있다.
 +
엔터프라이즈에서는 AppStream 2.0을 사용하여 애플리케이션 제공을 간소화하고 클라우드로의 마이그레이션을 완료할 수 있다. 또한, 애플리케이션을 다시 작성하지 않고도 전체 Software-as-a-Service(SaaS) 솔루션을 개발할 수 있습니다.
  
−
*Darknet 설명
+
*커맨드 입력 전달
−
**[[파일:9조_Darknet.png]|Darknet Layers]
+
C#의 소켓 프로그래밍과 키보드, 마우스 이벤트 핸들러를 활용하여 키보드, 마우스 이벤트를 클라이언트가 서버로 전달한다. 프로그램은 .NET Framework로 구성된 windows 전용 exe 파일이며, JRemote 라이브러리를 사용하여 제작하였다. 서버와 클라이언트 사이의 소켓을 생성하여 제어 요청, 요청 수신, 화면전송, 화면 수신, 이벤트 전송, 이벤트 수신의 단계를 거친다. 마우스 이벤트는 가상 커서를 만들어 이용한다.  
−
**Darknet은 Joseph Redmon이 독자적으로 개발한 신경망 프레임워크(neural network framework)로서 DNN(deep neural network)의 학습 레이어들을 배치시키고 실행시킬 수 있는 틀(framework)이다. DNN은 인간의 뇌가 패턴을 인식하는 방식을 모사한 알고리즘으로 입력 레이어와 출력 레이어 사이에 여러 개의 히든 레이어들로 이루어진 인공신경망이다. 각 레이어에서 나온 결과값(추출된 특징값)을 다음 레이어의 입력으로 주고 최종적으로는 이를 통해 분류나 군집화 작업을 수행할 수 있다. YOLO도 Darknet을 이용하여 학습된 신경망(결과물) 중 하나이다. Darknet을 이용하면 YOLO 뿐만 아니라 AlexNet, VGG-16, Resnet, Densenet 등 기존의 정통 주류의 DNN(Deep Neural Network)들도 돌려 볼 수 있다.
+
클라이언트는 서버의 ip 주소를 입력하고 viewer를 실행시켜 서버의 화면을 원격으로 조종한다. 서버는 클라이언트가 자신의 화면을 활용 할 수 있게 서버 프로그램을 실행시킨다.
−
 
−
*YOLO(You Only Look Once)
 
−
**YOLO는 각 이미지를 S x S 개의 그리드로 분할하고, 그리드의 신뢰도를 계산한다. 신뢰도는 그리드 내 객체 인식 시 정확성을 반영한다. 다음 그림과 같이 처음에는 객체 인식과는 동떨어진 경계 상자가 설정되지만, 신뢰도를 계산하여 경계 상자의 위치를 조정함으로써, 가장 높은 객체 인식 정확성을 가지는 경계 상자를 얻을 수 있다.  
 
−
**[[파일:9조_YOLO1.jpg|YOLO 객체 검출 시스템]]
 
−
**그리드의 객체 포함 여부를 계산하기 위해, 객체 클래스 점수를 계산하고 이 결과로 총 S x S x N개의 객체가 예측된다. 이 그리드의 대부분은 낮은 신뢰도를 가진다. 신뢰도를 높이기 위해 주변의 그리드를 합치고 이후에 임계값을 설정해 임계값 이하의 불필요한 부분은 제거할 수 있다. 아래 그림을 통해 30% 신뢰도 임계값을 설정함으로써 많은 그리드가 제거됨을 알 수 있다.
 
−
**[[파일:9조_YOLO2.png|신뢰도 설정 이전 그리드 결과]]
 
−
**[[파일:9조_YOLO3.jpg|YOLO 신경망 구성 및 그리드 신뢰도 계산 후 제거된 그리드]]
 
−
**YOLO는 단순한 처리로 속도가 매우 빠르다. 기존 다른 real-time 비전 기술과 비교할 때, 2배 정도 높은 성능을 보인다. 이미지 전체를 한 번에 바라보는 방식으로 클래스를 분별한다.
 
  
 +
*가상화 및 가상화 관리
 +
각 서비스를 컨테이너화 해서 클라우드 컨테이너 관리 플랫폼으로 관리한다.
  
−
===상세설계 내용===
+
====SW 구조====
−
*Usecase Diagram
+
서비스 제공 방식은 크게 3가지로 나뉜다. P2P 원격제어 방식, 스트리밍 서비스 플랫폼, 클라우드 원격제어 방식이다. P2P 원격제어 방식은 서버 컴퓨터를 클라이언트가 원격으로 제어하는 방식으로 이루어진다. 이 경우에, 서버는 게임 사용자를 위한 게임 맞춤 서버 환경을 제공해야 할 것이며, 보안상의 문제로 인해 게임 이외의 다른 리소스들에 대한 접근을 원천적으로 봉쇄해야 한다. 현재 클라우드 서비스를 제공하고 있는 기업들의 서비스를 원격제어해도 될 것이다.  
−
**[[파일:9조_UseCaseDiagram.png]]
 
  
−
*UI Diagram - CAM UI
+
두 번째는 스트리밍 플랫폼이다. 사용자는 자신이 플레이하고 있는 게임을 언제든지 실시간으로 스트리밍 할 수 있으며, 영상 클립 또한 저장하여 나머지 플레이어들과 자신의 플레이를 즐기고 공유 할 수 있다. 게임 플레이어는 OBS를 활용해서 자신의 게임플레이를 x.264로 AWS에 전송하고 AWS에서는 h.264로 인코딩하여 서버에 접속할 수 있는 모든 사용자에게 게임 화면을 배포할 수 있다.  
−
**[[파일:9조_UIDiagram - CAM UI.png]]
 
−
**Checkbox (On-Off):
 
−
***Localization Mode: 기존 특징점만을 이용한 Tracking 활성화 여부
 
−
***Show Points: CAM Frame 위에 특징점 출력 여부
 
−
***Show Model: CAM Frame 위에 AR 모델 출력 여부
 
−
**Button:
 
−
***Set AR Model: 클릭 시, 인식할 사물과 부착할 AR 모델을 설정할 수 있는 창을 띄운다.
 
−
***Start SLAM: 클릭 시, 영상 열기 창을 띄우고 영상을 선택하면 해당 영상에 대해 슬램 알고리즘을 실행한다.
 
−
***Exit: 클릭 시, 해당 프로그램을 종료한다.
 
−
**CAM Frame: 슬램 알고리즘이 실행되면 화면에 영상을 출력한다. 화면의 아래 쪽에 슬램 알고리즘의 상태를 출력하고 체크박스 설정에 따라 특징점과 AR 모델을 화면 위에 출력한다.
 
  
−
*UI Diagram - MAPPING UI
+
3번째 방식은 클라우드 원격제어 방식이다. 사용자는 클라우드 환경에서 배포하는 가상머신에 접근하여 게임을 즐기게 된다. 이 경우에 가상환경이기 때문에 microservice와 container 배포 개념이 포함되며, 게임을 제공하는 클라우드 서버에서 기본적으로 게임을 탑재할 수 있는 사양이 되어야 한다.
−
**[[파일:9조_UIDiagram - Mapping UI.png]]
 
−
**Checkbox (On-Off):
 
−
***Show Key Frames: Mapping Frame 위에 Key Frames 출력 여부
 
−
***Show Graph: Mapping Frame 위에 Covisibility Graph 출력 여부
 
−
**Button:
 
−
***Save Mapped Model: 클릭 시, 경로를 입력할 수 있는 창을 띄운다. 경로가 입력되면 해당 경로에 맵핑 정보가 담긴 파일을 저장한다.
 
−
***Load Mapped Model: 클릭 시, 파일을 열 수 있는 창을 띄운다. 파일을 선택하고 올바른 파일 형식이라면 해당 모델을 로드한다. Localization Mode가 on일 때만 사용가능하다.
 
−
***Reset: Mapping Frame을 초기화한다.
 
−
**Mapping Frame: 슬램 알고리즘이 실행되고 SLAM ON 상태가 되면 추정한 카메라의 위치를 중심에 두고 인식된 특징점들을 카메라의 시점에 따라 회전시켜 화면에 출력한다. 체크박스 설정에 따라 Key Frame과 Covisibility Graph를 화면 위에 출력한다.
 
  
 
==결과 및 평가==
 
==결과 및 평가==
 
===완료 작품의 소개===
 
===완료 작품의 소개===
 
====프로토타입 사진 혹은 작동 장면====
 
====프로토타입 사진 혹은 작동 장면====
−
*[[파일:9조시연_Moment0-1.jpg]]
+
*원격제어 시스템
−
*AR 모델로 사용할 3D 모델 FBX 파일과 세이브/로드에 사용되는 맵 바이너리 파일은 실행 파일과 같은 경로에 저장한다.
+
[[파일:원격제어.jpg]]
  
−
*[[파일:9조시연_Moment0-2.jpg]]
+
*스트리밍 서비스
−
*프로그램을 실행하면 영상을 촬영할 카메라 장치를 선택한다.
+
- 메인페이지
  
−
*[[파일:9조시연_Moment1.jpg]]
+
[[파일:메인페이지.jpg]]
−
*카메라를 선택하고 나면 영상을 받아와 SLAM 알고리즘을 수행하면서 현재 SLAM의 상태를 카메라 프레임 아래에 표시해준다.
 
−
*카메라 프레임에 영상에서 인식한 물체를 바운더리로 표시하고 인식한 특징점들을 출력한다.
 
−
*Draw Points 체크박스를 통해 특징점을 화면 위에 출력할 것인지의 여부를 결정할 수 있고, Localization 체크박스를 통해 특징점 추출은 잠시 멈추고 위치 계산만을 진행하는 Localization 모드로 설정할 것인지를 결정할 수 있다.
 
  
−
*[[파일:9조시연_Moment2-1.jpg]]
+
- 스트리밍
−
*[[파일:9조시연_Moment2-2.jpg]]
 
−
*SLAM 알고리즘을 수행하면서 계산한 3D 맵 포인트를 비롯한 맵 정보를 Mapping Frame에 출력한다. 녹색 직사각형은 현재 카메라 프레임의 위치를 나타내고, 붉은 점들은 현재 카메라의 위치를 추정하는 데 사용된 3D 맵 포인트를 의미하고 검은 점들은 사용되지 않은 포인트를 의미한다.
 
−
*왼쪽의 Show Key Frame, Show Graph 체크박스를 통해 Key Frame 또는 Covisibility Graph를 화면 위에 출력할 것인지의 여부를 결정할 수 있고 Localization 체크박스를 통해 Localization 모드로 설정할 것인지를 결정할 수 있다. Follow Camera 체크박스를 통해 모드를 끄거나 켜서 카메라를 움직였을 때 Mapping Frame에서 맵 포인트들을 이동하게 할 것인지 현재 카메라 프레임을 이동하게 할 것인지 여부를 결정할 수 있다.
 
−
*Mapping Frame에서 마우스의 클릭이나 스크롤을 이용해 화면을 회전하거나 확대할 수 있다.
 
  
−
*[[파일:9조시연_Moment3.jpg]]
+
[[파일:스트리밍1.jpg]]
−
*Plane Detect 버튼을 클릭하면 인식된 평면 위에 AR 모델을 부착한 영상을 Cam Frame에 출력한다.
+
 
−
*Object Detect 버튼을 클릭하면 인식한 물체 위에 AR 모델을 부착한 영상을 Cam Frame에 출력한다.
+
[[파일:스트리밍2.jpg]]
−
*Clear All 버튼을 클릭하면 부착된 AR 모델들을 모두 제거한다.
 
−
*Play Animation 체크박스를 통해서 AR 모델에 적용된 애니메이션을 실행할 것인지 여부를 결정할 수 있다.
 
−
*AR 모델은 적당한 3D 모델과 텍스처 파일을 미리 설정해두면 이용할 수 있기 때문에  다른 모델로도 해당 기능을 사용할 수 있다.
 
−
*왼쪽의 메뉴를 통해 AR 모델에 대해서 크기 설정이 가능하다.
 
−
*Draw Grid 모드를 끄거나 켜서 인식한 평면을 격자로 영상에 표현하게 할 것인지 여부를 결정할 수 있고 격자의 형태도 왼쪽 메뉴에서 조절할 수 있다.
 
  
 
====포스터====
 
====포스터====
 +
[[파일:포스터2.jpg]]
 +
  
 
===관련사업비 내역서===
 
===관련사업비 내역서===
−
*[[파일:9조_사업비내역서.png]]
+
[[파일:개발비.jpg]]
 +
 
  
 
===완료작품의 평가===
 
===완료작품의 평가===
−
[[파일:완료평가.jpg|가운데]]
+
[[파일:완료평가2.jpg]]
 +
 
  
−
===향후평가===
+
===결론===
−
*깊이 카메라 등을 활용하기 힘든 드론을 비롯한 모노 카메라를 이용한 드론의 자율 주행이나 장애물 인식 기능 자체 또는 모니터링 기능에 해당 기술을 적용할 수 있을 것으로 전망하였다. 추출한 맵 정보들은 포인트 클라우드에 mesh를 만들어 적절한 가공을 거쳐 모델링을 하면 영화 또는 VR 등에 사용할 수 있는 가상공간의 모델로 이용될 수 있을 것으로 전망하였다. 인식한 물체에 AR 모델을 부착하는 기능은 물체의 레이블별로 구별되는 AR 모델을 붙이거나 하는 방식을 이용하여 AR을 이용한 증강현실 전시관을 비롯한 다양한 응용에서 활용할 수 있을 것으로 전망하였다.
+
*실시간 영상 스트리밍은 해상도 960X540, Bitrate 2000k, 30fps에서  약 15초의 딜레이를 발생시키고 성공했으며  네트워크 환경이 좋을 경우 더 빠른 응답속도를 보여주었다.
 +
*커맨드 입력 전달을 위한 원격 조종의 경우 로컬 연결은 성공하였으나 Client와 Server의 거리가 멀리 떨어져 있는 경우에는 실패하였다.

2018년 12월 19일 (수) 10:45 기준 최신판

프로젝트 개요

기술개발 과제

  • 국문 : 클라우드 서비스를 이용한 게임 스트리밍 서비스
  • 영문 : Game streaming service using cloud service

과제 팀명

  • 9조

지도교수

  • 김진석 교수님

개발기간

  • 2018년 9월 ~ 2018년 12월 (총 4개월)

구성원 소개

  • 서울시립대학교 컴퓨터과학부 2015920040 임원경(팀장)
  • 서울시립대학교 컴퓨터과학부 2015920014 김태현
  • 서울시립대학교 컴퓨터과학부 2014920066 채철민
  • 서울시립대학교 컴퓨터과학부 2013920016 김영탄

서론

개발 과제의 개요

개발 과제 요약

저사양 PC소유 게이머에게 컴퓨팅 파워를 제공함으로써 저사양 PC나 콘솔에서도 적절한 비용를 지불하여 고사양의 게임을 즐길 수 있도록 할 것이다. 고사양 게임의 랜더링 작업을 고성능의 중앙 서버를 통해 수행하고 수행 결과를 인터넷으로 저사양 PC소유자에게 전달하여 컴퓨팅 파워를 제공함으로써 저사양 PC나 콘솔에서도 고사양의 게임을 즐길 수 있도록 하는 클라우드 게임 스트리밍 플랫폼을 구축할 것이다.

개발 과제의 배경

  • 최근 출시되는 게임들이 요구하는 PC 권장사양이 높아지고 있는 가운데 장비 교체 비용에 대한 부담때문에 현재 사용하고 있는 PC를 업그레이드 하지 못하는 사람이 늘고 있다.
  • PC뿐만 아니라 모바일, 게임 콘솔등 다양한 단말들을 통해 게임이 출시되고 있지만, 독점 콘텐츠의 경우 해당 단말을 구매하지 않으면 플레이 할 수 없는 경우가 있다.

개발 과제의 목표 및 내용

  • 콘텐츠를 PC나 모바일에서 원격으로 컨트롤 가능하도록 개발한다.
  • 콘텐츠에 명령을 입력한 결과를 스트리밍 서비스를 이용해 실시간으로 사용자에게 제공한다.
  • 도커를 활용해 단일 플랫폼 기반의 서비스를 다양한 플랫폼에서 이용 가능하도록 설계한다.
  • 원활한 스트리밍이 가능하도록 동영상 재생을 위한 적절한 코덱을 적용한다.
  • 사용자가 쉽게 접근할 수 있도록 범용성에 집중하여 UI/UX를 제작한다.


관련 기술의 현황

관련 기술의 현황 및 분석(State of art)

  • Playkey
플레이키.jpg

채굴자가 PC를 대여하여 저사양 컴퓨터를 가진 사용자에게 게임을 할 수 있도록 컴퓨팅 파워를 제공하는 플랫폼이다. 플레이키는 원래 클라우드 플랫폼으로써 2~3년간 서비스를 통해서 2017년 기준 유럽에 250만이 넘는 고객을 확보했다. 최근 플레이키는 블록체인을 도입함으로써 공공성 확보 뿐 아니라, 채굴 네트워크를 통해 GPU연산을 저사양 PC, 콘솔을 분배 하도록 하는 플랜을 가지고 있다.

  • Parsec

Parsec은 주로 비디오 스트리밍을 통해 클라우드 기반 게임에 사용되는 데스크톱 캡처 응용 프로그램이다. Parsec을 사용하면 인터넷 연결을 통해 비디오 게임 장면을 스트리밍 할 수 있으므로 PC에서 게임을 실행할 수 있지만 원격으로 재생할 수 있다. Parsec은 대기 시간이 적은 데스크톱 공유 소프트웨어로 사용할 수도 있다. 독점 프리웨어 응용 프로그램 인 Parsec은 최신 운영 체제에서 사용할 수 있다. Parsec은 Amazon Web Services 및 Paperspace에서 호스팅하는 사전 구성된 가상 시스템에 대한 프로비저닝 및 연결을위한 간단한 사용자 인터페이스를 제공한다. 2018년 1 월 Parsec은 Hewlett-Packard와 파트너 관계를 맺고 HP Omen PC를 위해 특별히 설계된 Parsec의 기술을 기반으로하는 무료 클라우드 게임 서비스 인 OMEN Game Stream을 개발했다.

  • OnLive

OnLive는 2009년 GDC에서 발표된 기술이다. 2010년에는 윈도우와 Mac 등의 데스크탑을 대상으로 서비스를 시작하였다. OnLive의 주력제품은 클라우드 게임 서비스로 가입자가 게임을 단말에 설치하지 않고 렌트하여 플레이하거나 데모플레이를 하는 것이었다. 게임은 로컬장치에서 랜더링 하지 않고 OnLive의 클라이언트 소프트웨어를 이용해 서버에서 랜더링 한 후에 스트리밍을 통해 동영상으로 전달되었다. 서비스는 PC, 모바일, TV, 게임 콘솔의 장치를 통해 사용가능했다. 키보드와 마우스를 사용하는 PC와 달리 TV와 모바일 장치는 마이크로콘솔과 연동되는 전용 무선 컨트롤러를 사용해 동작했다. 네트워크 대역폭의 한계로 인하여 데이터센터로부터 1000마일까지만 서비스가 가능했기에 2012년 기준 5곳의 데이터센터를 건설해서 운용했다. 또한 원활한 영상 서비스를 위해 자체개발한 비디오 압축칩, 자체 비디오 코덱을 사용했다. 2015년에 OnLive의 관한 특허를 Sony에 판매하여 모든 서비스를 종료하였다.

  • GaiKai

GaiKai는 2008년 네덜란드에서 창립되었다. 게임의 디지털 배급을 위해 개발되었으며 기존의 게임서비스를 대체하기보다는 새로 나온 게임 타이틀에 대한 홍보시장을 목표로 하였다. 데모 OnLive와 마찬가지로 서버 상에서 비디오 게임을 실행시키고 랜더링된 결과를 인터넷을 통해 사용자에게 전달한다. 그러나 사용자 단말에 설치된 Java 또는 Adobe Flash,Silerlight 플러그인 사용해 동영상 스트리밍을 하기 때문에 별도의 코덱이 아닌 표준 동영상 코덱(MPEG-4, H.264)를 통해 동작이 가능하다. 사용자는 별도의 장비나 소프트웨어의 설치 없이 웹브라우저를 통해 데모 게임을 실행할 수 있었고 개발자 입장에서는 게임 코드가 외부에 유출되지 않고 패치나 업글레이드가 용이한 장점이 있다. 또한 트위터나 페이스북 상의 링크를 공유해 친구들과 멀티플레이가 가능하도록 설계되었다.

  • 스팀 스트리밍 서비스

게임 플랫폼 스팀에서 제공하는 서비스로 “Steam in-home streaming”이라고도 한다. 집안에 2대의 컴퓨터가 있는 경우 같은 계정으로 같은 네트워크에 있는 두 컴퓨터를 스팀 클라이언트에 로그인 한 뒤에 게임을 실행하면 된다. 이를 통해 Window 전용 게임을 다른 OS의 PC로도 플레이가 가능하다. 또한 “스팀링크”라는 것이 존재하는데, 스팀링크는 별도의 공유기를 통해 스팀이 설치된 PC와 TV를 연결하는 기기이다. 유선으로 공유기와 PC를 연결하고 Wifi로 휴대폰을 연결한 뒤 휴대폰 상의 스팀 앱을 통해 동작을 입력하고 그 결과를 TV화면에 보여준다. 저렴한 가격에 콘솔기기를 가진듯한 효과를 얻을 수 있지만 어느 정도 PC사양과 네트워크 사양을 갖춰야 한다는 단점이 있다.

시장상황에 대한 분석

  • 목표시장

최근 출시되는 게임들이 요구하는 PC 권장사양이 높아지고 있는 가운데 장비 교체 비용에 대한 부담 때문에 현재 사용하고 있는 PC를 업그레이드 하지 못하고 사양이 부족해서 해당 게임을 즐기지 못하거나, 특정 게임이 콘솔이나 PC에서만 게임이 동작하여 전용 단말 없이는 그 게임을 즐기지 못하는 경우가 발생하고 있다. 이들이 게임을 플레이 할 수 있도록 컴퓨팅 파워를 제공하여 수익을 창출하거나 혹은 게임을 구매하기 전에 데모 플레이를 제공하여 해당 게임의 구매 결정을 도와주는 역할을 할 수 있을 것이다.

  • 목표시장의 성장추세
규모 그래프.jpg

한국콘텐츠진흥원에서 제공하는 2017년 대한민국 게임백서에 따르면 2016년 국내 게임시장 규모는 10조 8945억 원으로 5조 1436억 원을 기록한 2007년 이후로 지속적으로 성장해왔다. 특히 2016년 매출액 기준 온라인 게임이 4조 6464억 원(점유율 42.6%)으로 전체 게임시장에서 차지하는 비중이 가장 큰 것으로 나타났고, 모바일 게임도 4조 3301억 원(점유율 39.7%)로 온라인 게임시장 못지않은 규모를 보여줬다. 뒤이어 비디오게임, PC게임이 각각 2627억, 323억의 매출을 기록했다. 다만 주목해야 할 점은 PC게임시장이 전년대비 –14.8%의 성장률을 보인 반면, 모바일 게임시장이 전년대비 24.3%의 성장률을 보여줬다는 점이다. 이를 통해 게이머들이 PC게임 보다는 모바일 게임에 좀 더 관심이 있다는 것을 알 수 있었다. 또한 비디오게임의 경우 전년대비 무려 58.1%의 성장률을 보여주면서 비교적 비디오게임의 성적이 저조했던 우리나라에서는 꽤 의외의 결과라고 할 수 있다. 이를 통해 게이머들이 더 이상 PC에만 한정되지 않고 모바일, 게임 콘솔 등 다양한 플랫폼에서 제공하는 다양한 게임을 즐기는 것을 택하고 있다는 것을 알 수 있다.

설명

위와 같이 국내 게임시장이 점차 성장해 가는 가운데 세계 게임시장 또한 2016년에 1428억 1400만 달러를 기록하며 전년 대비 6.4% 성장하는 결과를 보여주고 있다. 이렇게 다양한 플랫폼에서 게임을 하길 원하는 사용자들을 위해 다양한 기업이 게임 스트리밍 시장에 진입했다. Steam의 경우 “Steam Link”라는 자체 개발한 공유기를 통해 개인용 컴퓨터를 이용해 스트리밍을 지원하도록 하고 구글, 삼성과 제휴를 맺어 Android 마켓, 갤럭시 Apps에서 연결이 가능하도록 하였고 삼성 스마트 TV에서도 스팀링크를 App을 설치할 수 있게 했다. 또한 비디오 그래픽회사인 nvidia에서는 “NVIDIA GRID”라는 클라우드 게이밍 시스템을 발표하여 다양한 단말에서 실행 가능한 멀티플랫폼 게임 시스템을 구축하였다.

  • 마케팅 전략

- 최근에 출시된 모바일 게임들도 PC게임 못지않게 사양이 점점 증가하면서 오래된 저사양의 휴대폰으로는 게임을 플레이 할 수 없는 상황이 자주 발생하고 있다. 최신 휴대폰의 경우 100만원을 호가하는 가격으로 게임을 위해서 구매하기엔 부담스러운 가격일수 있다. 이를 해결하기 위해서 PC에서 모바일 게임을 작동시켜주는 다양한 앱플레이어들이 생겼지만 본래 화면터치를 사용하여 동작하도록 설계된 게임을 키보드, 마우스를 통해 조작을 해야 하는 어색함이 있고 일부 게임의 경우 앱플레이어를 지원하지 않아 플레이 할 수 없는 경우도 있다. 또한 앱플레이어를 사용할 경우 PC를 켜야 하므로 언제 어디서든 즐길 수 있다는 모바일 게임의 특징이 사라지는 단점이 생긴다. 그러므로 저사양의 모바일 유저에게 위와 같은 것을 적극 어필하여 적은 구독료로 이용할 수 있는 서비스를 제공하면 큰 관심을 얻을 수 있을 것이다.

- 2017년에 3월 출시된 “배틀그라운드”라는 게임은 배틀로얄이라는 신선한 장르와 다양한 변수들을 특징으로 전 세계적으로 엄청난 인기를 얻었다. 그러나 출시 당시 최적화문제로 높은 사양의 PC스펙을 요구하였기 때문에 게임은 3만원인데 제대로 플레이하려면 본체를 구매하기 위해 100만원이 더 든다는 우스갯소리도 있을 정도였다. 이는 개인뿐만 아니라 PC방을 운영하는 사업자들에게도 큰 타격을 줬었는데 배틀그라운드를 플레이 할 수 없는 피시방은 사람들이 찾지 않았기 때문에 점포마다 여러 대의 PC를 업그레이드 하느라 엄청난 비용이 소모되었다. 그런데 또 안타까운 것은 그런 배틀그라운드의 열기가 금세 사그라졌다는 것이다. 실제 배틀그라운드는 18년 1월까지만 하더라도 동시접속자 320만명을 달성하고 국내 PC방 점유율 1위를 굳건하게 지켰지만 18년 11월 현재, 동시접속자 80만명에 국내 PC방 순위도 크게 추락하고 있다. 만약 배틀그라운드 열풍 당시에만 클라우드 게이밍 서비스를 구독하고 인기가 줄어든 다음에는 구독해지를 했다면 PC방 사업자들은 많은 돈을 절약할 수 있었을 것이다. 이렇게 PC방과 같이 여러 대의 PC를 운용하는 사업자에게 클라우드 게임 스트리밍 서비스를 적극적으로 홍보하면 많은 수익을 거둘 수 있을 것으로 예상된다.


개발 과제의 기대효과

기술적 기대효과

  • 사용자 입장에서는 추가적인 장비 설치 없이 모바일이나 콘솔에서 고품질 3D 어플리케이션을 실행할 수 있고, 프로그램을 단말이 아닌 서버에 설치하고 업데이트 하므로 사용자는 용량 부담 없이 편하게 게임을 즐길 수 있다.
  • 회사 입장에서는 게임 패치 및 업그레이드 적용이 데이터 센터의 서버에서 이루어지기 때문에 업그레이드가 용이하고 불법 복제의 위험이 없다. 또한, 사용자의 이용 패턴을 서버에 저장하여 게임 콘텐츠 개선이나 오류 디버깅에 이용할 수 있다.

경제적, 사회적 기대 및 파급효과

  • 별도로 장비를 구입하지 않아도 고사양 게임을 플레이 할 수 있게되어 PC방과 같이 다수의 PC를 사용하는 영업장의 경우 PC 업그레이드 비용이 감소하여 창업 및 유지가 지금보다 수월해질 것이다.
  • 저사양의 모바일로도 최신게임을 즐길 수 있게 되어서 게임을 위해서 고가의 휴대폰을 구매하지 않아도 될 것이다.


기술개발 일정 및 추진체계

개발 일정

개발일정.jpg

구성원 및 추진체계

  • 임원경 - 팀장, 웹 개발
  • 김태현 - 소프트웨어 테스트
  • 채철민 - 스트리밍 서비스 구축
  • 김영탄 - 소프트웨어 유지보수

설계

설계사양

제품의 요구사항

  • Client가 요청한 계산을 대신 수행할 수 있는 고성능의 PC 또는 서버
  • Streaming Delay를 감소시키기 위한 원활한 유무선 네트워크(속도 100mbps 이상)
  • 고화질 영상을 서비스하기 위한 데이터 압축기술

개발 환경

  • 하드웨어

- 100mbps 이상의 속도를 유지할 수 있는 네트워크 환경

- i5 이상의 CPU를 가진 PC

  • 개발 환경

- Windows10 운영체제

- .NET Framework

- Amazon Web Service

- Docker


개념설계안

  • 개념설계
개념설계.jpg

클라이언트가 서버에 게임에 대한 계산요청을 전송하면 서버는 해당 계산을 대신 수행한 결과를 영상으로 클라이언트에게 전송한다. 이때 효율적인 실시간 영상 전송을 위해 다양한 압축기술을 활용한다. 게임을 진행하면서 클라이언트가 키보드나 마우스 동작과 같은 명령을 입력하면 서버는 이를 인식하고 그에 대한 알맞는 계산을 수행한다.


사용 관련 기술 및 알고리즘

  • 실시간 스트리밍 기술
흐름.png

OBS Studio는 단순히 영상을 녹화, 방송하는 툴이다. 내부에서 영상 화질이나 bitrate, audio 및 압축 기법을 설정할 수 있으며 촬영된 영상을 RTMP 방식으로 AWS medialive에 보낸다. RTMP는 미리 데이터를 다운 받지 않고 시청하고 있는 프레임만 전송하는 기법으로, 이미 시청한 데이터는 폐기한다. OBS Studio에서 AWS medialive로 영상을 인코딩해서 전송하는데 H.264 코덱을 사용하지 않고 X.264를 사용해서 전송한다. 굳이 X.264를 사용한 이유는 X.264가 H.264에 비해 인코딩 성능이 앞서고 영상 압축시에 소모하는 자원이 H.264에 비해 적어서 저사양 장비를 가지고 있는 Client가 사용하기 더 적합할 것으로 예상되었기 때문이다. AWS meidallive는 입력된 영상을 압축 및 인코딩 하는 AWS 서비스이다. OBS Studio로부터 영상을 받게 되면 사용자가 여러 화질에서 시청이 가능하도록 화질에 따라서 여러 개의 output을 만들어 서비스 유형에 맞게 재인코딩을 진행한다. 인코딩을 실시할 때 H.264를 사용하며 여러 출력 유형의 인코딩된 영상을 medialpackage로 보낸다. AWS mediapackage는 AWS medialive에서 생성된 output 영상들을 뿌려주는 역할을 한다. 이때 여러 output 영상들을 HLS 방식으로 Client에게 서비스 할수 있게 m3u8의 확장자를 지닌 여러개의 URL을 생성해준다. HLS는 하나의 영상을 시간단위로 조각낸 ts파일을 재생목록 파일인 m3u8과 함께 HTTP를 통해 전송하는 방식으로 별도의 영상변형을 요구하지 않아 서버 비용이 절약된다. 이렇게 생성된 URL을 이용해 웹에서 동작이 가능해진다.


상세설계 내용

SW 특징

  • Microservice

마이크로서비스란 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로, 애플리케이션을 상호 독립적인 최소 구성 요소로 분할한다. 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀리식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 동일한 작업을 수행하기 위해 함께 작동한다. 이러한 각각의 구성 요소 또는 프로세스가 마이크로서비스이다. 이러한 소프트웨어 개발 접근 방식은 세분화, 경량화되어 있으며 유사한 프로세스를 다수의 애플리케이션 간에 공유할 수 있다는 특징이 있다. 이는 클라우드 네이티브 모델 구현을 위해 애플리케이션 개발을 최적화하는 데 필요한 주요 구성 요소이다.

여기서 마이크로서비스 기반 인프라를 사용하려는 이유가 무엇인지를 파악해야 한다. 단순히 개발자의 목표는 고품질 소프트웨어를 보다 신속하게 제공하는 것이다. 마이크로서비스는 이 목표를 실현하기 위한 수단이 되며, 이때 고려해야 할 사항이 있다. 바로 애플리케이션을 마이크로서비스로 분할하는 것만으로는 충분하지 않다는 사실이다. 애플리케이션을 관리하고 오케스트레이션하며 여기서 생성되고 수정되는 데이터를 처리해야 한다.

  • Container

Linux 컨테이너는 시스템의 나머지 부분과 격리된 프로세스 세트. 이러한 프로세스를 실행하는 데 필요한 모든 파일은 고유한 이미지에서 실행되므로, Linux 컨테이너는 개발 단계에서 테스트, 프로덕션에 이르기까지 이식성과 일관성을 유지할 수 있다. 따라서 전통적인 테스트 환경을 복제하는 개발 파이프라인보다 훨씬 더 빠른 배포를 실현할 수 있다.

컨테이너란, 애플리케이션을 개발하고 있다고 가정해 보자.노트북으로 작업하며 특정하게 설정된 환경을 사용하고 있다. 이때 다른 개발자들의 환경 설정은 약간 다를 수 있다. 현재 개발 중인 애플리케이션은 이 설정을 사용하고 특정 라이브러리, 종속성 및 파일에 의존하고 있으며, 그런 한편 회사는 자체 설정과 지원 파일 세트에 준하여 표준화된 개발 및 프로덕션 환경을 갖추고 있다. 이때, 서버 환경을 재구축하는 부가적인 작업 없이 가능한 로컬에서 이러한 환경을 에뮬레이션하려고 한다. 그렇다면 어떻게 이러한 환경 전체에서 애플리케이션이 작동되게 하고, 품질 검사를 통과하고, 큰 문제나 수정 없이 애플리케이션을 배포할 수 있을까에 대한 답은 바로 '컨테이너'를 사용하는 것입니다.

SW 기능

  • 스트리밍

1. API를 사용하여 Azure Media Services v3에서 라이브 스트림 LiveEvents는 Azure Media Services에서 라이브 스트리밍 콘텐츠를 처리하는 작업을 담당한다. LiveEvent는 라이브 인코더에 제공할 입력 엔드포인트(수집 URL)를 제공한다. LiveEvent는 라이브 인코더에서 라이브 입력 스트림을 수신하여 하나 이상의 StreamingEndpoints를 통해 스트리밍하는 데 사용할 수 있도록 한다. 또한 LiveEvents는 스트림을 추가로 처리하고 배달하기 전에 미리 보고 유효성을 검색하는 데 사용되는 미리 보기 엔드포인트(미리 보기 URL)을 제공한다.

2. Amazon App 2.0에서 라이브 스트림 Amazon AppStream 2.0은 완전관리형 애플리케이션 스트리밍 서비스이다. AppStream 2.0을 통해 중앙에서 데스크톱 애플리케이션을 관리하고 모든 컴퓨터의 브라우저로 안전하게 제공할 수 있다. 하드웨어 또는 인프라를 구매, 프로비저닝 및 운영할 필요 없이 전 세계 모든 사용자로 손쉽게 확장할 수 있다. AppStream 2.0은 AWS상에 구축되었으므로 가장 보안에 민감한 조직을 위해 설계된 데이터 센터 및 네트워크 아키텍처를 활용할 수 있다. 애플리케이션이 특정 사용 사례에 최적화된 가상 머신(VM)에서 실행되고 각 스트리밍 세션이 네트워크 상태에 맞춰 자동으로 조정되므로, 각 사용자는 GPU 집약적 3D 디자인 및 엔지니어링 애플리케이션을 비롯하여 자신의 애플리케이션에서 원활하고 응답성이 뛰어난 경험을 할 수 있다. 엔터프라이즈에서는 AppStream 2.0을 사용하여 애플리케이션 제공을 간소화하고 클라우드로의 마이그레이션을 완료할 수 있다. 또한, 애플리케이션을 다시 작성하지 않고도 전체 Software-as-a-Service(SaaS) 솔루션을 개발할 수 있습니다.

  • 커맨드 입력 전달

C#의 소켓 프로그래밍과 키보드, 마우스 이벤트 핸들러를 활용하여 키보드, 마우스 이벤트를 클라이언트가 서버로 전달한다. 프로그램은 .NET Framework로 구성된 windows 전용 exe 파일이며, JRemote 라이브러리를 사용하여 제작하였다. 서버와 클라이언트 사이의 소켓을 생성하여 제어 요청, 요청 수신, 화면전송, 화면 수신, 이벤트 전송, 이벤트 수신의 단계를 거친다. 마우스 이벤트는 가상 커서를 만들어 이용한다. 클라이언트는 서버의 ip 주소를 입력하고 viewer를 실행시켜 서버의 화면을 원격으로 조종한다. 서버는 클라이언트가 자신의 화면을 활용 할 수 있게 서버 프로그램을 실행시킨다.

  • 가상화 및 가상화 관리

각 서비스를 컨테이너화 해서 클라우드 컨테이너 관리 플랫폼으로 관리한다.

SW 구조

서비스 제공 방식은 크게 3가지로 나뉜다. P2P 원격제어 방식, 스트리밍 서비스 플랫폼, 클라우드 원격제어 방식이다. P2P 원격제어 방식은 서버 컴퓨터를 클라이언트가 원격으로 제어하는 방식으로 이루어진다. 이 경우에, 서버는 게임 사용자를 위한 게임 맞춤 서버 환경을 제공해야 할 것이며, 보안상의 문제로 인해 게임 이외의 다른 리소스들에 대한 접근을 원천적으로 봉쇄해야 한다. 현재 클라우드 서비스를 제공하고 있는 기업들의 서비스를 원격제어해도 될 것이다.

두 번째는 스트리밍 플랫폼이다. 사용자는 자신이 플레이하고 있는 게임을 언제든지 실시간으로 스트리밍 할 수 있으며, 영상 클립 또한 저장하여 나머지 플레이어들과 자신의 플레이를 즐기고 공유 할 수 있다. 게임 플레이어는 OBS를 활용해서 자신의 게임플레이를 x.264로 AWS에 전송하고 AWS에서는 h.264로 인코딩하여 서버에 접속할 수 있는 모든 사용자에게 게임 화면을 배포할 수 있다.

3번째 방식은 클라우드 원격제어 방식이다. 사용자는 클라우드 환경에서 배포하는 가상머신에 접근하여 게임을 즐기게 된다. 이 경우에 가상환경이기 때문에 microservice와 container 배포 개념이 포함되며, 게임을 제공하는 클라우드 서버에서 기본적으로 게임을 탑재할 수 있는 사양이 되어야 한다.

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

  • 원격제어 시스템

원격제어.jpg

  • 스트리밍 서비스

- 메인페이지

메인페이지.jpg

- 스트리밍

스트리밍1.jpg

스트리밍2.jpg

포스터

포스터2.jpg


관련사업비 내역서

개발비.jpg


완료작품의 평가

완료평가2.jpg


결론

  • 실시간 영상 스트리밍은 해상도 960X540, Bitrate 2000k, 30fps에서 약 15초의 딜레이를 발생시키고 성공했으며 네트워크 환경이 좋을 경우 더 빠른 응답속도를 보여주었다.
  • 커맨드 입력 전달을 위한 원격 조종의 경우 로컬 연결은 성공하였으나 Client와 Server의 거리가 멀리 떨어져 있는 경우에는 실패하였다.
원본 주소 "https://capstone.uos.ac.kr/cdc/index.php?title=9조(블록체인)&oldid=913"