운영체제#17

LeeMir, 07 June 2021

7강 - Multimedia Operating Systems

Multimedia
  • 특징
    • Data rate가 굉장히 높음(ex: 영화)
    • 실시간으로 처리해야 함(dead line 존재)
  • 하나의 멀티미디어 파일에는 다양한 내부 파일이 존재
    • 영상, 음성, 자막(각 나라별), Fast Forward, Fast Backward
  • Video Encoding
    • 옛날 브라운관 TV에는 전자총을 쏴서 화면을 표시함
      • 홀수라인 먼저 표시하고 다시 처음으로 이동해서 짝수라인 표시(인터레이싱)
        • 홀수 짝수 상관 없이 순서대로 표시하는 방법은 프로그래시브 방식이라고 함
  • Audio Encoding
    • 아날로그 신호를 Sampling해 디지털 신호로 변환
    • 이 때, 애매한 소수 같은 부분은 양자화(Quantizing)해 처리함
  • Fourier Transformation(푸리에 변환)
    • 복잡한 아날로그 신호를 간단한 삼각함수들의 연산으로 변환해 줌
    • 컴퓨터에 저장할 때에는 a sin b에서 a와 b의 값만 저장
      • 즉, 각 주파수에 해당하는 세기만을 따로 저장
    • 모든 구간을 다 저장해버리면 용량이 너무 커짐
      • 따라서 세기가 큰 부분만을 골라서 저장함으로써 압축이 가능
      • 주파수는 높을 수록 미세한 변화를 나타내므로 낮은 주파수에 해당하는 값을 잘 저장하는 게 중요
JPEG
  • 정지 영상, 사진 압축
  • 640 x 480이 표준 크기
    • 24-bit pixel
  • RGB로 이루어진 사진을 Y(명암), I(녹색), Q(붉은색)로 분할함
    • Y는 1 블록 당 8-bit pixel 단위로 640 x 480 크기로 저장
    • I와 Q는 320 x 240 크기로 축약해서 저장
    • 평면의 pixel들을 지그재그 형태로 순회해 일렬의 신호처럼 만듦
    • 이를 푸리에 변환을 통해 주파수 대 세기 데이터를 만듦
    • Quantization table을 통해 데이터를 양자화(낮은 주파수 성분은 그대로, 높은 주파수 성분은 없앰)함
    • 이렇게 압축한 것을 다시 화면으로 구성하면 원본이랑 형태는 비슷하면서 용량은 줄임
      • 유손실 압축
MPEG
  • 동영상 압축
  • 정지 영상에 대해서는 JPEG으로 압축할 수 있으니, frame을 압축
  • frame 종류
    • I frame(Intracoded) : JPEG로 압축된 사진
    • P frame(Predictive) : 앞의 frame과의 차이만 저장
    • B frame(Bidirectional) : 앞 frame과 뒤 frame의 차이를 저장
      • frame을 재생성하는 순서가 복잡해짐
  • I frame만으로도 영상을 구성할 수 있으나, P frame과 B frame을 도입해 압축률을 높임
Audio Compression
  • 푸리에 변환을 통해 압축 & 재합성
  • 가청 주파수 영역 밖은 저장할 필요 없음
  • 한 주파수에 매우 센 세기의 소리(신호)가 있을 경우, 그 주변은 저장할 필요가 없음(masking effect)
  • Audio 형태
    • Monophonic
    • Dual monophonic
      • Monophonic인데 English soundtrack과 Korea soundtrack이 존재
    • Disjoint stereo
      • 양쪽 채널을 분리해 각각 저장
    • Joint stereo
      • 양쪽 채널을 최대한 공통적인 부분은 공통으로 저장하고 다른 부분은 따로 저장
Real-Time Scheduling
  • Task마다 Deadline이 존재해 그 안에 실행되어야 함
  • 각 Task는 Periodic하게 수행
    • 한 주기 안에 무조건 한 번은 실행해야 함
    • 같은 순서로 실행될 필요는 없고 주기 안에만 실행하면 됨
  • 철저히 우선순위에 기반해 스케쥴링 함
    • Deadline을 지키기 위해
  • Rate Monotonic Scheduling(RMS)
    • Rate : Hz
      • 1 / 주기
    • Rate가 높을 수록 높은 우선순위를 부여함
    • 각 Task의 Utilization(실행시간 / 주기)의 총합이 n(2^(1/n)) - 1보다 작거나 같을 경우 무조건 스케쥴링이 가능
      • n은 Task의 개수
      • 이 조건에 해당하지 않더라도 스케쥴링이 가능한 경우가 있음
    • 스케쥴링 조건
      • 각 프로세스(Task)가 각 주기 안에 완료되어야 함
      • 각 프로세스는 서로 독립적이어야 함
        • 서로 자원을 공유하는 관계 X
      • 각 프로세스는 각 주기마다 같은 시간의 CPU 수행 시간을 가져야 함
      • Nonperiodic 프로세스는 deadline이 없음
      • 문맥 교환은 어떠한 overhead 없이 즉시 수행되어야 함
        • 이라고 가정
    • 스케쥴이 시작하기 전, 스케쥴이 되는지 검사한 후 진행
      • meta period까지 스케쥴을 그려보면 알 수 있음
        • meta period : 각 Task의 period의 최소 공배수
        • meta period 이후는 반복임
      • 새로운 Task가 들어왔을 때에도 스케쥴이 되는지 검사
  • Earliest Deadline First Scheduling(EDF)
    • Deadline이 가까운 Task가 높은 우선순위를 가짐
    • RMS로 못하는 스케쥴링을 EDF로 할 수 있음
      • EDF로 안되는데 RMS로 되는 경우도 있음
      • RMS는 계산으로 스케쥴 가능 여부를 판단할 수 있으나, EDF는 그려봐야 함
  • Priority Inversion(우선순위 역전)
    • 공유 자원을 사용하는 Task들이 lock / unlock을 할 동안 우선순위 낮은 Task가 중간에 끼어들어 우선순위를 역전해버리는 경우가 생김
    • Deadline에 도달할 가능성이 커짐
  • Priority Inheritance(우선순위 상속)
    • 다른 Task를 깨울 때 우선순위를 상속해줘 제 3의 Task가 중간에 끼어들 수 없도록 함
