개발 – 페이지 6 – 날조 블로그

Qt 5.8.0 WebEngine 모듈 빌드

보통은 그냥 Qt 홈페이지에서 빌드된것을 받아서 설치해도된다. 단, 5.8.0은 배포중인 VS 2017 타겟 바이너리가 없고, 디버깅 시 상황에 따라서는 약간 더 유리하기때문에 직접 빌드하는걸 선호한다. (그리고 그냥 갠적인 취향 약 80%) 이전에 누수를 찾을 수 없어 직접 빌드하여 QtSql의 ODBC 플러그인 메모리 누수 버그를 찾아내고 코드 리뷰에 올리고 커밋하여 아마도 5.6.0버전부터 적용되어있다는건 안비밀(…)

일단 두서없는 글이였지만 이것을 참조하여 OS의 비 유니코드 환경을 영어(미국)으로 바꾸는것이 이롭다.

이번에도 직접 빌드 삽질. 5.7.0과는 다르게 필요한 것들은 다 있는데 configure 후 nmake(or jom)을 해도 웹 엔진이 빌드되지않았다. 영문 문서…에서는 일단 해석도 잘 못하고 그냥 봤을때는 별다른 언급이 없었다. 정말 아무리 찾아봐도 별다른 내용이 없었다. (덕분에 5~6번은 distclean & build 한거같다.)

문서에 Qt 개별 모듈을 받아서 빌드 언급이 잠깐있어서 혹시나하여 소스코드에서 qtwebengine 폴더로 이동 후 qmake & nmake(or jom)을 실행하니 빌드가되었다. 아마도 이게 워낙 오래걸리고 덩치가 커서 기본적으로 skip 처리되어있는거 아닌가 싶다. 하지만 규모가 큰 C++ 프로젝트는 오류 한두개 생기는 법. 그래서 직접 빌드를 해본 내용을 정리.

환경 1
Visual Studio Community 2015 Update 3 (최소 Update 2가 요구된다.)
Windows SDK 10.0.15063.137

환경 2
Visual Studio Community 2017
Windows SDK 10.0.1563.137 (Visual Studio 2017에서 함께 설치되는 Windows SDK 10은 지우고 ISO 파일을 받아서 다시 깔았다. 필요에 의해서였는데 왜인지 기억이 안난다 -_-)

공통
Perl 최신버전 (Qt 문서에서는 Active Perl로 명시되어있지만 Strawberry Perl로도 가능)
Python 2.7.5 or later (Qt 문서에서는 2.7.5 or later로 명시되어있지만 3버전으로 테스트 안해봤음)
메모리는 8기가 이상.. 왠만하면 16기가 이상을 권장한다. 이것역시 WebEngine에서 사용하는 Chromium의 코그가 워낙 방대해서 메모리에 파일캐쉬를 많이 못하면 디스크 IO가 많이발생하여 빌드 속도에도 영향이있다.

Windows SDK 10을 설치하면 mt.exe 파일을 못찾는 경우가 발생한다. 명령줄에서 mt를 쳐서 명령을 못찾는다면 아래처럼 환경변수에 추가해야한다.
32비트 도구 프롬포트 환경
set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86
64비트 도구 프롬포트 환경
set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64

환경 1에서의 WebEngine 에러 수정
코드 리뷰: https://codereview.chromium.org/2317773002/patch/60001/70005

소스코드 폴더 기준으로 “qtwebengine\src\3rdparty\chromium\device\bluetooth” 경로의 bluetooth_task_manager_win.cc 파일을 열고 OnGetGattEventWin 함수가 정의된 157줄을 void 뒤 CALLBACK 추가하여 void CALLBACK OnGetGattEventWin으로 정의를 변경

환경 2에서의 configure 에러 수정
코드 리뷰: https://codereview.qt-project.org/#/c/177743
이건… 수정할게 좀 많다. 그냥 이 페이지를 참고해서 비교하어 수정하는게 나을것같다. qalgorithms.h파일의 경로는 “qtbase\src\corelib\tools”이다.
만약 직접 수정하기가 좀 그렇고 5.8.0버전의 코드를 빌드한다면 이 주소로 파일을 받은다음 압축을 풀고 이름을 원래대로 수정한다음 덮어씌워도 된다.

아래는 내가 사용한 configure 명령 줄
configure -opensource -confirm-license -prefix D:\OpenSource\Qt5.8.0 -opengl dynamic
opengl 옵션을 지정안하면 es2로 설정되고 5.5부터는 dynamic을 기본으로 사용하는 것 같다. (참고)
prefix는 빌드 후 nmake install 하면 바이너리와 헤더가 설치되는 경로.

