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비트로 동작할 때

shared_ptr 객체를 멀티스레드에서 사용할 때

분명 shared_ptr은 레퍼런스 카운트가 스레드 안정적이라고 되어있다고 나와있지만 아래와같은 코드를 실행하면 실행하자마자 에러가 발생한다.

#include <memory>

std::shared_ptr<int> g;

DWORD WINAPI U(void *)
{
    while (true)
    {
        std::shared_ptr<int> data = g;
    }
    return 0;
}

DWORD WINAPI C(void *)
{
    while (true)
    {
        std::shared_ptr<int> data = std::make_shared<int>(0);

        g = data;
    }
    return 0;
}

int main()
{
    HANDLE h1 = CreateThread(NULL, 0, U, NULL, 0, NULL);
    HANDLE h2 = CreateThread(NULL, 0, C, NULL, 0, NULL);

    WaitForSingleObject(h1, -1);
    WaitForSingleObject(h2, -1);

    return 0;
}

거의 수시간동안 구글링해도 한결같이 나오는건 레퍼런스 카운트는 스레드 안전하다는 것 정도.
그래도 다행이도 계속 검색해보니 결국 아래와같이 atomic을 사용하는 코드가 나왔다.

#include <atomic>
#include <memory>

std::shared_ptr<int> g;

DWORD WINAPI U(void *)
{
    while (true)
    {
        std::shared_ptr<int> data = std::atomic_load(&g);
    }
    return 0;
}

DWORD WINAPI C(void *)
{
    while (true)
    {
        std::shared_ptr<int> data = std::make_shared<int>(0);
        std::atomic_store(&g, data);
    }
    return 0;
}

int main()
{
    HANDLE h1 = CreateThread(NULL, 0, U, NULL, 0, NULL);
    HANDLE h2 = CreateThread(NULL, 0, C, NULL, 0, NULL);

    WaitForSingleObject(h1, -1);
    WaitForSingleObject(h2, -1);

    return 0;
}

저렇게 atomic_store, atomic_load를 사용하니 이제 정상적으로 shared_ptr 객체가 두 스레드간의 참조가 문제없이 되었다. 분명 부스트의 shared_ptr 기준으로 코드를 보면 InterlockedIncrement 함수를 사용하여 카운트하던데 그마저도 저런식으로 사용하니 0xDDDDDDDD로 채워진 이미 초기화 된 변수가 나타났다. 좀처럼 이해하기 힘든 동작이였다.

수시간, 그리고 며칠동안 구글링 아무리 해봐도 shared_ptr는 참조 카운트가 스레드 안전하다고 할 뿐 좀 더 자세한 내용 잘 나오지도않고(…) 그냥 이렇게 사용해야 정말 안전하다 정도로 알고 넘어가야겠다 -_-;;;

shared_ptr 객체를 멀티스레드에서 사용할 때 의문점

ByteBuffer 클래스를 만들고 매소드 get, size 선언. private 맴버를 d, s를 두어 아래와같이 구현하였다.

#include <algorithm>

ByteBuffer::ByteBuffer(char *data, int size)
{
    if(size == 0)
    {
        d = nullptr;
        s = 0;
    }
    else if(data == nullptr)
    {
        d = new char[size];
        s = size;
    }
    else
    {
        d = new char[size];
        s = size;

        std::copy(data, data + size, d);
    }
}

ByteBuffer::~ByteBuffer()
{
    delete[] d;
}

char *ByteBuffer::get()
{
    return d;
}

int ByteBuffer::size()
{
    return s;
}

Continue reading shared_ptr 객체를 멀티스레드에서 사용할 때 의문점

최근 NVENC로하고있는 삽질

팀뷰어나 VNC로는 클라이언트에서 하드웨어 가속을 사용하지 못해서인지 모바일에서나 노트북에서나 발열이 좀 많다는게 단점. 특히나 게임은 화면 업데이트 빈도가 높아서인지 팀뷰어가 최적화 잘되어있지만 그래도 사용할 수 있는 대역폭에 비하면 화질이 좋지 못하였다.

아이폰이 GIF를 지원하지않는건 GIF는 하드웨어가속을 사용할 수 없기때문이라는데, 왠지 원격을 H.264로 스트리밍하고 제어한다면 노트북에서도 낮은 프로세서 사용률로 실시간으로 게임도 스트리밍하여 컨트롤 할 수 있지 않을까싶어 거진 2주간 NVENC와 XDGI 삽질을 하였다. DirectX 인터페이스나 미디어 스팩이나 아무것도 모르고 시작해서 지금도 아는게 없는상태에서 그냥 무작정 해보아서 이제야 막 결과가 눈에 들어오는 수준 orz

일단 결과는 간략하게 아래와같다.

%ec%ba%a1%ec%b2%98

인코딩 & 스트리밍 프로그램은 보여지는 화면이 없고 아직 MPEG4의 정상적인 스트리밍 방법을 모르기에 그냥 데이터만 있어도 재생이 되는 ffplay로 인코딩 된 raw 데이터를 바로 뿌려보았다. (파일로 출력하고 ffplay에서 읽도록 하면 거의 0.5초 정도 수준으로 지연이 있지만 tcp로 전송하니 버퍼링이 있어서인지 1초 넘게 지연이 생겨버린다.) 정상적으로 게임 화면이 나타나긴하지만 코딩하며 실행하면서 그래픽 메모리를 잘못 건든것이 있는지 종종 아래처럼 처참하게 깨지는 화면이 나타난다는건 덤.

2016-10-01

도중에 AAC 가속도 재공되는 인텔의 Media Codec을 사용해보려했지만 그건 나중으로 미루고 일단 NVENC를 사용하여 스트리밍하는것 부터 완벽하다 싶으면 건들어봐야겠다. 과연 완성이나 되련지 모르겠지만 완성되면 코드를 공개하던지 해봐야겠다. 아마도 ffmpeg 라이브러리를 사용해서 인코딩 하고 스트리밍 활용하는 방향으로 전환될수도 있지만 그건 나중 문제(…)

아래 화면은 그래픽카드의 비디오 엔진 점유율과 스트리밍 CPU 점유율이다. Continue reading 최근 NVENC로하고있는 삽질