18년차 개발자의 멀티미디어 코덱개발 이야기

sayhi7의 이미지

KELP 와 제 블로그에 제가 작성했던 내용을 여기에도 올려 봅니다 ...

제가 올해 나이가 45 인데요 대학원을 졸업하고 대기업도 다녀봤고, 그후 프리랜서로 간간이 개발용역을 맡아서 처리했었고요 펌웨어 개발을 주로 개발용역을 하다보니 신경쓸 일은 많은데 들어오는 수입이 많지 않더군요 ... 그래서 4 - 5 년전에 생각한것이 OS 포팅쪽도 생각해 보다가 요근래 3 년 동안은 이동방송용 멀티미디어 코덱개발 관련한 일을 주로 하고 있읍니다 현재는 OS 에서 하는 작업은 WinCE 상에서 코덱을 최적화 설계하는쪽을 손대고 있구요

오디오 코덱쪽도 제일 처음에 시작한 일이 MPEG 규격문서를 찬찬히 분석하는 일이었고 규격문서 분석하다가 부족한 부분은 레퍼런스 소스를 분석하니까 어느정도 해결이 되는것 같읍니다

맨 처음에 분석한 오디오 디코더가 T-DMB 용 BSAC 이었는데 스펙트럼 데이타를 비트슬라이스로 디코딩하는 부분을 쉽게 이해가 안갔었는데 한 두달 보니까 이해가 가더군요 스펙트럼 데이타 디코딩을 분석하고나서 역양자화, PNS, TNS, 윈도우/필터뱅크 등을 분석하는데에도 한달 정도는 걸린것 같구요

오디오 디코더를 테스트 하려면 오디오 렌더링 기술이 필요한데 이것도 VS2005 에서 코덱출력인 PCM 데이타를 웨이브 파일로 만든후 WAVE 파일을 플레이하는 방식으로 테스트하고 있죠

WAVE 파일도 2 채널을 처리하는게 일반적인데 5.1 채널까지 처리할수 있는 WAVE 파일구조까지 분석이 끝나갑니다.

HE-AAC V2 디코더가 요즘 많이 사용되고 있는데 AAC LC 디코더 설계기술이 필요하고 여기에 SBR 디코더 설계기술과 PS 디코더 설계기술이 필요하지요 저는 다행히 이 설계기술을 85 % 분석이 끝난 상태라서 크게 걱정할 부분은 없는것 같읍니다

현재 서라운드 코덱의 개발을 많이들 하시는데요 서라운드 디코더의 경우 aacPlus 설계기술이 있으면 큰 어려움 없이 설계할수 있을것 같읍니다 서라운드 디코더의 경우 레퍼런스 소스를 어느 사이트에서 공개중인지 알지 못한데 MPEG 포럼에 정식회원 가입을 하면 정보를 얻을수 있으니 추후 가입해서 서라운드 코덱 관련한 레퍼런스 소스를 얻을 생각 입니다

어떤 자료를 보니까 HE-AAC V2 디코더의 출력이 2 채널 QMF 필터뱅크 인데 서라운드 코덱은 이것을 5.1 채널채널 QMF 필터뱅크로 확장해서 설계하는 구조인것 같읍니다.

H.264 디코더를 VS2005 로 올초에 코딩을 시작했는데요 코덱 코딩작업전에 약 일년정도 MPEG 규격자료를 찬찬히 분석작업을 했구요 MPEG 규격자료 분석작업이 어느정도 성과가 있어서 2009 년 1 월초부터 코딩을 시작한거지요

T-DMB 용용 H.264 디코더 S/W 설계를 1 월에 코딩을 시작하면서 처음에 가장 막혔던 부분이 T-DMB 스트림에서 H.264 비디오 압축데이타만을 따로 분리해내는 과정이 힘들구요 또한 T-DMB 방송스트림에서 H.264 파싱을 오류없이 처리하는게 쉽지 않더군요 지금까지도 이것과 관련된 오류가 있을 정도로 아주 까다로운 처리가 필요합니다. 현재는 해결방법을 겨우 찾아서 다행이긴하지만요

