PAC 2

EXERCICI 1 – Clip de vídeo incrustat en HTML5

Tasca 1.1. Tria un clip de vídeo de màxim 20 segons (pots crear-lo amb el teu dispositiu mòbil, que tingui objectes en detall i en moviment) i codifica’l amb Avidemux triant el format i resolució que creguis adients per a la seva publicació en web. Tenint en compte que no tots els navegadors accepten tots els còdecs, codifica el vídeo en els formats necessaris per tal què sigui compatible amb el màxim de navegadors possible. Explica les decisions preses en la codificació i el perquè de cadascuna. 

Dintre de les especificacions HTML5 hi ha un nou estàndard definit per a inserir i reproduir vídeo dintre d’una pàgina web, sense la necessitat d’un complement de tercers, utilitzant l’etiqueta <vídeo>. Tot i això, és important destacar que no existeix un únic format de vídeo que funcioni en tots els navegadors HTML5 i probablement això no canviï a curt termini. [2]

Figura 1. Compatibilitats: HTML5 <video> i format en els diferents navegadors.

A continuació s’explica breument cada format: [3]

  • Theora + Vorbis + Ogg:El format contenidor Ogg amb el còdec de vídeo Theora i el còdec d’audio Vorbis és compatible amb Gecko (Firefox), Chrome i Opera, i el suport per al format es pot agregar a Safari mitjançant la instal·lació d’un add-on. El format no es compatible amb Internet Explorer. Tot i això, és important destacar que WebM es preferent, generalment sobre Theora Ogg Vorbis quan estigui disponible, ja que proporciona una millor relació de compressió per a la qualitat i té suport en més navegadors. El format Ogg, sol ser utilitzat per donar suport a les versions més antigues dels navegadors en les que encara no hi ha suport per a WebM.
  • H.264 + ACC + MP4:El format contenidor MP4 amb el còdec de vídeo H.264, o bé amb el còdec d’audio AAC o bé el còdec d’audio MP3, es nativament compatible amb Internet Explorer, Safari i Chrome, però amb Chromium i Opera no és compatible el format. Firefox aviat permetrà el format, però només quan un decodificador de tercers estigui disponible.
  • WebM:El format WebM es basa en una versió restringida del format contenidor Matroska. Sempre utilitza el còdec de vídeo VP8 i el còdec de audio Vorbis. WebM es suportat nativament en Gecko (Firefox), Chrome i Opera, i el suport per al format es pot agregar a Internet Explorer i Safari mitjançant un add-on. 

Vist això, és important destacar que Avidemux només permet codificar el vídeo amb el format H,264 + ACC + MP4.

A continuació s’adjunta una captura de pantalla referent a les propietats del clip01.mp4.

Figura 2. Propietats clip1.mp4 (Avidemux)

Per altre banda, tot i que no ho especifica la PAC, s’ha optat també per a codificar el vídeo a través de Premiere (utilitzant certs plugins: Theora – http://fnordware.blogspot.com/2013/12/webm-and-theora-plug-ins-for-premiere.htmli WebM – http://www.fnordware.com/WebM/) per tal d’obtenir els formats Theora + Vorbis + Ogg i WebM.

A continuació es mostra la configuració dels formats:

Figura 3. Configuració del clip.ogv

Figura 4. Configuració del clip1.webm (1)

Figura 5. Configuració del clip1.webm (2)

Tasca 1.2. Crea la web. Genera un fitxer .html mitjançant un editor de text, incrusta-li el clip de vídeo codificat utilitzant el tag <video>d’HTML5 i prepara la web perquè pugui ser visualitzada des de la major part dels navegadors. Quines característiques es poden destacar de la publicació i visualització d’un vídeo en HTML5 respecte d’altres mètodes de publicació? 

El codi HMTL5 utilitzat és el que es presenta tot seguit. 

Figura 6. Clip1 incrustat utilitzant tag <video>

Utilitzant l’etiqueta <source>dintre de l’etiqueta <vídeo> es permet poder indicar totes les fonts dels vídeos en els diferents formats. D’aquesta manera, cada navegador visualitzarà el vídeo fent ús del format o còdec que li es adient.

A continuació, es mostra una captura d’exemple des d’un dels navegadors:

Figura 7. clip1 en Microsft Edge

Respecte a les característiques que es poden destacar de la publicació i visualització d’un vídeo en HTML5 respecte d’altres mètodes de publicació es pot dir: [8]

  • ADOBE FLASH:
    • Les seves característiques són madures i conegudes per els desenvolupadors. A més, són adoptades per a la majoria dels navegadors heretats, amb tecnologia consistent en totes les plataformes del navegador.
    • Requereix el complement Adobe Flash Player per a poder funcionar. 
    • Té problemes de seguretat.
    • Pateix bloqueigs freqüents.
    • Els navegadors més nous ja no son compatibles amb Flash Player i el suport per a navegadors mòbils s’ha eliminat per complet.
    • Incompatibilitat amb iOS.
    • Redueix la vida útil de la bateria en els dispositius mòbils. 
  • HTML5:
    • És un llenguatge de codi obert.
    • És amigable amb SEO.
    • Pot admet tecnologies similars a Flash.
    • És una interfície amb evolució.
    • Adobe Canvas permet dibuixar gràfics, fer collages de fotos, animacions, renderitzar vídeos a temps real amb JavaScript…
    • Té un manteniment menor.
    • És més segur que Flash.
    • És compatible amb iOS i amb Android. 
    • Permet la interoperabilitat.
    • Requereix menys potència de processament derivat al seu marc.
    • Té diverses opcions d’emmagatzemament.
    • Les tendes d’aplicacions no reconeixen HTML5.
    • Té menys capacitats fora de línia. 
    • No és totalment compatible amb tots els navegadors principals.

Per altre banda, HTML5 permet inserir vídeos que no estan carregats en el propi servidor utilitzant codi d’inserció des de Youtube, Vimeo, o d’altres… Aquest tipus de plataformes garanteixen la compatibilitat de contingut amb els navegadors més comuns, aconseguint una correcta visualització en la majoria de dispositius. Amb l’allotjament extern dels vídeos, la càrrega de transmissió no recau sobre el propi servidor… [9]

Tasca 1.3. Publica el fitxer .html i el vídeo en un servidor web per tal de veure-la amb una adreça http pública i torna a analitzar les seves característiques. Si no tens cap servidor web, pots utilitzar qualsevol dels hostings gratuïts que existeixen a Internet. 

Donat que en l’actualitat la estudiant disposa d’un hosting i domini propi, a través de 1&1, es procedeix a pujar els fitxers pac2_tasca1.html i la carpeta VIDEOS a través de Filezilla.

Figura 8. Pujada de fitxers a través de Filezilla al Hosting propi

La URL és la següent: https://escaperoomlife.com/pac2_tasca1

Tasca 1.4. Afegeix funcionalitat al vídeo mitjançant els diferents atributs que el tag <vídeo> ofereix. Experimenta!. Dona’m l’adreça web del vídeo per poder-lo visualitzar. 

A continuació s’explicaran els diferents atributs utilitzats de l’etiqueta <video>. 

Figura 9. Atributs utilitzats en <video>

Els atributs utilitzats han sigut: [4]

  • src (etiqueta source):Serveix per a especificar la URL/path del vídeo que es vol reproduir.
  • width i height:Permet especificar l’ample i alt del vídeo per a mostrar-se a la web.
  • controls:Permet especificar si es mostren o no els típics controls del vídeo (stop, play, volum…).
  • autoplay:Amb aquest atribut es pot especificar que el vídeo comenci automàticament a reproduir-se al carregar la pàgina. No obstant hi ha certs navegadors que no permeten això, com per exemple Chrome, ja que Google va decidir que era molest que al accedir a una web estigués un vídeo reproduint-se automàticament… [5] Per això, es convenient revisar les polítiques de reproducció automàtiques.
  • loop:Permet especificar la reproducció continua del vídeo, en bucle. Una vegada finalitzada la reproducció comença de nou a reproduir-se.  
  • poster:Permet especificar una imatge (URL) a mostrar quan el vídeo no està disponible, està carrgant o bé no ha començat la seva reproducció. Per defecte, és el primer frame del vídeo.

Per altre banda, hi ha més atributs com són:[4]

  • preload:Serveix per a especificar si es pretén que el vídeo es vagi carregant independentment de donar-li al play o no. Això augmenta el consum d’ample de banda però l’usuari tindrà menys talls en la reproducció. (es pot configurar com: none, metadata, auto).
  • muted:Aquesta funcionalitat serveix per a treure el volum del vídeo.
  • mediagroup:Estableix un grup de reproducció al que pertany el vídeo.

EXERCICI 2 – Streaming d’un vídeo

Tasca 2.1. Genera un clip de vídeo de qualitat HD d’uns 20 segons de durada (o descarrega’l de la web) que posseeixi moviment (quelcom equivalent al clip de futbol que he usat d’exemple). 

Com segurament no serà Flash Video, converteix-lo amb Avidemux i l’anomenarem clip01. La codificació de sortida és FLV1 (flash) i a VIDEO OUTPUT-CONFIGURACIÓ selecciona com a mode de codificació DOS PASADAS-BITRATE MEDIO (per mantenir la qualitat) i 5000 Kbps. Com format d’àudio, MP3 (lame) i com a contenidor, AVI. Inclou aquests clips en el lliurament de la pràctica. 

En primer lloc, donat que el vídeo realitzat per a la part 1 de la pràctica (que presenta un objecte en moviment) és en qualitat HD, és decideix continuar fent la part 2 de la pràctica amb aquest mateix vídeo… 

Per a saber que era un vídeo amb qualitat HD, es van revisar les propietats del vídeo: Tamaño de la imagen: 1920×1080 píxels. La alta definició, més coneguda com HD o HQ, és un sistema d’imatge, vídeo o so amb major resolució que la estàndard, aconseguint resolucions de 1280×720 píxels i 1920×1080 píxels [6].

A continuació es mostren captures de la configuració del vídeo amb Avidemux:

Figura 10. Conversió a Flashvideo del clip01.

Per a configurar el mode de codificació a “DOS PASADAS – TASA DE BITS MEDIA” a 5000 Kbps s’ha d’accedir al botó Configurar (una vegada seleccionada la sortida del vídeo FLV1 (flash)) i a la pestanya “Interfaz de usuario” serà necessari seleccionar la opció desitjada del desplegable de “Modo de codificación”. A més, s’ha de configurar el número de Kbps (per defecte està en 1500) a 5000.

La resta de paràmetres de configuració (sortida audio i format sortida) és deixen amb la configuració per defecte.

Tasca 2.2. Configura una emissió repetitiva i una recepció del clip01 amb els mateixos valors emprats al clip de futbol. Al VLC d’emissió, menú EINES-INFORMACIÓ DEL CÓDEC-CÓDEC (a Mac: FINESTRA- INFORMACIÓ MULTIMÈDIA-DETALLS DEL CÓDEC), indica els códecs amb els quals diu que es va generar el fitxer emmagatzemat. A ESTADÍSTIQUES indica la TAXA DE BITS DE CONTINGUT que està llegint de disc, és la necessària per a una reproducció correcta del contingut (és un valor canviant, de manera que pren un valor mitjà aproximat). 

En primer lloc es configura l’emissió repetitiva i la recepció del clip01, segons els valors emprats al cas d’exemple (clip de futbol). A continuació es deixa una imatge de l’emissió i recepció:

Figura 11. Emissió i recepció (VLC) del clip01

Seguidament es mostra la informació del còdec i les estadístiques (del VLC d’emissió):

Figura 12. Informació del còdec (VLC emissió)

Veiem com surten els valors que s’han configurat anteriorment amb el Avidemux.

Figura 13. Estadístiques (VLC emissió)

Tot i que a la imatge s’observa una taxa de bits de contingut de 6090 kb/s, realment aquest valor oscil·la entre entre 3800 kb/s i 6300 kb/s aproximadament. Tot i això, en el segon “0” de l’engegada del vídeo hi ha un pic d’uns 7000 kb/s aproximadament. 

Figura 14. Inicialització de la emissió del vídeo (clip01)

Tasca 2.3. al VLC de recepció, mitjançant EINES-INFORMACION DEL CODEC-CÓDEC (a Mac: FINESTRA-INFORMACIÓ MULTIMÈDIA-DETALLS DEL CÓDEC) confirma que el stream està codificat en els formats de vídeo i àudio seleccionats. A ESTADÍSTIQUES indica la TAXA DE BITS DE CONTINGUT a la qual està arribant el stream (pren un valor mitjà aproximat). 

Seguidament es mostren captures de pantalla de la informació del còdec i les estadístiques del vídeo (del VLC de recepció):

Figura 15. Informació del còdec (VLC recepció)

Com s’ha transcodificat (a través de l’emissió) el vídeo, podem veure com a la recepció del VLC el còdec de vídeo es H264 i el d’audio és MPEG Audio layer 1/2 (mpga).

Figura 16. Estadístiques (VLC recepció)

Per altre banda, la tasa de bits del contingut oscil·la però no tan bruscament com la observada a la del VLC emissió. Tot i que, aproximadament, oscil·la entre els 3000 kb/s i 6000 kb/s quan engega el vídeo aquest valor baixa bruscament anant-se a valors de 1000 kb/s aproximadament. 

Figura 17. Inicialització de la recepció del vídeo (clip01)

Tasca 2.4. si realitzes una pausa en el VLC emissor, quants segons triga en pausar-se el vídeo al receptor? Per què? Torna-ho a posar en reproducció. 

Quan es realitza una pausa en l’emissor en el VLC es pot detectar un retràs (delay) entre la pausa realitzada al emissor i la pausa del receptor. Concretament, fent la prova cinc vegades s’han detectat els següents valors de retràs: 2,86 s – 2,63 s – 1,95 s – 5,15 s – 5,25 s – 1,87 s. 

A mode de comentaris: 

– S’escull el segon 14 s en el emissor per a fer totes les proves (correspon al moviment del rotulador).

– Entre la segona i tercera prova es va haver de reiniciar el VLC derivat a que es va quedar penjat.

– Entre la tercera i la quarta es van deixar bastants minuts entre prova i prova (ja que es van fer més parades entre tercera i quarta però no es va enganxar correctament el segon de pausa del receptor).

– Entre la cinquena i la sisena prova es va tornar a reiniciar al veure que els valors eren molt alts.

Com es pot veure, s’observa que rere engegar el programa VLC sembla que el comportament entre el delay de la pausa a l’emissor i la pausa real del receptor és molt menor, en canvi quan el vídeo (en bucle) porta molta estona reproduint-se s’aprecia com aquest delay puja i a priori sembla com el VLC es queda com mig penjat…

Pel que respecta al retràs observat es pot dir que és principalment degut a que, tot i que es para el vídeo al Emissor, encara hi ha transferència de dades que s’havien enviat al receptor i que encara no havien arribat. És a dir, el receptor encara segueix rebent paquets que havia enviat el emissor previ a l’atur del vídeo. 

A més, tal i com podem veure a la següent imatge, podem veure com el client emmagatzema part del vídeo abans de l’inici de la reproducció, això permet evitar la parada del vídeo derivat a latències variables. En el cas de que el buffer es buidi el vídeo es pararà [10]. Per tant, fins a que no es buida el buffer, tot i que s’havia parat la transferència del vídeo al emissor, no s’aturarà.

Figura 18. Streaming: emmagatzemament en buffer del client [X]

Per altre banda, a mode comentari, es pot dir que l’ús de la CPU de l’ordinador està al 70% (aprox) i la temperatura estava aproximadament a 100 ºC durant l’streaming. Això pot estar afectant a que quan porta molta estona engegat l’streaming es produeixi un retard major entre pausa del emissor i pausa del receptor derivat a que probablement l’ordinador té més problemes per a gestionar totes aquestes tasques… A més, l’emissor i el receptor estan en el mateix ordinador i probablement si estiguessin en ordinadors diferents hi hauria un comportament més favorable.

Tasca 2.5. Calcula aproximadament la compressió que el VLC d’emissió està realitzant al transcodificar el fitxer emmagatzemat a stream en format H.264. Realitza una captura de pantalla de l’escriptori amb els dos VLC en marxa i les seves finestres amb les estadístiques de cadascun obertes, i insereix la captura en el document en el qual escrius les respostes d’aquesta pràctica. 

En primer lloc, es mostra la captura en la qual es pot veure les estadístiques de cadascun dels VLC (emissor – esquerra i receptor-dreta).

Figura 19. Estadístiques del emissor i receptor (1)

Per a calcular el factor de compressió, serà necessari fer la següent operació:

Com en l’exercici ens demanen la compressió que el VLC d’emissió està realitzant al transcodificar el fitxer emmagatzemat a stream en format H.264 serà necessari dividir la “Tasa de bits del contenido” del emissor entre la “Tasa de bits del contenido” del receptor.

Figura 20. Estadístiques del emissor i receptor (2)

Figura 21. Estadístiques del emissor i receptor (3)

En aquest cas, es pot veure que els factors de compressió són variables tot i que donen valors propers entre ells (aprox de 0,9 – 1,6). Concretament, al exercici no es modifica la velocitat de transmissió (era la que tenia configurada el vídeo a través d’Avidemux – 5000 kbps) i el que si que es fa es una transcodificació de Flash Video a H.264.

A mode de definició, la transcodificació permet efectuar conversions de un format digital a un altre format digital, per exemple convertir de format flash a un vídeo .mp4… [11]. H.264 permet una compressió millor que el Flash Video, tal i com es pot veure.

Tasca 2.6. realitza la pràctica seleccionant en el VLC emissor altre contenidor, ASF/WMV (Windows Media Video). Es detecta algun canvi en la qualitat de la imatge o del so respecte l’anterior? Per què? 

Rere canviar en el VLC emissor el contenidor ASF/WMV (Windows Media Video) es detecta que la qualitat de la imatge és molt pitjor que en el cas anterior (molt pixelada, es talla la imatge quan hi ha moviment, molts punts verds a tota la pantalla en general en bastants ocasions, etc) i respecte al so també es pot dir que es nota una pitjor qualitat (i so entretallat).

A continuació s’adjunten diverses per a veure diferencies referencies respecte a la qualitat de la imatge:

Figura 22. Reproducció amb encapsulació ASF/WMV (1)

Figura 23. Reproducció amb encapsulació ASF/WMV (2)

Figura 24. Reproducció amb encapsulació ASF/WMV (3)

Figura 25. Reproducció amb encapsulació MP4/MOV (1)

Figura 26. Reproducció amb encapsulació MP4/MOV (2)

Tot i això amb la configuració d’encapsulament MP4/MOV també hi ha algun moment on el vídeo es veu malament (a nivell de qualitat) però en comparació és força pitjor amb l’encapsulament ASF/WMV.

Per altre banda, si es revisa el factor de compressió podem veure que és molt variable:

Figura 27. Estadístiques encapsulació ASF/WMV (1)

Figura 28. Estadístiques encapsulació ASF/WMV (2)

Figura 29. Estadístiques encapsulació ASF/WMV (3)

Pel que fa a la pitjor qualitat del vídeo, en primer lloc dir que WMV és un tipus d’arxiu desenvolupat per Microsoft i que pot contenir vídeo en un dels diversos formats de compressió de vídeo. A nivell comparatiu, MP4 presenta una millor qualitat de vídeo i compressió que WMV [12]. Com es pot veure, el factor de compressió es menor que l’obtingut anteriorment quan es feia la transcodificació de .avi a .mp4, per tant un altre factor important es tenir en compte que quant “més pesa el vídeo” més requeriments (més paquets que s’han d’enviar) faran falta per a que el vídeo es vegi correctament.

Tasca 2.7. torna a seleccionar el contenidor que teníem (H.264+MP3), modifica la velocitat de vídeo a 2000 kbps, 500 kbps i 200 kbps (la d’àudio no la modifiquis) (a Mac cal refer la configuració de l’emissor). Fes una captura de pantalla dels dos VLC amb les seves finestres d’estadístiques obertes en els tres casos i copia-les en el document de la pràctica. En baixar la velocitat de transmissió fixada, de quina manera visual es reflecteix la pèrdua de qualitat? 

A continuació es mostren les captures corresponents als tres casos diferents. S’ha decidit fer dues captures o proves per a cada velocitat.

  • 2000 kbps

Figura 30. Estadístiques (emissor i receptor) – 2000 kbps (1)

Figura 31. Estadístiques (emissor i receptor) – 2000 kbps (2)

A continuació, es calcula el factor de compressió de la primera imatge de 2000 kbps:

  • 500 kbps

Figura 32. Estadístiques (emissor i receptor) – 500 kbps (1)

Figura 33. Estadístiques (emissor i receptor) – 500 kbps (2)

A continuació, es calcula el factor de compressió de la primera imatge de 500 kbps:

  • 200 kbps

Figura 34. Estadístiques (emissor i receptor) – 200 kbps (1)

Figura 35. Estadístiques (emissor i receptor) – 200 kbps (2)

A continuació, es calcula el factor de compressió de la primera imatge de 200 kbps:

El vídeo configurat amb la velocitat de transmissió de 200 kbps és veu molt “pixelat”, sobre tot, quan hi ha moviment. No s’aprecia tant la pèrdua de qualitat quan el vídeo mostra imatges estàtiques. Tot i això, el vídeo no mostra cap tall alhora de reproduir-se a diferència d’altres proves anteriorment realitzades.

Per altre banda, el vídeo configurat amb la velocitat de transmissió de 500 kbps és veu una mica menys “pixelat”, sobre tot pel que fa al moviment, en comparació al de 200 kbps. Respecte als objectes estàtics, és pot dir que és veu més nítida la imatge que al de 200 kbps. Mostra algun tall que altre en la visualització, tot i que no en excés… 

Finalment, el vídeo configurat amb la velocitat de transmissió de 2000 kbps és el que presenta una major qualitat de vídeo, tant en els objectes en moviment com en els estàtics, tot i que a vegades es veu algun tall que altre (amb píxels verds que ocupen gran part de la pantalla).  És important, dir que en els altres vídeos (amb menor velocitat de transmissió) no s’ha vist cap escena amb píxels verds… 

Com podem veure, a mesura que es disminueix la velocitat de transmissió el factor de compressió augmenta, essent més eficient la compressió del vídeo però en contrapart empitjorant la qualitat del mateix.

A més, com podem veure a les estadístiques la “tasa de bits del contenido” del receptor és cada vegada més petita a mesura que es va reduint el velocitat de transmissió. Un bitrate més gran comporta una major qualitat del vídeo, ja que el bitrate fa referència a la quantitat d’informació al reproduir un arxiu de vídeo que es capaç de llegir el nostre ordinador per segon [13].

Tasca 2.8. estant en el cas a 200 kbps, mitjançant la barra lliscant del VLC emissor avança o retrocedeix uns minuts en la reproducció i mira com es comporta el VLC receptor. Quants segons triga a reaccionar i per què no reacciona de manera immediata? En fer-ho, què passa amb la imatge i com es relaciona amb l’estructura GOP d’H.264/AVC i els seus fotogrames I, B i P? 

En primer lloc es fan proves avançant el vídeo des del segon 5 al 12, i s’aprecia:

  • Primera prova: Aproximadament hi ha un retràs de 2,2 s en que el receptor refresqui la nova posició de reproducció en el vídeo. 
  • Segona prova: Ara, aproximadament hi ha un retràs de 2,4 s en que el receptor VLC transmeti el vídeo a partir del segon 15.
  • Tercera prova: Ara, ha trigat 2,5 s.

Per altre banda, es fan proves retrocedint el vídeo des del segon 12 fins al 5, i s’aprecia:

  • Primera prova: El retràs és d’aproximadament 1,5 s.
  • Segona prova: Hi ha un retràs d’aproximadament 1,9 s.
  • Tercera prova: El retràs és d’aproximadament 1,8 s.

NOTA: També s’han fet altres proves amb altres segons per veure a nivell general l’efecte.

Rere cada prova d’avançar o retrocedir es detecta durant uns segons com hi ha un empitjorament de la qualitat del vídeo… Es percep concretament “pixelat” de color verd i congelament del vídeo en algunes ocasions, cosa que abans sense fer cap acció no succeïa. En el cas de retrocedir el vídeo, és important destacar com s’ha quedat el programa un parell o tres de vegades penjat… fent necessari el reinici de l’aplicació.

Pel que fa a lo de la no execució instantània de canvi de segon en el receptor podem dir que es derivat a les latències i el buffer tal i com s’ha indicat anteriorment en l’exercici 2.4.

Finalment, podem dir que la imatge en moltes ocasions es quedava pixelada, de color verda, congelada, etc i es podria explicar amb la relació de la estructura GOP d’H.264/AVC i la pèrdua dels seus fotogrames I, B i P: [10]

  • En cas de perdre un fotograma de tipus B no hi ha efectes en els altres fotogrames / quadres del GOP.

Figura 36. Pèrdua d’un quadre tipus B [10].

  • Si es perd un fotograma de tipus P, es perden la resta de fotogrames de tipus P o B en el mateix GOP ja que no es poden descodificar.

Figura 37. Pèrdua d’un quadre tipus P [10].

  • Si es perd un fotograma de tipus I, tots els fotogrames del GOP es perdràn completament ja que no estarà la imatge principal. Tot i això, també podria passar que només es perdés una part del quadre i no tot.

Figura 38. Pèrdua d’un quadre tipus I [10].

Tasca 2.9. si t’agrada indagar en el tema, cerca la manera de generar un streaming de vídeo des de la càmera del teu dispositiu mòbil fins al teu ordinador, ambdós connectats a la mateixa xarxa WiFi. Fes una captura de la pantalla del teu dispositiu i indica l’aplicació i configuració que has utilitzat per aconseguir-lo. 

En primer lloc, rere una cerca per internet, es descobreix l’aplicació RTSP Camera Server[8], una aplicació per a dispositius Android. Es fa servir, en aquest cas, un mòbil d’un familiar per a fer les proves.

Un cop localitzada l’aplicació i instal·lada l’aplicació, es procedeix a revisar la seva configuració:

  • Resolució del vídeo: Es revisa quina es la resolució i es deixa amb la configuració per defecte (640*480).

Figura 39Resolució RTSP

  • Orientació: Es revisa l’orientació i es configura en format vertical (per defecte la configuració era horitzontal – apaïsat).

Figura 40Orientació RTSP

  • RTSP Setup: Es fa revisió de tota la configuració del protocol RTSP, ja que posteriorment es necessari configurar aquests aspectes en el VLC. Es realitza una revisió del port RSTP utilitzat (5554). El port HTTP es deixa amb el seu valor per defecte (8080).

Figura 41Configuració RTSP

Un cop revisada tota la configuració es clica sobre el play i es deixa el dispositiu mòbil en una ubicació fixa per poder posteriorment configurar el programa VLC per la recepció del vídeo en Streaming.

Per la configuració del VLC, es segueix el procediment que s’explica en la pròpia pàgina on es pot descarregar l’aplicació. En aquest cas, es configurarà per realitzar el streaming amb la càmera posterior del mòbil.

  • S’obre l’aplicació VLC i dins del menú “Medi” es selecciona l’opció “Obrir ubicació de xarxa”

Figura 42Configuració VLC

  • Un cop dins d’aquest menú es realitza la configuració de la URL per tal d’accedir al procés streaming que es realitza mitjançant el dispositiu mòbil: rtsp://192.168.1.60:5554/back
    • 192.168.1.60: IP del dispositiu mòbil.
    • 5554: Port RTSP configurat en el dispositiu mòbil.
    • Back: La càmera desitjada per visualitzar via streaming.

Figura 43Configuració VLC

  • Finament un cop es clica en el botó “Reproduir” es comença a visualitzar via streaming el vídeo de la càmera posterior del dispositiu mòbil.

Figura 44- Streaming mòbil

Bibliografia i Webgrafia

[1] Ribelles García, Alexandre.  Plataformes de Distribució de Continguts, Mòdul 2. Transmissió. Universitat Oberta de Catalunya. [Consultat el 15 d’abril de 2020] http://materials.cv.uoc.edu/daisy/Materials/PID_00198465/pdf/PID_00198472.pdf

[2] Como codificar e implementar para vídeo HTML5. Encoding.com. [Consultat el 15 d’abril de 2020] https://help.encoding.com/knowledge-base/article/html5-video-format-conversion-support/

[3] Formatos de medios admitidos por los elementos HTML audio y vídeo. MDN web docs. [Consultat el 15 d’abril de 2020] https://developer.mozilla.org/es/docs/Web/HTML/Formatos_admitidos_de_audio_y_video_en_html5

[4] Todos los atributos de vídeo HTML5 y sus funcionalidades. [Consultat el 17 d’abril de 2020] https://www.anerbarrena.com/atributos-video-html5-5548/

[5] Autoplay no reproduce el vídeo. Stack Overflow. [Consultat el 17 d’abril de 2020] https://es.stackoverflow.com/questions/172292/autoplay-no-reproduce-el-video

[6] Alta definición. Wikipedia. [Consultat el 18 d’abril de 2020] https://es.wikipedia.org/wiki/Alta_definici%C3%B3n

[7] RTSP Camera Server. Google Play. [Consultat el 18 d’abril de 2020] https://play.google.com/store/apps/details?id=com.miv.rtspcamera&hl=es

[8] HTML5 VS. FLASH. La perspectiva tècnica. Nikhil Koranne. [Publicat el 27 de novembre de 2018][Consultat el 18 d’abril de 2020] https://www.chetu.com/es/blogs/technical-perspectives/html5-vs-flash.php

[9] Opciones para inserta vídeo en HTML en tu web. IONOS. [Publicat el 13 d’agost de 2019] [Consultat el 18 d’abril de 2020] https://www.ionos.es/digitalguide/paginas-web/creacion-de-paginas-web/consejos-para-insertar-un-video-en-html-en-tu-web/

[10] Video Streaming. Introducción. Área de Ingeniería Telemática. Universidad Pública de Navarra. [Consultat el 19 d’abril de 2020] https://www.tlm.unavarra.es/mod/resource/view.php?id=6517

[11] Handbrake el transcodificador de vídeo multiproceso. [Consultat el 19 d’abril de 2020] https://handbrake.es

[12] MP4 VS WMS: Cuál es la Diferencia entre WMV y MP4. [Consultat el 19 d’abril de 2020] https://videoconverter.iskysoft.com/es/video-tips/mp4-vs-wmv.html

[13] ¿Qué es el bitrate? Bitrate de vídeo, audio, internet y más… Tecnologia y informàtica. [Consultat el 19 d’abril de 2020] https://www.tecnologia-informatica.com/que-es-el-bitrate-video-audio/

close
¡ÚNETE A OTROS 56 SUSCRIPTORES!
Recibe las últimas novedades en tu bandeja de entrada cada 15 o 30 días.