3. col·lecció
L'adquisició inclou principalment dos aspectes: l'adquisició de vídeo i l'adquisició d'àudio. El vídeo és recollit per la càmera, que implica el funcionament rellevant de la càmera i el paràmetre de la càmera. A causa de les diferències en les càmeres de diversos fabricants de telèfons mòbils, hi ha algunes trampes en aquest sentit, que es descriuran a l'article sobre la càmera. L’àudio es recull a través d’un micròfon. Els micròfons de diferents telèfons mòbils admeten diferents taxes de mostreig d’àudio i, de vegades, l’àudio ha de ser cancel·lat per fer servir la funció de micròfon.
Punts clau de la tecnologia de captura de vídeo:
Comproveu si es pot utilitzar la càmera;
La imatge capturada per la càmera és horitzontal i cal girar la imatge capturada fins a cert punt abans de mostrar-la;
Hi ha una sèrie de mides d’imatges per triar quan la càmera captura. Quan la mida de la imatge capturada és incompatible amb la mida de la pantalla del telèfon mòbil, cal un processament especial;
La càmera del telèfon Android té una sèrie d'estats i el funcionament corresponent de la càmera ha d'estar en l'estat correcte;
Molts paràmetres de la càmera del telèfon Android tenen problemes de compatibilitat i aquests problemes de compatibilitat s’han de tractar millor.
Punts clau de la tecnologia de captura d'àudio:
Comproveu si es pot utilitzar el micròfon;
Necessiteu detectar el suport del telèfon mòbil per a una freqüència de mostreig d’àudio determinada;
En alguns casos, és necessari realitzar processos de cancel·lació de ressò a l’àudio;
Establiu la mida de memòria intermèdia correcta durant la captura d'àudio.
Nota: més endavant hi haurà un article especial sobre la col·lecció
4. processament
Processament de vídeo
La bellesa és ara gairebé una configuració estàndard del programari de transmissió en directe del telèfon mòbil. Després de l’embelliment, l’amfitrió té un aspecte més alt i és més atractiu per als fans. També hi ha algunes aplicacions d’emissió en directe d’Android que poden reconèixer la cara de l’amfitrió i afegir animacions divertides. Efectes especials, de vegades també hem d’afegir una filigrana al vídeo.
De fet, l’embelliment de vídeo i l’addició d’efectes especials es processen a través d’OpenGL. Hi ha GLSurfaceView a Android, que és similar a SurfaceView, però es pot representar amb Renderer. La textura es pot generar mitjançant OpenGL, SurfaceTexture es pot generar mitjançant l’identificador de textura i SurfaceTexture es pot lliurar a la càmera i, finalment, la pantalla de previsualització de la càmera i OpenGL es connecten a través de la textura, de manera que es poden realitzar una sèrie d’operacions a través d’OpenGL. .
Tot el procés d’embelliment no és més que generar una nova textura a través de la tecnologia FBO a OpenGL basada en la textura prevista per la càmera i, a continuació, utilitzar la nova textura per dibuixar l’onDrawFrame () al renderitzador. Afegir una filigrana consisteix primer a convertir una imatge en una textura i després utilitzar OpenGL per dibuixar. Afegir efectes especials de penjoll dinàmic és més complicat. En primer lloc, cal realitzar anàlisis algorítmiques per identificar les parts corresponents de la cara humana en funció de la imatge de vista prèvia actual i, a continuació, dibuixar les imatges corresponents a cada part corresponent. La realització de tot el procés és una mica difícil.
La figura següent és un diagrama de flux de tot el procés de bellesa:
Procés de bellesa
La imatge següent mostra molt bé els efectes de bellesa i animació.
Bellesa
Efectes d'animació i filigranes
Nota: hi haurà un article especial sobre OpenGL i la realització de tot el procés.
Processament d’àudio
En alguns casos, l'amfitrió ha d'afegir alguns sons addicionals per augmentar l'atmosfera de transmissió en directe, com ara aplaudiments, etc. Una manera d’afrontar-lo és reproduir el so addicional directament, de manera que el micròfon el reculli i el gravarà junts, però aquest tipus de processament no funcionarà quan l’àncora porti auriculars o necessiti realitzar un processament de cancel·lació de ressò al so. . Com que la funció corresponent no s'ha afegit al nostre projecte, no hi ha experiència rellevant per compartir de moment, és possible que afegim aquesta funció més endavant i la compartim amb vosaltres.
5. codificació
A través de la càmera i el micròfon, podem recollir les dades de vídeo i àudio corresponents, però es tracta de dades en brut en un format fix. En termes generals, la càmera recopila un fotograma per fotograma i el micròfon recopila dades d’àudio PCM. Si aquestes dades s’envien directament, la quantitat de dades sol ser molt gran, cosa que provoca una gran pèrdua d’amplada de banda, de manera que sovint és necessari codificar vídeo i àudio abans d’enviar-los.
Codificació de vídeo
1. Codificació predictiva
Com tots sabem, una imatge es compon de molts anomenats píxels. Un gran nombre d'estadístiques mostren que hi ha una forta correlació entre els píxels de la mateixa imatge. Com més curta sigui la distància entre dos píxels, més forta serà la correlació. En termes simples, com més propers siguin els valors dels dos píxels. Per tant, la gent pot utilitzar aquesta correlació entre píxels per realitzar codificacions de compressió. Aquest mètode de compressió s’anomena codificació de predicció intra-fotograma. No només això, la correlació entre fotogrames adjacents és generalment més forta que la correlació entre píxels dins d’un fotograma i la relació de compressió també és més gran. Es pot veure que mitjançant la correlació entre píxels (intra-fotograma) i la correlació entre fotogrames, és a dir, trobar el píxel de referència corresponent o fotograma de referència com a valor predit, es pot realitzar la codificació de compressió de vídeo.
2. Transformar la codificació
Un gran nombre d’estadístiques mostren que el senyal de vídeo conté els components de baixa freqüència i de CC de més intensitat energètica, és a dir, la part plana de la imatge i una petita quantitat de components d’alta freqüència, és a dir, els detalls de la imatge. Per tant, es pot utilitzar un altre mètode per a la codificació de vídeo. Després que la imatge experimenti una determinada transformació matemàtica, s'obté la imatge del domini transformat (com es mostra a la figura), on u i v són les coordenades de freqüència espacial respectivament.
Codificació de transformació
3. Codificació basada en formes d'ona
La codificació basada en formes d’ona utilitza un mètode de codificació híbrida basat en blocs que combina codificació predicta i codificació de transformació. Per tal de reduir la complexitat de la codificació i facilitar l’operació de codificació de vídeo, quan s’utilitza el mètode de codificació híbrida, primer es divideix una imatge en blocs de mida fixa, com ara el bloc 8 × 8 (és a dir, 8 files per bloc, 8 píxels per fila), bloc 16 × 16 (16 línies per bloc, 16 píxels per línia), etc., i després comprimir i codificar el bloc.
Des que l’UIT-T va publicar el primer estàndard de codificació de vídeo digital-H.261 el 1989, ha publicat successivament estàndards de codificació de vídeo com ara H.263 i estàndards de terminals multimèdia com H.320 i H.323. El Moving Picture Experts Group (MPEG) segons ISO ha definit MPEG-1, MPEG-2, MPEG-4 i altres programes d’entreteniment i compressió de TV digital que codifiquen els estàndards internacionals.
El març de 2003, l'UIT-T va promulgar l'estàndard de codificació de vídeo H.264. No només millora significativament la compressió de vídeo en comparació amb els estàndards anteriors, sinó que també té una bona afinitat de xarxa, especialment per a Internet IP, xarxa mòbil sense fils i altres prestacions de transmissió de vídeo de xarxa fàcils d’error, fàcils de bloquejar i que no garanteixen QoS . . Totes aquestes codificacions de vídeo utilitzen codificació híbrida basada en blocs, que són totes codificacions basades en formes d'ona.
4. Codificació basada en el contingut
També hi ha una tecnologia de codificació basada en el contingut, on el fotograma de vídeo es divideix primer en regions corresponents a diferents objectes i després es codifica. En concret, codifica la forma, el moviment i la textura de diferents objectes. En el cas més senzill, s’utilitza un esquema bidimensional per descriure la forma d’un objecte, s’utilitza un vector de moviment per descriure el seu estat de moviment i una textura es descriu mitjançant una forma d’ona de color.
Quan es coneixen els tipus d'objectes de la seqüència de vídeo, es pot utilitzar una codificació basada en el coneixement o basada en models. Per exemple, per a rostres humans, s’han desenvolupat alguns filferros predefinits per codificar les característiques de la cara. En aquest moment, l'eficiència de codificació és molt alta i només es necessiten uns quants bits per descriure les seves característiques. Per a les expressions facials (com ara enfadades, felices, etc.), les conductes possibles es poden codificar per semàntica. Com que el nombre de comportaments possibles d'un objecte és molt petit, es pot obtenir una eficiència de codificació molt alta.
El mètode de codificació adoptat per MPEG-4 és tant codificació híbrida basada en blocs com codificació basada en contingut.
5. Teixit suau i dur
Hi ha dues maneres d'implementar la codificació de vídeo a la plataforma Android, una és la codificació suau i l'altra és la codificació dura. Per a l’edició suau, sovint es basa en la CPU i utilitza la potència de càlcul de la CPU per realitzar la codificació. Per exemple, podem descarregar la biblioteca de codificació x264, escriure la interfície jni corresponent i després passar les dades d'imatge corresponents. Després de ser processada per la biblioteca x264, la imatge original es converteix en un vídeo en format h264.
El codi dur utilitza el MediaCodec proporcionat pel propi Android. Per utilitzar MediaCodec, heu de passar les dades corresponents. Aquestes dades poden ser informació de la vostra imatge o una superfície. Generalment es recomana la superfície, que és més eficient. Surface utilitza directament memòries intermèdies de dades de vídeo locals sense mapar-les ni copiar-les a ByteBuffers; per tant, aquest enfocament serà més eficient. Quan utilitzeu Surface, normalment no podeu accedir directament a les dades de vídeo originals, però podeu utilitzar la classe ImageReader per accedir a marcs de vídeo descodificats (o originals) no fiables. Pot ser que això sigui encara més eficient que utilitzar ByteBuffers, ja que alguns buffers locals es poden assignar a ByteBuffers directes. Quan utilitzeu el mode ByteBuffer, podeu utilitzar la classe Image i els mètodes getInput / OutputImage (int) per accedir al marc de dades de vídeo original.
Nota: L'article següent descriu específicament com es realitza la codificació de vídeo
Codificació d'àudio
AudioRecord es pot utilitzar a Android per gravar so i el so enregistrat és PCM. Si voleu expressar el so en llenguatge informàtic, heu de digitalitzar el so. La forma més comuna de digitalitzar el so és mitjançant la modulació del codi de pols (PCM). El so passa pel micròfon i es converteix en una sèrie de senyals de canvis de tensió. La forma de convertir aquest senyal en format PCM consisteix a utilitzar tres paràmetres per representar el so. Són: el nombre de canals, el nombre de bits de mostreig i la freqüència de mostreig.
1. Freqüència de mostreig
És a dir, la freqüència de mostreig, que fa referència al nombre de vegades que s’obté una mostra sonora per segon. Com més alta sigui la freqüència de mostreig, millor serà la qualitat del so i la reproducció del so serà més realista, però al mateix temps ocupa més recursos. A causa de la resolució limitada de l’oïda humana, no es pot distingir una freqüència massa alta. Hi ha 22 KHz, 44 KHz i altres nivells en targetes de so de 16 bits. Entre ells, 22 KHz equival a la qualitat del so de la transmissió FM ordinària i 44 KHz equival a la qualitat del so dels CD. La freqüència de mostreig comuna actual no supera els 48 KHz.
2. Nombre de bits de mostreig
És a dir, el valor de mostreig o valor de mostreig (és a dir, es quantifica l’amplitud de la mostra de mostreig). És un paràmetre utilitzat per mesurar la fluctuació del so, i també es pot dir que és la resolució de la targeta de so. Com més gran sigui el seu valor, més alta serà la resolució i més forta serà la potència sonora.
A l'ordinador, el nombre de bits de mostreig és generalment de 8 i 16 bits, però tingueu en compte que 8 bits no vol dir dividir l'ordenada en 8 parts, sinó dividir-la en 2 a la 8a potència, que és de 256 parts; el mateix passa amb 16 bits. Divideix l'ordenada en 2 fins al 16è poder de 65,536.
3. Nombre de canals
És fàcil d’entendre que n’hi ha de monofònics i estereofònics. El so monofònic només es pot produir per un altaveu (alguns també es processen en dos altaveus per emetre el mateix canal de so) i el pcm estèreo pot produir dos altaveus. Tots dos sonen (generalment hi ha una divisió del treball entre els canals esquerre i dret), de manera que pugueu sentir més l’efecte espacial.
Per tant, ara podem obtenir la fórmula per a la capacitat del fitxer pcm:
Capacitat d'emmagatzematge = (freqüència de mostreig ✖️ nombre de bits de mostreig ✖️ canal ✖️ temps) ➗ 8 (unitat: nombre de bytes)
Si l’àudio es transmet tot en format PCM, l’amplada de banda ocupada és relativament gran, de manera que l’àudio s’ha de codificar abans de la transmissió.
Ja hi ha alguns formats de so àmpliament utilitzats, com ara wav, MIDI, MP3, WMA, AAC, Ogg, etc. En comparació amb el format pcm, aquests formats comprimeixen les dades de so, cosa que pot reduir l’amplada de banda de la transmissió.
La codificació d'àudio també es pot dividir en dos tipus: codificació suau i codificació dura. Per a una edició suau, descarregueu la biblioteca de codificació corresponent, escriviu el jni corresponent i, a continuació, passeu les dades per codificar-les. El codi dur utilitza el MediaCodec proporcionat pel propi Android.
Nota: L'article següent descriurà específicament com es realitza la codificació d'àudio
6, envasos
El vídeo i l'àudio han de definir el format corresponent durant el procés de transmissió, de manera que es pugui analitzar correctament quan es transmeti a l'extrem oposat.
1. HTTP-FLV
A l'era del Web 2.0, els tipus de llocs web més populars són, naturalment, Youtube des de l'estranger, els llocs web Youku i Tudou a la Xina. Es pot dir que el contingut de vídeo proporcionat per aquests llocs té els seus propis mèrits, però tots utilitzen Flash com a operador de reproducció de vídeo sense excepció. La base tècnica que dóna suport a aquests llocs de vídeo és Flash Video (FLV). FLV és un nou format de vídeo multimèdia que utilitza la plataforma Flash Player àmpliament utilitzada a les pàgines web per integrar el vídeo a l'animació Flash. Dit d’una altra manera, sempre que els visitants del lloc web puguin veure animacions Flash, poden veure vídeos de format FLV sense necessitat d’instal·lar connectors de vídeo addicionals. L’ús de vídeos FLV aporta una gran comoditat a la difusió de vídeos.
HTTP-FLV encapsula les dades d'àudio i vídeo a FLV i les transmet al client mitjançant el protocol HTTP. Com a usuari de càrrega, només cal transmetre el vídeo i l'àudio en format FLV al servidor.
En termes generals, el vídeo i l'àudio en format FLV solen utilitzar el format h264 per al vídeo, i l'àudio en general utilitza el format AAC-LC.
El format FLV és transmetre primer la informació de la capçalera FLV, després transmetre les metadades amb els paràmetres de vídeo i àudio (Metadades), després transmetre la informació dels paràmetres de vídeo i àudio i, a continuació, transmetre les dades de vídeo i àudio.
Nota: L'article següent descriurà FLV amb detall
2. RTMP
RTMP és l'acrònim de Protocol de missatgeria en temps real. El protocol es basa en TCP i és un clúster de protocols, que inclou el protocol bàsic RTMP i RTMPT / RTMPS / RTMPE i moltes altres variants. RTMP és un protocol de xarxa dissenyat per a la comunicació de dades en temps real. S’utilitza principalment per a la comunicació d’àudio, vídeo i dades entre la plataforma Flash / AIR i un servidor multimèdia / interactiu que admet el protocol RTMP.
El protocol RTMP és un protocol de transmissió en temps real llançat per Adobe, que s’utilitza principalment per a la transmissió en temps real de fluxos d’àudio i vídeo basats en el format flv. Després d’obtenir les dades d’àudio i vídeo codificats, primer es requereix l’empaquetatge FLV i, a continuació, empaquetat en format rtmp i, posteriorment, es transmet.
Per utilitzar el format RTMP per a la transmissió, primer heu de connectar-vos al servidor, després crear un flux, publicar el flux i, a continuació, transmetre les dades de vídeo i àudio corresponents. Tota la transmissió es defineix mitjançant missatges, rtmp defineix diverses formes de missatges i, per enviar-los bé, els missatges es divideixen en blocs, cosa que fa que tot el protocol sigui més complicat.
Nota: articles posteriors descriuran RTMP amb detall
També hi ha diverses altres formes de protocols, com ara RTP, etc. Els principis generals són similars, de manera que no els explicaré un per un.
7. processament de xarxa deficient
El vídeo i l’àudio es poden enviar a temps amb una bona xarxa, sense provocar l’acumulació de dades de vídeo i àudio a nivell local, l’efecte de transmissió en directe és suau i el retard és petit. En un entorn de xarxa deficient, si no es poden enviar les dades d'àudio i vídeo, hem de processar les dades d'àudio i vídeo. Generalment hi ha quatre mètodes de processament de dades de vídeo i àudio en un entorn de xarxa deficient: disseny de memòria intermèdia, detecció de xarxa, processament de pèrdues de trames i processament de reducció de velocitat de bits.
1. Disseny de memòria intermèdia
Les dades de vídeo i àudio es transfereixen a la memòria intermèdia i l’emissor obté les dades de la memòria intermèdia i les envia, formant així un mode productor-consumidor asíncron. El productor només ha d’enviar les dades de vídeo i àudio recollides i codificades a la memòria intermèdia, i el consumidor és responsable de treure les dades de la memòria intermèdia i enviar-les.
Memòria intermèdia de vídeo i àudio
A la figura superior només es mostra el marc de vídeo i, òbviament, hi ha els marcs d’àudio corresponents. Per crear un model asíncron de productor-consumidor, Java ha proporcionat una bona classe. Atès que la pèrdua, inserció, eliminació, etc. de fotogrames s’ha de processar més endavant, és obvi que LinkedBlockingQueue és una molt bona opció.
2. Detecció de xarxa
Un procés important en el procés de processament deficient de la xarxa és la detecció de xarxa. Quan la xarxa es fa pobra, es pot detectar ràpidament i processar-la en conseqüència. Això farà que la resposta de la xarxa sigui més sensible i l’efecte sigui molt millor.
Calculem les dades del buffer d’entrada per segon i les dades enviades en temps real. Si les dades enviades són més petites que les dades del buffer d’entrada, l’amplada de banda de la xarxa no és bona. En aquest moment, les dades del buffer continuaran augmentant. Activeu el mecanisme corresponent.
3. Processament de marcs de caiguda
Quan es detecta la degradació de la xarxa, la pèrdua de trames és un bon mecanisme de resposta. Després de codificar el vídeo, hi ha fotogrames clau i fotogrames no clau. El marc clau és una imatge completa i el marc no clau descriu el canvi relatiu de la imatge.
L'estratègia de caiguda del marc es pot definir per si mateixa. Una cosa a tenir en compte és: si voleu deixar anar fotogrames P (fotogrames no clau), heu de deixar anar tots els fotogrames no clau entre els dos fotogrames clau, en cas contrari es produiran mosaics. El disseny de l’estratègia de pèrdua de fotogrames varia en funció de les necessitats i el podeu dissenyar vosaltres mateixos.
4. Taxa de reducció del codi
A Android, si s’utilitza la codificació dura per a la codificació, en un entorn de xarxa deficient, podem canviar la velocitat de bits de la codificació dura en temps real per fer que la transmissió en directe sigui més suau. Quan es detecta que l’entorn de la xarxa és pobre, també podem reduir la velocitat de bits de vídeo i àudio mentre deixem de banda. Quan la versió d'Android sdk sigui superior o igual a 19, podeu passar paràmetres a MediaCodec per canviar la velocitat de bits de les dades del codificador de codi dur.
Taxa de bits del paquet = paquet nou (); bitrate.putInt (MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bps * 1024);
mMediaCodec.setParameters (taxa de bits);
8. enviar
Després de diversos processos, les dades s'han d'enviar finalment, aquest pas és relativament senzill. Ja sigui HTTP-FLV o RTMP, fem servir TCP per establir una connexió. Abans de la transmissió en directe, heu de connectar-vos al servidor mitjançant el sòcol per verificar si podeu connectar-vos al servidor. Després de la connexió, utilitzeu aquest sòcol per enviar dades al servidor i tanqueu el sòcol després d’enviar-les.
