Author Archives: babyworm

20차 JCTVC meeting

20차 JCTVC meeting / 111차 MPEG meeting.

잊기 전에 몇가지 적어놔야지.. 항상 나중에 정리하려고 하다가 회사일하면서 까먹어서..

  1. JCTVC / SCC

Screen contents(말하자면.. 컴퓨터 화면..)를 잘 coding하기 위한 HEVC의 확장판을 만들고 있는데, 지난번에 갔던 삿포로 미팅에서 WD(working draft)가 나왔고, 이번에 PDAM(proposed draft amendment; 말하자면 표준화를 위한 초안)이 나왔습니다. (사실 아직 안나왔습니다. 미팅 끝나고 3주 내로 만들기로 한거라..)

삿포로에 갔을때만 해도 CfP 다음 단계라, 이런 저런 툴을 한꺼번에 많이 테스트 중이었는데, 이번엔 CE도 3개 밖에 없어서 아주 심플해졌더군요.

그럴만도 한 것이 많은 툴 들이 이전에 RExt 등에서 이미 제안되었다가 개선 정도가 한정되어 있다는 이유로 밀렸던 건데.. SCC에는 잘 맞는 툴 들인 경우가 있어서 그렇습니다. 즉 완전히 새로운 건 없다는 말도 됩니다만..

가장 중요한 변경 사항은 intra block copy(IBC)가 inter mode와 unification되었다는 점인데요. 이 과정에서 스펙에 많은 변경이 있었고, 여러 기고문 중에서 기존의 MC와 같이 동작할 수 없는 것들은 모두 보류되었습니다.  (제가 IBC쪽 track을 거의 들어가서..)

덩달아 CE3로 명맥을 유지하고 있던 intra line copy, intra string copy는 IBC에 비해서 명백하게 좋다는 증거를 보이지 못해서 더 이상 CE를 유지하지 않기로 결정되었습니다. ILC의 경우 IBC의 보조적인 정도의 gain을 가지고 있어서 그렇고(IBC가 이전처럼 별도의 모드였다면 곁가지로 넣을 만도 한데, unification 이후엔 MC의 동작을 바꾸면서 까지 고려할 정도로 매력적이지는 않게 된 거죠.), ISC의 경우 444 lossless에서는 장점이 있지만 1) 필요한 메모리의 양을 줄일 수 있는 방법이 없다는 점, 2) Palette mode와 경쟁하는데 크게 marit가 없다는 점  때문에 더 이상 CE로 연구되지 않기로 했습니다.

물론, ISC의 경우 좀 더 study가 되었음 좋겠다는 이야기는 있었습니다만… string copy를 위한 dictionary 생성, 유지에 들어가는 메모리를 줄일 수 있는 방법을 찾지 못했고, 이 메모리를 줄이기 위해서 search range를 줄이면 성능이 떨어지는 상태라 어찌 될지 모르죠.

이번 미팅이 비교적 빠른 시간안에 끝났는데(보통은 아침 9시에 시작해서 밤 9시, 10시까지인데 반해 이번에는 9시 30분에 시작 밤 8시 30분 이전에 끝났고, 예정보다 하루 일찍 끝나는 기염을..), 위의 unification 결정으로 기인하는 거죠.

이제 남은 건 IBC를 다듬어 나가는 건데, IBC가 loop filter를 거치지 않은 데이터를 사용해야 해서, 메모리 저장 공간과 bandwidth 문제가 있습니다. 이 부분을 위해서 CE2가 생성되었는데, 사실 CE2 자체에는 아직 별 내용이 없고, 다음 회의에서는 CE2관련된 제안들이 있겠죠. (이 부분에 대해서 재미있는 것들이 있을 수 있겠습니다만, 실험해볼 시간이 있을지나 모르겠습니다..)

Palette mode의 경우 크게 많은 기고문이 있었는데, 크게 개선된 건 없다고 보는 것이 맞을 것 같습니다. 좀더 refinement 하기 위해서 다시 CE1이 생성되었습니다.

  1. MPEG / video.

