Ontwikkeling van DirectShow-filters voor de visualisatie van een H.264/AVC-bitstroom

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Ontwikkeling van DirectShow-filters voor de visualisatie van een H.264/AVC-bitstroom door Dieter Van de Walle Promotor: prof. dr. ir. Rik Van de Walle Thesisbegeleider: lic. P. Lambert AFSTUDEERWERK INGEDIEND TOT HET BEHALEN VAN DE ACADEMISCHE GRAAD VAN LICENTIAAT IN DE INFORMATICA Academiejaar

2

3 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Ontwikkeling van DirectShow-filters voor de visualisatie van een H.264/AVC-bitstroom door Dieter Van de Walle Promotor: prof. dr. ir. Rik Van de Walle Thesisbegeleider: lic. P. Lambert AFSTUDEERWERK INGEDIEND TOT HET BEHALEN VAN DE ACADEMISCHE GRAAD VAN LICENTIAAT IN DE INFORMATICA Academiejaar

4 Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dit afstudeerwerk. Datum Handtekening iv

5 Dankwoord Deze thesis is er enkel kunnen komen dankzij de hulp en steun van vele mensen, ik ben dan ook iedereen dankbaar die mij geholpen en gesteund heeft tijdens de realisatie van deze thesis. Ik wil vooral mijn promotor, Prof. Rik Van de Walle, en begeleider, Lic. Peter Lambert bedanken. Als ik een probleem had of advies nodig had dan kon ik steeds op hen rekenen. Verder wil ik mijn familie bedanken voor de steun en afwisseling. Ook al mijn vrienden ben ik dankbaar, hoewel ze vooral zorgden voor moeilijk te weerstane afleidingen zorgden ze tegelijk ook voor de nodige mentale verfrissing na het werk. Ik had deze thesis echter nooit kunnen maken zonder de steun van die ene persoon die me drijft in alles wat ik doe en mij altijd bijstaat, mijn vriendin Joke. v

6 Ontwikkeling van DirectShow-filters voor de visualisatie van een H.264/AVC-bitstroom door Dieter Van de Walle Afstudeerwerk ingediend tot het behalen van de academische graad van licentiaat in de informatica Academiejaar Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitten: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. P. Lambert Samenvatting In deze thesis onderzoeken we de mogelijkheid om de decoder die voordien ontwikkeld werd door dhr. Pycke deel te laten uitmaken van de Windows DirectShow-architectuur. Eerst geven we een algemene inleiding tot DirectShow en de relevante aspecten van de H.264/AVC-standaard. Daarna maken we een gedetailleerde analyse van de eerder door dhr. Pycke ontwikkelde decoder. We besluiten de nieuwere, aangepaste en meer uitgebreide decoder van dhr. Devolder te gebruiken en stellen met oog op de integratie in DirectShow een aantal aanpassingen voor aan deze decoder. De eigenlijke implementatie van de nodige DirectShow-filters maakt ook deel uit van deze thesis. Een hoofdstuk wordt besteed aan de beschrijving van de beslissingen die werden genomen bij het ontwerp van deze filters en een beknopt overzicht van de implementatie. We slagen in ons opzet en hebben zowel een parser- als een decoderfilter ontwikkeld die het mogelijk maakt om H.264/AVC-bitstromen in het annex B formaat te gebruiken binnen de DirectShow-architectuur. De opbouw van deze filters maakt het mogelijk om ze met minieme aanpassingen te gebruiken in combinatie met andere decoders en/of andere DirectShow filters. Trefwoorden: H.264/AVC-standaard, videocompressie, DirectShow, 3ivx vi

7 Inhoudsopgave HOOFDSTUK 1 INLEIDING SITUERING DOELSTELLINGEN STRUCTUUR OPMERKINGEN...4 HOOFDSTUK 2 DIRECTSHOW INLEIDING DE DIRECTSHOW-FILTER Soorten DirectShow-filters Filter pins Het maken van een connectie tussen filters DE DIRECTSHOW-GRAAF Intelligent Connect Bewerkingen op een filter graaf Synchronisatie HOOFDSTUK 3 DE H.264/AVC-STANDAARD INLEIDING DE VIDEO CODING LAYER Levels en profielen Overzicht van encoder en decoder DE NETWORK ABSTRACTION LAYER De Access Unit HOOFDSTUK 4 DE DECODER INLEIDING ANALYSE VAN DE DECODER Object georiënteerd? Een volgende decoder De interface van de decoder Problemen voor gebruik in DirectShow (Threading) DE AANGEPASTE DECODER HOOFDSTUK 5 DE ONTWIKKELDE DIRECTSHOW-FILTERS vii

8 5.1 INLEIDING DE BRONFILTER DE PARSER FILTER Functie Ontwerpbeslissingen Implementatie DE DECODER FILTER Functie Ontwerpbeslissingen Implementatie METINGEN Methode en verantwoording De tests UITBREIDINGEN Zoeken in de videostroom Compatibel maken met de 3ivx splitter filter HOOFDSTUK 6 BESLUIT BIJLAGE A CD-ROM BIJLAGE B INSTALLATIE VAN DE FILTERS BIBLIOGRAFIE viii

9 Lijst van figuren FIGUUR 2.1 TYPISCHE DIRECTSHOW-GRAAF...9 FIGUUR 2.2 VOORBEELD VAN EEN GRAAF VOOR HET AFSPELEN VAN EEN VIDEOBESTAND MET GELUID...9 FIGUUR 3.1 OVERZICHT VAN EEN H.264/AVC-ENCODER FIGUUR 3.2 OVERZICHT VAN EEN H.264/AVC-DECODER FIGUUR 3.3 TOONT DE MOGELIJKE VOLGORDES VAN NAL-EENHEDEN BINNEN EEN ACCESS UNIT 17 FIGUUR 4.1 VISUALISATIE VAN DE STRUCTUUR VAN DE DECODER NAAR DE GEBRUIKER (PROGRAMMEUR) TOE FIGUUR 4.2 TYPISCHE DIRECTSHOW-GRAAF FIGUUR 4.3 DE ORIGINELE VORM VAN DE STARTDECODING() METHODE FIGUUR 4.4 DE AANGEPASTE CODE FIGUUR 5.1 TYPISCHE DIRECTSHOW-GRAAF FIGUUR 5.2 TYPISCHE GRAAF VOOR HET WEERGEVEN VAN EEN GECODEERD VIDEOBESTAND FIGUUR 5.3 GRAAF VOOR HET AFSPELEN VAN H.264/AVC-BITSTROOM FIGUUR 5.4 BOOM DIE DE WEERGEEFT VAN WELKE KLASSEN DE CBASEINPUTPIN KLASSE OVERERFT FIGUUR 5.5 MOGELIJKE TRANSITIES TUSSEN DE VERSCHILLENDE STATEN VAN FILTERS FIGUUR 5.6 DE TESTGEGEVENS FIGUUR 5.7 GRAFIEK MET VERGELIJKING VAN DE BEELDSNELHEDEN BEREIKT MET DE ORIGINELE DECODER TEN OPZICHTE VAN DE DIRECTSHOW-FILTERS ix

10 Hoofdstuk 1 Inleiding 1.1 Situering Deze thesis gaat in essentie over de Advanced Video Coding -standaard voor videocodering, ook bekend onder de namen ITU-T Recommendation H.264 of ISO/IEC (MPEG-4) Part 10. De standaard die tegenwoordig het meest gebruikt wordt voor videocodering is deze gekend onder de naam MPEG-4 Part 2 (Visual). Hoewel deze standaard nu al een tijdje bestaat, zijn de mogelijkheden ervan toch nog steeds niet volledig uitgediept. Deze standaard mag zeker een mijlpaal in de technologische vooruitgang genoemd worden. Sinds de ontwikkeling en ingebruikname van deze standaard is er echter al veel veranderd. Een breedbandaansluiting is gemeengoed in de meeste gezinnen. De bandbreedte beschikbaar op netwerken blijft verhogen. Ook de beschikbare rekenkracht is er sterk op vooruitgegaan. Dit laat toe om complexere, meer rekenkracht-intensieve algoritmes te gebruiken om videobeelden te comprimeren en zo een hogere efficiëntie in beeldcompressie te bereiken. De H.264/AVC-standaard speelt daar handig op in. De H.264/AVC-standaard beschrijft een manier om videosequenties op een bijzonder efficiënte manier te coderen. Dit betekent dat de geëncodeerde videosequentie zo weinig mogelijk bits bevat, terwijl de beeldkwaliteit zo veel mogelijk bewaard blijft. De trade-off voor deze hoge efficiëntie is een hogere complexiteit, wat zich in de praktijk vertaalt in een hoger CPU-verbruik. Dit hoeft echter geen bezwaar te vormen. Dankzij de wet van Moore weten we immers dat mogelijke grenzen aan processorkracht slechts tijdelijk zijn. 1

