Een Intel-marketingteam benaderde onlangs het Intel Science and Technology Center for Visual Cloud Systems met een verzoek. Ze waren op zoek naar verkeersvideo's om te gebruiken op beurzen en in demo's en vroegen zich af of we ze konden leveren vanuit ons Smart City Testbed in Pittsburgh. Toen we echter wat dieper ingingen op hun vereisten, werd het probleem complexer. Ze wilden een selectie uit verschillende gezichtspunten en locaties. Er waren ook beperkingen op inhoudslicenties en de aanwezigheid van persoonlijk identificeerbare informatie (bijvoorbeeld gezichten) in de video's. Onze kleine implementatie in Pittsburgh zou geen voldoende bron zijn voor deze gegevens. We wendden ons tot een van de grootste openbare videodatasets die beschikbaar zijn – de Yahoo/Flickr 100 miljoen (YF100M) dataset met ongeveer 800.000 video's. We hebben besloten om de combinatie van Scanner en het Visual Data Management System (VDMS) met Apache Spark, Panda's en Apache Arrow te gebruiken om bruikbare video's van YF100M te selecteren en een proof-of-concept te creëren rond Big Visual Data Analytics.

Wat is Big Visual Data Analytics?

In de afgelopen jaren heeft Big Data vele soorten gestructureerde en ongestructureerde, traditionele en kunstmatige intelligentie (AI)-georiënteerde data-analytische benaderingen overgenomen. Ondertussen betekent Video Analytics over het algemeen traditionele en AI-georiënteerde computervisie- en beeldanalysetechnieken op videogegevens. De mashup van deze twee benaderingen is wat ik bedoel met Big Visual Data Analytics:

  • Big– Visuele data is bijna per definitie groot. Een enkele 4k 60fps-video van twee uur kan een halve terabyte schijfruimte in beslag nemen, afhankelijk van het coderingsschema. YF100M bevat 800.000 video's, hoewel de meeste kort en van relatief lage kwaliteit zijn. De dataset van het Brown Institute waar ik het eerder over had, bevat 200.000 langere video's. Naarmate je de datasets en de bijbehorende applicatie- en videometadata schaalt, wordt de volledige schaal van een videodataset duidelijk.
  • Visueel– Naast de video-inhoud zelf worden vaak andere visueel georiënteerde gegevens gemaakt en gebruikt in applicaties. Deze gegevens kunnen individuele afbeeldingen en getransformeerde video's bevatten, videoverwerkingsgegevens zoals bewegingsvectoren, AI-gerelateerde gegevens zoals neurale netwerkfunctievectoren, afgeleide abstracties zoals begrenzingsvakken en segmentatiekaarten en generatieve gegevens zoals texturen en objectnetwerken. Al deze gegevens kunnen complex en duur zijn om te beheren en te analyseren.
  • Gegevens– Het combineren van de visuele data met metadata maakt de volledige reikwijdte van het dataprobleem voor een grote visuele datawetenschapper. Er kunnen aanzienlijke metadata zijn gekoppeld aan de video zelf – waar en wanneer het is genomen, wie en wat erin zit, wat de licentievoorwaarden en coderingsparameters zijn, enz. Vaak willen toepassingen ook niet-visuele gegevens met de visuele gegevens analyseren. In een smart city-geval wil ik bijvoorbeeld de timinggegevens van verkeerslichten correleren met het aantal voertuigen dat een verkeerscamera detecteert bij elke signaalcyclus.
  • Analytics– Het is verleidelijk om analyses samen te vatten als “inzicht af te leiden uit visuele data en de bijbehorende metadata.” Hoewel dat niet slecht is, zijn er toepassingen die de grenzen van deze definitie oprekken. Op CVPR dit jaar toonden we een demo waarin Scanner en VDMS samen werden gebruikt om skeletreconstructies en spelerhoudingen te genereren op 36 gesynchroniseerde videostreams van een voetbalwedstrijd. Deze poses werden vervolgens gebruikt om spelerreconstructies van hogere kwaliteit te maken in de volumetrische renderingpijplijn die door de Intel Sports Group werd geïmplementeerd. De poses zijn een “inzicht” maar de uiteindelijke waarde was de opname in de pijplijn. Dit “inzicht in operaties” stap is ook duidelijk in bewakingstoepassingen waar, bijvoorbeeld, kentekenherkenning een politiebericht kan genereren.

Het verzoek van ons marketingteam bracht ons dus een goed voorbeeld uit de praktijk van grote visuele data-analyse. Dit is hoe we hun uitdaging zijn aangegaan.

De YF100M-dataset

Zoals hierboven vermeld, hebben we de YF100M-kerndataset van het Multimedia Commons Initiative* gebruikt voor de proof of concept. De dataset heeft 99,2 miljoen afbeeldingen en ongeveer 800.000 video's. De video's tellen op tot ongeveer 8.081 uur, met een gemiddelde videolengte van 37 seconden en een mediane lengte van 28 seconden. YF100M is gedeeltelijk getagd en is vrijgegeven onder Creative Commons-voorwaarden. In absolute termen is de “out-of-the-box” fysieke grootte van de dataset is naar waarheid niet “groot” – 15 GB aan video's en afbeeldingen met een metadatabestand van 334 MB, maar het is een van de beste videodatasets die openbaar beschikbaar zijn. De afzonderlijke video's zijn vrijgegeven onder 6 verschillende Creative Commons-licentietypes, maar slechts één ervan was acceptabel voor marketingdoeleinden.

Bewijs van conceptvereisten en architectuur

Onze taak was om een ​​subset van de video's uit de dataset te selecteren op basis van de volgende criteria:

  1. Filter om alleen te werken met video's met de geautoriseerde licentie. Deze stap kwam eerst om ervoor te zorgen dat we niet het risico liepen per ongeluk onaanvaardbare video's op te nemen.
  2. Vind video's in die subset die zijn getagd met het trefwoord “traffic”.
  3. Identificeer video's in die subset die zijn gecodeerd als H.264. Onze downstream-verwerkingsengine kan geen VP9-gecodeerde bestanden aan die in kleine aantallen in de dataset aanwezig zijn.
  4. Detecteer gezichten en kentekenplaten in die subset en pas een vervagingsfilter toe op dat deel van de video.
  5. Stretch-doelen omvatten het identificeren van het gezichtspunt van de video (bijvoorbeeld van bovenaf, van een straatcamera, van een bewegend voertuig). We werken hier nog aan.

De architectuur die we hebben geïmplementeerd, wordt hieronder weergegeven en omvat drie primaire subsystemen: Apache Spark, Scanner en VDMS. De applicatielogica draait op een gecombineerde Spark, Scanner en VDMS-client. Die applicatie gebruikt de respectievelijke API's en dataformaten die compatibel zijn met de onderliggende subsystemen. Elk subsysteem is geïnstantieerd met behulp van afzonderlijke knooppuntgroepen binnen een gemeenschappelijk Amazon Elastic Kubernetes Service (EKS)-cluster, zodat we verschillende Intel® Xeon® Schaalbare op processor gebaseerde instantietypen voor elke subsysteemspecifieke werkbelasting. De gedeelde datastores zijn volledig toegankelijk vanuit de client en vanuit elk van de subsystemen. De metadata-datastore gebruikt Apache Arrow- en parketbestanden om gegevens tussen subsystemen te delen. De visuele en metadata gedeelde datastores zijn geïmplementeerd op Amazon Elastic File System (EFS). De YF100M-dataset zelf was rechtstreeks toegankelijk vanuit de openbare YF100m S3-bucket.

We hebben de Spark-functionaliteit geïmplementeerd met behulp van Spark-submit Python-query's naar het cluster, maar voor de eenvoud hebben we de meeste gegevens opschonen en filteren (bijv. Video's met 'traffic'-tags selecteren) met panda's op de client. Deze functies hadden eenvoudig op Spark kunnen worden gedaan, maar we hadden de uitschaalmogelijkheden voor deze workflow niet nodig. Bij een complexere analysetaak (bijvoorbeeld het gebruik van begrenzingsvakken en functievectoren om vergelijkbare gezichten in video's te identificeren), zou de parallellisatie van Spark waardevoller zijn.

We gebruikten FFprobe om coderingsgerelateerde informatie voor de video's van kandidaten. Alleen H.264-gecodeerde video's werden behouden in de kandidatenlijst.

We gebruikten Scanner en Intel® OpenVINO™ om gezichten en kentekenplaten te vinden en te vervagen. Om deze taak te laten werken, hebben we twee aangepaste scannervervagingsoperators toegevoegd. We zijn ook van plan om Scanner te gebruiken om de meer geavanceerde gezichtspunttaak te implementeren die ik hierboven als een uitgebreid doel noemde.

We gebruikten VDMS om de metadata en afgeleide visuele data voor de geselecteerde video's op te slaan – waardoor het gemakkelijk is om die gegevens voor volgende taken te gebruiken zonder de onderliggende rekenintensieve analyses opnieuw uit te voeren. Het juridische team kan bijvoorbeeld verzoeken om een ​​grondiger vervaging van gezichten dan oorspronkelijk was uitgevoerd. Met VDMS kunnen alleen de gezichtsgebieden worden opgehaald en opnieuw wazig gemaakt zonder de verwerking van gezichtsdetectie opnieuw uit te voeren.

POC-resultaat

Van de 787.479 YF100M-video's hadden 137.000 geschikte licenties voor ons doel. Hiervan werden 152 getagd als “verkeer” videos. We hebben ffprobe uitgevoerd en niet-H.264 eruit gefilterd om 137 kandidaten te krijgen. Vervolgens hebben we het vervagingsfilter over deze video's uitgevoerd om de uiteindelijke inhoud te produceren voor beoordeling door het marketingteam met het oorspronkelijke verzoek. Het verwerken van deze end-to-end-workflow op een kubernetes-cluster met drie knooppunten duurde ongeveer 40 minuten, waarbij de fase voor het vervagen van gezichten en licenties het grootste deel van de verwerkingstijd in beslag nam.

Conclusie

Terwijl deze workflow heeft een systeem dat is gebouwd op moderne cloudservices niet dramatisch benadrukt, het demonstreert wel de soorten toepassingen voor big visual data-analyse die commercieel interessant zijn. En het laat zien hoe deze applicaties het gebruik van traditionele data-analysetools zoals Spark en Panda's vereisen met visuele dataverwerkings- en beheertools zoals Scanner en VDMS. De volledige oplossingsstack is gebouwd met open source-software die draait in een openbaar beschikbare cloudinfrastructuur. Dat betekent dat u het systeem voor uw eigen toepassingen kunt repliceren met bijna geen investering vooraf – afgezien van het leren hoe je een big visual data analytics architect kunt worden.

Jim Blakley
Visual Cloud Innovation Senior Director, Intel

0

Geef een reactie