Dekodowanie wideo z ffmpegiem

 
W tym wpisie przedstawię podstawy użycia bibliotek, na których opiera się słynny program ffmpeg. Nie będę tu prezentował przykładów użycia ffmpega jako aplikacji. Przedstawię za to pewien minimalny kod, umożliwiający wydobycie i zdekodowanie do bitmapy  każdej klatki dowolnego wspieranego przez ffmpega pliku zawierającego wideo.

1. ffmpeg

Pod tą nazwą kryje się przede wszystkim pojedynczy program, obsługiwany z linii poleceń. W Internecie można znaleźć kilka określeń, m.in. “FFmpeg – the swiss army knife of Internet Streaming” albo oficjalne hasełko “A complete, cross-platform solution to record, convert and stream audio and video”. Można śmiało powiedzieć, że powyższe slogany są prawdziwe. Jeśli chodzi o operacje na cyfrowych multimediach, a przede wszystkim procesy dekodowania i kodowania wideo to ffmpeg jest najpotężniejszym z dostępnych narzędzi. Jest również niezwykle kłopotliwy, po pierwsze z powodu dość skomplikowanej składni poleceń, pod drugie z ubogiej dokumentacji. Do tego wymaga dość solidnej wiedzy z zakresu multimediów cyfrowych – form reprezentacji danych wideo i audio, kodowań, formatów, protokołów, a także rozmaitych niuansów z dziedziny przetwarzania audio/wideo.

Sam program ffmpeg, jeśli spojrzeć na rozmiar kodu źródłowego, jest dość kompaktowy. Cały jego ogromny mechanizm został umieszczony w pakiecie bibliotek:

avformat
avcodec
avutil
avdevice
avfilter
swscale
swresample
postproc

avformat obsługuje – jak sama nazwa wskazuje – formaty multimedialne, zwane też kontenerami, czyli na ogół pliki takie jak .avi .mov .mp4 .mkv itd. Implementuje rozmaite skanery i parsery które wyciągają z plików metadane i umożliwiają dostęp do kolejnych zakodowanych klatek/ramek wideo/audio.
avcodec – to obsługa kodeków – zarówno koderów jak i dekoderów wideo i audio, ale także napisów. Baza obsługiwanych przez avcodec kodeków jest ogromna i można śmiało stwierdzić, że avcodec obsługuje dekodowanie wszystkich współczesnych, “przemysłowych” kodowań.
swscale i swresample – pierwsza służy do obsługi skalowania wideo i konwersji między formatami piksela (w tym konwersje przestrzeni barw, np YUV –> RGB i odwrotnie), druga służy do operacji na zdekodowanym audio, głównie do zmian częstości próbkowania i liczby kanałów.

Na podstawie tych bibliotek można dość niewielkim wysiłkiem stworzyć prosty program playera, obsługujący olbrzymią liczbę kodeków i formatów. Jedyne czego by tutaj brakowało, to obsługa GUI. To daje pewne pojęcie o tym, jak potężnym narzędziem jest ffmpeg wraz z jego bibliotekami. W tym wpisie przedstawię pewien minimalny kod, obsługujący dekodowanie wideo z plików multimedialnych do bitmap RGB.

 

2. Kontener multimedialny

Warto przy okazji bardzo ogólnie opisać z czego składa się typowy plik multimedialny, zwany czasem kontenerem lub formatem. Jest to wprawdzie temat na osobny wpis, który być może niebawem powstanie.

 

kontener

Zatem plik multimedialny może zawierać metadane, które opisują jego zawartość, jednak nie musi tak być. Wystarczy przypomnieć sobie pliki mp3, które mogły zawierać tylko dźwięk, ale format dopuszczał załączanie tagów ID3, w których można było zawrzeć tytuł, autora, album i szereg innych informacji charakterystycznych dla utworu muzycznego.
Plik multimedialny może zawierać kilka strumieni. Z reguły mamy do czynienia z jednym audio, jednym wideo. Czasem ścieżek dźwiękowych jest kilka i wówczas najczęściej w metadanych znajduje się wzmianka o języku danej ścieżki dźwiękowej. Mogą się również tutaj znaleźć napisy, które przez ffmpega traktowane są jako oddzielne strumienie.