2-1.
지난 미팅에서 future codec에 대한 req.를 모았던 것 같은데요. 대략 6회사들이 관련된 제안 & brainstorming이 있었고(전 지난 미팅을 안가서, 이번 미팅에서 요약된 것을 보고, 관련 발표자료만 봤습니다. ) 이번 미팅에서 관련해서 다시 관련 TV 업체들의 의견들이 포함된 미팅이 있었습니다.

지난 미팅의 발표자료들을 보니 많은 회사에서, RExt가 부족하다는 의견(사실 high dynamic range와 larger color gamut에 대한 요구와 더불어)가 있어서, HEVC RExt에 이 요구를 만족시킬 수 있는지 확인해 보기로 했습니다. (CfE) 사실, 위의 부분에 대해서 별 관심이 없어서 잘 몰랐는데(YUV420 format만 다루니까.), 상당수의 회사들이 의견을 제시하고 있더군요.

압축률에 대해서는 현재보다  50%이상의 bitrate를 줄여야만 한다는 의견(원래 MPEG에서 물어본 것이 대략 25%만 줄이면 받아들일 만 하겠냐.. 라는 거라서..)이 있었고, 2025년까지는 어떻게든 해보라는..

화면 크기는 생각보다 커지지 않을 거라 다들 예측하고 있고.. frame rate와 color depth부분에 대해서는 많은 concern이 있는 정도고..

2-2.
예전에 봤을때는 VCB(video codec for browser. 즉, vp8)가 IVC (internet video codec)보다 훨씬 좋았는데, 이번에 나온 결과로는 IVC가 많이 좋아져서 VCB를 넘어서 H.264 HP에 근접(아직 차이는 있지만)하는 정도까지 도달했다고 주장했습니다. 잘되면 좋겠다는 생각과 흥미가 좀 있어서 중간에 BoG를 들어갈까 하다가 사람도 너무 적고 사실 좀 minor한 codec이라서 그냥 video plenary를 계속 들었는데.. 음.. 들어가볼껄 그랬다는 생각이 듭니다.

2-3.
tutorial로 genome data processing

data compression에 genetic algorithm을 이용하나.. 하고 들어갔는데 실은 말 그대로 genome data를 어떻게 잘 압축할 수 있는지 물어보기 위해서 genome data를 어떻게 처리하고 있는지 알려주는 자리였음.

생명공학을 하는 마누라 덕분에 in-vivo, in-vitro 같은 내용도 알아들어서 좋기는 했는데, 이걸 왜 MPEG에서.. 게다가 정식으로 AHG에서 다룬단다. (이미 들어와 있더군..) 데이터가 크고, 나중에 활용 부분이 많으니까 압축  전문가들이 압축할 수 있는 방법을 고안해봐.. 이런 느낌이랄까요..


설날과 겹치면서 돌아오는 비행기 예약이 힘들어서 금요일 plenary를 보지 못하고 돌아와야 하는 것이 약간 아쉽지만.. 같이 갔던 동료분이 같이 열심히 들어줘서 상당히 충실한 Meeting이었네요.

초등학교 코딩 교육..

어제 밤에 적은 글인데, DB를 날려서 다시 작성합니다.  

얼마전 딸래미 초등학교 예비 소집 때문에 초등학교에 갔다가 방과후 학습을 하는 것을 보게 되었는데, Kodu를 사용하고 있더군요. 초등학교에서 배우는 걸 보니, 역시 영어때문에 어려워하더군요..

 

한 1년전 쯤(작년 4월 포스팅에도 있지만..)에 딸래미도 Kodu를 좋아했는데, 이때 영어 때문에 어려워해서 Kodu 개발자와 한글화 관련해서 메일을 주고 받았었더랬죠.
당시 XNA에서 폰트 렌더링 문제 때문에 한글 지원이 어렵다고 메일을 받았는데(아래는 메일 내용의 일부), 생각해보니 급한대로 완성형에서 지원하는 글자만이라도 렌더링하자고 해 볼까 싶기도 하네요(2350자 밖에 지원되지 않을테니 반쪽짜리가 될텐 별로 맘에 들지는 않지만..). 왠지 XNA가 더 좋아질지도 좀 불확실하고 하니까요..