저의 경우 H.264 디코더 S/W 설계를 하면서 MPEG 규격자료를 참조해서 소스를 코딩했거든요 대부분의 사람들이 JM 소스를 50 % 이상 사용하고 나머지 JM 소스를 최적화해서 상용화하는게 일반적인데요

저의 경우 JM 소스를 한줄도 제 소스에 사용하지 않았기 때문에 예상치 못했던 오류가 많이 발생해서 이걸 디버깅하느라 짧게는 하루 잇틀에 해결되지만 길게는 한달이 넘게 걸려서 해결되는 경우도 꽤 있었거든요

현재는 하두 시행착오를 겪다보니 T-DMB 방송스트림을 하나는 JM 소스에 입력하고 다른 하나는 제가 설계한 소스에 입력해서 두 소스가 동작하는 과정에서 어떤 차이를 보이면서 동작하는지 추적을 통해 오류가 발견되면 디버깅 작업을 하고 있죠

현재 Visual Studio 2005 에서 H.264 디코더 S/W 를 설계중 인데 이제서야 코덱 제품화에 앞길이 보인다고 할까요 한 7 달 고생하니까 서광이 비추는것 같읍니다.

요즘 오디오코덱 동향이나 관련 이야기를 해볼까 합니다. 제가 요즘 관심을 가지고 있는게 서라운드 오디오 코덱쪽 입니다 ... ETRI 에서도 AT-DMB 관련해서 연구를 진행중이기도 하고요 ... 서라운드 코덱은 기존의 오디오코덱 + 서라운드 Synthesis 의 구조를 갖고 있죠 ... Parametric Stereo 의 확장된 형태라서 HE-AAC V2 코덱의 PS 디코더 부분의 이해가 있으면 좀 더 쉽게 접근할수 있읍니다. 서라운드 코덱의 레퍼런스 소스는 기존의 MPEG 사이트에서 공개하는듯 합니다.

오디오코덱 관련해서는 HE-AAC V2 디코더 S/W 설계기술을 85 % 이상 보유하고 있어서 Parametric Stereo 의 확장형태인 서라운드 코덱의 설계가 가능하고요 또 H.264 모바일용과 HD 용 설계기술을 모두 보유하고 있어서 H.264 SVC 디코더 설계의 기본은 갖추고 있기 때문에 SVC 디코더의 알고리즘을 추후 분석을 진행하면 충분히 SVC 의 개발이 가능하지요

현재 저는 H.264 Baseline Profile 디코더의 설계기술을 MPEG 규격자료 분석과 JM 소스분석을 병행하여 획득할수 있었으며 유명대학 교수님과 정부출연 연구소 관계자분의 도움을 받을수 있었기에 100 % 기술자립에 성공할수 있었읍니다.

Forums: 
madman93의 이미지

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

rgbi3307의 이미지

고급기술에 대해서 말씀해 주셔서 감사합니다.
그런데, 몇가지 궁금한 사항을 질문해도 될런지요.

Visual Studio 2005의 C로 코딩 하셨다면, 윈도우(WinCE)상에서만 동작하는지요?
WinCE 가 제공하는 라이브러리를 이용한 부분은 없는지요?
그리고,
ARM이나 MIPS 아키텍쳐의 Linux 환경에서도 동작되는 것인지 궁금합니다.
마지막으로,
"현재 차세대 비디오코덱인 NGVC(Next Generation Video Coding) / HVC(High Performance Video Coding) 표준제정이 준비중입니다." 라고 언급하신 부분이 MPEG 사이트에서 준비중인 것인지,
필자님께서도 연구하여 구현하고 있는 것인지도 궁금합니다.

