Yuvist 0.9.0 을 공개합니다.
Kivy framework을 사용한 YUV viewer 입니다.
4:0:0, 4:2:0, 4:2:2, 4:4:4 format을 지원하며
fragment shader를 사용하여 YUV to RGB conversion을 하므로 성능이 낮은 CPU에서도 잘 돕니다.
github에서 yuvist-release.zip을 다운받고 bin 디렉토리에서
윈도우이면 yuvist-0.9.0.zip을 맥이면 yuvist-0.9.0.dmg를 푸시면 됩니다.
소스코드는 https://github.com/luuvish/yuvist에 있습니다.
Windows8 consumer preview 가 공개되었습니다.
developer preview와 비교해 보아도 뭐가 달라진 건지 잘 모르겠습니다.
마우스로 메트로UI를 쓰는 건 여전히 불편합니다.
store에서 몇가지 어플을 설치해 보았습니다.
store 자체는 깔끔하고 편합니다만, 기존의 desktop 어플과 어떻게 공존할 지 궁금합니다.
총평 - developer preview에서 그렇게 많이 달라지지 않았다. 메트로와 데스크탑의 공존은 여전히 혼란스럽고 당황스럽다. 성공할 지 의심스럽다.
developer preview와 비교해 보아도 뭐가 달라진 건지 잘 모르겠습니다.
마우스로 메트로UI를 쓰는 건 여전히 불편합니다.
store에서 몇가지 어플을 설치해 보았습니다.
store 자체는 깔끔하고 편합니다만, 기존의 desktop 어플과 어떻게 공존할 지 궁금합니다.
총평 - developer preview에서 그렇게 많이 달라지지 않았다. 메트로와 데스크탑의 공존은 여전히 혼란스럽고 당황스럽다. 성공할 지 의심스럽다.
문제의 발단은 이렇습니다.
1) 웹브라우저가 다음과 같이 요청.
GET http://www.any-domain.com/any-route/
2) http://www.any-domain.com/ 웹서버가 자동으로 /any-route/ 뒤에 index.html 을 추가하고 응답.
RES /any-route/index.html
3) 웹브라우저가 index.html 안에 포함된 <script src="scripts/any-script.js"> 를 보고 any-script.js 요청.
GET http://www.any-domain.com/any-route/scripts/any-script.js
4) http://www.any-domain.com/ 웹서버가 /any-route/scripts/any-script.js 를 응답.
RES /any-route/scripts/any-script.js
5) 웹브라우저가 다음과 같이 요청.
GET http://www.any-domain.com/any-route
6) http://www.any-domain.com/ 웹서버가 자동으로 /any-route 뒤에 /index.html 을 추가하고 응답.
RES /any-route/index.html
7) 웹브라우저가 index.html 안에 포함된 <script src="scripts/any-script.js"> 를 보고 요청.
GET http://www.any-domain.com/script/any-script.js
8) http://www.any-domain.com/ 웹서버가 /scripts/any-script.js 를 찾을 수 없으므로 404 에러 발생.
RES /scripts/any-script.js - Error 404
즉, 문제는 /any-route 뒤에 / 가 붙지 않았을 때 index.html 은 응답하는데 scripts/any-script.js 는 경로가 /any-route 아래가 아닌 / 로 웹브라우저가 인식하는 것입니다.
생각해 보면 당연한 것일 수도 있는데, 웹브라우저는 any-route 가 실제로 파일인지 directory 인지 알지 못합니다. 설사 알고 요청한 것 일지라도 웹서버의 실제 내용은 아닐 수 있습니다. 그래서 웹브라우저가 /any-route 를 요구했을 때, 웹서버가 index.html 을 보내주어도 웹브라우저는 index.html 이 아니라 /any-route 라는 / 밑의 any-route 라는 파일을 받은 줄 압니다. any-route 의 경로가 / 에 있으므로 script/any-script.js 도 / 에 위치한 줄 알고 웹브라우저는 /script/any-script.js 을 요구하게 됩니다.
이 문제를 해결하는 가장 쉬운 방법은 redirect 로 다시 / 가 뒤에 붙은 url 을 돌려 주는 것입니다.
즉, /any-route 을 요구 받으면 웹서버가 우선 any-route 가 파일인지 디렉토리인지 판단한 후 디텍토리이면 /any-route/ 로 redirect 시키면 됩니다. 그러면 웹브라우저는 /any-route/ 로 다시 요청하면 되죠. 사실, connect.js 의 static middleware 는 기본 설정이 이런 동작을 하도록 되어 있습니다.
1) 웹브라우저가 다음과 같이 요청.
GET http://www.any-domain.com/any-route/
2) http://www.any-domain.com/ 웹서버가 자동으로 /any-route/ 뒤에 index.html 을 추가하고 응답.
RES /any-route/index.html
3) 웹브라우저가 index.html 안에 포함된 <script src="scripts/any-script.js"> 를 보고 any-script.js 요청.
GET http://www.any-domain.com/any-route/scripts/any-script.js
4) http://www.any-domain.com/ 웹서버가 /any-route/scripts/any-script.js 를 응답.
RES /any-route/scripts/any-script.js
5) 웹브라우저가 다음과 같이 요청.
GET http://www.any-domain.com/any-route
6) http://www.any-domain.com/ 웹서버가 자동으로 /any-route 뒤에 /index.html 을 추가하고 응답.
RES /any-route/index.html
7) 웹브라우저가 index.html 안에 포함된 <script src="scripts/any-script.js"> 를 보고 요청.
GET http://www.any-domain.com/script/any-script.js
8) http://www.any-domain.com/ 웹서버가 /scripts/any-script.js 를 찾을 수 없으므로 404 에러 발생.
RES /scripts/any-script.js - Error 404
즉, 문제는 /any-route 뒤에 / 가 붙지 않았을 때 index.html 은 응답하는데 scripts/any-script.js 는 경로가 /any-route 아래가 아닌 / 로 웹브라우저가 인식하는 것입니다.
생각해 보면 당연한 것일 수도 있는데, 웹브라우저는 any-route 가 실제로 파일인지 directory 인지 알지 못합니다. 설사 알고 요청한 것 일지라도 웹서버의 실제 내용은 아닐 수 있습니다. 그래서 웹브라우저가 /any-route 를 요구했을 때, 웹서버가 index.html 을 보내주어도 웹브라우저는 index.html 이 아니라 /any-route 라는 / 밑의 any-route 라는 파일을 받은 줄 압니다. any-route 의 경로가 / 에 있으므로 script/any-script.js 도 / 에 위치한 줄 알고 웹브라우저는 /script/any-script.js 을 요구하게 됩니다.
이 문제를 해결하는 가장 쉬운 방법은 redirect 로 다시 / 가 뒤에 붙은 url 을 돌려 주는 것입니다.
즉, /any-route 을 요구 받으면 웹서버가 우선 any-route 가 파일인지 디렉토리인지 판단한 후 디텍토리이면 /any-route/ 로 redirect 시키면 됩니다. 그러면 웹브라우저는 /any-route/ 로 다시 요청하면 되죠. 사실, connect.js 의 static middleware 는 기본 설정이 이런 동작을 하도록 되어 있습니다.
var connect = require('connect');
var server = connect.createServer()
.use(connect.static(__dirname))
.listen(80, 'www.any-domain.com');
> node server.js
node로 실행하면 server.js 가 실행된 위치에서 ./any-route/index.html 과 ./any-route/scripts/any-script.js 가 잘 읽히는 것을 알 수 있습니다. server.js 가 /any-route 를 요구 받았을 때, connect.static 에서 /any-route/ 로 redirect 시키기 때문에 자연스럽게 위의 문제가 해결됩니다.
그런데!!!
사실 위의 코드는 좀 문제가 있습니다. 불필요하게 외부에 server.js 와 같은 위치의 파일들이 노출되어 버리죠. http://www.any-domain.com/server.js 도 외부에서 볼 수 있습니다. 따라서 다음과 같이 고치는 것이 바람직 합니다.
> node server.js
node로 실행하면 server.js 가 실행된 위치에서 ./any-route/index.html 과 ./any-route/scripts/any-script.js 가 잘 읽히는 것을 알 수 있습니다. server.js 가 /any-route 를 요구 받았을 때, connect.static 에서 /any-route/ 로 redirect 시키기 때문에 자연스럽게 위의 문제가 해결됩니다.
그런데!!!
사실 위의 코드는 좀 문제가 있습니다. 불필요하게 외부에 server.js 와 같은 위치의 파일들이 노출되어 버리죠. http://www.any-domain.com/server.js 도 외부에서 볼 수 있습니다. 따라서 다음과 같이 고치는 것이 바람직 합니다.
var connect = require('connect');
var server = connect.createServer()
.use('/any-route', connect.static(__dirname + '/public'))
.listen(80, 'www.any-domain.com');
> node server.js
server.js 와 같은 위치에 있는 ./any-route/index.html 과 ./any-route/scripts/any-script.js 는 ./public/index.html 과 ./public/scripts/any-script.js 로 이동시킵니다.
server.use()의 첫번째 파라메터는 요청된 URL의 path 가 일치할 때 두번째 파라메터인 핸들을 수행하도록 합니다. 위와 같이 설정하면 /any-route 로 시작하는 URL의 request는 /any-route 가 제거된 URL이 __dirname + '/public' 에 위치한 파일들과 매치됩니다. 복작하게 router 와 app.get() 으로 패턴매칭하지 않아도 손쉽게 경로를 바꿀 수 있습니다.
그러나!!!
위의 수정된 코드는 이전의 경로 문제는 깔끔하게 해결했지만 처음에 언급했던 / 의 redirect 문제를 발생시킵니다. connect.static 에서 잘 처리되었던 redirect 이 왜 이 경우에는 동작하지 않는지 당황스럽죠.
문제는 connect.static 은 root 에 대해서는 redirect 를 하지 않기 때문에 발생합니다.
use()의 첫번째 파라메터로 넘겨준 route path 가 매치되면 connect.static 은 그 이후의 URL 경로부터 검색을 시작하는데 URL 경로가 더 이상 없으면 (정확히 /any-route 이면) 자동으로 / 를 URL path 로 지정합니다. 그리고 path 가 / 로 끝나므로 index.html 을 추가하고 index.html 을 응답으로 보내 버립니다.
만약 /any-route/scripts 와 같은 URL 경로가 왔다면, connect.static 은 /scripts 를 URL path 로 인식하고 /scripts 가 디렉토리인 것을 확인 한 후 /scripts/ 로 redirect 했을 것입니다. 오직 route path 가 정확히 일치할 때만 redirect 하지 않습니다.
/ 가 route path 였으면 redirect 를 하지 않아도 별 문제는 없었겠죠. 하지만, 일단 route path 가 / 이외의 path 로 설정되었을 때 index.html 안의 모든 상대 경로는 index.html 의 위치가 아닌 index.html 의 상위 디렉토리로 어긋나 버립니다.
이 모든 것을 무시하고 동작시키는 방법은 있죠.
index.html 안의 <script src="scripts/any-script.js"> 를 <script src="/any-route/scripts/any-script.js"> 처럼 절대 경로로 지정하면 됩니다. 동작은 하긴 하는데, 개발 중에 route path 가 변경되거나 웹서버를 다른 경로에 설치하면 모든 html 의 경로명을 수정해야 합니다. 단순히 노가다를 하는 것이 나쁘다는 것이 아니라 설치와 유지 보수가 어려워지므로 절대로 피해야 할 방법입니다.
connect.static 의 버그이긴 한데 우선 다른 방법으로 수정해 보지요.
req.url 을 normalize 하지 않고 단순히 test 하는게 좀 불안하긴 하지만 우선은 동작합니다.
connect.static 이 정식으로 패치되기 전에는 이런식으로 사용해도 무난할 듯 합니다.
> node server.js
server.js 와 같은 위치에 있는 ./any-route/index.html 과 ./any-route/scripts/any-script.js 는 ./public/index.html 과 ./public/scripts/any-script.js 로 이동시킵니다.
server.use()의 첫번째 파라메터는 요청된 URL의 path 가 일치할 때 두번째 파라메터인 핸들을 수행하도록 합니다. 위와 같이 설정하면 /any-route 로 시작하는 URL의 request는 /any-route 가 제거된 URL이 __dirname + '/public' 에 위치한 파일들과 매치됩니다. 복작하게 router 와 app.get() 으로 패턴매칭하지 않아도 손쉽게 경로를 바꿀 수 있습니다.
그러나!!!
위의 수정된 코드는 이전의 경로 문제는 깔끔하게 해결했지만 처음에 언급했던 / 의 redirect 문제를 발생시킵니다. connect.static 에서 잘 처리되었던 redirect 이 왜 이 경우에는 동작하지 않는지 당황스럽죠.
문제는 connect.static 은 root 에 대해서는 redirect 를 하지 않기 때문에 발생합니다.
use()의 첫번째 파라메터로 넘겨준 route path 가 매치되면 connect.static 은 그 이후의 URL 경로부터 검색을 시작하는데 URL 경로가 더 이상 없으면 (정확히 /any-route 이면) 자동으로 / 를 URL path 로 지정합니다. 그리고 path 가 / 로 끝나므로 index.html 을 추가하고 index.html 을 응답으로 보내 버립니다.
만약 /any-route/scripts 와 같은 URL 경로가 왔다면, connect.static 은 /scripts 를 URL path 로 인식하고 /scripts 가 디렉토리인 것을 확인 한 후 /scripts/ 로 redirect 했을 것입니다. 오직 route path 가 정확히 일치할 때만 redirect 하지 않습니다.
/ 가 route path 였으면 redirect 를 하지 않아도 별 문제는 없었겠죠. 하지만, 일단 route path 가 / 이외의 path 로 설정되었을 때 index.html 안의 모든 상대 경로는 index.html 의 위치가 아닌 index.html 의 상위 디렉토리로 어긋나 버립니다.
이 모든 것을 무시하고 동작시키는 방법은 있죠.
index.html 안의 <script src="scripts/any-script.js"> 를 <script src="/any-route/scripts/any-script.js"> 처럼 절대 경로로 지정하면 됩니다. 동작은 하긴 하는데, 개발 중에 route path 가 변경되거나 웹서버를 다른 경로에 설치하면 모든 html 의 경로명을 수정해야 합니다. 단순히 노가다를 하는 것이 나쁘다는 것이 아니라 설치와 유지 보수가 어려워지므로 절대로 피해야 할 방법입니다.
connect.static 의 버그이긴 한데 우선 다른 방법으로 수정해 보지요.
var connect = require('connect');
var server = connect.createServer()
.use(function(req, res, next) {
.use(function(req, res, next) {
if (/^\/any-route$/.test(req.url)) {
res.statusCode = 301;
res.setHeader('Location', req.url + '/');
res.end('Redirecting to ' + req.url + '/');
return;
}
next();
})
.use('/any-route', connect.static(__dirname + '/public'))
.listen(80, 'www.any-domain.com');
> node server.js
req.url 을 normalize 하지 않고 단순히 test 하는게 좀 불안하긴 하지만 우선은 동작합니다.
connect.static 이 정식으로 패치되기 전에는 이런식으로 사용해도 무난할 듯 합니다.
시장에 아직 출시되지 않은 제품이 성공할지 아닐지는 누구도 모릅니다. 예상할 수는 있지만 그 예상이 백퍼센트 맞다고 확신하지 못합니다. 제품의 품질과 상관없이 외부의 상황에 따라, 또는 전혀 무관한 운에 의해 성공하기도 실패하기도 합니다. 하지만 제품의 기능과 품질을 분석하고 시장상황과 소비자의 니드에 만족하는지 예상할 필요는 있습니다. 의도대로 제대로 설계하는 것이 엔지니어의 능력이고 미덕이니까요. 윈도우8 preview를 사용해보고 제 나름대로 분석해보고 이 제품이 시장에서 성공할 만한 제품인지 고민해 보았습니다.
9월 14일 윈도우 개발자 preview 버전이 공개되었습니다. http://msdn.microsoft.com/en-us/windows/home/ 에서 누구나 다운로드해서 설치 가능합니다. 저의 경우, 맥미니에서 VMware fusion 4 에서 가상머신에 설치했습니다. 가상머신에서 메모리 1G에 하드디스크 이미지를 60G로 잡았습니다. 호스트OS는 Window 7 x64였고 기본세팅에서 CPU만 듀얼코어로 설정했습니다. 개발툴이 포함된 64bit 버전이었고 설치후 용량이 13G 정도입니다.
설치한 후에 hotmail 계정을 유저로 등록하면 메트로UI로 된 시작화면을 보실 수 있습니다.
Desktop을 선탠하면 지금까지 익숙했던 에어로UI를 사용하실 수 있습니다.
이미 많은 다른 사용자들의 사용기와 감상평들이 인터넷에 올라왔고 유튜브에 올라온 타블렛 시연기도 보았기 때문에 어느 정도의 예상은 하고 있었습니다. 하지만 직접 사용해 보고 미리 알려진 내용이 정말인지 확인할 필요가 있었습니다. 그러나 사실은 직접 만저보기 전까지 판단을 미룬 가장 큰 이유는 일반적인 인터넷의 반응이 의아했기 때문이었습니다. 메트로와 에어로가 겹쳐진 모습이 상당히 불합리해 보였기 때문입니다. 왜 그런지는 클리앙에 올라온 리뷰를 참조바랍니다. 저의 생각과 상당히 일치합니다.
[리뷰] Windows 8 Preview (1/2)
[리뷰] Windows 8 Preview (2/2)
윈도우8을 칭찬하는 내용은 대체로 세가지 입니다.
- 다양한 하드웨어를 지원한다. 심지어 x86뿐 아니라 arm에서도 설치된다.
- 메트로UI가 산뜻하고 편하다.
- 비교적 저사양의 하드웨어에서도 가볍게 동작한다.
- 메트로UI와 에어로가UI가 조화롭지 못하다.앱이 중복되고 전환이 불편하다.
- 메트로UI는 마우스로 사용하기 불편하고 에어로UI는 터치로 사용하기 불편하다.
제 생각으로는 메트로UI나 에어로UI 각각은 상당히 훌륭합니다. 타블렛OS에서의 메트로UI는 취향의 호불호는 있을 지언정 iOS와 겨루어 보아도 뒤떨어지지 않는 (추월하지도 않는) 멋진 인터페이스라고 생각합니다. 문제는 전혀 상반된 성격의 UI가 기계적으로 합쳐졌다는 점입니다. 터치로 입력하는 UI와 마우스와 키보드로 입력하는 UI가 다르고, 10인치 화면을 사용하는 UI와 24인치 화면을 사용하는 UI는 다릅니다. 전혀다릅니다. 아이콘의 크기, 입력 제스쳐, 시선의 거리, 하나로 통합되어 동시에 제공될 수 없는 환경입니다. 모든 것을 아우르는 멋진 UI를 만드는 것이 꿈이긴 하지만 적어도 메트로와 에어로가 그렇지는 못합니다. 다른 성격의 인터페이스를 섞어서 모든 것을 커버할 수 있다고 생각한다면 엄청난 착각입니다. 결국 어느 한쪽을 포기할 수 밖에 없습니다. 불편할 것을 사용자의 기술로 커버하는 것은 어리석은 짓입니다. 단순히 묘기일 뿐이지요.
도데체 왜 어울리지도 않는 두 UI를 시작 메뉴에 겹쳐서 혼란스럽게 만들었을까요. 제 생각으로는 MS가 윈도우8의 성공은 메트로UI라는 멋진 터치용 UI와 이전 윈도우와의 호환성, 이 둘에 달려있다고 판단한 듯 싶습니다. 아이패드가 이미 시장에 나온지 1년 반이 넘어가고 있고 윈도우8이 정식으로 나올 때 쯤이면 2년 이상이 되어 있을 겁니다. 이미 타블렛 시장을 장악했고 제공되는 앱의 수는 어마어마 합니다. 이전 윈도우와 호환되지 않는 메트로UI만 제공하면 초기에 지원되는 앱의 수에서 경쟁이 되지 못합니다. 이는 결국 타블렛의 초기 판매에도 심각한 영향을 줄 수 밖에 없습니다. 타블렛은 폰과 달리 쓸만한 앱도 없이 동영상 보기와 웹브라우징만으로는 구매자의 욕구를 만족시키기 어렵습니다. 초기의 아이패드가 아이폰으로 나온 앱의 지원을 받은 상황과는 달리 윈도우폰7은 아이폰의 역할을 하고 있지 못합니다. 결국 폰이 아닌 데스크탑의 앱을 지원군으로 활용할 수 밖에 없는게 현실입니다.
상황이 좋지 않습니다. 윈도우8은 이미 애플이 2년 이상 장악하고 있는 타블렛 시장을 공략해야 합니다. MS는 애써 자신의 타블렛은 윈도우의 연장이라고 주장하고 싶어합니다만 결과물은 메트로UI는 아이패드가 정답이었다고 시인하고 있습니다. 정전식 터치에 최적화된 UI에 취소 기능의 홈버튼, 그리고 arm. 아이패드에 식상하고 앱이 부족해도 참을 수 있는 일부의 사용자는 구입할 지도 모릅니다. 에어로UI 덕분에 이전 윈도우처럼 사용하려던 타블렛 구매자들은 금방 격렬한 안티가 될겁니다. 데스크탑에서 메트로UI를 사용하는 유저들은 곧 메트로를 끄고 싶어하겠죠. 그런데 메트로가 사라진 윈도우7의 성능개선판인 윈도우8을 사람들에게 과연 구입하고 싶어할지는 모르겠습니다.
맥OS 라이언이 나왔을 때, 전 좀 실망했었습니다. iOS의 런치패드가 추가되고 미션콘트롤이 스패이스와 익스포제를 개선하고 풀스크린 모드와 화면사이즈 수정등등의 다양한 수정이 있었지만 결국 터치 인터페이스와 마우스 인터페이스는 통합하지는 못했습니다. 결국 iOS와 맥OS는 다르다는 것을 인정할 수 밖에 없었습니다. 기즈모도에서 라이언을 비난하고 윈도우8의 통합 인터페이스를 격찬할 때 뭔가 있는 줄 알았습니다. 솔직히 윈도우8는 라이언만도 못합니다. 최소한 라이언은 인터페이스의 차이점을 인정하고 포기했습니다. 윈도우8은 MS 역사상 최대의 실패작이 될지도 모릅니다. ME도 비스타도 뛰어넘는 무시무시한 실패작이 될 잠재력을 보이고 있습니다. 저라면 빨리 메트로UI와 에어로UI를 분리해서 타블렛용 OS와 데스크탑용 OS를 분리하겠습니다. 나중에 받을 원성과 비아냥에 비하면 그나마 호환성을 포기하는게 싸게 먹히는 거라고 봅니다. 애플의 기술력과 비교당하고 패배하면 그마나 점유하던 데스크탑 시장도 잠식당할 수 있겠죠.
그런데 윈도우밖에 모르는 사람들은 불편하면 말던 그냥 주는데로 윈도우8을 쓸거 같습니다. 원래 그런줄 알고요. 아님 그냥 계속 윈도우7 쓰던가.
AVPlayer와 ffmpeg 모두 열심히 개발하면서 버전이 올라가는 바람에 4월에 올렸던 내용이 어긋나면서 컴파일이 안되고 있었습니다. 주로 arm assembly code 관련된 문제가 많았고, gas-preprocessor.pl 의 매크로 지원 문제라서 받아서 컴파일하는 입장에서는 문제가 생길 때마다 매번 대응하기 곤란했습니다. 매번 git 에 코드가 올라올 때마다 확인할 수도 없는 노릇이어서 이번에는 아예 AVPlayer 소스안에 들어있는 ffmpeg code에 맞추어서 컴파일하도록 했습니다.
AVPlayer.zip 에 libs/FFmpeg 에 비교적 최근(아마도?) 소스가 들어있으므로 매번 git 에서 clone 할 필요없이 주어진 것으로 컴파일하기로 했습니다. 당장 최신 ffmpeg 의 기능이 필요하지 않다면 상관없을 듯 합니다. 그리고 universal library에 i386의 library는 제외시켰습니다. yasm을 설치하고 이전 스크립트로 컴파일해도 되지만 어차피 AVPlayer에 링크될 때 simulator 용을 만들 수 없으므로 컴파일할 필요는 없습니다. ffmpeg library 자체에 흥미있으신 분들은 이전 글을 참고해서 컴파일해 보시면 될 듯 합니다. 좀 무책임한 선택이지만 매번 버전 차이 때문에 이 글을 업데이트하는 일은 없었으면 하는 바람입니다.
AVPlayer.zip 에 libs/FFmpeg 에 비교적 최근(아마도?) 소스가 들어있으므로 매번 git 에서 clone 할 필요없이 주어진 것으로 컴파일하기로 했습니다. 당장 최신 ffmpeg 의 기능이 필요하지 않다면 상관없을 듯 합니다. 그리고 universal library에 i386의 library는 제외시켰습니다. yasm을 설치하고 이전 스크립트로 컴파일해도 되지만 어차피 AVPlayer에 링크될 때 simulator 용을 만들 수 없으므로 컴파일할 필요는 없습니다. ffmpeg library 자체에 흥미있으신 분들은 이전 글을 참고해서 컴파일해 보시면 될 듯 합니다. 좀 무책임한 선택이지만 매번 버전 차이 때문에 이 글을 업데이트하는 일은 없었으면 하는 바람입니다.
준비물
- Snow Leopard/Lion 이 설치된 Mac
- Xcode 최신버전 (4.1 이상, iPhoneOS4.3 SDK 이상)
- AVPlayer source code
http://eplayworks.com/avplayer/AVPlayerDist143.zip
위의 사이트에서 source code를 다운받습니다. - gabriel의 ffmpeg ios compile script
https://github.com/gabriel/ffmpeg-iphone-build
꼭 필요한 것은 아니지만 참고.
FFmpeg library만들기
- AVPlayerDist143.zip을 작업할 폴더에 풉니다.
- __MACOSX 폴더는 지워도 됩니다.
- https://github.com/yuvi/gas-preprocessor 에서 gas-preprocessor.pl을 가져와 /usr/local/bin으로 복사합니다.
- AVPlayer 안에 libs 디렉토리로 이동합니다. (cd libs)
- libs 안에 ffmpeg-armv6, ffmpeg-armv7 디렉토리를 만듭니다. (mkdir ffmpeg-armv6 ffmpeg-armv7)
- build-armv6 파일을 열어 15번째 줄에서 CONFIGURE_OPTIONS=" ... " 안에 --disable-doc 을 추가합니다.
- build-armv6 파일의 30번째 줄의 ./configure ... 을 ../FFmpeg/configure ... 으로 수정합니다.
- build-armv6 파일의 30번째 줄에서 gcc-4.2 와 iPhoneOS4.3.sdk 라고 되어 있는 부분을 자신의 버전과 일치하도록 수정합니다. 어떤 버전인지 자신이 없으면 /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ 과 /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/ 에 실제로 존재하는지 확인하면 됩니다.
- build-armv7 파일을 열어 build-armv6 에서 수정한 것처럼 고칩니다.
- FFmpeg 디렉토리에 있는 config.* 파일들을 삭제합니다. (rm -rf FFmpeg/config.*)
configure를 실행하면 생성되는 파일들인데 이 파일이 FFmpeg에 있으면 ffmpeg-armv6이나 ffmpeg-armv7에서 configure 가 되지 않습니다. - 이제 순서대로 build-armv6, build-armv7 스크립트를 실행합니다. (sh build-armv6; sh build-armv7)
각각의 target에 대해 configure, make를 순서대로 수행하게 됩니다.
모든 target의 library가 compile되면 ffmpeg-armv6/dist, ffmpeg-armv7/dist 에 include, lib 디렉토리가 만들어지고 해더와 라이브러리가 생성됩니다. - combine-libs 파일을 열어서 5번째 줄의 ARCHS="armv6 armv7 i386" 에서 i386 을 지웁니다.
그리고 8번째 줄의 BUILD_LIBS=" ... " 에서 마지막에 있는 libavcore.a 를 지웁니다.
28번째 줄과 31번째 줄의 i386 을 armv7 으로 수정합니다. - combine-libs를 실행해서 (sh combine-libs) 모든 target의 library를 합칩니다. ffmpeg-uarch에 최종 헤더와 라이브러리가 만들어집니다.
AVPlayer compile하기
- Xcode로 AVPlayer project를 엽니다.
- Project Navigator 의 Targets 에서 AVPlayer,AVPlayerHD의 Build Settings을 선택합니다.
- Search Paths 항목의 Header Search Paths 란의 내용을 수정합니다. ./libs/ffmpeg-uarch/include 으로 수정하고 Recursive를 체크하면 됩니다.
- Search Paths 항목의 Library Search Paths 란의 내용을 수정합니다. ., ./libs/ffmpeg-uarch/lib 으로 수정하고 Recursive를 체크하지 않아도 됩니다. . 는 libAVPlayerLib.a 을 링크하기 위해 꼭 필요합니다.
- Project Navigator 의 AVPlayer/libs/FFMPEG 밑의 libavcodec.a, libavcore.a, libavdevice.a, libavfilter.a, libavformat.a, libavutil.a, libswscale.a의 Utilities 창을 열고 경로를 수정합니다. AVPlayer/libs/ffmpeg-uarch/lib 밑에 있는 library를 지정하면 됩니다.
- 프로젝트의 라이브러리 설정은 모두 수정되었습니다. 이제 build 버튼만 누르면 됩니다. 단, 주의하실 점은 Simulator로는 build가 되지 않습니다. libAVPlayerLib.a에 AVPlayer의 중요한 코드들이 모두 숨어있는데, 이 라이브러리가 i386으로 compile 되어 있지 않습니다. arm용으로만 compile되어 있기 때문에 Device로만 bulid 가능합니다.
Google에서 또다른 소셜 서비스를 내놓았습니다.
아직 베타 기간이고 초대장을 받지 않으면 계정을 만들 수 없습니다. 서비스를 시작한지 얼마 되지는 않았지만 Google의 명성때문인지 많은 사람들이 관심을 보이고 사용해 보고 있네요. 주요 사용자를 보면 약간의 얼리어답터와 웹서비스 관련 종사자들이 많은 것 같습니다. 성비의 불균형이 심각합니다. 여성의 비율이 10분의 1입니다. 하하
Google의 소셜 서비스는 Google+가 처음이 아닙니다. 하지만 이전의 서비스는 비참하리만치 호응을 얻지 못하고 사라져 버렸습니다. 이번에는 Facebook과 Twitter를 철저히 연구해서 만들었습니다. 유사한 부분도 많고 이번 서비스의 부족한 부분을 보완한 것도 있습니다.
Facebook과 닮은점
소식과 댓글을 추가하는 방식
소식을 공유(인용)하는 방식
소식이나 댓글에 +1(좋아요)를 주는 기능
앨범(사진첩)을 소식으로 올리는 기능
소식을 공유(인용)하는 방식
소식이나 댓글에 +1(좋아요)를 주는 기능
앨범(사진첩)을 소식으로 올리는 기능
Twitter와 닮은점
사용자와의 관계가 단방향인 팔로우 관계
팔로우들을 분류하여 그룹화하는 서클 (리스트와 약간 다르나 본질은 같다)
팔로우들의 글을 모아서 보여주는 스트림(타임라인)
글에서 다른 사용자를 언급하는 멘션 기능
팔로우들을 분류하여 그룹화하는 서클 (리스트와 약간 다르나 본질은 같다)
팔로우들의 글을 모아서 보여주는 스트림(타임라인)
글에서 다른 사용자를 언급하는 멘션 기능
Google+ 만의 특징
소식을 읽을 수 있는 공개 범위를 다양하게 설정 가능
사용자 정보를 볼 수 있는 공개 범위를 다양하게 설정 가능
올린 글을 원하는 그룹의 사람들만 읽을 수 있도록 설정 가능하기 때문에 Facebook 같이 검증된 사람끼리만 글을 주고 받을 수도 있고 Twitter 처럼 일방적으로 남의 글을 읽는 것도 가능
사용자 정보를 볼 수 있는 공개 범위를 다양하게 설정 가능
올린 글을 원하는 그룹의 사람들만 읽을 수 있도록 설정 가능하기 때문에 Facebook 같이 검증된 사람끼리만 글을 주고 받을 수도 있고 Twitter 처럼 일방적으로 남의 글을 읽는 것도 가능
스파크는 제 입장에서는 그다지 쓸모 있는 기능은 아닌 것 같습니다.
그리고 다른 서비스에도 원래 있었는지 잘 모르겠는데, 사진에 태그를 넣어서 얼굴에 사용자를 매핑하고 관리하는 방식이 인상 깊었습니다. 잘 사용하면 여러가지로 활용할 수 있겠더군요.
Google+를 메인 SNS로 쓸까 말까 고민 중입니다. 분명 여러가지 장점이 있고 Facebook이나 Twitter를 모두 아우르는 기능을 가지고 있지만, 기능이 많다는 게 항상 장점은 아니라서요.
Twitter에서 공개되는 범위를 제한 할 수 없는게 아쉽지만, 반대로 간단한 관계와 사용법이 또한 장점이기도 합니다. 짧은 글을 쉽게 올리고 편하게 읽는 것이 Twitter의 본질이니까요.
Facebook의 좁은 인간관계를 답답해 할 수도 있지만 원래 개인의 사생활과 가십거리를 공유하는 공간입니다. 이미 오프라인에서 잘 알고 있는 사람들끼리 모여있는 공간이고 그에 맞는 글과 사진이 올라오게 되어 있습니다.
Google+의 서클이 멋진 기능이긴 하나 과연 일반인들이 쉽게 사용할 지는 의문입니다. 사실, 공개 범위를 설정했을 때 과연 이 소식이 누구에게 보이고 누구에게 보이지 않는지 정확히 이해할 수 있을까요? 많은 사용자들을 혼란에 빠뜨리고 어렵다고 느끼게 되면 아무리 멋진 기능이라도 사장
그리고 다른 서비스에도 원래 있었는지 잘 모르겠는데, 사진에 태그를 넣어서 얼굴에 사용자를 매핑하고 관리하는 방식이 인상 깊었습니다. 잘 사용하면 여러가지로 활용할 수 있겠더군요.
Google+를 메인 SNS로 쓸까 말까 고민 중입니다. 분명 여러가지 장점이 있고 Facebook이나 Twitter를 모두 아우르는 기능을 가지고 있지만, 기능이 많다는 게 항상 장점은 아니라서요.
Twitter에서 공개되는 범위를 제한 할 수 없는게 아쉽지만, 반대로 간단한 관계와 사용법이 또한 장점이기도 합니다. 짧은 글을 쉽게 올리고 편하게 읽는 것이 Twitter의 본질이니까요.
Facebook의 좁은 인간관계를 답답해 할 수도 있지만 원래 개인의 사생활과 가십거리를 공유하는 공간입니다. 이미 오프라인에서 잘 알고 있는 사람들끼리 모여있는 공간이고 그에 맞는 글과 사진이 올라오게 되어 있습니다.
Google+의 서클이 멋진 기능이긴 하나 과연 일반인들이 쉽게 사용할 지는 의문입니다. 사실, 공개 범위를 설정했을 때 과연 이 소식이 누구에게 보이고 누구에게 보이지 않는지 정확히 이해할 수 있을까요? 많은 사용자들을 혼란에 빠뜨리고 어렵다고 느끼게 되면 아무리 멋진 기능이라도 사장
되기 쉽습니다. 분명 기존 서비스의 부족한 부분을 보완한 훌륭한 기능이긴 하지만 정말 사용자들이 필요로 하는 건지, 잘 이해하고 활용할 수 있는 지는 의문입니다
.
Facebook과 Twitter에서 이미 맺어진 수많은 관계들를 간단히 옮겨 오는 것도 쉽지 않고 이미 특정 목적으로 잘 사용하고 있는 서비스를 바꿀 이유도 별로 없습니다. Google+가 성공하려면 왜 새로운 소셜 서비스를 사용해야 하는지 사용자들에게 어필할 필요가 있습니다.
Facebook과 Twitter에서 이미 맺어진 수많은 관계들를 간단히 옮겨 오는 것도 쉽지 않고 이미 특정 목적으로 잘 사용하고 있는 서비스를 바꿀 이유도 별로 없습니다. Google+가 성공하려면 왜 새로운 소셜 서비스를 사용해야 하는지 사용자들에게 어필할 필요가 있습니다.
AVPlayer를 컴파일하는 방법을 밑에서 포스팅했었습니다. 몇분이 질문을 하셔서 체크도 해볼 겸 다시 컴파일해 보니 왠 걸. 몇 달이나 되었다고 이것 저것 바뀌었더군요. 답변 몇줄 적는 걸로 해결되지 않을 것 같아 다시 정리해 보았습니다. 변경된 부분 위주로 빨간색으로 체크해 두었습니다.
준비물
- Snow Leopard 가 설치된 Mac
- Xcode 최신버전 (4.0.1, iPhoneOS4.3 SDK)
- AVPlayer source code
http://eplayworks.com/avplayer/AVPlayer-Objects.zip
위의 사이트에서 source code를 다운받습니다. - gabriel의 ffmpeg ios compile script꼭 필요한 것은 아니지만 참고 필요.
FFmpeg library만들기
- AVPlayer-Objects.zip을 작업할 폴더에 풉니다.
- __MACOSX 폴더는 지우세요.
- AVPlayer 안에 FFMPEG 디렉토리로 이동합니다.
- gas-preprocessor.pl을 /usr/local/bin으로 복사합니다.
- build-armv7으로 armv7용 library만 만드는 것도 가능하지만 combine-libs를 보면 뭔가 이상하죠? 사실 이 스크립드의 원본은 gabriel의 ffmpeg ios compile script입니다. 제대로 armv6, armv7, i386 library를 만들어서 universal library를 만들어 봅시다. (script가 수정되었으니 여기에 첨부된 것을 받으세요)
- 위의 첨부된 파일을 받아 FFMPEG 디렉토리에 풉니다.
- gabriel의 소스에서 svn의 revision을 고정했고 target 마다 별도의 svn source를 다운하지 않도록 변경되었고 configure의 option이 수정되었습니다. --enable-postproc 이 제거되었고 --enable-gpl 을 off 시켰습니다. gpl option을 켜면 LGPL license가 아닌 GPL license가 됩니다. 모든 소스를 공개해야 되죠. 마찬가지의 이유로 LGPL의 경우 libx264나 libxvid를 사용할 수 없게 됩니다.
- svn에서 checkout하는 부분은 git으로 clone하도록 수정되었습니다. 더이상 ffmpeg에서 svn로 source를 공유하지 않습니다. 또한 ffmpeg의 configure option이 변경되었기 때문에 --extra-ldflags="-arch arm7" 뒤에 -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/lib/system 이 추가되었습니다. 그리고 document 생성에 문제가 있어 --disable-doc 이 추가되었습니다.
- 바로 build script를 돌리면 지금(2011-04-24)의 ffmpeg은 버그가 있어서 컴파일되지 않습니다.
Undefined symbols for architecture armv7:
"memset", referenced from:
_ff_ac3_bit_alloc_calc_bap_armv6 in libavcodec.a(ac3dsp_armv6.o)
(maybe you meant:__memset_chk, _memset )
"ff_vp8_dct_cat_prob", referenced from:
.Literal_2 in libavcodec.a(vp8_armv6.o)
(maybe you meant: __ff_vp8_dct_cat_prob)
ld: symbol(s) not found for architecture armv7
이런 메시지가 나오면서 link에서 문제가 발생합니다.
ffmpeg-source/libavcodec/ac3dsp_armv6.S 의 82 line에서
b memset 을 b X(memset) 으로
ffmpeg-source/libavcodec/vp8_armv6.S 의 183 line에서
movrel r4, ff_vp8_dct_cat_prob 를 movrel r4, X(ff_vp8_dct_cat_prob) 로
수정하셔야 합니다. - 이제 순서대로 build-armv6, build-armv7, build-i386 스크립트를 실행합니다. ffmpeg 사이트에서 소스를 checkout해 온 후 configure, make를 순서대로 수행하게 됩니다.
- 모든 target의 library가 compile되면 ffmpeg-armv6/dist, ffmpeg-armv7/dist, ffmpeg-i386/dist에 include, lib 디렉토리가 만들어지고 해더와 라이브러리가 생성됩니다.
- combine-libs를 실행해서 모든 target의 library를 합칩니다. ffmpeg-uarch에 최종 헤더와 라이브러리가 만들어집니다. libavcore.a는 더이상 존재하지 않습니다. combine-libs에서도 제거되어야 합니다.
build-ffmpeg-ios4.3.tar.gz
AVPlayer compile하기
- Xcode로 AVPlayer project를 엽니다.
- Targets 에서 AVPlayer,AVPlayerHD의 Build Settings을 선택합니다.
- Search Paths 항목의 Header Search Paths 란의 내용을 수정합니다. $(SRCROOT)/FFMPEG/ffmpeg-uarch/include, $(SRCROOT)/FFMPEG/ffmpeg-armv7/dist/include 이런식으로 수정하고 Recursive를 체크하면 됩니다.
- Search Paths 항목의 Library Search Paths 란의 내용을 수정합니다. $(SRCROOT)/FFMPEG/ffmpeg-uarch/lib, $(SRCROOT)/FFMPEG/ffmpeg-armv7/dist/lib 식으로 수정하고 Recursive를 체크하면 됩니다.
- AVPlayer/LIBS/FFMPEG 밑의 libavcodec.a, libavcore.a, libavdevice.a, libavfilter.a, libavformat.a, libavutil.a, libswscale.a의 Utilities 창을 열고 경로를 수정합니다. AVPlayer/FFMPEG/ffmpeg-uarch/lib 밑에 있는 library를 지정하면 됩니다. libavcore.a는 이제 존재하지 않습니다. library에서 제거하세요.
- 프로젝트의 라이브러리 설정은 모두 수정되었습니다. 이제 build 버튼만 누르면 됩니다. 단, 주의하실 점은 Simulator로는 build가 되지 않습니다. libAVPlayerLib.a에 AVPlayer의 중요한 코드들이 모두 숨어있는데, 이 라이브러리가 i386으로 compile 되어 있지 않습니다. arm용으로만 compile되어 있기 때문에 Device로만 bulid 가능합니다.
