KorSA

[ 증상 ] 영상 frame streaming에서 원형 큐를 사용하여 frame을 관리하고 있었다. frame이 Queue의 size만큼 수신되면 원형 큐는 가득차게 되는데, 다음 frame을 받기 위해 나는 Queue에 존재하는 맨 처음 frame과 맨 마지막 frame의 시간 차가 일정 간격(period A라 하자)이상 차이가 나면 맨 앞의 frame을 버리는 정책을 취하였다. 하지만 이 과정에서 한 가지 버그가 발생하였는데, 이는 Queue에 frame이 가득차는 시간이 period A 보다 짧게 걸릴 경우, 맨 앞의 frame은 절대 버려지지 않는 것이었다. 이로 인해 새로 수신되는 frame들도 꽉찬 Queue에 들어가지 못하는 현상이 발생하였다. [ 해결 ] 그래서 나는 매 frame을 수신할..

[ 증상 ] 회사에서 영상 렌더링을 위한 Bitmap Create / Draw 코드를 고칠 일이 있었다. Bitmap Create 하는 구간과 Bitmap Draw 하는 구간을 하나의 mutex로 locking하였다. 이상없이 잘 되나 했더니 화면이 자꾸 껌벅껌벅 거리는 것이었다. [ 원인 ] 이유는 Bitmap Create가 시간을 많이 잡아먹어서 Draw가 제대로 수행되지 않았던 거였다. Bitmap Create 하면서 lock을 계속 잡고 있기 때문에, 같은 mutex를 사용하는 Bitmap Draw영역은 lock 구간에 들어가지 못하고 기다린다. [ 조치 ] lock을 걸 때에는 최대한 lock 구간 내부에서 빨리 빠져나와야 한다. 그래서 Bitmap Create 하는 부분을 locking 범위에..

[ 증상 ] 회사 프로그램에서 RTSP 영상을 렌더링하고 있었는데 특정 컴퓨터에서 영상이 지연되는 현상이 발생하였다. 플레이 시간이 길어질수록 VLC로 받은 영상 화면과 회사 프로그램에서 받은 영상 화면과의 시간 차가 점점 더 벌어졌다. 처음엔 두 프로그램 모두 비슷한 영상 화면을 보여주었는데, 점점 회사 프로그램의 영상 화면이 뒤늦게 플레이되고 있었다. [ 원인 ] 회사 프로그램에서 렌더링을 하기 위한 frame queue를 만들어서 수신한 frame들을 관리하는데, 이 frame queue에 frame이 너무 많이 쌓인 게 원인이었다. 즉, queue에서 frame을 Pop 하는 속도보다 Push 하는 속도가 더 빨랐던 것이다. 이러한 이유로 queue에는 처리되지 못한 frame들이 점점 쌓여갔고,..

1. Color Channel - 8 bit, 16 bit 등의 bit로 한 색깔을 메모리 상에서 표현함 몇몇 format에서는 꼭 8의 배수를 사용하지는 않는다. 그러나 byte align은 맞추어준다. 예를 들어 5bit로 한 color channel을 표현할 경우 3 channel은 15bit의 공간을 차지하지만, byte align을 위해 8의 배수인 16bit 공간을 사용한다. 마지막 1bit는 패딩인 것이다. +) 참고로, RGB를 예로 들어볼 때 Color Channel 은 R 하나, G 하나, B 하나를 의미한다. 2. 픽셀을 나타내는 format은 여러 가지가 있다. 디지털 이미지의 color channel structure는 다양함 WIC(Windows Imaging Component)..