11 1.2 Doelstellingen Deze thesis bouwt verder op de thesis van Tom Pycke ( ) (zie [1]). Deze thesis had tot doel om een raamwerk voor een H.264/AVC-decoder op te zetten, en om een eenvoudige decoder te implementeren. Dhr. Pycke is in zijn opzet geslaagd, en daarom beschikken wij nu over een lichtgewicht H.264/AVC-decoder. Voor gedetailleerde informatie over deze decoder verwijzen wij U door naar hoofdstuk 4, waar deze uitvoerig besproken wordt en enkele verbeteringen voorgesteld worden. Als we het voortaan hebben over de H.264/AVC-decoder, dan verwijzen wij altijd naar de decoder ontwikkeld door dhr. Pycke. Hoewel de decoder zijn taak naar behoren uitvoert is deze toch moeizaam in het gebruik. De decoder doet immers enkel het strikte minimum, namelijk een H.264/AVC-gecodeerd bestand omzetten in een ongecodeerd, ongecomprimeerd videobestand. In de meeste gevallen zal het de bedoeling zijn om dit ongecodeerde videobestand af te spelen. Daarvoor is dan echter nog een ander programma nodig, dat ook niet bepaald gebruiksvriendelijk te noemen is. Het zou veel gebruiksvriendelijker en efficiënter zijn mocht het mogelijk zijn om deze twee stappen te combineren. Deze thesis stelt een oplossing voor voor dit probleem. De thesis beschrijft hoe de decoder ingebed kan worden in de DirectShow-architectuur van Microsoft. Op die manier wordt niet enkel een oplossing geboden voor het bovenstaande probleem, we krijgen er meteen heel wat voordelen bij. Voor een gedetailleerde bespreking van deze voordelen, en een algemeen overzicht van de DirectShow-architectuur verwijzen wij U door naar het volgende hoofdstuk. We kunnen U echter reeds vertellen dat het afspelen van een H.264/AVC-geëncodeerd bestand dankzij de H.264/AVC-decoder en de DirectShow-architectuur net zo eenvoudig zal zijn als de manier waarop U eender welk mediabestand afspeelt op het Windows-platform: dubbelklikken op het H.264/AVC-bestand is genoeg om ervoor te zorgen dat de videosequentie wordt afgespeeld in uw favoriete mediaspeler! Dit klinkt erg simpel, maar dat is het zeker niet! DirectShow zorgt ervoor dat alle details met betrekking tot de (nochtans erg complexe) taak van het afspelen van mediabestanden, verborgen blijven voor de gebruiker. Eventuele componenten nodig voor het afspelen van een mediabestand (zoals bijvoorbeeld de H.264/AVCdecoder in het geval van een H.264/AVC-bestand) worden automatisch aangewend waar en wanneer nodig. Een groot deel van deze thesis bestond uit het implementeren van deze oplossing, men kan de voordelen van de ontwikkelde componenten dus zelf ervaren. We hopen dat de software ontwikkeld in het kader van deze thesis een hulpmiddel kan 2

12 zijn voor alle mensen die de H.264/AVC-decoder gebruiken, bestuderen of verder ontwikkelen. 1.3 Structuur Voor we kunnen overgaan tot de beschrijving van de ontwikkelde DirectShowfilters is het nodig dat U vertrouwd wordt (voor zover U dit nog niet bent) met de verschillende technologieën die aangewend werden om deze thesis te realiseren. Daarom zullen we het in de volgende 3 hoofdstukken hebben over respectievelijk DirectShow, de H.264/AVC-standaard en de H.264/AVC-decoder ontwikkeld door dhr. Pycke. Er valt over elk van deze onderwerpen echter erg veel te vertellen, en we zullen ons daarom beperken tot de delen die relevant zijn voor deze thesis. We gaan er echter van uit dat U over een basiskennis beschikt met betrekking tot videobewerking en bijhorende termen, en met betrekking tot objectgeoriënteerd programmeren. Na deze inleidende hoofdstukken vindt U een beschrijving van de ontwikkelde DirectShow-filters, en een verantwoording voor de beslissingen die genomen werden omtrent het ontwerp van deze filters. Een overzicht van de indeling van de hoofdstukken: Hoofdstuk 1: Inleiding Dit hoofdstuk. Hoofdstuk 2: DirectShow Een inleiding tot de Microsoft DirectShow-architectuur en een studie van de werking en interactie van DirectShow-filters. Hoofdstuk 3: De H.264/AVC-standaard In dit hoofdstuk bespreken we kort de geschiedenis van de H.264/AVCstandaard, en gaan we dieper in op de aspecten van de standaard die van belang zijn voor deze thesis. Hoofdstuk 4: De decoder Hier bespreken we beknopt de decoder ontwikkeld door dhr. Pycke, en in het bijzonder hoe deze decoder het best te gebruiken valt in combinatie met de DirectShow-architectuur. Er zal blijken dat dit niet zomaar mogelijk is, en er worden enkele verbeteringen aan deze decoder voorgesteld. Hoofdstuk 5: De ontwikkelde DirectShow-filters Dit hoofdstuk behandelt de essentie van deze thesis, namelijk de 3

13 ontwikkelde DirectShow-filters. Dit hoofdstuk wordt onderverdeeld in twee delen, een deel voor de parser filter en een deel voor de transform filter. Hoofdstuk 6: Besluit Conclusie. In bijlage vindt U een CD-ROM met daarop alle code van de ontwikkelde DirectShow-filters, alsook een digitale versie van deze thesis, en de bijhorende presentatie. 1.4 Opmerkingen Aangezien een groot deel van deze thesis bestaat uit programmeerwerk is het erg verleidelijk om ons te laten gaan in details omtrent de implementatie van de ontwikkelde filters. Dit komt de leesbaarheid van de thesis echter niet ten goede en daarom zullen we ons daarin proberen beperken. Indien U geïnteresseerd bent in de details van de implementatie van de ontwikkelde filters verwijzen wij U graag door naar de code en bijhorend commentaar van deze filters, die U kan vinden op de CD-ROM in bijlage. We hebben ons best gedaan om ervoor te zorgen dat deze code toegankelijk en goed gedocumenteerd is. Tijdens het lezen van deze thesis zal U merken dat we ervoor gekozen heb om meestal de engelse benaming aan te houden voor de verschillende termen die aan bod komen in deze thesis. De reden hiervoor is dat het proberen vertalen van alle engelse termen die aan bod komen vooraleerst bijna onbegonnen werk is, dat de nederlandse vertalingen vaak erg krampachtig overkomen, en dat het gebruik van vertalingen in veel gevallen ook erg verwarrend is. De betekenis van de vertaling valt immers vaak niet samen met de oorspronkelijke betekenis van de engelse term. 4

14 Hoofdstuk 2 DirectShow 2.1 Inleiding Microsoft DirectShow is een architectuur voor streaming media voor het Microsoft Windows platform. DirectShow zorgt ervoor dat allerhande gebruikelijke bewerkingen op streaming media, zoals afspelen, conversie van het ene mediaformaat naar het andere en het capturen van audio- of video-informatie, sterk vereenvoudigd worden. Met een simpele dubbelklik van de muis kan elk mediabestand dat gekend is binnen DirectShow afgespeeld worden. De gebruiker merkt helemaal niet dat de processen die dit mogelijk maken in feite erg complex zijn. De DirectShow-architectuur is uitbreidbaar: iedereen die over de nodige kennis beschikt kan zelf een DirectShow-component aanmaken en deze toevoegen aan de DirectShow-architectuur. En dit is precies wat ons te doen staat in deze thesis: één of meerdere DirectShow-componenten ontwikkelen die het mogelijk maken om een H.264/AVC-gecodeerde bitstroom af te spelen binnen de DirectShow-architectuur. Er zijn twee basisobjecten in DirectShow: de DirectShow-filter en de DirectShowgraaf. In de volgende paragrafen gaan we dieper in op elk object. 2.2 De DirectShow-filter De DirectShow-filter is de hoeksteen van de hele DirectShow-architectuur. Conceptueel is een DirectShow-filter een object waar een aantal datastromen ingaan (de inputs), en waar een aantal datastromen uitkomen (de outputs). De filter voert één specifieke bewerking uit op deze datastromen. Belangrijk om op te merken is dat een filter (en meer algemeen de hele DirectShow-architectuur) werkt 5

15 met datastromen. Zoals eerder reeds vermeld: de DirectShow-architectuur is een streaming architectuur. Concreet betekent dit dat een filter zich enkel bewust is van de stukken data die hij op een bepaald moment in de tijd toegewezen krijgt om te bewerken. De taak van een DirectShow-filter is simpel: elke stukje data dat de filter ontvangt verwerken en terug doorgeven. Een DirectShow-filter werkt volgens het principe van de black box: de gebruiker (in dit geval de programmeur) weet wat de filter doet (bijvoorbeeld: videobeelden encoderen/decoderen, een visueel effect toepassen op videobeelden, een echo toevoegen aan een geluidsstroom, ), maar hoeft zich geen zorgen te maken over hoe de filter zijn taak vervult of over de exacte werking van de filter Soorten DirectShow-filters De DirectShow-filters kunnen onderverdeeld worden in 3 klassen: De sourcefilter: Dit type filter is de bron van data, de filter genereert data. Eigen aan dit soort filters is dat ze niet beschikken over inputs. Ze hebben wel één of meer outputs. Dit type filter is vaak geassociëerd met een hardware apparaat, zoals bijvoorbeeld een geluidskaart, een webcam, De renderer filter: De renderer filter is het tegengestelde van de source filter. Deze filter beschikt enkel over inputs. Er komt enkel data in de filter. Dit type filter is als het ware het eindstation voor de datastroom. De data die deze filter binnenstroomt is dan ook meestal van een vorm die geschikt is voor weergave. Enkele typische voorbeelden van renderer filters: een filter die videogegevens afbeeldt op het scherm, een filter die audiogegevens afspeelt, een filter die gegevens schrijft naar een bestand, De transform filter: Dit type filter is het meest voorkomende. De filter bevat minstens één input en één output. Er stroomt data in de filter, de filter voert een transformatie uit op de gegevens en de bewerkte gegevens verlaten de filter. Enkele typische voorbeelden van transform filters: filters die audio-/videogegevens encoderen of decoderen, filters die een bepaald effect toepassen op een audiostroom (galm, echo, volumeverandering, ), filters die een bepaald effect toepassen op een videostroom (omzetting naar zwart/wit, het beeld vervagen, ). 6

16 2.2.2 Filter pins Een DirectShow-filter beschikt over een aantal inputs en over een aantal outputs. Binnen DirectShow bestaat er een object dat een dergelijke input of output vertegenwoordigt, namelijk de filter pin. Zo n pin is een object dat als tussenpersoon dient tussen de filter zelf en een andere filter. Een pin kan ofwel een input pin (er komen gegevens de filter binnen via deze pin) of een output pin (gegevens verlaten de filter via deze pin) zijn. Een filter heeft minstens één pin. Meestal ligt het aantal pins van een filter vast, maar het is mogelijk voor de filter om dynamisch pins toe te voegen en te verwijderen. De taak van een pin is in de eerste plaats om te onderhandelen over een connectie met een andere filter, en om data door te geven eens een connectie gemaakt is Het maken van een connectie tussen filters De filters zelf hebben eigenlijk weinig te maken met het connectieproces tussen de filters, aangezien het volledige connectieproces gedelegeerd wordt naar de filter pins. Een connectie tussen twee filters is dus eigenlijk eerder een connectie tussen een pin van elke filter, met name een output pin van de filter die zich opwaarts in de gegevensstroom bevindt en een input pin van de filter die zich lager in de gegevensstroom bevindt. Het maken van een verbinding tussen twee filters (of twee pins) is een ingewikkeld proces. De pins moeten het immers eerst eens worden over welke soort gegevens ze precies zullen uitwisselen, en hoe ze deze gegevens zullen uitwisselen. Concreet betekent dit dat er 3 dingen moeten afgesproken worden tussen beide pins. Ten eerste het mediatype van de gegevens die zullen doorgegeven worden. Dit mediatype beschrijft precies hoe de data die doorgegeven zal worden er moet uitzien. Ten tweede moet er ook een transportmechanisme afgesproken worden. Dit transportmechanisme beschrijft hoe de gegevens uitgewisseld zullen worden. En uiteindelijk moet er ook nog beslist worden welke allocator object gebruikt zal worden. Dit allocator object is verantwoordelijk voor het toewijzen ( alloceren ) van geheugen dat beide pins kunnen gebruiken om gegevens uit te wisselen. Nu zullen we bij elke fase in het connectieproces een woordje uitleg geven. Mediatype onderhandeling Voor twee pins (en dus ook de respectievelijke filters) een connectie kunnen maken moeten ze onderzoeken of de pins wel in staat zijn om gegevens uit te wisselen. Het heeft bijvoorbeeld weinig zin dat een output pin die audiogegevens doorgeeft een verbinding maakt met een input pin die videogegevens verwacht. 7

17 De output pin heeft de controle over de onderhandeling van het mediatype. De output pin zal eerst een lijst van geprefereerde mediatypes opvragen bij de input pin van de andere filter. De output pin zal elk mediatype van deze lijst dan onderzoeken om een mediatype te vinden dat beide pins ondersteunen. Indien dit mediatype gevonden wordt, dan kan de verbinding gemaakt worden. Indien de lijst geen ondersteunde mediatypes bevat, dan zal de output pin zelf mediatypes gaan voorstellen aan de input pin. Indien dit ook geen gemeenschappelijk ondersteunde mediatypes oplevert, dan faalt het connectieproces. De pins kunnen dan onmogelijk een connectie maken. Transportmechanisme onderhandeling Als het mediatype dat beide pins zullen gebruiken om onderling data uit te wisselen vastligt kan er verdergegaan worden met de volgende fase van het connectieproces, namelijk de onderhandeling omtrent het transportmechanisme. Er zijn twee soorten transportmechanismen: het push model en het pull model. Bij het push model zal de output pin alle data die hij ontvangt onmiddellijk doorgeven aan de input pin waarmee hij verbonden is. Die input pin moet dan gewoon de data aannemen. De output pin duwt de gegevens dus als het ware naar de verbonden input pin. Bij het pull model zal de input pin zelf gegevens gaan opvragen bij de verbonden output pin. Bij het merendeel van de connecties tussen filters wordt het push model gebruikt. Allocator onderhandeling De laatste stap bij het maken van een verbinding tussen twee pins is het afspreken van een allocator object. Dit object is verantwoordelijk voor het beschikbaar stellen van geheugenruimte waarin de pins de uit te wisselen gegevens kunnen plaatsen. Zo n stuk geheugen wordt een buffer genoemd. Er moet ook afgesproken worden hoeveel buffers er nodig zijn, en hoe groot elke buffer minstens moet zijn. Meestal bevinden deze buffers zich in het werkgeheugen van de computer, maar dit is niet altijd zo. Een filter die geassociëerd is met een hardware apparaat kan bijvoorbeeld geheugen van dit apparaat (bijvoorbeeld een grafische kaart) beschikbaar stellen om gegevens uit te wisselen, wat een bijzonder gunstig effect kan hebben op de prestatie. Ook hier heeft de output pin de controle over het onderhandelingsproces. De output pin stelt een allocator object voor aan de input pin, en de input pin keurt de allocator goed of geeft zijn eigen voorwaarden terug, net zolang tot er een akkoord bereikt wordt. Als deze fase van het onderhandelingsproces succesvol afgerond wordt, dan is de connectie tussen de filters een feit. De doorstroom van gegevens tussen de filters kan nu aanvangen. 8

18 2.3 De DirectShow-graaf Source Filter Transform Filter Renderer Filter 1 of meerdere Figuur 2.1 Typische DirectShow-graaf Een DirectShow-graaf verzamelt een aantal DirectShow-filters. Deze filters worden aan elkaar geschakeld tot een zinvolle combinatie. Een simpele graaf bestaat minstens uit een bronfilter en een renderer filter. Meestal bevinden er zich echter heel wat filters in een filtergraaf. De data stroomt als het ware door de verschillende filters in de graaf, van bronfilter(s) naar renderer filter(s). Elke filter ontvangt gegevens van de voorgaande filter(s) in de graaf (behalve de source filter, die geen data ontvangt), en elke filter geeft de bewerkte gegevens door aan de volgende filter(s) in de graaf (behalve de renderer filter, die geen gegevens doorgeeft). Figuur 2.2 Voorbeeld van een graaf voor het afspelen van een videobestand met geluid Om dit alles te illustreren ziet U in Figuur 2.2 een voorbeeld van hoe een graaf om een videobestand af te spelen eruit kan zien. Linksboven in de figuur ziet U de enige bronfilter in de graaf. De taak van deze filter is het inlezen van het bestand, en het doorgeven van de ingelezen data aan 9

19 de volgende filter, in dit geval de AVI Splitter filter. Deze filter zal de gegevens die hij ontvangt van de bronfilter onderzoeken en onderverdelen in 2 aparte datastromen: een audiostroom en een videostroom. De videodata (bovenste pad vertrekkende van de AVI Splitter filter) wordt doorgegeven aan een filter die de data zal decoderen naar een ongecomprimeerd videoformaat. Deze gegevens komen tenslotte in de Video Renderer filter terecht, die ervoor zorgt dat de beelden weergegeven worden op het scherm. De audiodata (onderste pad vertrekkende van de AVI Splitter filter) ondergaat een soortgelijke transformatie: de data wordt eerst gedecodeerd door middel van een MPEG Layer-3 Decoder filter, waarna de gedecodeerde gegevens terecht komen in de Default DirectSound Device renderer filter. Deze filter is geassociëerd met de geluidskaart en zorgt ervoor dat het geluid afgespeeld wordt. Deze combinatie van filters zorgt er dus voor dat de audio- en videogegevens die zich beide in het bestand bevinden afgespeeld worden. Merk op dat U duidelijk de stroom van de gegevens in de figuur kan zien, van bronfilter naar de 2 renderer filters Intelligent Connect Handmatig bepalen welke filters er nodig zijn om bijvoorbeeld een videoclip af te spelen is een erg lastig en tijdrovend werk. Als het nodig is dat uw programma verschillende mediaformaten ondersteunt, dan zal U heel wat tijd moeten besteden aan het zoeken van de nodige filters om met elk mediatype om te gaan en aan het zoeken naar manieren om deze filters te verbinden. Gelukkig bevat DirectShow een technologie genaamd Intelligent Connect. Intelligent Connect zal onderzoeken welke filters er in de graaf aanwezig zijn, hoe deze filters correct verbonden moeten worden en welke extra conversie filters eventueel nodig zijn om deze filters te verbinden, en Intelligent Connect zal de verbindingen dan ook maken. Dit gebeurt allemaal volledig automatisch achter de schermen, zonder enige tussenkomt van de programmeur. Op deze manier bespaart Intelligent Connect de programmeur al het lastige werk bij het verbinden van filters. Het nadeel van deze techniek is dat de programmeur niet precies weet welke filters er achter de schermen gebruikt worden of hoe ze verbonden zijn. Als er bijvoorbeeld meerdere filters beschikbaar zijn die dezelfde taak uitvoeren, dan zal Intelligent Connect willekeurig één van deze filters kiezen. De programmeur kan echter achteraf wel opvragen welke filters Intelligent Connect gekozen heeft. 10

20 Het is echter ook mogelijk om de filters die zeker moeten gebruikt worden aan de filter graaf toe te voegen voor Intelligent Connect gebruikt wordt. Bij het opstellen van de filter graaf zal Intelligent Connect zoveel mogelijk proberen gebruik maken van de filters die reeds zijn toegevoegd aan de graaf. Op die manier kan men suggesties doen aan Intelligent Connect over welke filters gebruikt moeten worden Bewerkingen op een filter graaf Er zijn drie basisbewerkingen mogelijk op een filtergraaf, deze zijn: run, stop en pause. De run bewerking zorgt ervoor dat de data begint te stromen door de graaf. De stop bewerking zorgt ervoor dat de datastroom stopgezet wordt. Als er een pause bewerking uitgevoerd wordt, dan wordt de datastroom ook stopgezet, maar alle filters blijven klaar om verder te werken van zodra er weer een run bewerking uitgevoerd wordt. Indien één van deze bewerkingen uitgevoerd wordt op een graaf, dan zal deze elke filter in de graaf op de hoogte brengen van deze bewerking. Op deze manier kan elke filter gepast reageren op de actie Synchronisatie Alle filters in de filter graaf dienen met elkaar te worden gesynchroniseerd. Bij het afspelen van een videofragment met geluid moeten geluid en beeld immers gelijklopen. Voor dit doel zorgt de filter graaf voor een softwarematige klok. Deze klok is beschikbaar voor elke filter in de graaf. Aan de hand van deze klok kunnen filters de timing van de gegevens verzorgen. Alle mediadata is immers gelabeld met het tijdstip waarop de data moet weergegeven worden. 11

21 Hoofdstuk 3 De H.264/AVC-standaard 3.1 Inleiding De MPEG-2/H.262-videocoderingstandaard die meer dan 10 jaar geleden ontwikkeld werd ( ), zorgde ervoor dat TV-signalen efficiënt verstuurd konden worden via satelliet, kabel of radiosignalen. Hedendaagse populaire breedbandoplossingen zoals xdsl of UMTS bieden echter een kleinere bandbreedte, die het tot nu toe nog niet mogelijk maakte om een uitgebreid aantal televisiekanalen aan te bieden via deze verbindingen. Er is dus nood aan een techniek die nog efficiënter is en nog meer compressie kan toepassen op de videobeelden. De technologische vooruitgang en het goedkoper worden van geheugen- en processorkracht zorgden ervoor dat zo n technieken mogelijk werden. In 1998 werd er door de Video Coding Experts Group (VCEG) van de International Telecommunication Union, Telecommunication Standardization Sector (ITU-T) gestart met een project genaamd H.26L met als doel om de coderingsefficiëntie te verdubbelen vergeleken met bestaande videocoderingsstandaarden. In 2001 vormde de VCEG samen met de Moving Picture Experts Group (MPEG) het Joint Video Team (JVT), met de opdracht om de nieuwe standaard, die ondertussen de naam H.264/AVC had gekregen, af te werken. In 2003 werd de standaard afgerond. De standaard staat ook bekend onder de naam MPEG-4 Part 10 Advanced Video Coding, en maakt dus deel uit van de MPEG-4 standaard. De H.264/AVC-standaard beschrijft enerzijds een zogenaamde Video Coding Layer (VCL), die beschrijft hoe videoinformatie moet gecodeerd worden, en een Network Abstraction Layer (NAL) die beschrijft hoe de VCL informatie moet onderverdeeld worden en welke extra informatie (headers) moet toegevoegd worden zodat de gegevens makkelijk verstuurd kunnen worden langs verschillende transportmechanismen of kunnen opgeslagen worden op verschillende media. 12

22 Voor deze thesis zal blijken dat vooral de beschrijving van de Network Abstraction Layer erg interessant zal zijn. Alles wat met de Video Coding Layer te maken heeft wordt immers afgehandeld door de H.264/AVC-decoder, die niet zozeer het onderwerp is van deze thesis. De standaard beschrijft de syntax van de Video Coding Layer en de Network Abstraction Layer en ook hoe een H.264/AVC-decoder er moet uitzien, maar over de encoder zegt de standaard niks. Men wordt dus volledig vrij gelaten in de implementatie van een H.264/AVC-encoder, zolang deze maar bitstromen produceert die voldoen aan de syntax beschreven in de standaard. Het is immers mogelijk dat men in de toekomst efficiëntere algoritmes vind om een gecodeerde bitstroom te genereren. Zolang deze bitstroom voldoet aan de syntax beschreven in de standaard is het dus perfect mogelijk om deze nieuwe algoritmes te gebruiken. In dit hoofdstuk zullen we een beknopt overzicht geven van de inhoud van de H.264/AVC-standaard. Dit is echter bedoeld als een inleiding tot H.264/AVC en niet als een gedetailleerde technische beschrijving, daarvoor verwijzen wij U door naar andere bronnen (zie [1], [3], [8] en [9]). En voor meer informatie over een specifiek onderwerp kan men altijd terecht in de standaard zelf ([11]). 3.2 De Video Coding Layer Levels en profielen H.264/AVC-video moet kunnen gebruikt worden op allerlei soorten apparaten, gaande van kleine mobiele toestellen (zoals GSM s bijvoorbeeld) tot digitale cinema projectoren. Het is echter duidelijk dat de decoder van deze laatste een stuk ingewikkelder zal zijn dan deze in een mobiel toestel. Daarom beschrijft de standaard 14 levels, die beschrijven wat een decoder moet kunnen. Deze levels beschrijven welk formaat het beeld heeft (resolutie in pixels) en hoeveel macroblokken er per seconde moeten gedecodeerd kunnen worden. Daarnaast bestaan er ook nog profielen. De standaard beschrijft 3 mogelijke profielen: het baseline-profiel, het main-profiel en het extended-profiel. Het baseline profiel Het baseline profiel is vooral bedoeld voor applicaties waarbij een minimale vertraging erg belangrijk is, zoals bijvoorbeeld videogesprekken. Aangezien zowel 13

23 encoder als decoder dus weinig tijd hebben om hun werk te doen, moeten deze vrij eenvoudig blijven. Het main profiel Dit profiel is bedoeld voor broadcasting en entertainment video (zoals bijvoorbeeld DVD). Aangezien tijd hier niet zo kritiek is als bij het baseline profiel, kan de bitstroom een stuk efficiënter gecodeerd worden. Het main profiel bevat dan ook vooral verbeteringen die de codeerefficiëntie verhogen. Aangezien de media waarvoor dit profiel bedoeld is weinig tot geen fouten introduceren, worden enkele technieken die de foutrobuustheid verhogen niet ondersteund. Het extended profiel Het extended profiel is een uitbreiding van het baseline profiel. Het is vooral bedoeld voor streaming video, dus foutrobuustheid en schaalbaarheid zijn heel belangrijk Overzicht van encoder en decoder De hoge compressiegraad die gehaald kan worden door middel van H.264/AVCcodering berust op een combinatie van vele vernuftige technieken. We zullen op een vereenvoudigde manier de werking van een H.264/AVC-encoder overlopen en daarbij de voornaamste technieken vermelden. In een eerste stap worden de beeldgegevens opgesplitst in verschillende componenten: een luminantiecomponent (lichtsterkte) en twee kleurcomponenten. De derde kleurcomponent kan berekend worden uit de luminantie en de twee andere kleurcomponenten. Deze representatie van beelden wordt het YUV-formaat genoemd (zie [4]). Aangezien het oog veel gevoeliger is voor verschillen in lichtsterkte dan voor kleurverschillen, wordt de kleurcomponent onderbemonsterd. Dit betekent dat de kleurgegevens met een minder hoge resolutie opgeslagen worden, zowel horizontaal als verticaal wordt in elke kleurcomponent slechts om de andere pixel opgeslagen. Dit betekent dus dat slechts 1/4 e van alle kleurinformatie opgeslagen wordt. Dit alleen betekent al een compressie van 50%! 14

24 Figuur 3.1 Overzicht van een H.264/AVC-encoder Daarna wordt het beeld onderverdeeld in de zogenaamde macroblokken, die elk 16x16 pixels van de luminantiecomponent en 8x8 pixels van elke chrominatiecomponent bevatten. De nu volgende stappen worden telkens apart op elke component van het macroblok uitgevoerd. In een volgende stap zal men ofwel de spatiale redunantie ofwel de temporele redunantie gaan uitbuiten. Spatiale redunantie steunt op het feit uit dat naburige pixels vaak erg gelijkend zijn. Temporele redunantie steunt op het feit dat twee opeenvolgende beelden vaak erg gelijkend zijn. De encoder zal de inhoud van elk macroblok voorspellen aan de hand van spatialeof temporele redunantie. Daarna wordt het verschil gemaakt van het voorspelde macroblok en het echte macroblok. Aangezien deze voorspelling vaak erg goed is, zal dit verschil dan ook erg klein zijn, en dus weinig informatie bevatten (en makkelijk te comprimeren zijn)! Het verschil van elk macroblok zal nu door middel van transform coding (een bewerking sterk gelijkend aan een discrete cosinus transformatie) omgezet worden in een aantal coëfficiënten. Deze worden vervolgend gekwantiseerd. Dit kwantiseren kan je zien als een soort afronden van de coëfficiënten. De resulterende kwantisatiewaarden voor elk macroblok worden dan in zig-zag volgorde overlopen en in een entropie-encoder ingevoerd. In dit geval wordt gebruik gemaakt van runlength encoding. 15

25 Figuur 3.2 Overzicht van een H.264/AVC-decoder Bij de decodering gebeurt dit proces omgekeerd: de videogegevens worden eerst gedecodeerd door de entropie-decoder. Door middel van eerder gedecodeerde macroblokken wordt een voorspelling gemaakt van de inhoud van het macroblok. Deze voorspelling wordt dan aangepast met het verschil dat door middel van een inverse transformatie en dequantisatie berekend werd aan de hand van de gedecodeerde kwantisatiewaarden. Zo bekomt men (ongeveer) weer het originele beeldsegment. Tenslotte wordt er nog een antiblokfilter toegepast op elk gedecodeerd beeld om te voorkomen dat de grenzen tussen de macroblokken te zichtbaar zouden zijn. 3.3 De Network Abstraction Layer Het Network Abstraction Layer gedeelte van de H.264/AVC-standaard beschrijft hoe de gegevens uit de Video Coding Layer dienen te worden onderverdeeld, en welke extra gegevens (de zogenaamde header-data) er dienen toegevoegd te worden opdat de gegevens geschikt zouden zijn voor het transport over verschillende transportmechanismen of opslagmedia. Alle gegevens uit de VCL zijn vervat in NAL-eenheden, die elk een integer aantal bytes bevatten. Doordat de gegevens als het ware verpakt zijn in deze NALeenheden zijn ze geschikt voor transport over zowel pakket-gebaseerde transportmechanismen (zoals TCP/IP, UDP, etc) als over bitstroom-gebaseerde transportmechanismen. Het enige verschil is dat een NAL-eenheid in het laatste 16

26 geval voorgegaan wordt door een startcode die het begin van de NAL-eenheid markeert De Access Unit start access unit delimiter SEI primary coded picture De H.264/AVC-standaard legt enkele beperkingen op aan de volgorde waarin NALeenheden kunnen voorkomen. Zo moet een Picture Parameter Set (PPS) NAL-eenheid (dit is een NAL-eenheid die parameters bevat over de geëncodeerde beelden) of een Sequence Parameter Set NAL-eenheid (dit is een NALeenheid die parameters bevat over een bepaald stuk geëncodeerde videobeelden) logischerwijs eerder in de gegevensstroom voorkomen dan NAL-eenheden die verwijzen naar de PPS of SPS NAL-eenheid in kwestie. redundant coded picture end of sequence end of stream end Figuur 3.3 Toont de mogelijke volgordes van NAL-eenheden binnen een Access Unit Bepaalde NAL-eenheden vormen samen een zogenaamde Access Unit. Deze Access Unit is heel belangrijk, omdat deze precies één geëncodeerd beeld bevat. Met andere woorden: aan de hand van de informatie vervat in de NALeenheden uit één Access Unit heeft de decoder precies genoeg informatie om één beeld te decoderen. Er bestaan heel strikte regels die vertellen welke soorten NAL-eenheden er toegelaten zijn en in welke volgorde deze mogen voorkomen binnen een Access Unit. Figuur 3.3 toont een grafische voorstelling van de mogelijke volgordes van soorten NAL-eenheden binnen een Access Unit. Deze figuur is overgenomen uit de H.264/AVCstandaard, waar U ook een gedetailleerde beschrijving kan vinden van bovenvernoemde regels ([11]). 17

27 Hoofdstuk 4 De decoder 4.1 Inleiding Vorig academiejaar ( ) koos Tom Pycke een thesis die als doel had om de bestaande referentie-implementatie van een AVC/H.264-decoder te bestuderen en deze te optimaliseren (zie [1]). Deze decoder vormt samen met een referentieimplementatie van een H.264/AVC-encoder de H.264/AVC-referentiesoftware die ter beschikking wordt gesteld door de International Telecommunications Unit (ITU) (zie [12]). Het doel van deze referentiesoftware is om een voorbeeld te geven van een mogelijke implementatie van een encoder en decoder die aan de standaard voldoen, en meer nog: alle aspecten van de standaard implementeert. De basis van deze decoder werd ontwikkeld door een kleine groep experts, maar na verloop van tijd hebben reeds talloze programmeurs een bijdrage geleverd aan de ontwikkeling van de software. Naarmate de standaard verder evolueerde was het soms nodig dat de referentiesoftware werd aangepast om te blijven voldoen aan de standaard. Zoals te verwachten valt heeft dit allemaal zijn invloed gehad op de code van deze referentiesoftware. De code is helemaal niet homogeen: er zijn grote stijlverschillen tussen grote delen van de code omdat deze delen door verschillende mensen ontwikkeld zijn. Er is weinig documentatie of structuur te besporen in de code: functies van meer dan duizend regels code, gebruik van goto statements Dit alles is natuurlijk niet bevorderlijk voor de leesbaarheid van de code! Daarnaast werd er ook helemaal geen rekening gehouden met snelheidsvereisten, waardoor deze software ongelofelijk traag is en heel veel resources verbruikt. Het doorgronden van de code van de referentiedecoder mag dan ook wel een titanenwerk genoemd worden, laat staan het optimaliseren ervan! Daarom heeft dhr. Pycke ervoor gekozen om een nieuwe H.264/AVC-decoder te schrijven. Het 18

28 ontwikkelen van een decoder die alle aspecten van de H.264/AVC-standaard ondersteunt is verre van haalbaar door één persoon in het kader van een thesis. De ontwikkelde decoder implementeert dan ook slechts een subset van de functies die de referentiedecoder ondersteunt. De decoder is er echter op gericht om te dienen als een efficiënt en makkelijk uitbreidbaar raamwerk voor een algemene decoder. In theorie zou het dus vrij eenvoudig moeten zijn om componenten of functionaliteit toe te voegen aan deze decoder. 4.2 Analyse van de decoder De decoder is vrij gemakkelijk in gebruik, ondanks het feit dat deze vanaf de DOScommandolijn moet gebruikt worden. De applicatie verwacht bij uitvoering 2 bestandsnamen als parameters: een inputbestand dat H.264/AVC-gecodeerde gegevens bevat en een outputbestand waar de gedecodeerde videobeelden in terecht zullen komen in IYUV formaat (zie [4]). Zoals eerder vermeld is deze decoder echter nog vrij beperkt: enkel intragecodeerde beelden worden ondersteund (de zogenaamde I-beelden). Uit tests blijkt dat de decoder gemiddelde 2,2 maal sneller is dan de referentie-decoder. In de volgende paragrafen vindt U een analyse van de decoder met oog op de toekomstige integratie in de DirectShow-architectuur. U zal merken dat deze niet zonder enige aanpassingen bruikbaar is voor onze doeleinden Object georiënteerd? Eén van de belangrijkste streefdoelen van dhr. Pycke was om de decoder object georiënteerd te maken. Bij het design van de decoder heeft hij volgens ons echter een vrij belangrijke vergissing gemaakt, waardoor de mogelijkheden om de decoder op een object georiënteerde manier te gebruiken ernstig beperkt worden. Geïnteresseerden vinden de technische onderbouwing in de volgende alinea. Kort samengevat komt het er op neer dat het niet mogelijk is om meer dan één decoder object aan te maken zonder dat er ernstige fouten optreden in alle decoders. Dit vormt natuurlijk een groot probleem voor de integratie in de, volledig objectgeoriënteerde (!), DirectShow-architectuur. De technische uitleg over dit probleem is als volgt. Dhr. Pycke gebruikt een object dat alle informatie bevat die van belang is tijdens het decoderingsproces, de zogenaamde DataManager. Dit object wordt zowat overal in de code aangesproken, wat dhr. Pycke ertoe heeft aangezet om dit object globaal te declareren binnen het hele project. Dit is inderdaad een erg gemakkelijke oplossing om het object binnen 19

29 het hele project beschikbaar te stellen, maar dit druist ook in tegen alle principes van objectoriëntatie! Indien er nu immers meerdere decoder objecten aangemaakt worden, dan zullen deze allemaal hetzelfde DataManager object aanspreken. Dit is helemaal niet de bedoeling! De DataManager bevat immers maar de gegevens voor één decoder! De verschillende decoder objecten zullen dus tegelijkertijd de gegevens van dit ene DataManager object bewerken, wat onvermijdelijk tot ernstige fouten zal leiden. Dit probleem is fundamenteel voor de hele code. Er is volgens ons geen eenvoudige manier om dit op te lossen. Een oplossing zou onvermijdelijk aanpassingen vereisen doorheen de ganse code Een volgende decoder Tijdens de loop van dit academiejaar zijn wij echter in contact gekomen met dhr. Wouter Devolder, die ook werkte aan een thesis die verderbouwt op de thesis van dhr. Pycke (zie [2]). Het opzet van deze thesis was om functionaliteit toe te voegen aan de bestaande decoder van dhr. Pycke. Tijdens een gesprek hebben we onze meningen uitgewisseld over de decoder van dhr. Pycke en bleek dat we het beiden eens waren dat deze decoder wel enkele verbeteringen kon gebruiken. We waren ook erg blij te horen dat dhr. Devolder in het kader van zijn thesis al heel wat van deze verbeteringen had aangebracht aan de decoder. Onder andere het hierboven beschreven probleem in verband met het niet-object-georiënteerd-zijn van de decoder werd reeds opgelost door dhr. Devolder. Het leek me dan ook voor de hand liggend dat we niet de decoder van dhr. Pycke zouden gebruiken als basis voor ons werk, maar de verbeterde decoder van dhr. Devolder. Niet alleen bevat deze decoder heel wat verbeteringen en vormt deze dus een veel stabielere basis om op verder te bouwen, deze decoder bevat ook meer functionaliteit! Concreet: de decoder van dhr. Pycke was enkel in staat om I- beelden te decoderen. Dhr. Devolder heeft in het kader van zijn eindwerk functionaliteit toegevoegd aan de decoder waardoor deze nu ook in staat is om P- beelden te decoderen. Dit vormt een belangrijke toevoeging aan de decoder! De decoder ontwikkeld door dhr. Pycke bevatte reeds de volgende functionaliteit: Het decoderen van I-beelden Kan 5 conformance bitsteams decoderen (I-beelden) Flexible Macroblok Ordering Bestand tegen ontbrekende macroblokken en slices bij I-beelden Dhr. Devolder heeft de volgende functionaliteit toegevoegd aan deze decoder: 20

30 Het decoderen van P-beelden Het beheer van referentiebeelden Kan 5 extra conformance bitsteams decoderen Bestand tegen ontbrekende macroblokken bij P-beelden De interface van de decoder Input object: - Read() - ReadNalUnit() InputDecoder object: - InputDecoder (Input, Output) - StartDecoding() Output object: - PictureOutput() - EndOfStream() Figuur 4.1 Visualisatie van de structuur van de decoder naar de gebruiker (programmeur) toe Het gebruik van de decoder is uitermate eenvoudig: men hoeft enkel een InputDecoder object aan te maken met als parameters een Input en een Output object. Als men dan de methode StartDecoding() oproept, dan zal de decoder gegevens inlezen uit het Input object en de gedecodeerde beelden doorgeven aan het Output object. Het Input object bepaalt naargelang de implementatie waar de data vandaan komt. Meestal zal deze ingelezen worden uit een bestand. Een andere mogelijkheid is een implementatie die streaming data ontvangt vanaf het internet. Hetzelfde geldt voor het Output object. De meest voor de hand liggende implementatie is dat die de videogegevens gewoon in een bestand wegschrijft. Het is echter ook perfect mogelijk om bijvoorbeeld een implementatie te ontwikkelen die de beelden weergeeft op het scherm. Dit hele proces gebeurt zo vlug mogelijk. Dit wil zeggen dat de snelheid van het hele proces enkel beperkt wordt door de snelheid waarmee het Input object data kan leveren, de snelheid waarmee het Output object data kan aannemen, en de snelheid van de decoder zelf (beperkt door de rekenkracht van de computer). De decoder is dus als programmeur heel eenvoudig in het gebruik, maar kan toch erg veelzijdig gebruikt worden! 21

31 4.2.4 Problemen voor gebruik in DirectShow (Threading) Source Filter Transform Filter Renderer Filter 1 of meerdere Figuur 4.2 Typische DirectShow-graaf Om te verklaren waarom de decoder in zijn huidige vorm minder geschikt is voor gebruik binnen een DirectShow-filter is het onvermijdelijk dat we het hebben over het concept van threads. Een thread kan vereenvoudigd gezien worden een stuk code dat in parallel uitgevoerd wordt, onafhankelijk van andere code. Eerst een woordje over hoe een typische DirectShow-graaf werkt met betrekking tot threads. Herinner U uit hoofdstuk 2 dat een typische DirectShow-graaf bestaat uit een bronfilter gevolgd door één of meerdere transform filters en eindigend bij een renderer filter (zie Figuur 4.2). In deze graaf zijn typisch 2 threads aanwezig. Een eerste thread bevindt zich in de bronfilter. Deze thread haalt de informatie op (bijvoorbeeld bij een hardware apparaat) en zal deze doorgeven aan de volgende filter in de graaf. Merk op dat de bronfilter op deze manier eigenlijk de hele graaf aandrijft. Het is namelijk pas als de bronfilter de volgende filter oproept om data door te geven dat deze volgende filter in staat is om iets te doen, en op een zelfde manier is de daaropvolgende filter pas in staat om iets te doen als hij opgeroepen wordt door de voorgaande filter. De oproep van de bronfilter propageert zich dus typisch door alle volgende transform filters tot aan de renderer filter. De bronfilter ligt dus aan de basis voor alles wat gebeurt in alle transform filters. Of anders gezegd: de bronfilter draagt de controle over aan de volgende filter in de graaf, die op zijn beurt de controle weer overdraagt aan zijn opvolger, etc De 2 de thread uit de graaf bevindt zich in de renderer filter. Aangezien deze vaak tijdskritisch werk moet uitvoeren (bijvoorbeeld een beeld op een exact moment weergeven) kan deze het zich niet veroorloven om afhankelijk te zijn van de oproepen van de bronfilter, gepropageerd tot aan de renderer filter. Daarom bevat de renderer filter vaak een eigen thread zodat deze onafhankelijk van andere code kan werken. Naast deze 2 threads nodig voor de werking van de DirectShow-graaf speelt er vaak ook nog een 3 de thread mee, namelijk de programma- of controlethread. Deze thread is niet nodig voor de werking van de graaf, maar deze thread zorgt wel voor de controle over de graaf. Dit houdt typisch in het starten, stoppen en pauzeren 22

32 van de werking van de graaf, maar daarnaast bijvoorbeeld ook het opbouwen en vrijgeven van de graaf. Nu we een algemeen beeld hebben van de rol van threads in een DirectShow-graaf kunnen we eens één transform filter in het bijzonder bekijken. Zoals hierboven vermeld werkt een transform filter eigenlijk volledig passief. De filter kan pas in werking treden als deze een oproep ontvangt van de voorgaande filter in de graaf. Laten we daar nu de decoder bij betrekken. Zoals we hebben gezien bevat deze slechts één methode om het decodeerproces te starten, namelijk StartDecoding(). Deze methode eist echter de controle op tot het decodeerproces volledig voltooid is. Dit valt echter niet te verenigen met de werking van de DirectShow-filter. Stel dat de filter de controle over de thread krijgt van zijn voorganger, en de filter roept dan de StartDecoding() methode van de decoder op. Deze methode zal echter blokkeren, want nog niet alle data om de volledige videosequentie te decoderen is beschikbaar. Deze data kan echter maar beschikbaar komen als de bronfilter en alle voorgaande filters de controle krijgen. Maar de controle zal nooit doorgegeven worden aan de volgende filter in de graaf, en nooit terugkeren naar de bronfilter. We hebben dus een zogenaamde deadlock situatie: de decoder wacht op de voorgaande filters, maar deze wachten onrechtstreeks tot de decoder de controle teruggeeft. De graaf zit dus vast en er zal helemaal niks gebeuren. Dit kan echter opgelost worden, namelijk door de decoder een eigen thread te geven om in te werken. De decoder zal dan binnen zijn eigen thread zo vlug mogelijk proberen om de data te decoderen. Aangezien deze data echter maar met mondjesmaat binnenkomt en aangezien ook de gedecodeerde data maar met mondjesmaat kan weggevoerd worden (gezien de werking van de DirectShowgraaf) zal de decoder echter automatisch afgeremd worden tot het juiste werktempo. Op deze manier is het perfect mogelijk om de decoder te gebruiken zonder dat er enige wijzigingen hoeven aangebracht worden aan de decoder. We hebben er echter voor gekozen om de decoder niet op deze manier te gebruiken, om verschillende redenen. Ten eerste, performantie: het gebruik van een extra thread is een dure operatie: er gaan veel resources verloren. Qua geheugen, aangezien elke thread over zijn eigen context moet beschikken. Maar ook qua rekenkracht: het aanmaken van een thread is een relatief zware operatie. De thread zal ook voor het grootste deel van de tijd geblokkeerd staan, wachtend op data of wachtend tot hij data kwijt kan. Dit kan zorgen heel wat verspilde CPU-tijd. Maar objectief gezien is dit verlies van performantie eigenlijk helemaal niet belangrijk, de hoofdreden om niet voor deze oplossing te kiezen is eenvoud. Het kan misschien tegenstrijdig klinken, maar deze oplossing is namelijk helemaal niet 23

33 zo eenvoudig als ze klinkt. Er komt namelijk heel wat kijken bij het gebruik van threads, voornamelijk op het vlak van synchronisatie. Ieder die reeds met threads heeft moeten programmeren zal U kunnen vertellen dat dit algauw héél complex wordt. Men moet er namelijk aan denken dat een filter meer moet kunnen dan enkel data bewerken, de filter moet ook in staat zijn om te pauzeren en het verwerken te hervatten, of om te stoppen met werken en terug te keren naar een initiële staat. Om dit te implementeren met de decoder in een aparte thread zou er héél véél synchronisatie nodig zijn tussen de thread van de bronfilter en de decoder-thread. En zoals we al vermeldden, synchronisatie tussen threads is heel complex, maar het is vooral ook materie waarbij het erg gemakkelijk is om fouten te maken die zorgen voor erg vreemd gedrag en die bijzonder moeilijk op te sporen zijn. Onze conclusie: na afweging van beide opties is het duidelijk dat het aanpassen van de decoder uiteindelijk veel makkelijker is dan de oplossing met behulp van een thread. 4.3 De aangepaste decoder StartDecoding() { // Initialisatie code } NalUnit na; while (na = leesnalunit()) { // Decodeer NAL-eenheid } // Afwerkings code Figuur 4.3 De originele vorm van de StartDecoding() methode InputDecoder() { // Initialisatie code } DecodeNalUnit(NalUnit na) { // Decodeer NAL-eenheid } FinishDecoding() { // Afwerkings code } Figuur 4.4 De aangepaste code Het is dus nodig om de decoder zo aan te passen dat er geen nood meer is aan een aparte thread om deze te gebruiken. Idealiter zou het mogelijk moeten zijn om telkens een stukje data in te voeren in de decoder, waarop deze dit stukje data 24

34 decodeert en de controle onmiddellijk teruggeeft aan de oproeper. Idealiter zou dit stukje data een NAL-unit zijn. Het probleem met de decoder bevindt zich voornamelijk bij de StartDecoding() methode. Deze neemt namelijk veel te veel werk voor zijn rekening. We hebben nood aan meer controle over het decoderingsproces. Als we deze methode nader bekijken, dan zien we dat deze van de vorm is zoals in Figuur 4.3. De methode bevat dus eerst wat initialisatie code, daarna wordt in een lus één voor één elke NAL-eenheid ingelezen en gedecodeerd, en uiteindelijk wordt er nog wat afwerkingscode uitgevoerd. We zien dat deze methode dus eigenlijk erg goed valt onder te verdelen in aparte methodes. Laten we om te beginnen de initialisatiecode in een aparte methode InitializeDecoder() stoppen, en de afwerkingscode in een methode FinishDecoding(). Als we nu afspreken dat de oproeper zorgt voor het inlezen van de NAL-eenheden, dan kunnen we de while-lus uit de oorspronkelijke methode gewoon weglaten, en een nieuwe methode maken die precies één NAL-eenheid decodeert. Deze methode noemen we DecodeNalUnit(NalUnit na). De code krijgt dan de vorm als in Figuur 4.4. We kunnen nu dus precies hetzelfde doen als wanneer we gewoon StartDecoding() oproepen, maar nu hebben we veel meer controle over het hele proces. We kunnen de NAL-eenheden één voor één invoeren in de decoder, en deze zal na het decoderen van elke NAL-eenheid de controle onmiddellijk teruggeven aan de oproeper. Door de functionaliteit van de StartDecoding() methode slim op te splitsen kunnen we nu dus precies doen wat we wilden! Door de aanpassingen aan de decoder bevindt deze zich nu dus in een ideale vorm om te gebruiken in het kader van een DirectShow-filter. Merk ook op dat deze aanpassingen het gebruik van de methode StartDecoding() niet uitsluiten. De decoder kan dus op beide manieren gebruikt worden, ofwel door gewoon StartDecoding() op te roepen, ofwel door vervolgens de methodes InitializeDecoder(), DecodeNalUnit() voor elke NAL-eenheid en uiteindelijk FinishDecoding() op te roepen. De beide manieren mogen echter niet door elkaar gebruikt worden. De aanpassingen aan de decoder vormen dus geen beperking, maar integendeel een uitbreiding van de functionaliteit van de decoder. 25

35 Hoofdstuk 5 De ontwikkelde DirectShowfilters 5.1 Inleiding Source Filter Transform Filter Renderer Filter Figuur 5.1 Typische DirectShow-graaf 1 of meerdere Source Parser Decoder Renderer Filter Filter Filter Filter Bron-bitstroom Gecodeerde videogegevens Ongecomprimeerde videobeelden Figuur 5.2 Typische graaf voor het weergeven van een gecodeerd videobestand We vertelden al hoe een typische DirectShow-graaf eruit ziet (Figuur 5.1). Deze typische vorm blijft ook geldig voor een graaf die als doel heeft om gecodeerde videogegevens af te spelen. Een dergelijke graaf ziet eruit zoals in Figuur 5.2. Bij 26

36 deze figuur zijn er 2 transformatiefilters. In een graaf voor het weergeven van een gecodeerd videobestand hebben deze twee filters elk een specifieke taak. De eerste filter, die de parser filter genaamd wordt, heeft als taak om de ontvangen bitstroom als het ware te interpreteren. De filter analyseert de gegevens en beslist wat hun betekenis is. Daarna kan de parser filter deze gegevens gebruiken om enkele eigenschappen van de bitstroom af te leiden en om de bitstroom te gaan onderverdelen. De filter zal de data dan stuk per stuk doorgeven aan de volgende filter, de decoder filter. Deze decoder filter doet precies wat zijn naam doet vermoeden: de gecodeerde gegevens decoderen. Als we Figuur 5.2 nu concreet gaan vertalen naar deze thesis toe, dan krijg je de volgende figuur: Source Filter H.264/AVC Parser Filter H.264/AVC Decoder Filter Renderer Filter H.264/AVC bitstroom Annex B formaat NAL-eenheden Ongecomprimeerde videobeelden Figuur 5.3 Graaf voor het afspelen van H.264/AVC-bitstroom De bronfilter is verantwoordelijk voor het inlezen van de brongegevens, die een H.264/AVC-bitstroom moeten zijn in het formaat zoals beschreven in het Annex B gedeelte van de standaard ([11]). Deze gegevens komen terecht in de H.264/AVCparser filter, die de gegevens zal onderzoeken en de verschillende NAL-eenheden zal onderscheiden. De parser filter zal de NAL-eenheden dan één voor één doorgeven aan de H.264/AVC-decoder filter, die de gegevens zal decoderen en omzetten in ongecodeerde, ongecomprimeerde videobeelden. Die beelden zijn geschikt om weergegeven te worden door de renderer filter. Merk op dat in de 3 voorgaande figuren de gedecodeerde gegevens telkens rechtstreeks in de renderer filter ingeveord werden. Als het enkel nodig is om het bronbestand weer te geven zonder meer, dan zal de graaf er inderdaad zo uitzien (en dit zal dus in het overgrote deel van de gevallen zo zijn). Dit hoeft echter niet! De ongecomprimeerde beelden zijn geschikt om door tal van andere transformatie filters bewerkt te kunnen worden. Er kunnen zich dus nog enkele extra transformatie filters tussen de decoder filter en de renderer filter bevinden (bijvoorbeeld om een visueel effect toe te voegen aan de gedecodeerde beelden). 27

37 Herinner U ook dat de renderer filter niet noodzakelijk een filter moet zijn die de beelden op het scherm weergeeft. Het doel van deze thesis is dus om er voor te zorgen dat het mogelijk is om een graaf zoals in Figuur 5.3 op te bouwen die daadwerkelijk in staat is om een H.264/AVC-bitstroom te decoderen en af te spelen. Daar hebben we dus 4 filters voor nodig: een bronfilter, een parser filter, een decoder filter en een renderer filter. We zullen verder zien dat we voor de eerste en de laatste filter gebruik kunnen maken van reeds bestaande DirectShow-filters. De parser filter en de decoder filter bestonden tot op heden nog niet. Conclusie: voor het afspelen van een H.264/AVC-bitstroom moeten we een parser filter en een decoder filter ontwikkelen! Waarom meerdere filters? U zou zich kunnen afvragen waarom we niet gewoon één filter gebruiken voor het inlezen, decoderen en weergeven van een H.264/AVC-bitstroom. Dit druist echter helemaal in tegen de geest van DirectShow, en met reden! Door deze opsplitsing heeft elke filter één specifieke taak. De bronfilter behandelt de input. De parser verdeelt de bitstroom onder in NAL-pakketjes (en is dus ruwweg verantwoordelijk voor de NAL-laag). De decoder decodeert de NALpakketjes (en is dus verantwoordelijk voor de VCL-laag) en de renderer filter zorgt voor de weergave (de output). Dit zorgt voor een grote mate van flexibiliteit. Als we de videostroom bijvoorbeeld niet willen tonen op het scherm maar naar een bestand schrijven, dan moeten we enkel een andere renderer filter verbinden met de decoder filter. Als de gegevens niet uit een bestand komen maar bijvoorbeeld gestreamd worden vanaf internet, dan kunnen we gewoon een andere bronfilter gebruiken. Stel dat de H.264/AVC-gegevens zich niet in het Annex B formaat bevinden maar bijvoorbeeld in een containerformaat ingebed zitten (bijvoorbeeld samen met geluidsgegevens), dan hoeven we enkel een andere parser filter te gebruiken. Evengoed kunnen we een andere decoder filter aansluiten in plaats van onze H.264/AVC-decoder (zolang deze andere filter ook H.264/AVC-NALeenheden kan decoderen natuurlijk). Algemeen kunnen we dus stellen dat de onderverdeling ervoor zorgt dat we makkelijk bepaalde functionaliteit kunnen hergebruiken. 28

38 5.2 De bronfilter Als bronfilter hebben we een filter nodig die gegevens uit een bestand kan inlezen. We voelen aan dat een filter met een dergelijke veelgebruikte functionaliteit al moet bestaan. Na enig zoekwerk blijkt dat de filter die daar meestal voor gebruikt wordt de Asynchronous File Source -filter is. Deze filter wordt gebruikt om allerlei soorten bestanden in te lezen. De filter heeft geen enkel besef van het soort bestand dat hij aan het inlezen is. Er zijn enkele manieren om aan te geven welke bronfilter gebruikt moet worden voor welk type bestanden. De meest gebruikte manier is op basis van de bestandsextensie. Door wat gegevens toe te voegen aan het Windows register kunnen we opgeven dat voor alle bestanden met extensie.264 de Asynchronous File Source -bronfilter gebruikt moet worden. Daar kunnen we dan ook opgeven welk mediatype en mediasubtype deze bronfilter moet publiceren op zijn output pin. Aan de hand van dit mediatype zal beslist worden welke filters er moeten aangekoppeld worden om het bestand weer te geven. Indien er echter in het Windows register niet opgegeven wordt welke bronfilter moet gebruikt worden, zal DirectShow zelf een gepaste bronfilter selecteren. We zullen dit dan ook niet doen. Het voordeel van het gebruik van een bronfilter die reeds voorhanden is, is duidelijk: we moeten geen tijd meer spenderen aan het zelf ontwikkelen van een bronfilter. Een tweede voordeel is minder evident. Deze filter wordt namelijk aangesproken door gebruikt te maken van de IAsyncReader interface. Concreet heeft dit als gevolg dat we niet enkel de Asynchronous File Source -bronfilter kunnen gebruiken, maar gelijk welke filter die deze interface implementeert. De Asynchronous File Source -filter is namelijk ontwikkeld om lokale bestanden in te lezen, maar we kunnen bijvoorbeeld evengoed de URL File Source -bronfilter gebruiken, die geoptimaliseerd is om bestanden in te lezen die via een URL bereikbaar zijn, zoals bijvoorbeeld een bestand dat zich op het internet bevindt. En zo bestaan er vast nog filters die deze interface implementeren en die hun input op andere manieren bekomen. Door één enkele waarde aan te passen in het Windows register kunnen we er dus voor zorgen dat er een compleet andere bronfilter gebruikt wordt en dat de gegevens dus op een geheel andere manier verkregen worden. En dit zonder dat de rest van de graaf beïnvloed wordt! Meer informatie hierrond vindt U in het Microsoft Developers Network ([10]). 29

39 5.3 De parser filter Functie Zoals hiervoor al vermeld heeft de parser filter als doel om de bitstroom te interpreteren, onder te verdelen en door te geven aan de decoder filter. De parser filter is ook verantwoordelijk voor het verkrijgen van bepaalde parameters over de gecodeerde videostroom, in het bijzonder de grootte van een beeld (in pixels) en de snelheid waarmee de beelden elkaar opvolgen (beelden per seconde) Ontwerpbeslissingen Opsplitsen: per NAL-eenheid of per access unit? Eén van de eerste vragen die we onszelf stelden bij het ontwikkelen van de parser filter was of we de output moesten opsplitsen per NAL-eenheid of per access unit. Voor beiden valt iets te zeggen. De opsplitsing per NAL-eenheid is een stuk eenvoudiger te implementeren. Tevens is de NAL-eenheid sowieso de logische eenheid binnen de H.264/AVC-bitstroom, dus ligt het voor de hand om de bitstroom op te splitsen per NAL-eenheid. Anderzijds komt de opsplitsing per access unit beter overeen met de semantiek van de DirectShow MediaSample: het object waarin elk stuk data doorgegeven wordt tussen 2 filters. Zoals de naam impliceert is het de bedoeling dat dit object één sample (bemonstering) bevat, wat in ons geval overeenkomt met één beeld. En de gegevens vervat in één access unit worden inderdaad gedecodeerd tot precies één beeld. Anderzijds wordt een MediaSample binnen DirectShow vaak gebruikt als transportmiddel voor alle soorten data, onafhankelijk van de semantiek van die data. Eén sample van een ongecomprimeerde audiostroom is bijvoorbeeld typisch één of twee bytes groot, en deze enkele bytes één voor één transporteren tussen de filters zou een grote overhead veroorzaken. Een access unit is per definitie altijd groter dan één NAL-eenheid, wat dus betekent dat er meer gegevens in één keer worden doorgegeven. Dit kan een miniem performantievoordeel opleveren ten opzichte van het doorgeven van vele kleine stukjes data (de aparte NAL-eenheden). Met het oog op de toekomstige decoder filter heeft het opsplitsen per access unit ook een voordeel. Het zou dan namelijk mogelijk moeten zijn om de decoder filter zo te maken dat er voor elk inkomende data-eenheid ook een uitgaande dataeenheid gegenereerd wordt. De inkomende data-eenheid is namelijk de access 30

40 unit, en de decoder zet deze per definitie om in één gedecodeerd beeld, wat precies de uitgaande data-eenheid van de decoder filter is. Door deze speciale eigenschap zouden we gebruik kunnen maken van een speciale basisklasse die reeds heel wat functionaliteit geïmplementeerd heeft (zie hierover meer in paragraaf 5.4.3). Jammer genoeg blijkt echter dat de decoder ons een stok tussen de wielen steekt: als we één access unit invoeren in de decoder zal deze niet altijd precies één beeld decoderen. Dit is een eigenschap van de decoder veroorzaakt door de gekozen implementatiemethode. Deze reden om in de parser filter op te splitsen per access unit vervalt dus. Uiteindelijk hebben we ervoor gekozen om op te splitsen per NAL-eenheid. Dit leidt tot een eenvoudige implementatie in de parser filter. De decoder filter kan nu ook de inhoud van een aangeleverde data-eenheid rechtstreeks in de decoder invoeren. Indien de decoder filter een access unit aangeleverd zou krijgen, dan zou deze ook nog logica moeten bevatten om de verschillende NAL-eenheden uit de access unit te parsen. In onze oplossing gebeurt al het parsen in de parser filter en hoeft de decoder filter zich daar geen zorgen meer om te maken. De oplossing is dus de netste en ook de eenvoudigste! Het beeldsnelheidsprobleem Zoals we al vermeld hebben is de parser filter ook verantwoordelijk voor het opzoeken van de grootte van de videobeelden (in pixels) en voor het opzoeken van hoe snel de beelden elkaar moeten opvolgen (de zogenaamde framerate of beeldsnelheid). Het opzoeken van de grootte van de videobeelden is geen probleem, het opzoeken van de beeldsnelheid daarentegen wél. Dit gegeven bevindt zich namelijk nergens in een Annex B gecodeerd H.264/AVC-videobestand! Normaalgezien wordt dit gegeven opgeslagen in het containerformaat waarin de H.264/AVC-bitstroom zich bevindt, maar aangezien dit er niet is, beschikken we dus ook niet over de beeldsnelheid! Even hebben we overwogen om dit op te lossen door de gebruiker een klein dialoogvenster te tonen waarin hij of zij de gepaste framerate kan selecteren, telkens wanneer de parser filter geladen wordt. Dit zou echter het gehele klik-enspeel effect teniet doen en na een tijd vast erg vervelend blijken. Daarom hebben we er voor gekozen om gewoon de meestvoorkomende framerate hard te coderen. Dit betekent dat elk H.264/AVC-bestand altijd op dezelfde framerate zal afgespeeld worden. Filmpjes waarvoor deze framerate niet klopt zullen een beetje trager of vlugger afgespeeld worden dan de bedoeling is. Aangezien het overgrote deel van de videofilmpjes echter aan 25 beelden per seconde wordt afgespeeld (dit is de 31

41 gekozen waarde die we hard gecodeerd hebben), zal dit volgens ons weinig tot geen afbreuk doen aan het nut van de filter Implementatie De input pin Welke basisklasse? Binnen de DirectShow-architectuur bestaan er al heel wat standaard klassen met als enig doel om ervan over te kunnen erven en jezelf zo veel werk te besparen. Deze klassen kun je zien als een soort omgekeerde boom. In Figuur 5.4 ziet U een voorbeeld van één pad uit een dergelijke boom. Uit deze figuur kunnen we afleiden dat de klasse CBaseInputPin rechtstreeks overerft van de Figuur 5.4 Boom die de weergeeft klasse CBasePin en onrechtstreeks van de van welke klassen de klassen CUnknown en CBaseObject. Elke CBaseInputPin klasse overerft klasse die overerft voegt een bepaalde functionaliteit toe aan zijn ouderklasse. De overervende klasse is dus een specifiëring van de ouderklasse. Concreet betekent dit dat de lagere klassen al erg veel functionaliteit zullen bevatten en slechts weinig wijzigingen zullen nodig hebben om ze om te vormen tot de klasse die we nodig hebben. De hogere klassen daarentegen bevatten relatief weinig functionaliteit, waardoor we meer werk zelf moeten doen als we een dergelijke klasse gebruiken als basisklasse. Jammer genoeg voldoen de lagere klassen niet altijd aan de vereisten voor de klasse die we nodig hebt, waardoor we noodgedwongen moeten teruggrijpen naar een hogere klasse. Voor we dan ook aan gelijk welke klasse beginnen zullen we eerst nagaan van welke klassen we kunnen overerven en de klasse uitkiezen die het best geschikt is als basisklasse. De minst uitgebreide basisklasse voor een pin is de klasse CBasePin. Er zijn twee andere klassen afgeleid van deze klasse, namelijk de klassen CBaseInputPin en CBaseOutputPin. Deze klassen zijn bedoeld voor input pins en output pins respectievelijk. We onderzoeken of we de klasse CBaseInputPin niet kunnen gebruiken, maar concluderen dat dit ons geen voordeel oplevert. Deze klasse is er immers voor gemaakt om te verbinden met een andere pin die de IMemInputPin interface gebruikt. De bronfilters die wij gebruiken ondersteunen echter de IAsyncReader interface in de plaats. CBasePin wordt dus onze basisklasse. 32