언제부턴가 이게 궁금하더라고요.
View인것 같기는 한데. 이게 또 단순하게 View라고 보기에는
예를들어 Live Encoder의 Preview화면 같은건 그 자체가 데이터란 말이죠.
그럼에도 엮시 화면에 나오는거니까 View의 영역이 맞을까요?
사실 기본적으로는 C++개발자이고 동영상 일을 오래 하다 보니 Model같은것을 적용해서 개발을 한적이 없습니다. 만…
GUI부분은 C++로는 더이상은 못 만들겠다 싶다보니 의문이 드네요.
C++ GUI라이브러리가 이제 거의 안나오고 좀 쓸만하다 싶으면 상용에 C++도 아닙니다.
예를들면 QT는 상용에 이거 자체가 상당히 큰 프레임웍이라 QT로 개발하는 순간 종속성에
묶여버리죠.
SCITER, UltraLight 웹UI입니다. 일정 규모 이상의 기업일 경우 유료입니다.
IMGUI 좋긴한데… 커스텀화 하기가 엄청 번거롭죠.
기타 나머지것들도 비슷비슷합니다.
이제 C++로는 코어만 만들고 UI는 다른걸 가져다 써야 하는 상황인데.
더욱이 이렇다보니 플레이어나 프리뷰를 하는것들은 View가 맞는 것 같긴한데.
코어 라이브러리를 거기다 심어야 한다는게 매우 걸리는거죠.
1개의 좋아요
일전에 WPF로 영상 플레이어 프로젝트를 했던 경험으로는
영상 인코딩 처리는 C++ 라이브러리에서 처리 되었는데
해당 C++ 라이브러리가 참조된 서비스는 영상 이미지 데이터를 지속적으로 스트림으로 데이터를 내보내기만 하고
필요한 뷰모델이 의존성 주입 받아서
영상 이미지를 스트림 형식으로 뿌려주면 바인딩 처리된 뷰에 플레이 되도록 처리 했었습니다.
이렇게 데이터 플로우 설계로 했을때
말씀 하신 인코더 처리의 데이터는 영상 처리의 코어인 C++ 라이브러리를 사용해서 스트림 형태로 계속 뿌려 주기만 하고 (이 데이터를 누가 받을지는 알 필요가 없습니다.)
그 스트림이 필요한 뷰모델이 스트림으로 흘러가는 데이터에 빨때를 꽃아 영상 데이터를 받아
뷰에 통보 해주는 식으로 분리 할 수 있습니다.
이러면 동영상 뷰어 처리는 뷰, 모델, 뷰모델 어디 한곳에 속한다고 볼 수 없고, 여러 역할들의 존재가 모여서 뷰어 처리를 한다고 볼 수 있습니다.
4개의 좋아요
저도 생각은 했던 부분이 코어는 아예 별개의 것으로 개념을 잡고 해야지 않나 싶었는데.
그게 맞는 길인 것 같네요.
일단 현재는 저는 개인적으로는 코어만 작업을 하고 있고요.
이후에 UI를 아발로니아 또는 우노를 생각하고 있습니다.
코어 부분도 전체적으로 멀티플랫폼으로 지원 가능하도록 만들고 있어서 WPF를 붙이기는 약간 아깝기도 하고요.
문제는 팀원들이 C++밖에 못하는데다 C++을 C스타일로 만드는 사람들이라 제가 만드는것에
거부감이 좀 있습니다. 답답한 현실이죠.
2개의 좋아요