Jeszcze rzut oka na to co z reguły zawierają metadane kontenera multimedialnego.

metadane

Musimy przy tym pamiętać, że większość formatów (kontenerów) multimedialnych wspiera tylko określone kodeki. Przykładem może być MPEG2 Transport Stream, który może jedynie przenosić strumienie wideo zakodowane w którymś z kodowań MPEG.

W dzisiejszym wpisie skupimy się wyłącznie na pojedynczym strumieniu wideo.

3. Program

Biblioteki ffmpega napisane są w C, nagłówki do nich nie zawierają typowego zabezpieczenia w postaci #ifdef __cplusplus dlatego pracując w C++ każdy #include z API ffmpega musi być zawarty w magicznym bloku extern “C” {} wymuszającym traktowanie zawartych funkcji jako stricte C, inaczej kompilator “zmanglowałby” nazwy funkcji zgodnie ze standardem C++, co kończy się błędem z serii “unidentified symbol“.

Potem w main():

To wywołanie aktywuje wszystkie muksery, demuksery, parsery, kodery i dekodery, z jakimi zbudowany był nasz build ffmpega.

avformat_open_input otwiera plik multimedialny. W przedostatnim parametrze możemy określić dokładnie, za pomocą jakiego demuksera plik ma być otwarty. Tutaj jest to NULL, zatem avformat będzie musiał odgadnąć o jaki format chodzi, co raczej nie sprawi bibliotece problemu, nawet, gdy usuniemy rozszerzenie .mov .
AVFormatContext jest obiektem przechowującym stan parsera i demuksera pliku. Powstaje wskutek wywołania avformat_open_input. Nie jest to jednak tzw nieprzejrzysty wskaźnik (opaque pointer). Jest to rozbudowana struktura, w której zawarte są inne struktury itd. Większość pól kontekstu ma swoje konkretne znaczenie w procesie muksowania (kodowania) i demuksowania (dekodowania). Większość popularnych formatów posiada wydzielone miejsce w pliku, gdzie przechowywane są najistotniejsze metadane, na przykad liczba strumieni, ich konfiguracje, czas trwania i tym podobne. W takich przypadkach kontekst wypełni się wszystkimi potrzebnymi informacjami wskutek wywołania avformat_open_input. W przypadku formatów, w których nie ma oddzielnego “nagłówka” z metadanymi, jak na przykład MPEG2 TS, przydatne może się okazać wywołanie avformat_find_stream_info.

Funkcja ta przespaceruje się potreści pakietów kontenera poszukując informacji o liczbie strumieni i ich konfiguracji. Akurat przypadku pliku .mov nie jest to niezbędny krok.
W tym przypadku okazało się, że w pliku są 3 strumienie #0 – wideo, #1 – dane (timecode), #2 – audio. Do badania kontenerów multimedialnych polecam skorzystać z narzędzia ffprobe w pakiecie ffmpega, bardzo ładnie wypisuje wszystkie informacje zawarte w AVFormatContext.
Pora wyodrębnić pierwszy napotkany strumień wideo:

avformat w trakcie otwierania pliku stara się ustalić z jakim kodekiem mamy do czynienia w każdym ze strumieni i jaka jest konfiguracja kodeka wymagana do odkodowania zawartego w strumieniu medium.

Wypisze:
ID kodeka wideo: 28
Niewiele to mówi, jest to jedynie enum wewnątrz avcodec.h, jednak możemy za pomocą tego ID wydobyć z avcodec’a obiekt dekodera odpowiadający temu ID.

