3. versameling
Verkryging bevat hoofsaaklik twee aspekte: video-verkryging en klankverwerwing. Die video word deur die kamera versamel, wat die betrokke werking van die kamera en die parameterinstelling van die kamera behels. As gevolg van die verskille in die kameras van verskillende selfoonvervaardigers, is daar 'n paar slaggate in hierdie verband, wat in die artikel oor die kamera beskryf sal word. Klank word deur 'n mikrofoon versamel. Die mikrofone van verskillende selfone ondersteun verskillende klankmonstersnelhede, en soms moet die klank weergalm word om die mikrofoonfunksie te ondersteun.
Belangrikste punte vir video-opnametegnologie:
Kyk of die kamera gebruik kan word;
Die beeld wat deur die kamera vasgelê is, is horisontaal en die beeld moet tot 'n sekere mate gedraai word voordat dit vertoon word;
Daar is 'n reeks beeldgroottes om van te kies wanneer die kamera vang. As die grootte van die beeld nie ooreenstem met die skermgrootte van die selfoon nie, is spesiale verwerking nodig;
Die Android-telefoonkamera het 'n reeks toestande en die ooreenstemmende werking van die kamera moet in die regte toestand wees;
Baie parameters van die Android-telefoonkamera het probleme met die versoenbaarheid, en hierdie versoenbaarheidskwessies moet beter hanteer word.
Belangrike punte vir klankopnametegnologie:
Kyk of die mikrofoon gebruik kan word;
Moet die ondersteuning van die selfoon vir 'n sekere klankmonstersnelheid opspoor;
In sommige gevalle is dit nodig om eggo-kansellasie op die klank te verwerk;
Stel die korrekte buffergrootte tydens klankopname.
Opmerking: Daar sal later 'n spesiale artikel oor die versameling verskyn
4. verwerking
Videoverwerking
Beauty is nou amper 'n standaardkonfigurasie van sagteware vir regstreekse uitsending van selfone. Na verfraaiing het die gasheer 'n hoër voorkoms en is dit aantrekliker vir aanhangers. Daar is ook 'n aantal Android-regstreekse uitsaaitoepassings wat die gasheer se gesig kan herken en prettige animasies kan byvoeg. Spesiale effekte, soms moet ons ook 'n watermerk by die video voeg.
Trouens, die verfraaiing van video's en die toevoeging van spesiale effekte word deur OpenGL verwerk. Daar is GLSurfaceView in Android, wat soortgelyk is aan SurfaceView, maar dit kan met Renderer weergegee word. Tekstuur kan gegenereer word deur OpenGL, SurfaceTexture kan gegenereer word deur die tekstuur Id, en SurfaceTexture kan aan Camera oorhandig word, en uiteindelik word die kamera-voorskermskerm en OpenGL verbind deur die tekstuur, sodat 'n reeks bewerkings deur OpenGL uitgevoer kan word .
Die hele proses van verfraaiing is niks anders nie as om 'n nuwe tekstuur te genereer deur middel van die FBO-tegnologie in OpenGL, gebaseer op die tekstuur wat deur die kamera voorbeskou is, en dan die nuwe tekstuur te gebruik om op die OnDrawFrame () in die Renderer te teken. Om 'n watermerk by te voeg, is om eers 'n prentjie in 'n tekstuur te omskep en dan OpenGL te gebruik om te teken. Die toevoeging van dinamiese hangende spesiale effekte is ingewikkelder. Eerstens is dit nodig om algoritmiese ontledings uit te voer om die ooreenstemmende dele van die menslike gesig op grond van die huidige voorskoubeeld te identifiseer, en dan ooreenstemmende beelde op elke ooreenstemmende deel te teken. Die realisering van die hele proses is ietwat moeilik.
Die volgende figuur is 'n vloeidiagram van die hele skoonheidsproses:
Skoonheidsproses
Die onderstaande foto toon die skoonheids- en animasie-effekte baie goed.
Beauty
Animasie-effekte en watermerke
Opmerking: Daar sal 'n spesiale artikel wees oor OpenGL en die realisering van die hele proses.
Oudioverwerking
In sommige gevalle moet die gasheer 'n paar ekstra klanke byvoeg om die regstreekse uitsaai-atmosfeer te verhoog, soos applous, ensovoorts. Een manier om dit te hanteer, is om die addisionele klank direk af te speel, sodat die mikrofoon dit sal versamel en dan saam kan opneem, maar hierdie soort verwerking sal nie werk as die anker oorfone dra of om die geluid van die echo-kansellasie te verwerk nie. . Aangesien die ooreenstemmende funksie nog nie by ons projek gevoeg is nie, is daar voorlopig geen relevante ervaring om te deel nie. Ons kan hierdie funksie later byvoeg en dit dan met u deel.
5. kodering
Deur middel van die kamera en mikrofoon kan ons die ooreenstemmende video- en klankdata versamel, maar dit is rou data in 'n vaste formaat. Oor die algemeen versamel die kamera een raam vir raam en die mikrofoon versamel PCM-klankdata. As hierdie data direk gestuur word, is die hoeveelheid data baie groot, wat lei tot 'n groot vermorsing van bandwydte, en dit is dus nodig om video en klank te kodeer voordat u dit stuur.
Videokodering
1. Voorspellende kodering
Soos ons almal weet, bestaan 'n beeld uit baie sogenaamde pixels. 'N Groot aantal statistieke toon dat daar 'n sterk korrelasie tussen pixels in dieselfde beeld is. Hoe korter die afstand tussen twee pixels, hoe sterker is die korrelasie. In leekwoorde, hoe nader is die waardes van die twee pixels. Daarom kan mense hierdie korrelasie tussen pixels gebruik om kompressiekodering uit te voer. Hierdie kompressiemetode word intra-raam voorspellingskodering genoem. Nie net dit nie, die korrelasie tussen aangrensende rame is oor die algemeen sterker as die korrelasie tussen pixels binne 'n raam, en die kompressieverhouding is ook groter. Daar kan gesien word dat deur die korrelasie tussen pixels (intra-raam) en die korrelasie tussen rame, dit wil sê deur die ooreenstemmende verwysingspixel of verwysingsraamwerk as die voorspelde waarde te vind, videokompressiekodering gerealiseer kan word.
2. Transformeer kodering
'N Groot aantal statistieke toon dat die videosignaal die mees energie-intensiewe GS- en laefrekwensie-komponente bevat, dit wil sê die plat deel van die beeld, en 'n klein hoeveelheid hoëfrekwensie-komponente, dit wil sê die besonderhede van die beeld. Daarom kan 'n ander metode gebruik word vir videokodering. Nadat die beeld 'n sekere wiskundige transformasie ondergaan het, word die beeld in die getransformeerde domein verkry (soos getoon in die figuur), waar u en v onderskeidelik die ruimtelike frekwensiekoördinate is.
Transformeer kodering
3. Golfvorm-gebaseerde kodering
Golfvorm-gebaseerde kodering gebruik 'n blokgebaseerde hibriede koderingsmetode wat voorspellende kodering en transformeringskodering kombineer. Om die koderingskompleksiteit te verminder en die videokodering makliker te verrig, moet u, wanneer u die hibriede koderingsmetode gebruik, eers 'n beeld verdeel in blokke van vaste grootte, soos blok 8 × 8 (dit wil sê 8 rye per blok, 8 pixels per ry), Blok 16 × 16 (16 reëls per blok, 16 pixels per reël) ensovoorts, en druk dan die blok saam.
Sedert ITU-T die eerste digitale videokoderingstandaard-H.261 in 1989 vrygestel het, het dit agtereenvolgens videokoderingstandaarde soos H.263 en multimedia-terminale standaarde soos H.320 en H.323 bekendgestel. Die Moving Picture Experts Group (MPEG) onder ISO het MPEG-1, MPEG-2, MPEG-4 en ander vermaak en digitale TV-kompressiekodering wat internasionale standaarde kodeer, gedefinieer.
In Maart 2003 het ITU-T die H.264-videokoderingstandaard afgekondig. Dit maak nie net dat videokompressie aansienlik verbeter is in vergelyking met vorige standaarde nie, maar dit het ook 'n goeie netwerkaffiniteit, veral vir IP-internet, draadlose mobiele netwerk en ander prestasie van die netwerk-video-oordrag wat maklik is om te fouteer, maklik is om te blokkeer en QoS nie maklik is nie. . . Al hierdie videokodering maak gebruik van blokgebaseerde hibriede kodering, wat almal golfvorm-gebaseerde kodering is.
4. Inhoudsgebaseerde kodering
Daar is ook 'n inhoudsgebaseerde koderingstegnologie, waar die videoraam eers verdeel word in gebiede wat ooreenstem met verskillende voorwerpe en daarna gekodeer word. Dit kodeer spesifiek die vorm, beweging en tekstuur van verskillende voorwerpe. In die eenvoudigste geval word 'n tweedimensionele omtrek gebruik om die vorm van 'n voorwerp te beskryf, 'n bewegingsvektor word gebruik om die bewegingstoestand daarvan te beskryf, en 'n tekstuur word beskryf deur 'n kleurgolfvorm.
Wanneer die soorte voorwerpe in die video-reeks bekend is, kan kennisgebaseerde of modelgebaseerde kodering gebruik word. Byvoorbeeld, vir menslike gesigte is 'n paar voorafbepaalde draadraamwerke ontwikkel om die kenmerke van die gesig te kodeer. Op die oomblik is die koderingsdoeltreffendheid baie hoog, en slegs 'n paar stukkies is nodig om die funksies daarvan te beskryf. Vir gesigsuitdrukkings (soos kwaad, gelukkig, ens.), Kan moontlike gedrag deur semantiek gekodeer word. Aangesien die aantal moontlike gedrag van 'n voorwerp baie klein is, kan 'n baie hoë koderingsdoeltreffendheid verkry word.
Die koderingsmetode wat deur MPEG-4 gebruik word, is beide blokgebaseerde hibriede kodering en inhoudsgebaseerde koderingsmetode.
5. Sagte en harde breiwerk
Daar is twee maniere om videokodering op die Android-platform te implementeer, die een is sagte kodering en die ander is harde kodering. Vir sagte redigering is dit dikwels afhanklik van die CPU en gebruik die rekenaarkrag van die CPU om kodering uit te voer. Ons kan byvoorbeeld die x264-koderingsbiblioteek aflaai, die toepaslike jni-koppelvlak skryf en dan die ooreenstemmende beelddata deurgee. Nadat dit deur die x264-biblioteek verwerk is, word die oorspronklike prent in h264-formaat omskep in 'n video.
Die harde kode gebruik die MediaCodec wat deur Android self verskaf word. Om MediaCodec te gebruik, moet u die ooreenstemmende data verstuur. Hierdie data kan yuv-beeldinligting of 'n oppervlak wees. Oppervlak word gewoonlik aanbeveel, wat doeltreffender is. Surface gebruik plaaslike video-databuffers direk sonder om dit na ByteBuffers te karteer of te kopieer; daarom sal hierdie benadering doeltreffender wees. As u Surface gebruik, het u gewoonlik nie direk toegang tot die oorspronklike videodata nie, maar u kan die ImageReader-klas gebruik om toegang te verkry tot onbetroubare gedekodeerde (of oorspronklike) videorame. Dit kan steeds doeltreffender wees as die gebruik van ByteBuffers, omdat sommige plaaslike buffers gekarteer kan word om ByteBuffers te stuur. As u ByteBuffer-modus gebruik, kan u die Image-klas en getInput / OutputImage (int) -metodes gebruik om toegang tot die oorspronklike videodata-raam te kry.
Opmerking: Die volgende artikel sal spesifiek beskryf hoe u videokodering kan uitvoer
Audio kodering
AudioRecord kan in Android gebruik word om klank op te neem, en die opgeneemde klank is PCM-klank. As u die klank in rekenaartaal wil uitdruk, moet u die klank digitaliseer. Die mees algemene manier om klank te digitaliseer, is deur Pulse Code Modulation (PCM). Die klank gaan deur die mikrofoon en word omskep in 'n reeks seine van spanningveranderings. Die manier om so 'n sein in PCM-formaat om te skakel, is om drie parameters te gebruik om die klank voor te stel. Dit is: die aantal kanale, die aantal steekproefbits en die bemonsteringsfrekwensie.
1. Bemonsteringsfrekwensie
Dit wil sê die steekproeffrekwensie, wat verwys na die aantal kere wat 'n klankmonster per sekonde verkry word. Hoe hoër die monsternemingsfrekwensie, hoe beter die klankgehalte en hoe realistieser die klankweergawe, maar terselfdertyd gebruik dit meer hulpbronne. Vanweë die beperkte resolusie van die menslike oor kan 'n te hoë frekwensie nie onderskei word nie. Daar is 22 KHz, 44 KHz en ander vlakke in 16-bis-klankkaarte. Onder hulle is 22KHz gelyk aan die klankgehalte van gewone FM-uitsendings, en 44KHz is gelykstaande aan die klankgehalte van CD. Die huidige algemene steekproeffrekwensie oorskry nie 48 KHz nie.
2. Aantal steekproewe
Die steekproefwaarde of steekproefwaarde (dit wil sê die amplitude van die steekproefmonster word gekwantifiseer). Dit is 'n parameter wat gebruik word om die fluktuasie van die klank te meet, en dit kan ook gesê word dat dit die resolusie van die klankkaart is. Hoe groter die waarde, hoe hoër die resolusie en hoe sterker die klankvermoë.
Op die rekenaar is die aantal steekproefbits meestal 8 bisse en 16 bisse, maar let op dat 8 bisse nie die ordinaat in 8 dele verdeel nie, maar verdeel in 2 tot die 8ste krag, wat 256 dele is; dieselfde geld vir 16 bisse. Dit verdeel die ordinaat in 2 tot die 16de mag van 65,536 XNUMX.
3. Aantal kanale
Dit is maklik om te verstaan dat daar monofonies en stereofonies is. Monofoniese klank kan slegs deur een luidspreker geproduseer word (sommige word ook in twee luidsprekers verwerk om dieselfde kanaalklank uit te voer), en stereo pcm kan twee luidsprekers maak. Albei klink (gewoonlik is daar 'n arbeidsverdeling tussen die linker- en regterkanaal), sodat u die ruimtelike effek meer kan voel.
Dus, nou kan ons die formule kry vir die kapasiteit van die pcm-lêer:
Stoorkapasiteit = (steekproeffrekwensie number️ aantal steekproefbits ✖️ kanaal ✖️ tyd) ➗ 8 (eenheid: aantal grepe)
As die klank almal in die PCM-formaat versend word, is die besette bandwydte relatief groot, dus moet die klank gekodeer word voordat dit oorgedra word.
Daar is al baie gebruikte klankformate, soos wav, MIDI, MP3, WMA, AAC, Ogg, ens. In vergelyking met die pcm-formaat komprimeer hierdie formate die klankdata, wat die transmissiebandwydte kan verminder.
Die klankkodering kan ook in twee tipes verdeel word: sagte kodering en harde kodering. Vir sagte redigering, laai die ooreenstemmende koderingsbiblioteek af, skryf die ooreenstemmende jni en gee die data vir kodering in. Die harde kode gebruik die MediaCodec wat deur Android self verskaf word.
Opmerking: Die volgende artikel sal spesifiek beskryf hoe u klankodering kan uitvoer
6, verpakking
Die video en klank moet die ooreenstemmende formaat tydens die transmissieproses definieer, sodat dit korrek ontleed kan word wanneer dit aan die ander kant oorgedra word.
1. HTTP-FLV
In die Web 2.0-era is die gewildste soorte webwerwe natuurlik Youtube uit die buiteland, Youku en Tudou-webwerwe in China. Daar kan gesê word dat die video-inhoud wat deur sulke webwerwe verskaf word, hul eie meriete het, maar hulle gebruik Flash sonder uitsondering as 'n video-afspeelbediener. Die tegniese basis wat hierdie video-webwerwe ondersteun, is Flash Video (FLV). FLV is 'n splinternuwe video-formaat vir streaming media, wat gebruik maak van die Flash Player-platform op webbladsye wat baie gebruik word om video in Flash-animasie te integreer. Met ander woorde, solank besoekers aan die webwerf Flash-animasies kan kyk, kan hulle natuurlik video's van FLV-formaat kyk sonder om addisionele video-invoegtoepassings te installeer. Die gebruik van FLV-video's bied groot gemak vir die verspreiding van video's.
HTTP-FLV omsluit klank- en videodata in FLV, en stuur dit dan aan die kliënt deur middel van die HTTP-protokol. As die oplaaier hoef slegs die video en klank in FLV-formaat na die bediener gestuur te word.
Oor die algemeen gebruik die video en klank in die FLV-formaat gewoonlik die h264-formaat vir die video, en die klank gebruik gewoonlik die AAC-LC-formaat.
Die FLV-formaat is om eers die FLV-koptekstinligting oor te dra, dan die metadata met die video- en klankparameters (Metadata) te stuur, dan die video- en klankparameterinligting te stuur, en dan die video- en klankdata te stuur.
Opmerking: Die volgende artikel sal FLV breedvoerig beskryf
2. RTMP
RTMP is die afkorting van Real Time Messaging Protocol. Die protokol is gebaseer op TCP en is 'n protokolgroep, insluitend RTMP basiese protokol en RTMPT / RTMPS / RTMPE en vele ander variante. RTMP is 'n netwerkprotokol wat ontwerp is vir intydse datakommunikasie. Dit word hoofsaaklik gebruik vir klank-, video- en datakommunikasie tussen die Flash / AIR-platform en 'n streaming media / interaktiewe bediener wat die RTMP-protokol ondersteun.
Die RTMP-protokol is 'n intydse transmissieprotokol wat deur Adobe geloods word, wat hoofsaaklik gebruik word vir die intydse uitsending van klank- en videostrome gebaseer op die flv-formaat. Nadat die gekodeerde video- en klankdata verkry is, is eers FLV-verpakking nodig, dan in rtmp-formaat verpak en dan versend.
Om die RTMP-formaat vir oordrag te gebruik, moet u eers met die bediener verbind, dan 'n stroom skep, dan die stroom publiseer en dan die ooreenstemmende video- en klankdata stuur. Die hele versending word gedefinieer deur boodskappe, rtmp definieer verskillende vorms van boodskappe, en om die boodskappe goed te kan stuur, word die boodskappe in blokke verdeel, wat die hele protokol ingewikkelder maak.
Opmerking: aLater artikels sal RTMP volledig beskryf
Daar is ook verskeie ander vorme van protokolle, soos RTP, ens. Die algemene beginsels is soortgelyk, so ek sal dit nie een vir een verduidelik nie.
7. swak netwerkverwerking
Die video en klank kan betyds onder 'n goeie netwerk gestuur word, sonder om die opeenhoping van video- en klankdata plaaslik te veroorsaak, en die regstreekse uitsaai-effek is glad en die vertraging is klein. In 'n slegte netwerkomgewing, as die klank- en videodata nie uitgestuur kan word nie, moet ons die klank- en videodata verwerk. Daar is oor die algemeen vier verwerkingsmetodes vir video- en klankdata in 'n swak netwerkomgewing: bufferontwerp, netwerkopsporing, verwerking van raamverlies en verwerking van bisnelheidsverlaging.
1. Bufferontwerp
Video- en klankdata word na die buffer oorgedra, en die sender kry die data uit die buffer en stuur dit, wat 'n asynchrone produsent-verbruiker-modus vorm. Die produsent hoef slegs die versamelde en gekodeerde video- en klankdata na die buffer te stoot, en die verbruiker is verantwoordelik om die data uit die buffer uit te haal en te stuur.
Video- en klankbuffer
Slegs die videorame word in die figuur hierbo getoon, en natuurlik is daar ooreenstemmende klankrame binne. Om 'n asynchrone produsent-verbruikersmodel te bou, het Java 'n goeie klas gelewer. Aangesien raamverlies, invoeging, verwydering, ens. Later verwerk moet word, is dit duidelik dat LinkedBlockingQueue 'n baie goeie keuse is.
2. Netwerkopsporing
'N Belangrike proses in die proses van swak netwerkverwerking is netwerkopsporing. As die netwerk swak word, kan dit vinnig opgespoor word en dan dienooreenkomstig verwerk word. Dit sal die netwerkrespons sensitiewer maak en die effek baie beter wees.
Ons bereken die gegewens in die invoerbuffer per sekonde en die gegewens wat in reële tyd uitgestuur word. As die uitgestuurde data kleiner is as die data in die invoerbuffer, is die netwerkbandwydte nie goed nie. Op die oomblik sal die data in die buffer aanhou toeneem. Aktiveer die ooreenstemmende meganisme.
3. Val van raamverwerking
Wanneer netwerk agteruitgang opgespoor word, is raamverlies 'n goeie reaksiemeganisme. Nadat die video gekodeer is, is daar sleutelrame en nie-sleutelrame. Die sleutelraam is 'n volledige prentjie en die nie-sleutelraam beskryf die relatiewe verandering van die beeld.
Die raamvalstrategie kan op sigself gedefinieer word. Een ding om op te let, is: as u P-rame (nie-sleutelrame) wil laat val, moet u alle nie-sleutelrame tussen die twee sleutelrame laat val, anders vind daar mosaïeke plaas. Die ontwerp van die raamverliesstrategie wissel na gelang van die behoeftes, en u kan dit self ontwerp.
4. Kodeverminderingskoers
In Android, as harde kodering vir kodering gebruik word, in 'n swak netwerkomgewing, kan ons die bitsnelheid van harde kodering intyds verander om die regstreekse uitsending gladder te maak. As daar gevind word dat die netwerkomgewing swak is, kan ons die video- en klankbitsnelheid verlaag terwyl ons rame laat val. As die Android SDK-weergawe groter as of gelyk is aan 19, kan u parameters aan MediaCodec deurgee om die bitsnelheid van die data vanaf die hardkode-kodeerder te verander.
Bundelbitsnelheid = nuwe bundel (); bitrate.putInt (MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bps * 1024);
mMediaCodec.setParameters (bitrate);
8. stuur
Na verskillende verwerkings moet die data uiteindelik uitgestuur word. Hierdie stap is relatief eenvoudig. Of dit nou HTTP-FLV of RTMP is, ons gebruik TCP om 'n verbinding te bewerkstellig. Voor die regstreekse uitsending moet u via die Socket met die bediener verbind om te verifieer of u met die bediener kan verbind. Gebruik die Socket na die verbinding om data na die bediener te stuur en maak die Socket toe nadat die data gestuur is.