configure 명령이 완료된 후 nmake(or jom)을하면 문제없이 빌드 될것이며 이후 nmake install(or jom install)을하면 기본 Qt 모듈들이 복사될것이고, WebEngine을 빌드하려면 소스코드 폴더에서 qtwebengine 폴더로 이동한 후 qmake하고 역시나 nmake(or jom)하여 빌드, nmake install(or jom install)하면된다.

단지 주의할것으로는 perl, python명령이 실행되는지, flex, bison, gperf명령이 실행되는지 확인하는것이 좋다. Qt 소스코드 내 gnu 명령어들이 있으니 아래처럼 환경변수를 변경하여 재공되는거로 쓰는게 이로울거같다. (소스가 “D:\OpenSource\qt-everywhere-opensource-src-5.8.0″에 있다는 가정)

set PATH=%PATH%;D:\OpenSource\qt-everywhere-opensource-src-5.8.0\gnuwin32\bin;D:\OpenSource\qt-everywhere-opensource-src-5.8.0\qtbase\bin

환경변수가 잘 설정되었다면 아래와같이 각각의 버전정보를 볼 수 있다.

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>python --version
Python 2.7.13

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>perl --version

This is perl 5, version 24, subversion 1 (v5.24.1) built for MSWin32-x64-multi-thread

Copyright 1987-2017, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


D:\OpenSource\qt-everywhere-opensource-src-5.8.0>bison --version
bison (GNU Bison) 3.0
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>flex --version
flex 2.5.37

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>gperf --version
GNU gperf 3.0.1
Copyright (C) 1989-1998, 2000-2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Douglas C. Schmidt and Bruno Haible.

뭐… 갠적으로는 webengine을 사용할 일이 없지만 왠지 5.7 빌드할때와 달라서 불필요한 삽질을 한거같다(…)

Objective-C와 Swift에서 NSData(Data) 데이터 단순 탐색

Objective-C 코드 (bytes는 NSData 클래스 객체에서 bytes를 호출하여 얻은 데이터 포인터)

for(uint32_t i = 0; i < dataSize - 4; i++)
{
    uint32_t startCode = *(uint32_t *)(bytes + i);

    if(startCode == 0x01000000)
    {
        [points addObject:[NSValue valueWithPointer:bytes + i]];
        [nalSizes addObject:[NSNumber numberWithInt:4]];
        
        i += 3;
    }
    
    if((startCode & 0x00FFFFFF) == 0x00010000)
    {
        [points addObject:[NSValue valueWithPointer:bytes + i]];
        [nalSizes addObject:[NSNumber numberWithInt:3]];
        
        i += 2;
    }
}

Swift 코드 (3.0으로 빌드, streamData는 Data 클래스의 객체)

streamData.withUnsafeBytes { (p8: UnsafePointer) in
    while i < count
    {
        if p8.advanced(by: i + 0).pointee == 0 && p8.advanced(by: i + 1).pointee == 0
        {
            if p8.advanced(by: i + 2).pointee == 0 && p8.advanced(by: i + 3).pointee == 1
            {
                offsets.append(i)
                nalSizes.append(4)
                
                i += 4
                
                continue
            }
            if p8.advanced(by: i + 2).pointee == 1
            {
                offsets.append(i)
                nalSizes.append(3)
                
                i += 3
                
                continue
            }
        }
        i += 1
    }
}

H264에서 NAL 헤더를 찾는 코드이다. 어쩌다보니 기존에 Objective-C로 코드를 만들어놓은걸 Swift로 옮기다보니... 생각보다 삽질을 많이하게되었다. 프레임워크는 동일하지만 Swift는 기본적으로 포인터 연산을 지원하지않기때문에 C에서의 구조체, 바이너리 데이터를 int형식으로 형변환하여 비교하는 등의 연산에서 자유롭지않아보인다. 동일한 LLVM에서 컴파일되고 1:1 호환 가능하다고는하지만 위와같은 사항 외에도 언어의 특성이있어서 목적은 동일하지만 결국은 코드의 구조는 달라졌다.

딱봐도 Swift의 코드가 비효율적으로 보이지만 초당 1메가정도의 데이터에서 CPU점유율을 보면 1~2%정도만 더 Swift에서 많이 사용한다. 아직 릴리즈 빌드는 찾아본적없어서 export하게되면 또 차이날지는 모르겠지만... 현재로서는 약 2~3시간 삽질을 한 결과 위 코드가 Objective-C의 코드와 가장 근접한 CPU 사용률을 보이는 코드이다.

아래는 순서대로 Objective-C, Swift 코드에서의 CPU 사용률

VideoToolbox 디코더에서 픽셀 포맷을 BGRA와 420YpCbCr를 사용할때의 CPU 점유율 차이

일단 각각의 차이

kCVPixelFormatType_32BGRA 값을 사용할 때

kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange 값을 사용할 때

하드웨어 스펙

420YpCbCr 색상으로 출력할 때 평균적으로 3~4%정도 점유율이 더 적다. Metal 텍스쳐 두개를 생성하고 GPU에서 색상변환하기위해 소비되는 연산보다 VideoToolbox에서 BGRA로 변환하여 CVImageBufferRef 객체를 생성하는 부하가 더 큰것으로 보인다.

맥에서 어느정도 끝나면 iOS앱에도 Metal을 사용해서 얼마나 차이나는지 비교해봐야겠다.

Video Decode Acceleration Framework 사용 시 주의점

최근 거의 2주일동안 apple의 하드웨어 H264 디코더인 VDA와 씨름을 하였다. 이건 H264의 깊이있는 지식을 가지고 쓴것이 아니고 단지 VDA로 하드웨어 디코딩을 하기위해 중점을 맞춘것이니 깊이있는 지식은 넘어가고 VDA나 VideoToolbox를 사용하기위해 참고하는 정도만으로 넘어가야 할 것이다.

VDA에 관한 기술문서로 https://developer.apple.com/library/content/technotes/tn2267/_index.html 페이지가 거의 유일하며, 그나마 참조할건 http://stackoverflow.com/questions/29525000/how-to-use-videotoolbox-to-decompress-h-264-video-stream 이 글의 댓글이 거의 유일하다. (물론 VideoToolbox와 VDA는 초기화 방법이 서로 다르지만, VDA에서 지원되는 기능은 VideoToolbox에서도 동일하게 지원하는거로 보이고 avcC라는 것을 생성하지 않아도 되기때문에 초기화가 더 수월하다.)

먼저 이론적인 기본은 위 stackoverflow의 댓글로 확인하면 될것이다. 약간 첨언한다면 H264는 3바이트, 또는 4바이트짜리 Start Code라고 불리는 코드로 각각의 프레임을 구분한다. 그리고 디코딩에 필요한 NALU 타입은 7 (SPS), 8 (PPS), 5 (IDR), 1 (non-IDR) 정도로 보인다.

디코더를 초기화하기 위해서는 SPS, PPS가 필요하며, 이 정보를 바탕으로 디코딩을 한다. (영어가 된다면 https://developer.apple.com/videos/play/wwdc2014/703/ 이것이 참고가 될것이고, 프레젠테이션 자료는 Resource 탭에서 받을 수 있다.) Continue reading Video Decode Acceleration Framework 사용 시 주의점 →

닷넷 Any CPU 빌드한 바이너리가 64비트 OS에서 32비트로 동작할 때

닷넷으로 Text to Speech. 즉 입력 된 텍스트를 읽어주는 TTS를 해달라는 부탁으로 시작하게 된 삽질.

내가 사용하는 OS는 윈도 10이고 타겟은 윈도 7이였다. 윈도 TTS는 https://msdn.microsoft.com/en-us/library/hh361572(v=office.14).aspx 이곳에서 Runtime, Language Packs 두가지를 설치하면 된다고 되어있는데… 이상하게 아무리 재설치를해도 한글 음성이 지원되는 Voice 객체가 나타나지않았다.

윈도 제어판에서는 한글 음성이 나타나는데 닷넷에선 아무리 해도 나타나지않아 포기하고 C++로 Voice 객체를 조회해보았지만 역시나 실패. 혹시나해서 64비트로 빌드하여 다시 조회하니 Heami가 나타나는 것이였다.

그런것이였다. 윈 10은 32비트, 64비트 둘 다 한글 Voice가 재공되는 것이였다… 근데?! 뭐지? 싶어 닷넷 실행파일 띄워놓고 작업관리자 열어보니 32비트로 실행되고있고, 구글링해보니 http://stackoverflow.com/a/23351613 이 댓글이 나왔고, 프로젝트 속성을 보니 아래 옵션이 있었다.

2016-10-16-1

32비트 기본 사용…!!! 32비트 기본이라니! 하.하!? VS2015에서 기본으로 체크되는 옵션인지 어떤지는 모르겠지만 회사에서 VS2015가 나오자마자 구입하였는데… 왠지 최근 만든 닷넷 어플들 32비트 모드로 동작하고있을거같다.

아마도 ActiveX라던지 COM Object, 기타 외부 네이티브 라이브러리가 32비트가 대다수라 생기는 문제가 많기때문에 이런걸 기본옵션으로 체크되어있는거같은데… 나같은 경우엔 그 반대라서 하루 삽질을 하였다.

아… 해결되어서 좋긴한데 왜 눈물이 나려하지… 내 시간은..

Continue reading 닷넷 Any CPU 빌드한 바이너리가 64비트 OS에서 32비트로 동작할 때 →