AVCodec jest obiektem kodera-dekodera. Jest to w zasadzie struktura tylko do odczytu, która powstaje podczas wołania av_register_all . Na podstawie ID możemy wydobyć dekoder odpowiadający kodekowi naszego strumienia o ile został wkompilowany w nasz build podczas budowania bibliotek. Powyższy kod wypisał:
Kodek wideo: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
Teraz pora na uruchomienie dekodera. O ile obiekt AVCodec jest swego rodzaju singletonem, zawierającym jedynie wskaźniki do funkcji realizującej dany kodek, obiekt AVCodecContext jest już tym, co przechowuje cały stan kodowania bądź dekodowania.
AVCodec jest jeden na cały proces, natomiast AVCodecContext alokujemy za każdym razem, gdy chcemy coś zakodować/zdekodować. Otwarcie dekodera powoduje związanie kontekstu z kodekiem.
Podczas otwierania pliku avformat stworzył również po jednej strukturze AVCodecContext na każdy strumień. W przypadku audio i wideo struktury te zostały wypełnione konfigurcjami strumieni i kodeków. Mając AVCodecContext i AVCodec możemy już uruchomić dekoder:

Warto nadmienić, że z biblioteki avcodec można korzystać oddzielnie od avformat. Wówczas twórca aplikacji sam musi zaalokować AVCodecContext i najczęściej wypełnić go konfiguracją umożliwiającą zdekodowanie strumienia.

Ten fragment kodu w zasadzie nie robi nic. Gdyby seekTimestamp miał wartość taką jak w zakomentowanych liniach to nastąpiłoby “przewinięcie” strumienia do danego czasu. W tym wypadku podstawą czasu strumienia wideo jest milisekunda.
av_seek_frame powoduje skok demuksera do czasu podanego w argumencie (seekTimestamp). Jednak w większości współczesnych kodeków wideo poszczególne klatki strumienia zą od siebie zależne i większości klatek nie można zdekodować zanim nie zostaną zdekodowane poprzednie. Dlatego avformat w takich przypadkach skacze do najbliższej klatki kluczowej, która nie zależy od innych klatek i może być zdekodowana natychmiast. Flaga AVSEEK_FLAG_BACKWARD oznacza tyle, że seek zaprowadzi nas do najbliższej klatki kluczowej, której timestamp jest niewiększy od podanego do funkcji. Bez tej flagi byłby to timestamp niemniejszy od podanego. Teraz czas na demuksowanie, czyli wyciąganie zakodowanych klatek z kontenera.

av_read_frame czyta z kontenera kolejne pakiety audio/wideo (a także pozostałych typów strumieni). Prosty filtr eliminuje te, które nie należą do pierwszego strumienia wideo.
av_init_packet inicjalizuje pola AVPacket do wartości zerowych, w końcu packet został zaalokowany na stosie i jego poszczególne pola są niezainicjalizowane.

AVFrame reprezentuje tutaj klatkę zdekodowaną, do frm dekoder zapisze obraz powstały ze zdekodowania klatki packet. Za pomocą zmiennej got sygnalizowane jest, że w tym wywołaniu do frm avcodec zapisał zdekodowaną ramkę. W przypadku niektórych kodeków (np audio) aby powstała ramka wyjściowa, na wejście musi zostać podanych kilka ramek wejściowych. Poza tym w przypadku niektórych dekoderów ramka wyjściowa pojawia się dopiero po włożeniu dwóch ramek na wejściu (codec delay). Po dotarciu do końca pliku w dekoderze mogą znajdować się zbuforowane ramki, wówczas “wypłukuje” się je (flush) za pomocą pustych AVPacket (packet.data = NULL).
Ponieważ z większości dekoderów wideo otrzymamy bitmapy w przestrzeni barw YUV i dodatkowo podpróbkowane (np YUV 4:2:0), konieczna będzie konwersja do RGB. Tutaj sięgamy po swscale.

Pole pix_fmt w AVCodecContext mówi jaki jest format piksela, czyli z jaką przestrzenią barw mamy do czynienia i ile bitów przypada na  każdą składową piksela. Jak widać, nie przeprowadzamy tutaj skalowania, a jedynie konwersję przestrzeni barw. Po tej operacji, w buforze rgb24 znajdzie się zdekodowana bitmapa w formacie RGB i głębi 8 bitów na kolor.

A oto wynik działania dla filmu Big Buck Bunny i timestampów:

frame

frame

frame

 

Poniżej pełen kod programu:

(kliknij aby rozwinąć)

 

2 przemyślenia nt. „Dekodowanie wideo z ffmpegiem

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *