3. kogumine
Omandamine hõlmab peamiselt kahte aspekti: video omandamine ja heli omandamine. Video kogub kaamera, mis hõlmab kaamera asjakohast toimimist ja kaamera parameetrite seadistamist. Erinevate mobiiltelefonide tootjate kaamerate erinevuste tõttu on selles osas mõningaid lõkse, mida kirjeldatakse kaamerat käsitlevas artiklis. Heli kogutakse läbi mikrofoni. Erinevate mobiiltelefonide mikrofonid toetavad erinevat heli diskreetimissagedust ja mõnikord tuleb heli mikrofoni funktsiooni toetamiseks kaja tühistada.
Videohõive tehnoloogia põhipunktid:
Kontrollige, kas kaamerat saab kasutada;
Kaamera jäädvustatud pilt on horisontaalne ja jäädvustatud pilti tuleb enne kuvamist teatud määral pöörata;
Kaamera jäädvustamisel saate valida rea pildisuurusi. Kui pildistatud pildi suurus ei vasta mobiiltelefoni ekraani suurusele, on vaja spetsiaalset töötlemist;
Android-telefoni kaameral on rida olekuid ja kaamera vastav töö peab olema õiges olekus;
Paljudel Androidi telefonikaamera parameetritel on ühilduvusprobleeme ja nende ühilduvusprobleemidega tuleb paremini tegeleda.
Heli püüdmise tehnoloogia põhipunktid:
Kontrollige, kas mikrofoni saab kasutada;
Vajadus tuvastada mobiiltelefoni tugi teatava heli proovivõtusageduse jaoks;
Mõnel juhul on vajalik heli kaja tühistamise töötlemine;
Heli jäädvustamise ajal määrake õige puhvri suurus.
Märkus. Kollektsiooni kohta on hiljem spetsiaalne artikkel
4. töötlemine
Video töötlemine
Ilu on nüüd peaaegu tavaline mobiiltelefoni otseülekande tarkvara konfiguratsioon. Pärast kaunistamist on peremees välimuselt kõrgem ja fännidele atraktiivsem. Samuti on mõned Androidi otseülekande rakendused, mis tunnevad ära saatejuhi näo ja lisavad lõbusaid animatsioone. Efektid, mõnikord peame ka videole lisama vesimärgi.
Tegelikult töödeldakse video kaunistamist ja eriefektide lisamist OpenGL-i kaudu. Androidis on GLSurfaceView, mis sarnaneb SurfaceView'ga, kuid seda saab renderdada Rendereriga. Tekstuuri saab genereerida OpenGL-i kaudu, SurfaceTexture'i saab luua tekstuuri Id kaudu ja SurfaceTexture'i saab kaamerale üle anda ning lõpuks on kaamera eelvaate ekraan ja OpenGL ühendatud tekstuuri kaudu, nii et OpenGL-i kaudu saab läbi viia mitmeid toiminguid .
Kogu kaunistamisprotsess pole midagi muud kui OpenGL-i FBO-tehnoloogia abil uue tekstuuri genereerimine kaamera eelvaadatud tekstuuri põhjal ja seejärel uue tekstuuri kasutamine Rendereris oleva onDrawFrame () joonistamiseks. Vesimärgi lisamine tähendab kõigepealt pildi muutmist tekstuuriks ja seejärel joonistamiseks OpenGL-i kasutamist. Dünaamiliste ripatsite eriefektide lisamine on keerulisem. Esiteks on vaja läbi viia algoritmiline analüüs, et tuvastada praeguse eelvaate pildi põhjal inimese näo vastavad osad ja seejärel joonistada vastavad kujutised igale vastavale osale. Kogu protsessi realiseerimine on mõnevõrra keeruline.
Järgmine joonis on kogu iluprotsessi vooskeem:
Iluprotsess
Alloleval pildil on ilu- ja animatsiooniefektid väga hästi näha.
Ilu
Animatsiooniefektid ja vesimärgid
Märkus: OpenGL-i ja kogu protsessi realiseerimise kohta on spetsiaalne artikkel.
Helitöötlus
Mõnel juhul peab saatejuht otseülekande õhkkonna suurendamiseks lisama mõned täiendavad helid, näiteks aplaus ja nii edasi. Üks võimalus sellega toime tulla on lisaheli otse esitamine, nii et mikrofon kogub selle ja salvestab siis koos, kuid selline töötlemine ei toimi, kui ankur kannab kõrvaklappe või peab heli kaja tühistamise töötlema . Kuna vastavat funktsiooni pole meie projekti lisatud, pole praegu asjakohast kogemust, mida jagada, võime selle funktsiooni lisada hiljem ja siis teiega jagada.
5. kodeerimine
Kaamera ja mikrofoni kaudu saame koguda vastavad video- ja heliandmed, kuid need on fikseeritud formaadis toorandmed. Üldiselt kogub kaamera ühe kaadri haaval ja mikrofon PCM-i heliandmeid. Kui neid andmeid saadetakse otse, on andmemaht sageli väga suur, mille tulemuseks on suur ribalaiuse raiskamine, seetõttu on sageli vaja enne saatmist video ja heli kodeerida.
Video kodeerimine
1. Ennustav kodeerimine
Nagu me kõik teame, koosneb pilt paljudest nn pikslitest. Suur hulk statistikat näitab, et sama pildi pikslite vahel on tugev seos. Mida lühem on kahe piksli vaheline kaugus, seda tugevam on korrelatsioon. Võlakokkuvõttes on lähemal kahe piksli väärtused. Seetõttu saavad inimesed tihenduskodeerimiseks kasutada seda korrelatsiooni pikslite vahel. Seda tihendusmeetodit nimetatakse kaadrisiseseks prognoosimiseks. Vähe sellest, külgnevate kaadrite vaheline korrelatsioon on üldiselt tugevam kui kaadris olevate pikslite korrelatsioon ning ka tihendussuhe on suurem. On näha, et kasutades pikslite (kaadrisisene) ja kaadritevahelise korrelatsiooni, st prognoositud väärtusena vastava võrdluspiksli või võrdlusraami leidmist, saab videokompressiooni kodeerimise realiseerida.
2. Transformeerige kodeerimine
Suur hulk statistikat näitab, et videosignaal sisaldab kõige energiamahukamaid alalis- ja madalsageduskomponente, see tähendab pildi tasast osa, ja väikest hulka kõrgsageduslikke komponente, see tähendab pilt. Seetõttu saab video kodeerimiseks kasutada teist meetodit. Pärast seda, kui pilt läbib teatud matemaatilise transformatsiooni, saadakse transformeeritud domeenis olev pilt (nagu on näidatud joonisel), kus u ja v on vastavalt ruumilise sageduse koordinaadid.
Teisenda kodeerimine
3. Lainekujul põhinev kodeerimine
Lainekujul põhinev kodeerimine kasutab plokipõhist hübriidkodeerimismeetodit, mis ühendab ennustava kodeerimise ja transformatsiooni kodeerimise. Kodeerimise keerukuse vähendamiseks ja videokodeerimise toimingu hõlbustamiseks jagage hübriidkodeerimismeetodi kasutamisel pilt kõigepealt fikseeritud suurusega plokkideks, näiteks plokiks 8 × 8 (see tähendab 8 rida plokis, 8 pikslit rea kohta), plokk 16 × 16 (16 rida plokis, 16 pikslit reas) ja nii edasi ning seejärel tihendage ja kodeerige plokk.
Kuna ITU-T avaldas 261. aastal esimese digitaalse videokodeerimise standardi H.1989, on see järjestikku välja andnud videokodeerimise standardid nagu H.263 ja multimeediumterminali standardid nagu H.320 ja H.323. ISO liikuva pildi ekspertrühm (MPEG) on määratlenud rahvusvahelised standardid MPEG-1, MPEG-2, MPEG-4 ning muud meelelahutus- ja digitaaltelevisiooni tihenduskoodid.
2003. aasta märtsis kuulutas ITU-T välja videokodeerimise standardi H.264. See mitte ainult ei muuda videokompressiooni varasemate standarditega võrreldes märkimisväärselt paremaks, vaid omab ka head võrguühendust, eriti IP-Interneti, traadita mobiilsidevõrgu ja muu võrgu videoedastuse jõudluse osas, mida on lihtne viga teha, lihtne blokeerida ja mida pole lihtne tagada . . Kõik need videokodeeringud kasutavad plokipõhist hübriidkodeerimist, mis kõik on lainekujul põhinevad kodeeringud.
4. Sisupõhine kodeerimine
Samuti on olemas sisupõhine kodeerimistehnoloogia, kus videoraam jagatakse kõigepealt erinevatele objektidele vastavateks piirkondadeks ja seejärel kodeeritakse. Täpsemalt kodeerib see erinevate objektide kuju, liikumist ja tekstuuri. Lihtsamal juhul kasutatakse objekti kuju kirjeldamiseks kahemõõtmelist kontuuri, selle liikumisolekut kirjeldatakse liikumisvektoriga ja värvi lainekuju abil tekstuuri.
Kui videosarja objektide tüübid on teada, saab kasutada teadmistepõhist või mudelipõhist kodeerimist. Näiteks inimeste nägude jaoks on välja töötatud mõned etteantud traadiraamid näo tunnuste kodeerimiseks. Sel ajal on kodeerimise efektiivsus väga kõrge ja selle funktsioonide kirjeldamiseks on vaja ainult mõnda bitti. Näoilmete (näiteks vihane, õnnelik jne) puhul on võimalik käitumine semantika abil kodeeritud. Kuna objekti võimalike käitumiste arv on väga väike, on võimalik kodeerimise efektiivsus väga kõrge.
MPEG-4 poolt kasutatav kodeerimismeetod on nii plokipõhine hübriidkodeerimine kui ka sisupõhine kodeerimismeetod.
5. Pehme ja kõva kudumine
Videokodeerimise rakendamiseks Android-platvormil on kaks võimalust, üks on pehme kodeerimine ja teine karm kodeerimine. Pehme redigeerimise korral tugineb see sageli protsessorile ja kasutab kodeerimise jaoks protsessori arvutusvõimsust. Näiteks võime alla laadida x264 kodeerimisraamatukogu, kirjutada vastava jni liidese ja seejärel sisestada vastavad pildiandmed. Pärast töötlemist x264 teegis teisendatakse algne pilt h264-vormingus videoks.
Kõvakood kasutab Androidi enda pakutavat MediaCodecit. MediaCodeci kasutamiseks peate sisestama vastavad andmed. Need andmed võivad olla yuv-pilditeave või Surface. Üldiselt soovitatakse pinda, mis on tõhusam. Surface kasutab otse kohalikke videoandmete puhvreid, ilma et neid kaardistataks või ByteBuffersisse kopeeritaks; seetõttu on see lähenemine tõhusam. Surface'i kasutamisel ei pääse tavaliselt otse juurde algsetele videoandmetele, kuid ebausaldusväärsete dekodeeritud (või originaalsete) videoraamide juurde pääsemiseks võite kasutada klassi ImageReader. See võib siiski olla tõhusam kui ByteBufferite kasutamine, sest mõnda kohalikku puhvrit saab kaardistada otseste ByteBufferite jaoks. ByteBufferi režiimi kasutamisel saate algsele videoandmeraamile juurdepääsemiseks kasutada Image klassi ja getInput / OutputImage (int) meetodeid.
Märkus. Järgmises artiklis kirjeldatakse konkreetselt videokodeerimise toimingut
Audio kodeerimine
AudioRecordi saab Androidis heli salvestamiseks kasutada ja salvestatud heli on PCM-heli. Kui soovite heli väljendada arvutikeeles, peate heli digiteerima. Kõige tavalisem viis heli digiteerimiseks on pulsikoodimodulatsioon (PCM). Heli läbib mikrofoni ja muundatakse pingemuutuste signaalide jadaks. Sellise signaali teisendamiseks PCM-vormingusse on heli esitamiseks kasutada kolme parameetrit. Need on: kanalite arv, proovivõtubittide arv ja proovivõtusagedus.
1. Proovivõtusagedus
See tähendab, et proovivõtusagedus, mis viitab helinäite sekundis saamise arvule. Mida suurem on proovivõtusagedus, seda parem on helikvaliteet ja realistlikum heli taasesitamine, kuid samal ajal võtab see rohkem ressursse. Inimese kõrva piiratud eraldusvõime tõttu ei saa liiga kõrget sagedust eristada. 22-bitistes helikaartides on 44KHz, 16KHz ja muud tasemed. Nende hulgas on 22KHz samaväärne tavalise FM-ringhäälingu helikvaliteediga ja 44KHz on samaväärne CD helikvaliteediga. Praegune ühine proovivõtusagedus ei ületa 48KHz.
2. Proovivõtubittide arv
See tähendab, et valimi väärtus või valimi väärtus (see tähendab, et valimi valimi amplituud kvantiseeritakse). See on parameeter, mida kasutatakse heli kõikumise mõõtmiseks, samuti võib öelda, et see on helikaardi eraldusvõime. Mida suurem on selle väärtus, seda suurem on eraldusvõime ja tugevam helivõimsus.
Arvutis on proovivõtubittide arv tavaliselt 8 bitti ja 16 bitti, kuid pange tähele, et 8 bitti ei tähenda ordinaadi jagamist 8 osaks, vaid jagatuna kaheksandaks astmeks, mis on 2 osa; sama kehtib 8 bitti kohta. See jagab ordinaadi kaheksandaks 256. astmele 16 2.
3. Kanalite arv
On lihtne mõista, et on monofoonilisi ja stereofoonilisi. Monofoonilist heli saab toota ainult üks kõlar (mõned töödeldakse sama kanaliheli väljastamiseks ka kaheks kõlariks) ja stereo-pcm suudab teha kahte kõlarit Mõlemad heli (vasakpoolse ja parema kanali vahel on tavaliselt tööjaotus), et saaksite rohkem tunda ruumilist efekti.
Nii saame nüüd pcm-faili mahtuvuse valemi:
Salvestusmaht = (proovivõtusagedus sam️ proovivõtubittide arv kanal time️ aeg) ➗ 8 (ühik: baitide arv)
Kui kogu heli edastatakse PCM-vormingus, on hõivatud ribalaius suhteliselt suur, mistõttu tuleb heli enne edastamist kodeerida.
Juba praegu on mõned laialt kasutatavad helivormingud, näiteks wav, MIDI, MP3, WMA, AAC, Ogg jne. Võrreldes pcm-vorminguga tihendavad need vormingud heliandmeid, mis võib vähendada edastuse ribalaiust.
Heli kodeerimise võib jagada ka kahte tüüpi: pehme kodeerimine ja karm kodeerimine. Pehmeks redigeerimiseks laadige alla vastav kodeerimisraamatukogu, kirjutage vastav jni ja sisestage seejärel andmed kodeerimiseks. Kõvakood kasutab Androidi enda pakutavat MediaCodecit.
Märkus. Järgmises artiklis kirjeldatakse konkreetselt, kuidas heli kodeerida
6, pakend
Video ja heli peavad edastamisprotsessi käigus määratlema vastava vormingu, et seda saaks vastaspoole edastamisel õigesti sõeluda.
1. HTTP-FLV
Veeb 2.0 ajastul on kõige populaarsemad veebisaitide tüübid loomulikult välismaalt pärit Youtube, Hiinas asuvad Youku ja Tudou veebisaidid. Selliste saitide pakutaval videosisul võib öelda, et sellel on omad eelised, kuid nad kõik kasutavad Flash-i eranditult video taasesituse kandjana. Neid videosaite toetav tehniline alus on Flash Video (FLV). FLV on uhiuus voogesituse meediumivideovorming, mis kasutab veebi lehtedel laialt levinud Flash Playeri platvormi video integreerimiseks Flash-animatsiooni. Teisisõnu, kuni veebisaidi külastajad saavad vaadata Flash-animatsioone, saavad nad loomulikult vaadata FLV-vormingus videoid ilma vajaduseta täiendavaid videopluginaid installida. FLV-videote kasutamine pakub video levitamisel suurt mugavust.
HTTP-FLV kapseldab heli- ja videoandmed FLV-sse ning edastab need seejärel kliendile HTTP-protokolli kaudu. Üleslaadijana tuleb serverisse edastada ainult FLV-vormingus video ja heli.
Üldiselt kasutavad FLV-vormingus video ja heli video jaoks tavaliselt h264-vormingut ning heli tavaliselt AAC-LC-vormingut.
FLV-vormingus tuleb kõigepealt edastada FLV päise teave, seejärel edastada metaandmed koos video- ja heliparameetritega (metaandmed), seejärel edastada video- ja heliparameetrite teave ning seejärel edastada video- ja heliandmed.
Märkus. Järgmises artiklis kirjeldatakse FLV-d üksikasjalikult
2. RTMP
RTMP on reaalajas sõnumside protokolli lühend. Protokoll põhineb TCP-l ja on protokolliklaster, mis sisaldab RTMP-põhiprotokolli ja RTMPT / RTMPS / RTMPE-d ning paljusid muid variante. RTMP on võrguprotokoll, mis on mõeldud reaalajas andmesideks. Seda kasutatakse peamiselt heli-, video- ja andmesideks Flash / AIR platvormi ja voogedastusmeedia / interaktiivse serveri vahel, mis toetab RTMP-protokolli.
RTMP-protokoll on Adobe käivitatud reaalajas edastamise protokoll, mida kasutatakse peamiselt heli- ja videovoogude reaalajas edastamiseks flv-vormingu põhjal. Pärast kodeeritud video- ja heliandmete hankimist on kõigepealt vaja FLV-pakendeid, mis seejärel pakitakse rtmp-vormingusse ja seejärel edastatakse.
RTMP-vormingu kasutamiseks edastamiseks peate kõigepealt ühendust serveriga looma, seejärel looma voo, seejärel voog avaldama ja seejärel edastama vastavad video- ja heliandmed. Kogu edastamine on määratletud sõnumitega, rtmp määratleb sõnumite erinevad vormid ning sõnumite korralikuks saatmiseks jagatakse sõnumid plokkideks, mis muudab kogu protokolli keerukamaks.
Märkus: aHilisemad artiklid kirjeldavad RTMP-d üksikasjalikult
Samuti on olemas veel mitu protokollivormi, näiteks RTP jne. Üldised põhimõtted on sarnased, nii et ma ei hakka neid ükshaaval selgitama.
7. võrgu halb töötlemine
Video ja heli saab hea võrgu ajal õigeaegselt saata, põhjustamata video- ja heliandmete kohalikku kogunemist, otseülekande efekt on sujuv ja viivitus on väike. Halvas võrgukeskkonnas peame heli- ja videoandmeid töötlema, kui heli- ja videoandmeid ei saa välja saata. Kehvas võrgukeskkonnas on video- ja heliandmete töötlemiseks üldiselt neli meetodit: puhvri kujundus, võrgu tuvastamine, kaadrikadu töötlemine ja bitikiiruse vähendamise töötlus.
1. Puhvri disain
Video- ja heliandmed kantakse puhvrisse ning saatja saab andmed puhvrist ja saadab need, moodustades seega asünkroonse tootja-tarbija režiimi. Tootjal on vaja vaid kogutud ja kodeeritud video- ja heliandmed puhvrisse lükata ning tarbija vastutab andmete puhvrist väljavõtmise ja saatmise eest.
Video- ja helipuhver
Ainult videokaader on näidatud ülaltoodud joonisel ja ilmselgelt on sees vastavad heliraamid. Asünkroonse tootja-tarbija mudeli loomiseks on Java pakkunud hea klassi. Kuna kaadri kadu, sisestamine, eemaldamine jms tuleb hiljem töödelda, on ilmne, et LinkedBlockingQueue on väga hea valik.
2. Võrgu tuvastamine
Oluline protsess võrgu halva töötlemise protsessis on võrgu tuvastamine. Kui võrk muutub kehvaks, saab selle kiiresti tuvastada ja seejärel vastavalt töödelda. See muudab võrgu reageerimise tundlikumaks ja mõju on palju parem.
Arvutame sisendpuhvris olevad andmed sekundis ja reaalajas välja saadetud andmed. Kui välja saadetud andmed on väiksemad kui sisendpuhvris olevad andmed, pole võrgu ribalaius hea. Praegu jätkub puhvris olevate andmete suurenemine. Aktiveerige vastav mehhanism.
3. Drop frame töötlemine
Kui tuvastatakse võrgu halvenemine, on kaadrikadu hea reageerimise mehhanism. Pärast video kodeerimist on võtmeraamid ja võtmevabad kaadrid. Võtmeraam on tervikpilt ja võtmevaba raamistik kirjeldab pildi suhtelist muutust.
Kaadri langemise strateegiat saab ise määratleda. Üks asi, mida tuleb märkida, on: kui soovite P-kaadreid (mitte võtmega kaadreid) visata, peate kõik võtmeta kaadrid kahe võtmekaadri vahele viskama, vastasel juhul tekivad mosaiigid. Raami kadumise strateegia kujundus varieerub sõltuvalt vajadustest ja saate selle ise kujundada.
4. Koodi vähendamise määr
Kui kodeerimiseks kasutatakse karmkodeerimist, võime Androidis kehvas võrgukeskkonnas muuta reaalajas kõvakodeerimise bitikiirust, et muuta otseülekanne sujuvamaks. Kui tuvastatakse, et võrgukeskkond on halb, võime kaadri langetamise ajal vähendada ka video- ja heli bitikiirust. Kui Androidi SDK versioon on suurem või võrdne 19, saate parameetrid edastada MediaCodecile, et muuta kõvakodeeritud andurite andmete bitikiirust.
Bundle bitrate = uus Bundle (); bitrate.putInt (MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bps * 1024);
mMediaCodec.setParameters (bitikiirus);
8. saata
Pärast mitmesugust töötlemist tuleb andmed lõpuks välja saata, see samm on suhteliselt lihtne. Kas see on HTTP-FLV või RTMP, kasutame ühenduse loomiseks TCP-d. Enne otseülekannet peate ühendama serveriga sokli kaudu, et kontrollida, kas saate serveriga ühenduse luua. Pärast ühenduse loomist kasutage seda soklit andmete serverisse saatmiseks ja pärast andmete saatmist sulgege pesa.
