$memo = preg_replace('/#WMTAG:(.*)#/e', '$wmvp->linktag("$1")', $memo);
이 두줄을 올리기 위해 -_- 약 이틀간 아스트랄한 삽질을 하게되었다.
이늠은 wmv에 저장된 메타데이터를 긁어와서 동영상의 width, height 등의 몇가지 정보를 기반으로 태그를 생성한다..
그럴려고 오리지널 문서를 뒤적이다.. 옵셋 대역과 헤더스트럭처를 따다 대충 php상에서 구현했다
이미 요 밑에 보면 알겠지만 exif를 위해 인디언 변환로직들은 아예 클래스화를 시켜놨다.
귀찮아서 대충대충 몇개 파일만 놓고 해당영역이 있는 옵셋으로 다이렉트 점프를 시켰더니 몇몇파일이 안돌더라..
문서를 다시 찬찬히 훌터봤더니 헤더->스트림프로퍼티 에 속하는 4가지 플래그,스트림택,오브젝옵셋이 설정된 갯수에 따라 -_- 파일의 옵셋값이 밀리더라.. 이 방대한 문서속에 이 네줄이 보일리가 있겠는가 --
단순한 삽질이 아니었다. 연관된 값들을 모두 파싱해서 옵셋위치를 계산해내야했다..
좀전에 대충 마무리가 되었는데 짜고나서 소스코드를 보니 줄수가 400줄이나되더라 -_- 용량은 20k가량된다
다행이다.. 그래도 매킨토시에서 wmv를 못만든다는것이.. 아마 모토로라 바이너리처리까지 들어갔으면 코딩은 미궁에 빠졋을지도 모른다 -_-
이제 사이트는 #WMTAG:파일주소# 라는 명령어를 자동으로 검사하고, 디비캐시를 이용하여 동영상의 링크를 걸어주도록 된다...
다른 사이트들이 동영상을 고정폭에 링크하고 50%, 100%, 200%, 전체화면등의 버튼을 만들어 놨던 이유를 대충 알것같다.. 또하라면 안한다.. -_-
왜 메타데이터를 이렇게 분류했는가는 궁극이다. 이전에 코덱개발작업을 할때.. 메타처리시스템을 삽입한적이 있다.
flexible 한 데이터를 처리하기 위해 static structure 를 그대로 삽입하는것은 멍청한짓이라고 보였다.
그 코덱은 현재 매우 뛰어난 코덱으로 매우 빠른 버퍼링과 높은 압축품질을 자랑한다.
따라서 매우 빠른 초도 버퍼링상태에서 동영상의 전체정보를 가져와서 처리해야한다.
그러나 그 버퍼링은 환경에 따라 틀리므로 이 버퍼링의 사이즈조차 유동적 구조체를 따라 링크시켜야 했다.
0.1미리초가 아까운 상황에서 구조체로 인해 고정공간을 받아온다는것은 코덱에 있어 넌센스 그자체였다.
wmv나 기타 모든 코덱이 버퍼링이 느리고 이로인한 손해가 있는것은 아마도 멍청한 메타구조체때문이라 생각한다. 뭐 압축률이 기인하는것도 사실이지만, 구조체 최적화만으로 1초를 벌수있다고 생각했다.
하지만.. 지금 자세히 보니 2초는 더 줄일수 있을것같다.
지금 이 글을 보는 사람이 머리가 돌아간다면 무엇때문에 비디오 크기를 초도메타정보에 삽입해야 하는지를 상상할 수 있을것이고, 그 코덱이 무슨코덱인지 단방에 맞출수 있겠지만.. 언급하는일은 없도록 하자. 아픈기억이다 -_-
Posted by LeCieL