Multimedia File System Paradigms
  • 기존의 Video server - Client는 pull server였음
    • Client가 Request를 보내야 server에서 video block을 보내줌
    • 그러나 Video server에는 push server가 어울림
      • 각 Block에 대한 Request가 아닌, Video 하나에 대한 Request만으로 server에서 block을 순차적으로 보내는 방식
  • Near Video on Demand
    • 만약 1000명의 사용자가 동시(완전 동시가 아닌 조금씩 다른 시간대)에 영화를 시청한다면 1000개의 연결을 구성해야할까?
    • 2시간(120분)짜리 영상을 5분 단위로 24개 stream으로 구성하면 효율적으로 처리할 수 있음
      • 그러나 사용자는 5분 단위로 맞춰 요청하지 않음
        • 5분 단위에서 사용자가 요청한 시간만큼은 따로 연결을 구성해 데이터를 받고, 그 외는 5분 단위 stream에서 받음
  • Placing a File on a Single Disk
    • 한 영화 파일을 Disk에 어떻게 저장할 것인가
    • Video 따로, Audio track 따로, Text track 따로 구역을 나눠 저장하면 헤드의 동선이 매우 비효율적임
    • 따라서 영화를 frame 단위로 나눠 frame당 Video Audio Text으로 순차적으로 구성
  • File Organization Strategies
    • Small disk block일 경우
      • Frame Index Table 존재
      • 한 frame을 여러 disk block에 걸쳐 배치
      • 공간 낭비는 작으나 Frame Index Table 때문에 RAM 사용량이 heavy함
    • Large disk block일 경우
      • Block Index Table 존재
      • 한 disk block에 여러 frame이 들어감
      • disk block에 frame이 들어가지 못하는 작은 공간이 남을 수 있어 공간 낭비 발생
      • 낭비되는 공간을 줄이기 위해 frame을 split함, 다만 두 개의 block에 걸쳐 frame이 저장되기 때문에 추가적인 탐색이 필요함
  • Placing Files for Near Video on Demand
    • 매 초마다 모든 stream을 해당 사용자들에게 보내줘야 함
    • 한 track에 각 stream에 대한 frame을 저장
    • 헤드의 움직임을 최소화
  • Placing Multiple Files on a Single Disk
    • 여러 개의 영화 파일을 disk에 어떻게 배치할 것인가?
    • 인기 있는 영화를 가운데 track에 배치
      • 헤드의 동선을 최적화하기 위함
  • Placing Files on Multiple Disks
    • 영화 파일들을 여러 개의 disk에 어떻게 배치할 것인가?
    • 한 disk에 한 파일씩 저장하면 인기 영화가 담긴 disk만 많이 사용됨
    • 따라서 각 영화를 여러 disk에 나눠 저장
      • 그러나 영화 특성상 앞부분이 가장 많이 읽힘
        • 따라서 나눠서 저장할 때 순서를 Random하게 저장하거나 골고루 사용될 수 있도록 세밀하게 순서 조정해 저장
  • Block Caching
    • User 1과 User 2가 같은 영화를 요청했는데, User 2가 10초 늦게 요청
      • 두 개의 연결을 만들어야 하는가?
    • 사용자가 느낄 수 없는 정도로 User 1은 느리게, User 2는 빠르게 재생해 둘의 sync를 맞춰 하나의 stream으로 merge
  • Static Disk Scheduling
    • 수많은 stream에서 disk에 데이터 요청
    • 요청한 데이터를 track 순으로 정렬 후 scan algorithm에 따라 scan
  • Dynamic Disk Scheduling
    • 요청은 주기적으로 같은 시간에 오지 않음
      • 무차별적으로 옴
    • 실시간 스케쥴링에는 deadline이 필수인데 scan algorithm에는 deadline 개념이 존재하지 않음
    • 만약 EDF로 처리한다면 헤드가 무리하게 움직일 수 있음
    • 이를 절충해, deadline 순으로 정렬한 후 몇 개를 묶어 그 안에서 track 순으로 정렬하고 scan algorithm을 수행함