The problem is that XNA requires us to convert all the fonts we use to textures.  These textures need to contain every glyph at every size used.  Currently Kodusupports ~1900 glyphs in 10 fonts/sizes.  This is by far the biggest cost we have during build time.  Adding Korean glyphs (Hangul) would add about 13,000 more glyphs.  At one point I tried adding a similar number of glyphs for Chinese.  The build went on for several hours and then failed.  Unfortunately this is going to prevent us from supporting most East Asian languages.

 

Scratch 역시 점점 세를 넓혀가고 있는 것 같습니다. Mindstorm 제어가 실질적으로 Scratch라서 비슷하네.. 하고 생각하고 있었는데, scratch를 이용해서 Android app을 만들 수 있는http://ai2.appinventor.mit.edu/ 도 있네요. (요건 어떤 분이 만든 한글 교재  http://www.srook.net/wpaper/635577391625625000)

최근에 꽤나 유명해진 http://code.org 역시 실제로는 scratch라 할 수 있죠(음.. visual programming이 다 비슷한 건지는 잘 모르겠지만.. ). 사실은 게임 프로그래머가 희망 사항이라는 우리 딸래미도 scratch editor만 이용할 때는 거의 그림 위주로 놀았는데, code.org를 접하면서는 약간씩 논리를 잡아가는 느낌입니다.

 

요즘에는 제가 Unity를 배우고 있는데, 주변에 누군가 게임 프로그래밍에 아주 간단한 platform이라고 해서 본 건데요.. (딸래미가 알려달라고 옆에서 하도 떼를 써서.)

음.. 간단하기는 한데, 문자로 coding해야 하고, 이를 위해서는 영어를 좀 읽을 수 있어야 해서 딸래미한테 알려주려면 한 3년은 있어야 할 것이고.. 그 기간이면 저도 unity를 알려줄 만큼 익숙해지지 않을까 하는 희망이 드네요.. 딸래미 덕분에 공부하네요.. 🙂

정말 좋네요. 🙂

EDA playground

오랫만에 포스팅하네요.

사실 그동안 심신을 지치게 했던 project를 마무리했기 때문에 비교적 가벼운 마음이 되었습니다.

오늘 소개할 것은 EDA playground 라는 사이트입니다.

http://www.edaplayground.com/home

 

그 동안 UVM이니 뭐니 이야기를 많이 했는데, 직장인 분들은 회사 밖에서는 뭔가를 할 수 없는 환경이라서 집에서는 간단한 공부하기도 쉽지 않았을 것입니다. (물론 능력 되시는 분들께서는 좋은 시뮬레이터를 사용하실 수 있으시겠지만 말이죠..)

위의 사이트에서 아주 간단한 예제 정도는 처리해 줄 수 있습니다.

물론, 개인적으로 환경을 구성하는 것이 속도나 관리 면에서 더 좋겠지만, 간단한 것 정도는 위의 사이트에서 파일들을 추가하고 테스트 해 보면 되니까 개인적으로는 비교적 쓸만 한 것 같습니다.

한 가지 단점(?)은 Waveform viewer가 GTKwave를 Web으로 보여주는 거라 써서 보는 거라.. 기능이 좀 약하고, 제어가 불편하다는 정도.. 그래도 대충 해보는데 문제는 없습니다.

제 생각에는 학부 수업 정도까지는 cover 하는데 별 문제가 없을 것으로 보이네요.

 

또하나, EDAplayground에 보면  이런 저런 예제들과 간단한 Verilog tutorial을 가지고 있으니, 초보자 분들께도 도움이 될 것으로 보입니다. (로그인도 Facebook 혹은 Google 계정으로 가능하고..)

오랫만에 괜찮은 사이트인 것 같습니다.