DMB칩에서 받아온 영상을 v4l의 VIDIOCCAPTURE ioctl을 이용해 Read 해서 받아옵니다.
raw 데이터는 YUV422P 이미지이고 이것이 720*240 으로 들어오게 되는데
실제 데이터는 720*240에서 320*240 부분이기 때문에
ffmpeg라이브러리를 이용해서 320*240만큼만 crop을 하고 이것을 다시 YUV420P로
변환을 해냅니다.
Xlib을 쓰면 변환된 420P 이미지를 바로 뿌려줄수가 있는것 같더군요.
gdk_draw---- 를 쓰려면 데이터가 420P 에서 다시 RGB이미지로 변환을 해야하기 때문에 오버헤드가 너무 심합니다.
XvShmPutImage 를 쓰고 싶은데 GTK로 만든 window를 이것에 어떻게 맵핑시켜야할지 막막합니다.
id를 얻어오거나 하는 관련함수 몇개를 써봤는데 안되더군요..
제가 생각해 봐도 gtk나 xlib API를 이용해서 화면에 출력 하는 것은 성능상의 문제가 있어 보이는군요.
ffmpeg라이브러리를 이용해 보시는게 어떨까 싶네요.
display장비가 임베디드 장비시라면 framebuffer를 직접 억세스 할 수 있도록 해서 뿌리셔야 할테고요..
현재 작업을 하는 목적이 gtk와 v4l을 이용해서 pvr머신용 교육교재를 만드는 것입니다.
따라서 framebuffer를 직접 액세스 할 수 없고 v4l의 VIDIOCCAPTURE의 ioctl을 통해
read로 액세스 하고 있습니다. 물론 이 read 액세스하는 시간도 재 봤습니다만
그렇게 크진 않습니다.
샘플로 받은 소스코드가 있었습니다만
데이터가 yuv422P로 들어오는 것을 420p로 변환후 90 도 회전시킨다음
x를 직접 생성해서 화면에 뿌려주더군요.
사용한 함수는 XvShmPutImage 였습니다.
이것은 화면 출력해주는 오버헤드가 거의 없더군요..
제가 만든 소스는 ffmpeg라이브러리를 사용해서 422P를 420P로 변환후
320*240만큼 잘라내서 RGB데이터로 변환, gdk_draw_rgb_image를 이용해 뿌려줍니다.
시간을 재어봤는데 422p 에서 RGB데이터로 변환하는데 걸리는 시간이 매우 컸습니다.
불안정적으로 크기도 했구요.
그래서 320*240 크기만 해도 많이 끊깁니다. 그리고 화면이 밀려보이는 현상이
많이 보이더군요. 버퍼링도 해봤습니다만 (race condition해결을 하진 않았지만)
성능향상은 커녕 오히려 시간이 더 걸리더라구요.
받은 샘플 데이터와 제가 사용한 것은 read 하는 루틴은 물론,
VIDIOCCAPTURE를 사용하는것까지 모두 똑같고 YUV422P에서 420P로 변환하는
루틴은 ffmpeg라이브러리를 사용했기 때문에 오히려 더 나을거라 예상됩니다.
다만 gdk_rgb----를 이용해 화면에 뿌려주고 있고 rgb데이터로 변환하는 루틴이
추가됐기 때문에 더 많은 오버헤드가 있다고 추측하고 있습니다.
x가 아니더라도 상관없습니다. rgb변환만 하지 않아도 오버헤드는 확실히 줄일수
있을것 같습니다. 어떻게 해야할런지.. 막막하네요. 사흘동안 밤을 새도 답이 안나오네요.
휴.. ㅠㅠ
gdk때문에 느린 게
gdk때문에 느린 게 아닌 것 같네요. 그런 식으로 이미지를 뿌리면 xlib 써도 느린 건 마찬가지일 겁니다.
xv extension xshm 등등 x 프로토콜로 데이터를 전송하지 않아도 되는 방법을 이용하세요.
자세한 로직은..
DMB칩에서 받아온 영상을 v4l의 VIDIOCCAPTURE ioctl을 이용해 Read 해서 받아옵니다.
raw 데이터는 YUV422P 이미지이고 이것이 720*240 으로 들어오게 되는데
실제 데이터는 720*240에서 320*240 부분이기 때문에
ffmpeg라이브러리를 이용해서 320*240만큼만 crop을 하고 이것을 다시 YUV420P로
변환을 해냅니다.
Xlib을 쓰면 변환된 420P 이미지를 바로 뿌려줄수가 있는것 같더군요.
gdk_draw---- 를 쓰려면 데이터가 420P 에서 다시 RGB이미지로 변환을 해야하기 때문에 오버헤드가 너무 심합니다.
XvShmPutImage 를 쓰고 싶은데 GTK로 만든 window를 이것에 어떻게 맵핑시켜야할지 막막합니다.
id를 얻어오거나 하는 관련함수 몇개를 써봤는데 안되더군요..
조언부탁드리겠습니다.
질문 다시 정리하자면..
현재 GTK로 만들어 놓은 UI 가 있습니다.
이것중 하나의 gdkwidget의 window의 xwindow 주소값을 가져와서
바로 이미지를 뿌려주려고 합니다.
어떤 방식으로 해야할지 막막합니다.
답변 부탁드립니다..
제가 생각해 봐도
제가 생각해 봐도 gtk나 xlib API를 이용해서 화면에 출력 하는 것은 성능상의 문제가 있어 보이는군요.
ffmpeg라이브러리를 이용해 보시는게 어떨까 싶네요.
display장비가 임베디드 장비시라면 framebuffer를 직접 억세스 할 수 있도록 해서 뿌리셔야 할테고요..
http://fftv.sourceforge.net/
여기도 한번 참조해 보세요.
샘플로 받은 소스가 있었습니다.
현재 작업을 하는 목적이 gtk와 v4l을 이용해서 pvr머신용 교육교재를 만드는 것입니다.
따라서 framebuffer를 직접 액세스 할 수 없고 v4l의 VIDIOCCAPTURE의 ioctl을 통해
read로 액세스 하고 있습니다. 물론 이 read 액세스하는 시간도 재 봤습니다만
그렇게 크진 않습니다.
샘플로 받은 소스코드가 있었습니다만
데이터가 yuv422P로 들어오는 것을 420p로 변환후 90 도 회전시킨다음
x를 직접 생성해서 화면에 뿌려주더군요.
사용한 함수는 XvShmPutImage 였습니다.
이것은 화면 출력해주는 오버헤드가 거의 없더군요..
제가 만든 소스는 ffmpeg라이브러리를 사용해서 422P를 420P로 변환후
320*240만큼 잘라내서 RGB데이터로 변환, gdk_draw_rgb_image를 이용해 뿌려줍니다.
시간을 재어봤는데 422p 에서 RGB데이터로 변환하는데 걸리는 시간이 매우 컸습니다.
불안정적으로 크기도 했구요.
그래서 320*240 크기만 해도 많이 끊깁니다. 그리고 화면이 밀려보이는 현상이
많이 보이더군요. 버퍼링도 해봤습니다만 (race condition해결을 하진 않았지만)
성능향상은 커녕 오히려 시간이 더 걸리더라구요.
받은 샘플 데이터와 제가 사용한 것은 read 하는 루틴은 물론,
VIDIOCCAPTURE를 사용하는것까지 모두 똑같고 YUV422P에서 420P로 변환하는
루틴은 ffmpeg라이브러리를 사용했기 때문에 오히려 더 나을거라 예상됩니다.
다만 gdk_rgb----를 이용해 화면에 뿌려주고 있고 rgb데이터로 변환하는 루틴이
추가됐기 때문에 더 많은 오버헤드가 있다고 추측하고 있습니다.
x가 아니더라도 상관없습니다. rgb변환만 하지 않아도 오버헤드는 확실히 줄일수
있을것 같습니다. 어떻게 해야할런지.. 막막하네요. 사흘동안 밤을 새도 답이 안나오네요.
휴.. ㅠㅠ
[code]XvShmPutImage 를
이 말씀은 GDK Reference Manual/X Window System Interaction 에 나오는 함수들을 사용해 보셨다는 말 같군요. 제대로 맵핑만 시켜주면 잘 될거 같은데, 그렇지 않은가 보죠. 어떤식으로 맵핑시켰는지 좀 더 하나하나 상세하게 적어 주시면 다른 분들이 좀 더 도움을 주실 수 있을 거 같습니다.
혹시 아래 링크의 답변이 도움이 될지도 모르겠습니다. 이 질문 올린 사람은 더미윈도우를 쓰는 방법으로 일단 가능하기는 한데, 이 방법이 마음에 들지 않나 봅니다.
http://mail.gnome.org/archives/gtk-list/2002-September/msg00215.html
전 사실 이런거에 문외한이라서 도움은 못드리겠네요. 혹시 해결하시게 되면, 글로 올려주시면 감사하겠습니다. DMB 장치중에 리눅스를 기반으로 하는 것도 있을 텐데, 데스크탑 리눅스용으로 사용할 수 있는 것이 나오지 않는 이유는 뭘까요???
해결했습니다.
엑스 프로그래밍이 처음이라 많이 어려웠습니다.
대충 해결은 했네요. 말씀대로 엑스 시스템 인터랙션쪽으로 해결을 보았습니다.
다만 일반적으로 엑스 윈도우를 생성하고
이것저것 등록(?)하는 일련의 과정은 하지 않아도 되네요.
지금 개발하는 것과 관련된 것은 제 블로그에 포스팅하고 있고
조만간 이쪽으로도 글을 올리도록 하겠습니다.
덧. 제가 사용하는 장치도 임베디드 리눅스를 사용하고 있습니다.
데스크탑용이 없나요? USB로 인식하는 장치만 있으면 가능할듯도 싶다는 생각이 드네요.
많은분들 도움 감사드립니다.
댓글 달기