3. kokoelma
Hankinta sisältää pääasiassa kaksi näkökohtaa: videoiden hankkimisen ja äänen hankinnan. Kamera kerää videon, johon sisältyy kameran asianmukainen käyttö ja kameran parametriasetus. Eri matkapuhelinvalmistajien kameroissa olevien erojen vuoksi tältä osin on joitain sudenkuoppia, joita kuvataan kameraa käsittelevässä artikkelissa. Ääni kerätään mikrofonin kautta. Eri matkapuhelimien mikrofonit tukevat erilaisia äänen näytteenottotaajuuksia, ja joskus ääni on kaiun poistettava mikrofonitoiminnon tukemiseksi.
Videon kaappaustekniikan tärkeimmät kohdat:
Tarkista, voidaanko kameraa käyttää;
Kameran ottama kuva on vaakasuora, ja kaapattua kuvaa on käännettävä jossain määrin ennen näyttämistä;
Kameran sieppauksessa on valittavissa joukko kuvakokoja. Kun otetun kuvan koko on ristiriidassa matkapuhelimen näytön koon kanssa, tarvitaan erityinen käsittely;
Android-puhelinkamerassa on joukko tiloja, ja vastaavan kameran toiminnan on oltava oikeassa tilassa;
Monilla Android-puhelinkameran parametreilla on yhteensopivuusongelmia, ja nämä yhteensopivuusongelmat on käsiteltävä paremmin.
Äänen sieppaustekniikan pääkohdat
Tarkista, voidaanko mikrofonia käyttää;
Tarve tunnistaa matkapuhelimen tuki tietylle äänen näytteenottotaajuudelle;
Joissakin tapauksissa on tarpeen suorittaa kaiun peruutuksen käsittely äänellä;
Aseta oikea puskurikoko äänen sieppauksen aikana.
Huomaa: Kokoelmasta tulee myöhemmin erityisartikkeli
4. käsittely
Videon käsittely
Kauneus on nyt melkein vakiokokoonpano matkapuhelinten suoraa lähetystä varten. Kauneuttamisen jälkeen isännällä on korkeampi ulkonäkö ja houkuttelevampi faneille. On myös joitain Androidin suoria lähetyssovelluksia, jotka tunnistavat isännän kasvot ja lisäävät hauskoja animaatioita. Erikoistehosteet, joskus meidän on myös lisättävä vesileima videoon.
Itse asiassa videoiden kaunistaminen ja erikoistehosteiden lisääminen käsitellään OpenGL: n kautta. Androidissa on GLSurfaceView, joka on samanlainen kuin SurfaceView, mutta se voidaan renderöidä Rendererillä. Tekstuuri voidaan luoda OpenGL: n kautta, SurfaceTexture voidaan luoda tekstuurin Id: n kautta ja SurfaceTexture voidaan luovuttaa kameralle, ja lopuksi kameran esikatselunäyttö ja OpenGL yhdistetään tekstuurin kautta, jotta sarja toimintoja voidaan suorittaa OpenGL: n kautta .
Koko kaunistamisprosessi ei ole muuta kuin uuden tekstuurin luominen FBO-tekniikan avulla OpenGL: ssä kameran esikatsaman tekstuurin perusteella ja sitten uuden tekstuurin käyttäminen Rendererin onDrawFrame () -sovellukseen. Vesileiman lisääminen on ensin muuntaa kuva tekstuuriksi ja käyttää sitten OpenGL: ää piirtämiseen. Dynaamisten riipusten erikoistehosteiden lisääminen on monimutkaisempaa. Ensinnäkin on välttämätöntä suorittaa algoritmianalyysi tunnistaakseen ihmiskasvojen vastaavat osat nykyisen esikatselukuvan perusteella ja piirtää sitten vastaavat kuvat kuhunkin vastaavaan osaan. Koko prosessin toteuttaminen on jonkin verran vaikeaa.
Seuraava kuva on vuokaavio koko kauneusprosessista:
Kauneusprosessi
Alla oleva kuva näyttää hyvin kauneus- ja animaatioefektit.
Kauneus
Animaatioefektit ja vesileimat
Huomaa: Tulee erityinen artikkeli OpenGL: stä ja koko prosessin toteuttamisesta.
Äänenkäsittely
Joissakin tapauksissa isännän on lisättävä lisää ääniä suoran lähetyksen ilmapiirin lisäämiseksi, kuten suosionosoitukset ja niin edelleen. Yksi tapa käsitellä sitä on toistaa ylimääräinen ääni suoraan, niin että mikrofoni kerää sen ja tallentaa sen sitten yhdessä, mutta tällainen käsittely ei onnistu, kun ankkuri käyttää kuulokkeita tai joudutaan suorittamaan kaiunpoiston käsittely äänellä . Koska vastaavaa toimintoa ei ole lisätty projektiimme, toistaiseksi ei ole asiaankuuluvaa kokemusta, jonka voimme jakaa, voimme lisätä tämän toiminnon myöhemmin ja jakaa sen sitten kanssasi.
5. koodaus
Kameran ja mikrofonin kautta voimme kerätä vastaavat video- ja äänitiedot, mutta nämä ovat raakatietoja kiinteässä muodossa. Yleisesti ottaen kamera kerää yhden kuvan kehykseltä ja mikrofoni kerää PCM-äänidataa. Jos nämä tiedot lähetetään suoraan, datamäärä on usein hyvin suuri, mikä johtaa paljon kaistanleveyden tuhlaukseen, joten on usein tarpeen koodata video ja ääni ennen lähettämistä.
Videokoodaus
1. Ennakoiva koodaus
Kuten me kaikki tiedämme, kuva koostuu monista ns. Pikseleistä. Suuri määrä tilastoja osoittaa, että saman kuvan pikselien välillä on vahva korrelaatio. Lyhyempi etäisyys kahden pikselin välillä, sitä vahvempi korrelaatio. Maallikon kannalta, mitä lähempänä kahden pikselin arvot ovat. Siksi ihmiset voivat käyttää tätä pikselien välistä korrelaatiota pakkauskoodauksen suorittamiseen. Tätä pakkausmenetelmää kutsutaan kehyksen sisäiseksi ennustuskoodaukseksi. Paitsi, vierekkäisten kehysten välinen korrelaatio on yleensä vahvempi kuin kehyksessä olevien pikselien välinen korrelaatio, ja myös pakkaussuhde on suurempi. Voidaan nähdä, että käyttämällä pikselien (kehyksen sisäinen) ja kehysten välistä korrelaatiota, toisin sanoen vastaavan vertailupikselin tai viitekehyksen löytäminen ennustetuksi arvoksi, videopakkauskoodaus voidaan toteuttaa.
2. Muunna koodaus
Suuri määrä tilastoja osoittaa, että videosignaali sisältää eniten energiaa kuluttavia DC- ja matalataajuisia komponentteja, toisin sanoen kuvan tasaista osaa, ja pienen määrän korkeataajuisia komponentteja, ts. kuva. Siksi videokoodaukseen voidaan käyttää toista menetelmää. Kun kuva on läpikäynyt tietyn matemaattisen muutoksen, saadaan muunnetun alueen kuva (kuten kuvassa on esitetty), jossa u ja v ovat vastaavasti paikkataajuuskoordinaatit.
Muunna koodaus
3. Aaltomuotoon perustuva koodaus
Aaltomuotopohjainen koodaus käyttää lohkopohjaista hybridikoodausmenetelmää, joka yhdistää ennakoivan koodauksen ja muunnoskoodauksen. Koodauksen monimutkaisuuden vähentämiseksi ja videokoodausoperaation helpottamiseksi suorittamalla hybridikoodausmenetelmä ensin jaa kuva kiinteän kokoisiksi lohkoiksi, kuten lohkoksi 8 × 8 (ts. 8 riviä lohkoa kohden, 8 pikseliä riviä kohti), lohko 16 × 16 (16 riviä lohkoa kohden, 16 pikseliä riviä kohti) ja niin edelleen, ja pakkaa ja koodaa sitten lohko.
Koska ITU-T julkaisi ensimmäisen digitaalisen videokoodausstandardin H.261 vuonna 1989, se on peräkkäin julkaissut videokoodausstandardit, kuten H.263, ja multimediapäätestandardit, kuten H.320 ja H.323. ISO: n mukainen Moving Picture Experts Group (MPEG) on määritellyt MPEG-1, MPEG-2, MPEG-4 ja muut viihde- ja digitaalitelevisiopakkauskoodaukset kansainvälisiksi standardeiksi.
Maaliskuussa 2003 ITU-T julkisti H.264-videokoodausstandardin. Se paitsi parantaa videon pakkaamista huomattavasti aiempiin standardeihin verrattuna, mutta sillä on myös hyvä verkko affiniteetti, erityisesti IP-Internetin, langattoman matkapuhelinverkon ja muun verkon videonsiirtotehon suhteen, joka on helppo virheitä, helppo estää ja jota ei ole helppo taata QoS . . Kaikki nämä videokoodaukset käyttävät lohkopohjaista hybridikoodausta, jotka kaikki ovat aaltomuotoon perustuvia koodauksia.
4. Sisältöpohjainen koodaus
On myös sisältöpohjainen koodaustekniikka, jossa videokehys jaetaan ensin eri objekteja vastaaviin alueisiin ja sitten koodataan. Erityisesti se koodaa eri esineiden muodon, liikkeen ja tekstuurin. Yksinkertaisimmassa tapauksessa kaksiulotteista ääriviivaa käytetään kuvaamaan kohteen muotoa, liikevektoria kuvaamaan sen liiketilaa ja tekstuuria kuvaamaan väriaaltomuoto.
Kun videosekvenssin objektityypit tunnetaan, voidaan käyttää tieto- tai mallipohjaista koodausta. Esimerkiksi ihmisen kasvoille on kehitetty joitain ennalta määriteltyjä lankakehyksiä kasvojen piirteiden koodaamiseksi. Tällä hetkellä koodaustehokkuus on erittäin korkea, ja sen ominaisuuksien kuvaamiseen tarvitaan vain muutama bitti. Kasvojen ilmeissä (kuten vihainen, onnellinen jne.) Mahdollinen käyttäytyminen voidaan koodata semantiikalla. Koska kohteen mahdollisten käyttäytymismäärien määrä on hyvin pieni, voidaan saavuttaa erittäin korkea koodaustehokkuus.
MPEG-4: n hyväksymä koodausmenetelmä on sekä lohkopohjainen hybridikoodaus että sisältöpohjainen koodausmenetelmä.
5. Pehmeä ja kova neulonta
On kaksi tapaa toteuttaa videokoodaus Android-alustalla, toinen on pehmeä ja toinen kovakoodaus. Pehmeässä muokkauksessa se luottaa usein suorittimeen ja käyttää koodausta suorittimen laskentateholla. Voimme esimerkiksi ladata x264-koodauskirjaston, kirjoittaa asiaankuuluvan jni-käyttöliittymän ja siirtää sitten vastaavat kuvatiedot. Käsittelyn jälkeen x264-kirjasto alkuperäinen kuva muunnetaan videoksi h264-muodossa.
Kova koodi käyttää MediaCodecia, jonka Android tarjoaa itse. Jotta voit käyttää MediaCodecia, sinun on syötettävä vastaavat tiedot. Nämä tiedot voivat olla yuv-kuvan tietoja tai pintaa. Yleensä suositellaan pintaa, mikä on tehokkaampaa. Surface käyttää suoraan paikallisia videodatapuskureita kartoittamatta tai kopioimatta niitä ByteBuffersiin; siksi tämä lähestymistapa on tehokkaampi. Kun käytät Surfacea, et yleensä voi käyttää suoraan alkuperäistä videodataa, mutta ImageReader-luokan avulla voit käyttää epäluotettavia dekoodattuja (tai alkuperäisiä) videokehyksiä. Tämä voi silti olla tehokkaampaa kuin ByteBuffers, koska jotkut paikalliset puskurit voidaan yhdistää suoraan ByteBuffersiin. Kun käytät ByteBuffer-tilaa, voit käyttää Image class- ja getInput / OutputImage (int) -menetelmiä päästäksesi alkuperäiseen videotietokehykseen.
Huomaa: Seuraava artikkeli kuvaa erityisesti videokoodauksen suorittamisen
Audio koodaus
AudioRecordia voidaan käyttää Androidissa äänen tallentamiseen, ja tallennettu ääni on PCM-ääni. Jos haluat ilmaista äänen tietokonekielellä, sinun on digitoitava ääni. Yleisin tapa digitalisoida ääni on pulssikoodimodulaatio (PCM). Ääni kulkee mikrofonin läpi ja muuttuu sarjaksi jännitemuutosten signaaleja. Tapa muuntaa tällainen signaali PCM-muotoon on käyttää kolmea parametria äänen esittämiseen. Ne ovat: kanavien lukumäärä, näytteenottobittien lukumäärä ja näytteenottotaajuus.
1. Näytteenottotaajuus
Toisin sanoen näytteenottotaajuus, joka viittaa siihen, kuinka monta kertaa ääninäyte saadaan sekunnissa. Mitä korkeampi näytteenottotaajuus, sitä parempi äänenlaatu ja realistisempi äänentoisto, mutta samalla se vie enemmän resursseja. Ihmiskorvan rajoitetun resoluution vuoksi liian suurtaajuutta ei voida erottaa. 22-bittisissä äänikorteissa on 44KHz, 16KHz ja muita tasoja. Niistä 22 kHz vastaa tavallisen FM-lähetyksen äänenlaatua ja 44 kHz vastaa CD: n äänenlaatua. Nykyinen yhteinen näytteenottotaajuus ei ylitä 48KHz.
2. Näytteenottobittien lukumäärä
Toisin sanoen näytteenottoarvo tai näytteenottoarvo (eli näytteenoton näyte on kvantisoitu). Se on parametri, jota käytetään äänen vaihtelun mittaamiseen, ja sen voidaan myös sanoa olevan äänikortin resoluutio. Mitä suurempi sen arvo, sitä suurempi resoluutio ja sitä voimakkaampi ääniteho.
Tietokoneessa näytteenottobittien lukumäärä on yleensä 8 bittiä ja 16 bittiä, mutta huomaa, että 8 bittiä ei tarkoita ordinaatin jakamista 8 osaan, vaan jaettuna 2: een kahdeksasosaan, joka on 8 osaa; sama pätee 256 bittiin. Se jakaa ordinaatin 16: sta 2 16: n 65,536. voimaan.
3. Kanavien lukumäärä
On helppo ymmärtää, että on mono- ja stereofonisia. Monofonista ääntä voi tuottaa vain yksi kaiutin (jotkut prosessoidaan myös kahteen kaiuttimeen saman kanavan äänen tuottamiseksi), ja stereo-PCM voi tuottaa kaksi kaiutinta Molemmat äänet (vasemman ja oikean kanavan välillä on yleensä työnjako), joten voit tuntea spatiaalisen vaikutuksen enemmän.
Joten nyt voimme saada kaavan pcm-tiedoston kapasiteetille:
Tallennuskapasiteetti = (näytteenottotaajuus sam️ näytteenottobittien lukumäärä kanavan time️ aika) ➗ 8 (yksikkö: tavujen lukumäärä)
Jos ääni lähetetään kaikki PCM-muodossa, varattu kaistanleveys on suhteellisen suuri, joten ääni on koodattava ennen lähetystä.
Jo nyt on joitain laajalti käytettyjä äänimuotoja, kuten wav, MIDI, MP3, WMA, AAC, Ogg jne. Pcm-muotoon verrattuna nämä muodot pakkaavat äänidataa, mikä voi vähentää lähetyskaistanleveyttä.
Äänikoodaus voidaan myös jakaa kahteen tyyppiin: pehmeä koodaus ja kovakoodaus. Pehmeää muokkausta varten lataa vastaava koodauskirjasto, kirjoita vastaava jni ja syötä sitten tiedot koodausta varten. Kova koodi käyttää MediaCodecia, jonka Android tarjoaa itse.
Huomaa: Seuraava artikkeli kuvaa erityisesti äänikoodauksen suorittamisen
6, pakkaus
Videon ja äänen on määritettävä vastaava muoto lähetysprosessin aikana, jotta se voidaan jäsentää oikein, kun se lähetetään toiseen päähän.
1. HTTP-FLV
Web 2.0-aikakaudella suosituimmat verkkosivustotyypit ovat luonnollisesti Youtube ulkomailta, Youku ja Tudou -sivustot Kiinasta. Tällaisten sivustojen tarjoamalla videosisällöllä voidaan sanoa olevan omat ansiot, mutta ne kaikki käyttävät Flashia videotoiston kantajana poikkeuksetta. Näitä videosivustoja tukeva tekninen perusta on Flash Video (FLV). FLV on upouusi median suoratoistovideomuoto, joka hyödyntää verkkosivuilla yleisesti käytettyä Flash Player -alustaa videon integroimiseksi Flash-animaatioon. Toisin sanoen, niin kauan kuin verkkosivuston kävijät voivat katsella Flash-animaatioita, he voivat luonnollisesti katsella FLV-muotoisia videoita tarvitsematta asentaa uusia videolaajennuksia. FLV-videoiden käyttö tuo videoiden levittämiseen suurta mukavuutta.
HTTP-FLV kapseloi ääni- ja videotiedot FLV: ksi ja lähettää sen sitten asiakkaalle HTTP-protokollan kautta. Lähettäjänä vain FLV-muodossa oleva video ja ääni on lähetettävä palvelimelle.
Yleisesti ottaen FLV-muodossa olevat videot ja äänet käyttävät yleensä videota varten h264-muotoa ja ääni yleensä AAC-LC-muotoa.
FLV-muodon on ensin lähetettävä FLV-otsikkotiedot, sitten lähetettävä metatiedot video- ja ääniparametreilla (metatiedot), sitten lähetettävä video- ja ääniparametritiedot sekä lähetettävä sitten video- ja äänidata.
Huomaa: Seuraava artikkeli kuvaa FLV: tä yksityiskohtaisesti
2. RTMP
RTMP on lyhenne sanoista Real Time Messaging Protocol. Protokolla perustuu TCP: hen ja on protokollaryhmä, joka sisältää RTMP-perusprotokollan ja RTMPT / RTMPS / RTMPE: n ja monia muita variantteja. RTMP on verkkoprotokolla, joka on suunniteltu reaaliaikaiseen tiedonsiirtoon. Sitä käytetään pääasiassa ääni-, video- ja tietoliikenteeseen Flash / AIR-alustan ja suoratoistovälineen / interaktiivisen palvelimen välillä, joka tukee RTMP-protokollaa.
RTMP-protokolla on Adoben käynnistämä reaaliaikainen lähetysprotokolla, jota käytetään pääasiassa ääni- ja videovirtojen reaaliaikaiseen siirtoon flv-muodon perusteella. Saatuaan koodatun video- ja äänidatan ensin vaaditaan FLV-pakkaus, joka sitten pakataan rtmp-muotoon ja lähetetään sitten.
Jos haluat käyttää RTMP-muotoa lähetykseen, sinun on ensin muodostettava yhteys palvelimeen, luotava virta, sitten julkaistava virta ja lähetettävä sitten vastaava video- ja äänidata. Koko lähetys määritellään viesteillä, rtmp määrittelee erilaiset viestimuodot, ja jotta viestit voidaan lähettää hyvin, viestit on jaettu lohkoihin, mikä tekee koko protokollasta monimutkaisemman.
Huomaa: Myöhemmissä artikkeleissa kuvataan RTMP yksityiskohtaisesti
On myös useita muita protokollamuotoja, kuten RTP, jne. Yleiset periaatteet ovat samanlaiset, joten en selitä niitä yksi kerrallaan.
7. huono verkon käsittely
Video ja ääni voidaan lähettää ajoissa hyvässä verkossa, aiheuttamatta video- ja äänidatan kertymistä paikallisesti, suoran lähetyksen vaikutus on sujuva ja viive pieni. Jos ääni- ja videotietoja ei voida lähettää huonossa verkkoympäristössä, ääni- ja videotiedot on käsiteltävä. Video- ja äänidataa on yleensä neljä prosessointimenetelmää heikossa verkkoympäristössä: puskurisuunnittelu, verkon tunnistus, kehyshäviön käsittely ja bittinopeuden vähentämisen käsittely.
1. Puskurin suunnittelu
Video- ja äänidata siirretään puskuriin, ja lähettäjä saa tiedot puskurista ja lähettää ne muodostaen siten asynkronisen tuottaja-kuluttaja-tilan. Tuottajan on vain työnnettävä kerätyt ja koodatut video- ja äänitiedot puskuriin, ja kuluttaja on vastuussa tietojen poistamisesta puskurista ja lähettämisestä.
Video- ja äänipuskuri
Vain videokehys on esitetty yllä olevassa kuvassa, ja sisällä on ilmeisesti vastaavia äänikehyksiä. Asynkronisen tuottaja-kuluttaja-mallin rakentamiseksi Java on tarjonnut hyvän luokan. Koska kehyksen menetys, lisäys, poisto jne. On käsiteltävä myöhemmin, on selvää, että LinkedBlockingQueue on erittäin hyvä valinta.
2. Verkon tunnistus
Tärkeä prosessi verkon heikossa käsittelyssä on verkon havaitseminen. Kun verkko heikkenee, se voidaan nopeasti tunnistaa ja sitten käsitellä vastaavasti. Tämä tekee verkon vastauksesta herkempiä ja vaikutus on paljon parempi.
Laskemme tulopuskurin tiedot sekunnissa ja lähetetyt tiedot reaaliajassa. Jos lähetetty data on pienempi kuin syöttöpuskurin data, verkon kaistanleveys ei ole hyvä. Tällä hetkellä puskurin tiedot kasvavat edelleen. Aktivoi vastaava mekanismi.
3. Pudota kehyksen käsittely
Kun verkon heikkeneminen havaitaan, kehyshäviö on hyvä vastemekanismi. Kun video on koodattu, on avainkehyksiä ja muita kuin avainkehyksiä. Avainkehys on täydellinen kuva, ja ei-avainkehys kuvaa kuvan suhteellisen muutoksen.
Kehyksen pudottamisstrategia voidaan määrittää itse. Yksi asia on huomata: jos haluat pudottaa P-kehyksiä (ei-avainkehykset), sinun on pudotettava kaikki avaimeton kehykset kahden avainkehyksen väliin, muuten esiintyy mosaiikkeja. Runkohäviöstrategian suunnittelu vaihtelee tarpeiden mukaan, ja voit suunnitella sen itse.
4. Koodin vähennysaste
Jos koodauksessa käytetään kovakoodausta, voimme huonossa verkkoympäristössä Androidissa muuttaa kovakoodauksen bittinopeutta reaaliajassa suoran lähetyksen sujuvuuden parantamiseksi. Kun havaitaan, että verkkoympäristö on huono, voimme myös vähentää video- ja äänibittinopeutta pudottaessamme kehyksiä. Kun Android SDK -versio on suurempi tai yhtä suuri kuin 19, voit välittää parametrit MediaCodecille muuttaaksesi tiedon bittinopeutta kovakoodatusta kooderista.
Bundlen bittinopeus = uusi Bundle (); bitrate.putInt (MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bps * 1024);
mMediaCodec.setParameters (bittinopeus);
8. Lähetä
Eri käsittelyjen jälkeen tiedot on lähetettävä lopulta, tämä vaihe on suhteellisen yksinkertainen. Olipa kyseessä HTTP-FLV tai RTMP, käytämme TCP: tä yhteyden muodostamiseen. Ennen suoraa lähetystä sinun on muodostettava yhteys palvelimeen Socketin kautta varmistaaksesi, että voit muodostaa yhteyden palvelimeen. Kun yhteys on muodostettu, lähetä tietoja palvelimelle tällä Socketilla ja sulje Socket tietojen lähettämisen jälkeen.