From:
*알지비 (메신저: rgbi3307(at)nate.com)
*학창시절 마이크로마우스를 만들었고, 10년동안 IT관련 개발자로 일하고 있음.
*틈틈히 커널연구회(http://www.kernel.kr/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

From:
*알지비 (메일: rgbi3307(at)nate.com)
*틈틈히 커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

정태영의 이미지

ITU-T와 MPEG이 함께 차세대 코덱에 대한 표준화를 준비하고 있고, 다음 달 말에 열리게 될 미팅에서 Call for Proposal을 발표할 예정입니다.

--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

lex의 이미지

전 4년차 순수 오디오코덱 개발자입니다.
참고로 배경지식이 전무한 상태에서 맨땅에 헤딩하는식으로 오디오코덱개발자의 길을 걸어왔습니다.

오늘 가입하고 '오디오코덱 개발자'를 검색해보니 가장 위에 뜨길래 읽어보았습니다.
마침, 오디오코덱 개발자가 별로 없어서 저의 위치가 어느정도인지 가늠할 수가 없는 찰나에 이런 글을 읽으니 궁금증이 생기는군요.

글을 읽어보니 단기간내에 수많은 멀티미디어 코덱을 섭렵하신거 같은데, 여기서 제가 여쭙고 싶은건 어느 레이어를 섭렵하셨는지, 단순 코드레벨인지
아니면 알고리즘 레벨인지 궁금합니다. 아무리 맨땅에 헤딩을 했어도 현재 저는 FFT와 여러가지 Signal processing에서 해메고 있습니다.(이제 좀 기지개를 켜는 단계입니다.)
PNS, TNS등 AAC에 있는 여라가지 툴을 1달만에 섭렵하셨다고 하는데, 알고리즘 이해도가 어느정도인지 그리고 100% 이해하셨다면 어떠한 배경지식이 있어야 하는지 궁금합니다.
특히, PNS, TNS 같은 경우는 공개된 논문도 없는걸로 알고 있습니다.(Signal processing 알고리즘에 대한 갈증이 너무나도 많습니다.)

그리고, 설계기술이 85%라고 하셨는데, 단순히 스펙 알고리즘을 그대로 차용하신건지 아니면 독자적인 알고리즘을 차용하신건지요.
일례로 MP3나 AAC 등 오디오 코덱에 보면 글에 쓰신것처럼 역양자화란 것을 합니다. 그런데, 이게 상당히 복잡도가 높고 테이블로 만들어도 상당히 크기 때문에
수치해석이란 학문을 통한 인터폴레이션 알고리즘을 많이 씁니다. 이처럼 독자적인 알고리즘을 가지고 계신지요. 참고로 저는 '이렇게도 할 수 있구나' 정도의 레벨입니다.

제가 오디오코덱 개발을 3년 넘게 하면서 느낀건, 단순 코드레벨 최적화를 하는 단순 프로그래머로 남느냐,
아니면, 알고리즘을 이해하고 알고리즘 레벨 최적화를 할 수 있는 프로그래머가 되느냐 입니다. 전, 현재, 후자를 향해서 가려고 노력하고 있습니다.
다들, 단순 코드레벨 최적화만 하면 그걸로 할일은 끝이다라고 하지만, 그래도, 자기가 뭘 만들고 있는지는 알아야 된다고 생각하기에 후자를 택한겁니다.
님은 전자입니까 후자입니까?

sayhi7의 이미지

저의 경우 오디오코덱의 규격문서와 참조소스를 두세달 정도 파니까 TNS TOOL 를 제외한 나머지 부분은 모두 분석이 가능했구요
규격문서도 한줄한줄 꼼꼼히 살펴보았구요 ... 참조소스도 세부 알고리즘을 파악할수 있을 정도로 꼼꼼히 살펴보았읍니다
다른분의 경우 참조소스를 최적화해서 라이브러리 형태로 회사에서 상용화하는 경우가 많은데요
저는 참조소스를 전혀 사용치 않고 MPEG 규격대로 오디오코덱을 독자적으로 설계한 경우구요 ...
이제 궁금증이 풀리셨나요 ?

sayhi7의 이미지

오디오코덱 개발 3 년차 라고 글을 올리셨지요 ....

제가 예전에 파악하기로
PNS 의 경우,
제 개인적인 생각으로는 규격문서내에 perceptual noise substitution decoding 에 대해서 pseudo function 이 정의되 있어서 이것과 참조소스의 PNS 부분을 분석해서 짜 맞추기를 하면 되지 않을까 라고 분석을 했었읍니다 ...

오디오 코덱에서 FFT 의 경우
제 개인적인 생각으로는
스펙트럼 데이타 디코딩시 디코딩 알고리즘이 규격문서에 제시되 있는것으로 저는 파악했기에 스펙트럼 데이타에 대해서는 FFT 가 없어도 되겠다 라고 분석을 했었읍니다 ...

오디오코덱 사실 어렵읍니다.
디코더는 어찌어찌 한다해도 인코더는 실력자 정도가 가능하다고 지금은 생각하고 있읍니다 ...

역양자화의 경우
규격문서에 정의된 부분과 참조소스에 구현된 부분을 살펴보고 어떻게 동작한다 라고 이해하는 정도 입니다 ...

사실 오디오 디코더의 경우
규격문서와 참조소스를 살펴보면 아주 난해한 부분을 빼면 동작 알고리즘은 이해는 가는데요 ... 실제 코덱설계시 이해하는 부분과 실제 구현 사이에는 뭔가 갭이 있을꺼라 지금은 생각하고 있답니다 ...

그리고 저는
규격문서와 참조소스에 제시된 동작 알고리즘을 이해하는 정도라고 말씀드릴수 있을것 같읍니다 ...

magingax의 이미지

...

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

sayhi7의 이미지

오디오 코덱개발의 경우
AAC Decoder 의 허프만 디코딩, 윈도우 필터뱅크 이해는 코덱 규격문서와 참조소스를 병행해서 보시면 좋을것 같구요
BSAC Decoder 의 경우 비트슬라이스 디코딩의 이해에 어려움이 있었는데 참조소스와 규격문서를 한동안 보니 이해가 가더군요

저의 경우 오디오 코덱의 경우 코덱 규격문서에서 규정한 알고리즘 이해수준 이라고 말씀드릴수 있을것 같읍니다.

H.264 Baseline Deocoder Profile 1.3 의 개발을 진행해 보았는데요
제가 어려움을 겪은 부분은 MPEG 에서 규격문서를 만들때 여기에 디코더 설계에 필요한 모든자료를 포함하지 않았기에
모자르는 부분은 참조소스를 분석해서 이해를 해야 하는데 이게 말처럼 쉽지 않았구요

디블럭킹 필터의 경우, 어떤방식으로 매크로블럭의 경계를 부드럽게 처리하는지 이해하는데
2 년이 걸렸다고 하면 웃으시겠죠 ?

오디오/비디오 인코더의 경우
디코더쪽 설계보다 훨씬 어려운 점이 남들보다 실시간 처리가 가능한 성능이 개선된 독창적인 알고리즘을 개발해야 하는데
진짜 상용화 수준의 알고리즘 개발은 어떤 인간들이 할까 궁금하기도 합니다 ...
시행착오를 줄이면서 개발하는 방법을 지닌 분이 고수 이시겠죠 ?

저 위의 글 원문에 100% 기술보유 라고 쓴 부분은 지금 시점에서는 절대로 쓰고 싶지 않읍니다 ...
지금 보면 정말 어이가 없네요 !!!!!
이 글을 쓸때 기술보유 100 % 라고 쓴 배경에는
코덱 알고리즘에 대해 웬만큼 이해가 되었다고 해도 참조소스를 제가 독자적으로 개발을 진행해 보니
MPEG 규격에 모든게 명확히 제시되 있지 않아서 사실상 성공 가능성이 거의 없다는것을 파악하지 못했던것 같읍니다.

저의 단순한 생각으로는
MPEG 규격에 모든게 제시되 있으리라고 생각해서 개발이 가능하다라고 판단을 햇었는데
실제 개발을 경험해 보니 현실은 제 생각과 많이 어긋났읍니다 ....

winner의 이미지

제가 회사에 처음 입사한게 2009년 6월입니다.
4년이라는 세월 동안 많은 것을 느낄 수 있었습니다.

oosap의 이미지

본문의 내용과는 상관없는 글입니다. 그래서 그냥 지나칠 수도 있지만, 짚어드리는게 좋겠다 싶어 몇 줄 적어봅니다.

아래에 제가 구글에서 '읍과습' 으로 검색해본 내용중 도움이 될 만한 글들을 올려봅니다.
1988년에 한글 맞춤법이 개정되면서 '읍'은 틀리고 '습'이 맞다고 하는 것 같습니다.

http://www.hangulo.net/hangul/hanmat.htm

http://k.daum.net/qna/view.html?qid=00DYT

본문을 쓰신 선생님께서 반응을 주시면 이 글을 지우겠습니다. 그럴 수 있도록 제 글에 답글을 달지 말아주세요.
다시금 밝힙니다. 이 글을 쓰는 것은 강좌를 쓰신 선생님께 도움을 드리려는 것일 뿐입니다. 맞춤법 개정이 될 때 이미 학교과정을 마치셨던 어느정도 연배가 되신 분들이 흔히 습관적으로 잘못 쓰시는 것을 봤었는데 이렇게 알려드리면 좋겠다는 생각을 했을 뿐입니다.

http://kldp.org/node/123704

KLDP 에 맞춤법 관련한 재미난 쓰레드가 있었습니다.

Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.

sayhi7의 이미지

죄송합니다 ... 구세대라 예전 방식대로 쓰게되네요 !!!!!

oosap의 이미지

모르시고 계시던게 아니었네요 ^^;
좋은 강좌에 괜한 글 쓴 것 같습니다. 왠지 느낌표가 많은 응답은 무섭습니다. _ _;
글 내용은 제가 잘 모르는 분야입니다만 강좌를 올려주셔서 감사드립니다.
(제 글에 답글로 메세지를 주셔서 제 글을 지울 수 없게 됐습니다.)

Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.

익명 사용자의 이미지

맞춤법 바뀌기 전에도
같습니다는 같습니다였습니다.
그리고 띄어 쓰기도 틀리셨네요.

익명 사용자의 이미지

이런 일이 진정 프로그래머가 하는 일이라고 느껴집니다.
웹에 관련한 잡다한 일만 10년째 하다보니 한우물만 파고 싶어지네요...

sayhi7의 이미지

개발자 웹 개발환경에서 SVN 레퍼지토리로 최신소스를 업데이트하고 CI Server 에서 개발자 웹 개발 PC 로부터 저장된 SVN 으로부터 최신소스를 다운받아
빌드후 개발서버로 Deploy 하는 웹 개발환경 셋팅하는것 부터 쉽지가 않구요

스프링 MVC 개발환경을 적용해 테스트 소스를 빌드후 디플로이 하는 과정 및 개발소스 파일 설계 작업 자체를 공부하는게 말처럼 쉽지 않고
JSP 를 사용한 서블릿 설계의 개념 및 세부 동작원리를 이해하는것도 쉽지 않던데요

웹을 10 년 하셨다니 참 저는 갈 길이 멀다라고 느껴 집니다 ...

요즘은 멀티미디어만 해서는 버티기 힘들더라구요
왜냐하면 멀티미디어 분야를 제대로 파악해서 분석하시는 분들은 대학원에서 석박사를 밟으신 분들이나 가능하고
저 같이 맨 땅에 헤딩한 사람은 아무래도 체계적으로 공부한 사람을 따라가기가 어려워서
멀티미디어 분야는 제가 할수 있을 만큼만 하고

요즘 대세인 멀티미디어와 웹 기술의 융합분야를 열심히 분석해 보는데
웹 분야 또한 제대로 파악하려면 그동안 10 년간의 기술 변천사를 파악해야하는데
세상에 쉬운 일이 없네요

익명 사용자의 이미지

안녕하세요? 답답한 마음에 여기저기 웹서핑을 하다가 귀하의 글을 읽고 혹시나 하는 마음의 이글을 남겨봅니다.
짧게 말씀드리면 개발되어진 영상코덱이 영상보다 1초늦게 오디오가 나옵니다. 이점을 수정을 할 수 있게 도움을
받을 수 있는 분이나 업체를 아려주실 수 있는지요.
jhkim7kr@gmail.com

gilgil의 이미지

음성 delay는 여러가지 요인에 의해 발생할 수 있습니다.

[송신측]
1. 녹음 delay : 음성은 일정 주기동안 녹음(sampling)이 완료될 때까지의 delay
2. 압축 delay : raw data를 bistream으로의 압축 과정에서 생기는 delay
3. 송신 delay : 압축 bitstream을 네트워크로 송신할 때까지의 delay

[네트워크]
4. 전송 delay : 네트워크상으로 송신측에서 수신측까지 패킷이 도달할 때까지 걸리는 delay

[수신측]
5. 수신 delay : 수신을 해서 해체 프로세스를 탈 때까지의 delay
6. 해제 delay : bitstream을 raw data로의 압축 해제 과정에서 생기는 delay
7. 재생 delay : 재생 device에 이미 재생이 예약되어 있는 기존의 버퍼 때문에 생기는 delay

음성 delay의 가장 큰 이유 중의 하나는 바로 7번입니다(프로세스의 일시적인 hang이나 network상의 jitter현상으로 발생).

delay를 최소화할 수 있는 방법은 주기적으로 음성 재생 delay를 없애 줄 수 있도록 재생 버퍼를 flush시키는 일입니다.

sequaier의 이미지

영상 처리에 대한 책을 읽고 FFT 를 공부하고 있습니다.
FFT 변환이후, 주파수 스펙트럼된 데이터는 뭘 의미한 건가요?
(re) + j(im) 의 데이터가 생기는데, 이 데이터의 크기(magnitude)에 관심이 있습니다.
이 데이터의 단위가 뭔지 궁금해 글을 올립니다.

DFT 변환한 데이터는 주파수 순번대로 데이터가 나열되는데,
FFT 변환한 데이터는 주파수가 아닌듯 합니다. 아니면 다른 단위인지 도무지 모르겠습니다.

gilgil의 이미지

> FFT 변환이후, 주파수 스펙트럼된 데이터는 뭘 의미한 건가요?
각 주파수 성분의 크기입니다. real 값은 cosine coefficient, image 값은 sine coefficient입니다.

> DFT 변환한 데이터는 주파수 순번대로 데이터가 나열되는데, FFT 변환한 데이터는 주파수가 아닌듯 합니다. 아니면 다른 단위인지 도무지 모르겠습니다.
같은 의미입니다.

1. FT(fouriter transform) 이론은 원래 실수의 영역임.
2. FT 이론을 컴퓨터에 적용하다 보니 정수로 처리를 해야 하고, 그래서 DFT(Discrete Fourier Transfom)이라는 용어가 나옴.
3. DFT는 O(N^2)의 time complexity를 가지는 반면에 FFT는 O(N logN)의 time complexity를 가짐(output 똑같음). 속도 개선때문에 DFT보다 FFT를 선호.
4. 다만 FFT는 data 갯수가 power of 2 이어야만 한다는 제약이 있음

익명 사용자의 이미지

오래전에 쓰신 글인데, 재미있게 읽었습니다.
저도 프로그래머이지만, 주위에서 codec을 전문적으로 개발하고 계신 분을 뵙기가 쉽지 않아서, 무척 흥미를 가지고 읽었습니다.

회사 업무를 위해서 모바일에서 높은 성능으로 동작가능한 jpeg200 decoder가 필요해서 혹시나 하고 여쭤봅니다.
기존에 개발하신 게 있으시거나, 아니면 이쪽에 흥미가 있으셔서 개발을 할 예정을 가지고 계신가요?
openjpeg 같은 외부 라이브러리로 구현은 가능할 것 같은데, 성능에 문제가 있다고 알고 있습니다.

만약 의향이 있으시다면, 금액이나 결과물 전달 내용 등에 대해서 말씀드리고 싶습니다.
별도 연락처가 없으셔서, 여기 댓글로 남깁니다.
부디 이 글을 읽으셨으면 합니다. ^^

익명 사용자의 이미지

^^

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.