Práctica 3 - MPEG System (Javier de la Rica) (2016)

Pràctica Español
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ingeniería de Sistemas Audiovisuales - 3º curso
Asignatura Comunicaciones Multimedia
Año del apunte 2016
Páginas 59
Fecha de subida 21/04/2016
Descargas 25
Subido por

Vista previa del texto

Javier de la Rica Comunicaciones Multimedia Multimedia Communications MPEG System Departamento de Ingeniería Telemática (ENTEL) Jorge Mata Juanjo Alins Oscar Esparza José L. Muñoz 1 Presentació de la pràctica Aquesta pràctica presentar de forma resumida i compacta la normativa de l’estàndard MPEG-2, una de les bases sobre les que s’ha desenvolupat la codificació i transmissió audiovisual sobre xarxes de comunicacions. En primer lloc es presenta una introducció general, per passar a analitzar a continuació la codificació de vídeo segons de l’estàndard (ISO/IEC 13818-2) i en la segona part s’estudia la especificació de sistema (ISO/IEC 13818-1) dins les seves dues vessants, l’stream de programa i l’stream de transport.
2 Introducció 2.1 ISO/MPEG: Estàndard de vídeo digital El 1988 es creà un grup de treball de la ISO sota el nom de MPEG, "Moving Pictures Expert Group", per establir estàndards de codificació d’imatges en moviment i el seu àudio associat per diverses aplicacions com emmagatzemament digital, distribució i comunicació. D’una norma amb les característiques d’aquesta se’n deriven conseqüències importants com que el senyal de vídeo pot ser tractat com un format de dades més, que pot ser integrat amb altres tipus de dades, i d’aquí la seva aplicació a sistemes multimèdia. A més, en l’accés a dades de terminals remots, el senyal de vídeo codificat pot viatjar a través de les xarxes de comunicació, el que possibilita l’aplicació de la norma per als sistemes purs de transmissió.
El desembre de 1990 es publicà el primer esborrany de l’estàndard, MPEG-1, que normalitza el format del flux de dades codificats, així com els processos de codificació i descodificació. La seva aplicació eventual en canals de comunicació va fer superar ràpidament la idea original que restringia la norma a equips d’emmagatzemament digital. Fou per aquest motiu que es va considerar necessari desenvolupar una segona norma destinada a un marge més ampli d’aplicacions. Aquesta segona norma és l’estàndard MPEG-2, que pretén crear un estàndard genèric d’arquitectura oberta, amb aplicacions en camps tan diversos com sistemes de distribució de televisió per cable, telefonia visual, sistemes de vídeo-vigilància, connexions digitals de televisió terrestre i via satèl·lit, etc.
Aquest estàndard internacional ha estat publicat en 4 parts: Javier de la Rica Comunicaciones Multimedia 13818-1 systems: específica la codificació de sistema de l’especificació. Defineix una estructura multiplexada per combinar àudio, vídeo i mitjans per representar la temporització per tal de sincronitzar les diferents seqüències en temps real.
13818-2 vídeo: especifica la representació codificada del vídeo i el procés descodificador requerit per reconstruir les imatges.
13818-3 àudio: especifica la representació codificada de l’àudio.
13818-4 conformance: especifica els procediment per determinar les característiques dels corrents codificats i la conformitat dels tests segons els requeriments de 13818-1, 13818-2 i 13818-3.
3 Descripció de l’estàndard ISO/IEC 13818 3.1 Codificació de Vídeo MPEG-2 La part de vídeo d’aquesta recomanació va ser desenvolupada en resposta a la creixent necessitat d’un mètode de codificació genèric per imatges en moviment i el seu àudio associat per diferents aplicacions com l’emmagatzemament digital, radiodifusió de televisió i comunicacions. Aquesta recomanació especifica la representació codificada de la informació de la imatge.
Aquesta especificació ha estat pensada per ésser genèrica, és a dir, l’estàndard és independent d’una aplicació particular i cobreix un ampli rang d’aplicacions, tasses de bit, resolucions, qualitats i serveis; el que no vol dir que ignori els requeriments concrets de les diferents aplicacions.
La sintaxi complerta es pot dividir en dos grans categories. Una és la sintaxi no escalable que s’estructura com una ampliació de la sintaxi definida a ISO/IEC 11172-2 (MPEG-1). La segona és la sintaxi escalable, la qual s’aconsegueix estructurant l’stream total en dos o més capes on la capa base es pot usar com a sintaxi no escalable.
L’ especificació suporta transmissió a taxa de bit constant, a taxa de bit variable, accés aleatori, salt de canal, descodificació escalable, editabilitat de l’stream de bit, així com funcions especials com moviment ràpid cap endavant i enrere, moviment lent, pausa i congelat d’imatges.
3.1.1 Característiques del bitstream El bitstream definit per MPEG, intenta ser prou flexible per tal de ser usat des de diverses aplicacions. Aquesta flexibilitat li és conferida mitjançant un gran nombre de paràmetres, i fent ús d’una estructura jeràrquica basada en agrupacions de bits anomenades layers.
3.1.2 Paràmetres Els paràmetres que defineixen les característiques del bitstream codificat i del descodificador, estan continguts en el mateix bitstream. Això permet que l’algoritme sigui utilitzat per imatges de diferents grandàries i relacions d’aspecte, i en canals o dispositius que operin en un ample rang de bitrates.
3.1.3 Jerarquia del bitstream El bitstream està estructurat en capes, que configuren una estructura jeràrquica. A continuació s’indiquen aquestes capes.
● Sequence. És la capa superior de la jerarquia de codificació, i consisteix en una capçalera i varis grups d’imatges (groups-of-pictures: GOP). La capçalera inicialitza l’estat del descodificador.
Javier de la Rica Comunicaciones Multimedia ● GOP. És un punt d’accés aleatori, i.e. és l’entitat més petita que pot ser descodificada de forma independent. Està format per una capçalera (on hi ha la informació de temps i d’edició) i vàries imatges.
● Picture. Correspon a una imatge de la seqüència. D’imatges n’hi ha de quatre tipus, en funció de la informació utilitzada per a codificar-les. Una picture, es composa d’una capçalera (on hi ha informació de temps, del tipus d’imatge, i de la codificació) i de varis slices.
● Slice. Proporciona correcció d’errors. Si el bitstream esdevé il.legible, el descodificador pot recuperar la informació a partir del següent macroblock. També té una capçalera (amb informació de posició i informació d’escala de quantificació) i un o més macroblocks.
● Macroblock. És la unitat bàsica per a la compensació de moviment i pels canvis d’escales de quantificació. La capçalera del macroblock conté l’escala de quantificació i la informació de compensació de moviment. Cada macroblock correspon a una àrea de la imatge de 16×16 pels de luminància i 8×8 pels de croma (Cb i Cr), doncs tal com s’indica en el format d’entrada (SIF), la croma està submostrejada horitzontal i verticalment. Així doncs, un macroblock correspon a la combinació de 6 blocks de 8×8 pels; 4 blocks per a la luminància, i 1 bloc per a cada component de croma (Cb, Cr).
● Block. Els blocs són les unitats bàsiques de codificació. La DCT s’aplica a nivell de block.
Cada block conté 64 pels, distribuïts en un array de 8×8.
3.1.4 Tipus d’imatges Una imatge consisteix en tres matrius rectangulars de nombres de 8 bits; una matriu de luminància (Y), i dues matrius de crominància (Cb, Cr). Les matrius de crominància tenen la meitat de files i columnes, doncs la croma està submostrejada vertical i horitzontalment.
La recomanació MPEG diferencia tres tipus d’imatges, en funció de la informació que s’utilitza per a codificar-les: ● Imatges I: Utilitzen el tipus de codificació intraframe (Intra), i.e. usant únicament informació d’elles mateixes.
● Imatges P: Utilitzen codificació intraframe i interframe cap enrere; codificació predictiva (Predicted), i.e. usant predicció per compensació de moviment a partir d’una imatge I o P anterior.
● Imatges B: Utilitzen codificació intraframe i interframe bidireccional; codificació predictiva bidireccional (Bidirectionally predictive), i.e. usant predicció per compensació de moviment a partir d’imatges I i/o P anteriors i/o posteriors.
3.1.5 Organització de les imatges en sèries periòdiques Imatges d’aquests diferents tipus es combinen per a donar lloc als grups d’imatges (GOP). Un grup d’imatges ha de contenir com a mínim una imatge I. Aquesta imatge I pot estar seguida de vàries imatges I i P. Les imatges B poden ser intercalades entre cada parell d’imatges I o P, i inclús poden precedir la imatge I inicial (en l’ordre de presentació). Per a facilitar la tasca del codificador, és ordenar les imatges en sèries periòdiques (tot i que la normativa no ho exigeix). Per a determinar la sèrie periòdica es fa usant dos paràmetres: M i N. N representa el període de repetició de les imatges I; així doncs, si tenim 11 imatges entre cada dues I’s, N valdrà 12. D’altra banda, M indica (1 + nombre d’imatges B) que segueixen una I o una P. Els exemples següents ajuden a aclarir aquestes definicions de M i N.
M=1, N=1 → I I ...
M=1, N=2 → I P I ...
Javier de la Rica Comunicaciones Multimedia M=1, N=3 → I P P I ...
M=2, N=2 → I B I ...
M=3, N=3 → I B B I ...
M=2, N=4 → I B P B I ...
M=3, N=12 → I B B P B B P B B P B B I ...
Aquesta nomenclatura, descrita per la norma MPEG-I, és bastant estàndard, si bé en alguns casos, la M, s’utilitza com a M-1 (segons la notació que s’ha descrit), això vol dir que M representaria la quantitat de B’s seguides. La figura, representa una sèrie periòdica d’imatges, amb M=3 i N=9, i indica les relacions entre imatges quan a informació que s’utilitza per a la seva codificació.
Així doncs, no totes les combinacions dels paràmetres M i N, són vàlides. Únicament ho seran aquelles en què es compleixi la relació: N=k×M, on k és un enter positiu.
Figure 1: Tipus de predicció en un grup d’imatges (M=3, N=9) 3.2 Sintaxi i semàntica de la trama de vídeo En general, l’estructura sintàctica més elevada de l’stream de vídeo codificat és la seqüència de vídeo. Notem que quan s’usa una extensió escalable, dos o més corrents de bits són descodificats en un únic descodificador. Cada un d’aquests corrents complirà amb aquesta especificació.
En general, cada flux pot ser pensat com una mena de jerarquia sintàctica on cada estructura conté una o més estructures subordinades. Per exemple, la estructura picture conté una o més estructures slice, les quals poden contenir una o més estructures macroblock. A l’hora de construir la seqüència caldrà aplicar una sèrie de regles semàntiques. A la figura 2.5 podem veure l’organització de l’stream de vídeo de nivell alt.
El conjunt d’extensions permeses a cada punt de l’stream és diferent. A cada punt de l’stream on les extensions són permeses, qualsevol número de extensions entre les definides pot ser inclòs. No obstant, cada tipus d’extensió només podrà aparèixer un cop.
Javier de la Rica Comunicaciones Multimedia Figure 2: Organització de l’stream de bits de nivell alt 3.3 Perfils i nivells Per tal de fer pràctica la realització de la sintaxi d’aquesta especificació, s’ha estipulat un nombre limitat de subconjunts de la sintaxi mitjançant els conceptes de ’perfil’ i ’nivell’. El propòsit de definir aquests perfils i nivells és facilitar l’intercanvi de l’stream entre diferents aplicacions.
Un perfil es defineix com un subconjunt de la sintaxi de l’stream complert definit segons aquesta especificació.
Un nivell es defineix, per a cada perfil, com a un conjunt de lligams imposats als paràmetres de l’stream.
Tots els elements sintàctics i valors de paràmetres que no estan explícitament lligats, poden prendre qualsevol dels possibles valors permesos per aquesta especificació.
El ’profile_and_level_indication’ dins la ’sequence_extension’ indica el perfil i nivell que compleix l’stream. Els perfils possibles definits a l’especificació són: Simple, Main, SNR Scalable, Spatially Scalable i High. Respecte als nivells, els valors possibles són: Low, Main, High 1440 i High.
A la següent figura podem veure una taula que ens mostra els diferents subconjunts de la sintaxi i la semàntica definides pel perfils i nivells, definits per aquesta recomanació.
Javier de la Rica Comunicaciones Multimedia Figure 3: Taula de Perfills i Nivells MPEG-2 ● "Resolució": ● "Y ● "Número ● "Taxa ● "Mida VBV ● Quan ens trobem amb l’expressió "na", aquesta indica no aplicable.
● Les cel·les buides indiquen que el perfil a aquell nivell no està definit.
indica els marges superiors (upper bounds) per la densitat de mostres per mostres per línia / línies per quadre / quadres per segon. Pels perfils escalable espacialment (Spatial) i alt (High) quan parlem de resolució superior ens referim a la capa d’exalçament i quan parlem de resolució inferior ens referim a la capa base. Per la resta de perfils (Simple, Main i SNR) quan parlem de resolució superior ens referim a la capa base.
mostres/seg.": indica els marges superiors (upper bounds) de la taxa de mostreig de luminància. En el cas del perfil High, aquests valors són per 4:2:2 / 4:2:0.
de capes": indica el marge superior (upper bounds) per totes les capers (base + enhancement) / les capes d’exalçament espacial (spatial enhancement) / les capes d’exalçament SNR (SNR enhancement).
de bit (Mbit/s)": indica la taxa de bit en Mbits per segon. En el cas dels perfils SNR, Spatial i High es refereix als marges superiors (upper bounds) per la suma de les capes disponibles en l’stream de bits escalable. Aquests són per totes les capes, la suma de la capa base i la capa mitja, o la capa base únicament.
búffer (Mb)": indica els requeriments de búffer (en Mbits/s) de cada capa. Pels perfils SNR, Spatial i High, aquests valors és refereixen a la capa d’exalçament (enhancement 2) / la capa mitja (middle o enhancement 1) / la capa base (base).
Javier de la Rica Comunicaciones Multimedia 4 La capa de Sistema MPEG-2 4.1 Introducció 4.1.1 L’stream de sistema Aquesta part de la recomanació s’encarrega de combinar un o més streams elementals, així com altres dades en un stream simple o múltiple, preparat per emmagatzemament o transmissió.
La codificació de sistema es pot especificar de dues formes: l’stream de transport o l’stream de programa. Cadascun d’ells està optimitzat per un conjunt diferent d’aplicacions. Ambdós proporcionen la sintaxi de codificació que és necessària i suficient per sincronitzar la descodificació i presentació de la informació de vídeo i àudio. La informació es codifica a la sintaxi fent servir marques temporals. Ambdós definicions d’stream són multiplexades orientades a paquet.
L’stream de programa és anàleg a la capa de sistema ISO/IEC 11172 (MPEG-1) i és el resultat de combinar un o més streams de paquets PES (Packetized Elemetary Stream) dins un únic stream, amb una base temporal comuna. Està dissenyat per ser usat en ambients relativament lliures d’errors i és adient per aplicacions que poden incloure processament software d’informació tal com aplicacions multimèdia interactives.
Respecte a l’stream de transport combina un o més programes codificats amb una o més bases de temps independents dins un únic stream. Un programa es defineix com una col·lecció d’streams elementals amb una base temporal comuna. És dissenyada per ser usada en ambients on solen produir-se errors.
Tot i que ambdós streams (transport i programa) es dissenyen per diferents aplicacions i cap d’ells és un subconjunt de l’altre, és possible fer una conversió de l’un a l’altre per mitjà dels paquets PES.
Figure 4: Visió simplificada de la recomanació ITU-T Rec. H.222.0 ISO/IEC 13818-1 Tant l’stream de transport, com l’stream de programa estan construïts en dues subcapes. La més externa és la subcapa de sistema i la més interna la de compressió. L’stream d’entrada al descodificador de sistema MPEG-2 (Transport Stream Decoder o Program Stream Decoder) consisteix en la subcapa de sistema que conté les subcapes de compressió. En canvi, les entrades als descodificadors de Vídeo i Àudio contenen només la subcapa de compressió.
La subcapa de sistema proporciona les funcions necessàries per usar un o més streams de dades comprimides en un sistema (operacions multiplex-wide). Aquesta capa rep el nom de ’packet Javier de la Rica Comunicaciones Multimedia stream transport layer’ i ’pack layer’ per l’stream de transport i de programa respectivament. La subcapa de compressió serveix per operacions específiques d’stream. Les parts de vídeo i àudio d’aquesta especificació defineixen les capes codificades de compressió per les dades d’àudio i vídeo. La codificació d’altres tipus de dades no està definida en aquesta especificació, però és suportada per la capa de sistema proporcionada. Aquesta subcapa rep el nom de ’PES packet layer’, tant per l’stream de transport com de programa.
Figure 5: Exemple de descodificador i demultiplexor de transport o programa 4.1.2 Packetized Elementary Stream Tant l’stream de transport com l’stream de programa estan lògicament constituïts per paquets PES.
Un paquet PES està format per una capçalera seguida de les dades. La capçalera comença amb un start code de 32 bits que també identifica l’stream al qual pertany el paquet de dades i conté camps com el DTS (decoding time stamp) i el PTS (presentation time stamp). El camp de dades del paquet PES conté un nombre variable de bytes contigus d’un stream elemental.
És possible construir un stream de dades com un stream contigu de paquets PES, cadascun contenint dades del mateix stream elemental. Aquest stream s’anomena PES stream. Quan el paquet PES s’usa per formar streams PES, s’han d’incloure els camps Elementary Stream Clock Reference (ESCR) i Elementary Stream Rate (ES_rate). Aquest stream PES és una construcció lògica que pot ser molt útil en les implementacions d’aquest estàndard. L’stream PES no conté alguna informació de sistema necessària que es conté en els stream de transport i de programa.
4.1.3 Model de temporització Sistema, vídeo i àudio tenen un model de temporització on el retard total ”end to end” és constant.
La codificació de l’stream de sistema conté informació de temporització que es pot usar per implementar els sistemes que incloguin aquest retard constant. Tota la temporització es defineix en termes d’un rellotge de sistema comú (STC). En l’stream de transport aquesta temporització es realitza mitjançant el ’Program Clock Reference’ (PCR) i en l’stream de programa mitjançant el ’System Clock Reference’ (SCR).
4.1.4 Accés condicional L’encriptació i enxifrat per l’accés condicional a programes codificats a l’stream de programa o l’stream de transport és suportada per l’stream de dades de sistema. Els mecanismes d’accés condicionals no són especificats aquí.
Javier de la Rica Comunicaciones Multimedia 4.1.5 Operacions multiplex-wide Les operacions multiplex-wide inclouen la coordinació de la recuperació de dades del canal, l’ajustament de rellotges i el control de búffers. Si la taxa de transport de dades del canal és control·lable, aquest transport s’ha d’ajustar de manera que no es produeixi overflow ni underflow dels buffers del descodificador; però si aquesta taxa no es controlable, els descodificadors de l’stream elemental han de subordinar la seva temporització a les dades rebudes pel canal per evitar overflow i underflow.
L’stream de programa està composat de packs, els headers dels quals faciliten les tasques indicades.
Especifica els instants de temps en els quals cada byte ha d’entrar al Program Stream Decoder. De forma similar, l’stream de transport està format per transport stream packets, els headers dels quals contenen informació dels instants de temps en els quals cada byte ha d’entrar al Transport Stream Decoder. El primer pack de cada stream de programa porta paràmetres per assistir als descodificadors en la seva tasca. El mateix passa amb l’stream de transport.
4.1.6 Operacions de l’stream individual Demultiplexat En la codificació, l’stream de programa està format pel multiplexat d’streams elementals, i l’stream de transport està format pel multiplexat d’streams elementals o el contingut d’altres streams de transport. En la descodificació es requereix un demultiplexat per reconstruir els streams elementals.
Els codis ’Stream_id’ als headers de l’stream de programa i ’packet_id’ al de transport ho fan possible.
Sincronització La sincronització entre els múltiples streams elementals s’aconsegueix amb ’Presentation Time Stamps’ als streams de programa i transport. Aquestes marques temporals es donen generalment en unitats de 90 Hz. En canvi, el System Clock Reference (SCR), Program Clock Reference (PCR) i l’opcional Elementary Stream Clock Reference (ESCR) tenen extensions amb resolucions de 27 MHz. La descodificació de N streams elementals es sincronitza ajustant la descodificació d’streams a una base temporal mestre comuna. Aquest rellotge comú pot ser d’un dels N descodificadors, un rellotge de la font de dades o un rellotge extern. Dins d’un stream de transport, cada programa ha de tenir la seva pròpia base temporal.
Com que el PTS s’aplica a la descodificació d’un stream elemental individual, aquest resideix a la capa de paquets PES. La sincronització ’end to end’ es produeix de la següent manera: el codificador salva les marques temporals en el moment de la captura, aquestes es propaguen amb les dades associades i el descodificador les usa per fixar el temps per la presentació.
4.2 L’stream de programa 4.2.1 Estructura de codificació La capa de codificació de l’stream de programa permet combinar un o més streams elementals dins un únic stream. Les dades de cada stream elemental es multiplexen i codifiquen juntament amb informació que permet restablir els streams elementals en perfecte sincronisme. Pot ser de grandària fixa o variable. En cada cas, les trames elementals constituents també poden ser de taxa fixa o variable.
Cada stream elemental està format per unitats d’accés (que són la representació codificada de les unitats de presentació -que en el cas de vídeo són les imatges-). Aquestes unitats d’accés inclouen totes les dades de la imatge codificada. Les dades dels streams elementals s’emmagatzemen en els paquets PES.
En un stream de programa, els paquets PES s’organitzen en packs. Un pack comença amb un ’pack header’ seguit de zero o més paquets PES. El ’pack header’ comença amb un ’start code’ de 32 bits Javier de la Rica Comunicaciones Multimedia i s’usa per emmagatzemar la temporització i la informació de la taxa de bit. El primer ’pack header’ de l’stream de sistema comnença amb un ’system header’, que opcionalment pot repetir-se en els altres ’pack headers’. Aquest transporta un resum dels paràmetres de sistema definits a l’stream.
4.2.2 Program stream system target decoder El ’Program stream system target decoder’ (P-STD) és un model conceptual usat per definir els termes necessaris de l’stream amb precisió i que serveix per modelar el procés descodificador durant la construcció o verificació dels streams de programa.
Freqüència de rellotge del sistema La informació temporal referenciada al P-STD es transporta a diferents camps de dades. Aquests valors es codifiquen com el valor mostrejat del rellotge de sistema. El valor de la freqüència de rellotge de sistema es mesura en Hz i ha de complir el següent lligam: 27 000 000 - 540 <= system_clock_frequency <= 27 000 000 + 540 Entrada al ’Program stream system target decoder’ Les dades de l’stream de programa entren al STD. L’instant en el que un byte entra al STD es pot recuperar de l’stream d’entrada descodificant el camp SCR codificat al pack header. L’instant d’arribada per tots els altres bytes, t(i), s’ha de construir a partir del SCR i la taxa a les que les dades arriben, la qual, per cada pack, és el valor representat al camp ’program_mux_rate’ dins el pack header.
Búffers Les dades dels paquets PES de l’stream elemental ’n’ es passen al búffer de l’stream ’n’. La transferència del byte ’i’ des de l’entrada del STD al búffer és instantània. Els bytes presents al pack header, system headers o PES packet headers de l’stream de programa no es portaran a cap búfffer però s’usaran per controlar el sistema. En l’instant de descodificació les unitats d’accés s’esborren del búffer i es descodifiquen instantàniament donant lloc a les unitats de presentació.
Descodificació i presentació Els diferents streams elementals de cada búffer es descodifiquen instantàniament a cada descodificador i poden ser retardats en els seus respectius búffers en cas que sigui necessària reordenació abans de ser presentats a la sortida del P-STD.
Els dispositius de presentació reals d’àudio i vídeo generalment tenen retards diferents i cal imposar retard adicionals de post-processat. El STD modela aquests retards a zero.
4.2.3 Especificació de la sintaxi i la semàntica La sintaxi de l’stream de programa s’organitza com una sèrie arbitrària de packs contigus encapçalats per un ’pack_start_code’. Cada pack està format per un pack_header, seguit dels bits d’informació (que són els PES packets). El header està composat d’una sèrie de camps d’informació que opcionalment, a excepció de en el primer pack_header de cada pack on és obligatori, pot anar seguit d’una extensió anomenada system_header (una sèrie més de camps que controlen el sistema).
La capa de paquets de l’stream de programa es defineix mitjançant la capa de paquets PES (els mateixos que els definits per l’stream de transport). El nombre de PES packets presents a cada pack també és arbitrari. El PES packet header està format per una sèrie de camps obligatoris i d’altres d’opcionals, entre els que destaquen les marques temporals de descodificació i presentació (PTS i DTS). Els bytes de dades del paquet PES han de ser una sèrie de bytes de dades de la trama elemental, indicada pels camps ’stream_id’ o ’PID’.
4.2.4 Program stream map El program stream map proporciona una descripció dels streams elementals de l’stream de programa i la relació entre els uns i els altres. Quan es transporta en un stream de transport, aquesta Javier de la Rica Comunicaciones Multimedia estructura no ha de ser modificada. El program stream map és present com un paquet PES amb valor del camp stream_id de 0xBC.
4.2.5 Program stream directory El directori d’un stream sencer està format per totes les dades de directori dels PES packets identificats amb el ’directory_stream_id’. Les entrades del directori poden ser requerides per referenciar les imatges I en un stream de vídeo. Les unitats d’accés s’han d’incloure en el directori en el mateix ordre en que aparèixen al stream de bits.
4.3 L’stream de transport 4.3.1 Estructura de codificació L’stream de transport consisteix, com ja hem dit, en un o més programes els quals contenen un o més streams elementals multiplexats plegats. En general, pot ser de taxa fixa o variable. En cada cas, les trames elementals constituents també poden ser de taxa fixa o variable, però, en particular, en el cas on l’stream de transport conté múltiples programes no és possible construir un stream de transport on la taxa de bit total sigui variable.
L’stream de transport ha estat dissenyat de manera que una sèrie d’operacions sobre ell siguin possibles amb un mínim esforç. Entre aquestes operacions podem destacar les següents: ● Obtenir les dades codificades d’un programa de l’stream de transport, descodificar-les i presentar aquests resultats ● Extreure els transport stream packets d’un programa de l’stream de transport i produir com a sortida un stream de transport diferent amb només aquest programa ● Extreure els transport stream packets d’un o més programes d’un o més streams de transport i produir com a sortida un stream de transport diferent ● Extreure el contingut d’un programa de l’stream de transport i produir com a sortida un stream de programa que conté aquest programa ● Agafar un stream de programa, convertir-lo en stream de transport per transportar-lo per un medi amb pèrdues, i recuperar-lo en un idèntic stream de programa vàlid, en certs casos Cada stream elemental està format per unitats d’accés (representació codificada de les unitats de presentació). Aquestes unitats d’accés inclouen totes les dades de la imatge codificada. Les dades dels streams elementals es transporten en els paquets PES, que dins d’aquest stream estan inserits dins del transport stream packet. En els streams de transport, aquests transport stream packets tenen tots una longitud de 188 bytes. Un transport stream packet comença amb un prefix de 4 bytes que conté un identificador de paquet (PID) de 13 bits, el qual identifica, via les taules PSI (program specific information), els continguts de les dades del transport stream packet. Paquets amb un valor de PID porten dades d’un i només un stream elemental.
Les taules PSI es transporten dins de l’stream de transport. N’hi ha 4: ● Program Association Table ● Program Map Table ● Network Information Table ● Conditional Acces Table Aquestes taules contenen la informació necessària i suficient per demultiplexar els programes presents.
Javier de la Rica Comunicaciones Multimedia 4.3.2 Transport stream system target decoder El ’Transport stream system target decoder’ (T-STD) és un model conceptual usat per definir els termes necessaris de l’stream amb precisió i que serveix per modelar el procés descodificador durant la construcció o verificació dels streams de transport.
Freqüència de rellotge del sistema La informació temporal referència al T-STD es transporta a diferents camps de dades. Aquests valors es codifiquen com el valor mostrejat d’un rellotge de referència del programa que trobem al camp PCR. Aquesta freqüència de rellotge del sistema es mesura en Hz i ha de estar sotmesa al següent lligam: 27 000 000 - 540 <= system_clock_frequency <= 27 000 000 + 540 Entrada al ’Transport stream system target decoder’ L’entrada al T-STD és l’stream de transport. El T-STD descodifica només un programa cada cop.
En el model de T-STD totes les indicacions temporals es refereixen a la base temporal d’aquest programa. L’instant en el que un byte entra al T-STD es pot obtenir mirant el camp PCR.
Búffers Els transport stream packets que contenen dades de la trama elemental n, es passen al búffer de transport de l’stream n. La transferència del byte ’i’ des de l’entrada del STD al búffer és instantània. Els bytes que formen part del paquet PES o el seu contingut es transporten al búffer principal. Els transport stream packets que contenen informació de sistema, pel programa seleccionat per descodificar, entren al búffer de transport de sistema, a la taxa d’stream de transport, i després són transferits al búffer principal de sistema. La grandària del búffer de transport de sistema es fixa a 512 bytes. La grandària del búffer principal de sistema és de 1536 bytes.
Per cada búffer d’un stream elemental, totes les dades de cada unitat d’accés s’esborren com a màxim al seu temps de descodificació especificat als camp DTS o PTS. Al temps que s’esborren del búffer aquestes unitats d’accés, es descodifiquen donant lloc a les unitats de presentació. En general, els diferents búffers mai poden sofrir overflow, encara que es permet, en algun mode d’actuació, que algun búffer sofreixi underflow.
Descodificació i presentació La descodificació i la presentació dins del ’Transport stream system target decoder’ és la mateixa que la definida pel ’Program stream system target decoder’ definida a l’apartat anteriorment.
4.3.3 Especificació de la sintaxi i la semàntica La sintaxi de l’stream de transport s’organitza com una sèrie arbitrària de transport packets contigus encapçalats per un byte de sincronisme (sync_byte). Aquest transport packet s’organitza amb un header, seguit dels bits d’informació (payload). En funció d’alguns camps que composen el header, aquest pot anar seguit, opcionalment, d’una sèrie més de camps sota el nom genèric d’adaption_field. El payload (data_byte) el composen una sèrie de bytes de dades contigus, formats per paquets PES, dades de PSI, dades privades o paquets nuls, en funció del camp PID del header.
Els paquets PES usats a l’stream de transport són els mateixos que els definits per l’stream de programa.
4.3.4 Program specific information Program Specific Information (PSI) inclou les dades normatives i privades que possibiliten el demultiplexat de programes pels descodificadors. Els programes es composen d’un o més streams elementals amb diferents PIDs. Als programes, streams elementals o parts d’ells s’hi pot accedir condicionalment. PSI es classifica segons 4 estructures de taules. Aquestes es poden segmentar en Javier de la Rica Comunicaciones Multimedia seccions i ser inserides en transport stream packets. Una secció és una estructura sintàctica que es pot usar per mapejar les taules PSI dins els transport stream packets.
Aquestes 4 taules són: ● Program Association Table: Identifica la correspondència entre un número de programa (program_number) i el valor del PID dels transport stream packets que transporten la definició del programa. El program_number és la etiqueta numérica associada a un programa ● Program Map Table: Proporciona el mapejat entre els números de programa i els streams elementals de que consten. La program map table és la colecció complerta de les definicions de tots els programes per l’stream de transport. Aquesta taula s’ha de transmetre en paquets ● Network Information Table: Proporciona paràmetres físics de la xarxa. Aquesta secció és opcional i el seu contingut és privat ● Conditional Access Table: Proporciona l’associació entre un o més sistemes d’accés condicional. La taula pot ser segmentada en una o més seccions, abans d’inserir-se als paquets de l’stream de transport, amb la sintaxi corresponent ● Sobre les taules PSI és possible, també, transportar taules de dades privades. Per aquest cas existeix una sintaxi de la secció privada 5 Estudi previ A. Indica algunes de les principals diferències entre els codificadors: 1. Àudio (https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats) a. MP3 Formato lanzado y publicado en 1993 por ISO/IEC MPEG Audio Committee. Dicho formato sirve para reproducción de música, pero no para aplicaciones telefónicas ni compresión de audio sin pérdidas. Junto con el formato AAC es compatible con todos los sistemas operativos. En el caso de Infraestructuras Multimedia de soporte para formatos de compresión de audio es compatible con ACM, DirectShow, QuickTime, GStreamer, FFmpeg y Media foundation.
b. AAC (Advanced Audio Coding) Formato lanzado y publicado en 1997 por ISO/IEC MPEG Audio Committee como el formato MP3. Compatible tanto para reproducción y consumo de audio y música y aplicaciones telefónicas como para compresión de audio sin pérdidas. Junto con el formato MP3, es compatible con todos los sistemas operativos. En el caso de Infraestructuras Multimedia de soporte para formatos de compresión de audio es compatible con ACM, DirectShow, QuickTime, GStreamer, FFmpeg y Media foundation.
Javier de la Rica Comunicaciones Multimedia c. Opus Lanzado y publicado en 2012 por IETF. Útil para reproducción y consumo de música y audio y para aplicaciones telefónicas, pero como el MP3, no apto para compresión de audio sin pérdidas. A diferencia de los dos formatos anteriores, el presente formato no es compatible con los sistemas operativos Palm OS y Symbian OS 2. Video (https://en.wikipedia.org/wiki/Comparison_of_video_codecs) a. H.262 (MPEG2 Video) MPEG2 es la designación para un grupo de estándares de codificación de audio y vídeo acordado por MPEG y publicados como estándar ISO. Por lo general es usado para codificar señales de transmisión, en los que se incluye TDT satélite o cable.
Es parecido a MPEG1 pero también proporciona soporte para vídeo entrelazado. Éste no está optimizado para bajas tasas de bits, pero supera en desempeño a MPEG1 a tasas mayores a 3Mbits/s.
b. H.264 (Advanced Video Coding) Se trata de una norma que define un códec de vídeo de alta compresión. Su uso inicial estuvo enfocado hacia el vídeo de baja calidad para videoconferencias y aplicaciones por internet, basados en 8bits por muestra y con un muestreo ortogonal de 4:2:0.
H.264 no supone una gran tecnología con respecto a las normas de codificación de vídeo anteriores. Las diferencias que se pueden encontrar son a pequeña escala sobre el principio general de codificación. Lo más importante es la menor cantidad de información necesaria para almacenar los vídeos codificados mediante el presente códec.
c. H.265 o HEVC (High Efficiency Video Coding) Norma que define un format de compresión de vídeo. Éste reemplaza a los macrobloques – que fueron utilizados en normas anteriores – con unidades de codificación en árbol (CTU), que pueden usar estructuras de bloques más grandes, de hasta 64x64 píxels y pueden mejorar el subparticionado de la imagen en estructuras de tamaño variable.
d. VP9 El vodec VP9 es una creación de Google en 2013. Se trata de un formato abierto de compresión de vídeo libre de regalías.
Uno de los objetivos de VP9 es reducir la tasa de bits un 50%. Otro ed los objetivos es mejorarlo hasta el punto en que tenga una mejor eficiencia de compresión que el explicado anteriormente, H.265 o HEVC (High Efficiency Video Coding).
Javier de la Rica Comunicaciones Multimedia B. Comenta les principals característiques dels contenidors multimèdia: (https://en.wikipedia.org/wiki/Comparison_of_video_container_formats) 1. MPEG-2 Transport Stream (ISO/IEC 13818-2) MPEG-2 es para la codificación genérica de imágenes en movimiento y el audio asociado que crea un flujo de vídeo mediante tres tipos de datos de marco (cuadros Intra, cuadros posteriores Predecibles y cuadros predecibles Bidireccionales) arreglados en un orden específico llamado La estructura GOP – Group of Pictures.
2. MPEG-4 (ISO/IEC 14496-12) Método para la compression difital de audio y vídeo. Ofrece una serie de tecnologías para los desarrolladores, proveedores de servicios y usuarios finales.
Éste permite a diferentes desarrolladores crear objetos multimedia que posean mejores habilidades de adaptabilidad y flexibilidad para mejorar la calidad de los servicios y tecnologías como la TDT.
Los proveedores de la red de datos pueden utilizar MPEG4 para la transparencia de los datos. También proporciona a los usuarios una amplia gama de interacción con distintos objetos animados.
El formato MPEG4 puede realizar distintas funcionas, entre las que las más importantes son la multiplezación y sincronización de datos asociados con los objetos del medio tal que pueden ser eficientemente transportados por distintos canales de la red, y la interacción con la escena audiovisual que se forma en el lado del receptor.
3. Blu-ray Disc Audio-Video (BDAV) MPEG-2 Transport Stream (M2TS) Propiedad y desarrollado por Blu-ray Disc Association. Consta tanto de una velocidad de bit como de una velocidad de trama variables. Se estructura en capítulos y dispone de subtítulos. Dispone de la posibilidad de introducir etiquetas (tags) y menús. Es posible visualizarlo en streaming y dispone de codecs y contenedores 3D y reproductores hardware.
4. Matroska Multimedia Container (.mkv, .mk3d, .mka, .mks) Propiedad de CoreCodec, Inc. Dispone de una velocidad de bit y velocidad de trama variable. Como el contenedor anterior, dispone de una estructuración en caoítulos y con subtítulos además de la posibilidad de introducir etiquetas (tags) y visualización en Streaming, aunque a diferencia de BDAV no se puede tener menú, pero dispone de 6 Desenvolupament de la pràctica 6.1 Objectius L’objectiu d’aquesta part és proporcionar un conjunt d’eines i una metodologia per generar fluxos de vídeo MPEG-2 codificats adequadament per la seva transmissió. Per aconseguir aquest objectiu Javier de la Rica Comunicaciones Multimedia es faran una sèrie d’anàlisi que ens permetin avaluar el paràmetres més convenients d’un codificador 6.2 Eines ● Codificador FFmpeg ● Eina d’anàlisi dvdsnoop ● Reproductor dvdview ● Eina de representació gràfica xmgrace ● Full de càlcul gnumeric ● Utilitats bitrate, mpginfo, tcprobe, bbdmux, mpgtx, tsinfo, ts2es, tsplay 6.3 Codificació i anàlisi L’estudi de seqüències de vídeo és una tasca que requereix una bona part d’avaluació subjectiva. La qualitat d’una imatge no depèn únicament d’un sol paràmetre, podem trobar imatges molt diferents, i per tant el nostre varem d’ “acceptable” és molt variable. No podem doncs, afirmar categòricament que una imatge és acceptable si està per sobre d’una relació senyal soroll determinada ni que d’altra banda si es troba per sota, és forçosament inacceptable. La decisió no és tan digital, sinó que admet un cert grau de tolerància que pot ser més o menys estricte en funció del contingut de la imatge; objectes que hi surten, nombre de colors, variació d’aquests, contrast, etc....
Si passem a examinar seqüències hem de considerar també la variació temporal. Si es vol estudiar una seqüència, s’han de tenir en compte les seves característiques pel que fa a la variació temporal de les imatges que la composen. No és el mateix una escena d’una pel·lícula de molta acció, on els canvis de pla són molt seguits, que considerar un escena lenta d’una pel·lícula romàntica o un locutor de telenotícies, on la variació d’una imatge a la següent és pràcticament nul·la. Així doncs, sembla interessant fer un estudi tipificat de les diferents seqüències que ens podem trobar i intentar esbrinar quins són els paràmetres òptims que ens permeten visualitzar i transmetre cadascuna d’aquestes seqüències amb una qualitat acceptable.
Per a l’estudi de seqüències de vídeo serà necessària un programari que ens permeti capturar seqüències, visualitzar-les, codificar-les de diferents maneres, i avaluar subjectivament i objectivament la seva qualitat. Serà necessari també avaluar i comparar el nombre de bits utilitats en cada quadre. A continuació es proposaran una sèrie d’exercicis bàsics per conèixer el programari que ens permetrà realitzar l’estudi de diferents seqüències.
Javier de la Rica Comunicaciones Multimedia 6.3.1 Anàlisi de la codificació de vídeo MPEG-2 Realitzar el següents exercicis i comenta el programari que es fa servir i els resultats obtinguts. En cada cas s’ha de discutir quines opcions s’han aplicat i s’han de comentar els resultats de la forma més gràfica possible.
telematic@telem:~$ cd /home/telematic/streams telematic@telem:~/streams$ ls audio/ Silent-Heart-Track2.wav BigBuckBunny_640x360.mp4 test.264 HaleakalaSunset-14.mpg berni.mpg sintel.m2v big_buck_bunny.mp4 test.ts HaleakalaSunset.mpg big_1000.mpg sintel_trailer-1080p.mp4 big_buck_bunny.webm transport-mpeg/ HaleakalaSunset.mpg1 big_320_x180_CBR_400K+32K.ts bipbop-gear1-all.ts sintel_trailer-1080p.ogv tv_watching_t1.rm pcmar_1000.mpg big_664.mpg sintel_trailer.m2v bipbop-gear1-all.tsx Video-Galileo-AVC-2003-182.rm pcmar_664.mpg BigBuckBunny_272x144.m2v Star_Wreck_UK_trailer.MP4 dashevc-ondemand-20s-v1.mp4 warriors-700-sp-VBR.mpg* ScienceCommons.mpg BigBuckBunny_640x360.m4v@ Track2.mp3 surfing.265 ed_hd_512kb.mp4 Silent-Heartwarriors-700-sp-VBR.ogv A. Fent servir el programari dvdview i un arxiu MPEG2 (extensió .mpg) Comprova prèviament les opcions del programari fent: dvdview -h telematic@telem:~$ dvdview -h DVDview 1.2.1 30.Nov.2001 (c) Dirk Farin -----------------------------------------------usage: dvdview <options> filename.mpg Options: -B Skip B-frames -P Skip P-frames (and B-frames) -T # Set speed (100 for realtime, >100 for faster) -L Disable time synchronization. Decodes as fast as possible.
-S # Set output size.
-N # Number of frames to decode -v # Enable logging level (0 <= # <= 7) 0 - off 1 - sequence headers 2 - gop headers 3 - picture headers 4 - slice headers 5 - macroblocks Javier de la Rica Comunicaciones Multimedia 6 - DCT coefficients 7 - binary slice data -F Write PPM sequence rather than display stream contents.
-J Write JPEG sequence rather than display stream contents.
-Y s Write single YUV file rather than display stream contents.
-W s Write YUV with additional header information to file 's'.
-U s Bind DVDview input to a UDP port.
-M Show macroblock boundaries (twice for bigger marks).
-d Show boundary as dark pixels.
-l Show boundary as bright pixels.
-Q Show QScale of macroblocks.
-V Show motionvectors of macroblocks (vectors).
-C Show motionvectors of macroblocks (colors).
-p Enable vectors in P-frames.
-b Enable vectors in B-frames.
-c Show colored motionvectors.
-f Enable forward vectors.
-r Enable backward vectors.
-O hold mode -s Show decoder speed in fps.
-n Show frame-number.
-R Rotate image display 90 degrees.
-0 Suppress all video output.
-A Extract audio-stream to stdout. Pipe this into mpg123.
-3 Extract AC3-stream to stdout. Pipe this into ac3dec.
-a # -h select AC3-stream (0-7) default is 0.
Show this usage information - - - - - - Linux only features - - - - - - -D # Play VideoCD track rather that MPEG file (omit filename) -X Use X11 output even when MGA_VID is available.
Javier de la Rica Comunicaciones Multimedia 1. analitza gràficament: ▪ l’estructura de la imatge en MacroBlocks $ dvdview -T 100 -M -b HaleakalaSunset.mpg Se puede observar la reproducción con una separación entre MacroBlocks ▪ els valors del quantificador en els MacroBlocks $ dvdview -T 50 -Q -s HaleakalaSunset.mpg Javier de la Rica Comunicaciones Multimedia Se puede apreciar una reproducción del mismo contenido multimedia pero más lenta, observándose a su vez un escalado de los macrobloques.
2. analitza el fitxer de traces Sunset_traze.txt resultant del dvdview ▪ genera el fitxer de traces: $ dvdview -L -Q -s -v 4 -N 200 HaleakalaSunset.mpg > Sunset_traze.txt ▪ edita el fitxer text: $ gedit Sunset_traze.txt & a. Estudiant el fitxer de traces resultant, determina: ▪ Mitjançant la capçalera de la seqüència: la resolució, el número de frames per second, el màxim bitrate i el submostreig de croma aplicat. Indica el número de MacroBlocks (MB) que té una imatge de la seqüència.
SequenceHeader: MPEG-2: true width: 640 height: 480 aspect code: 1 framerate: bitrate: 30.0 3750 VBV buf.size: 112 constrained: false profile: Main level: Main progr. seq.: true chroma format:4:2:0 low delay: false La cabecera de secuencia indica los parámetros propios del vídeo. Dichos parámetros no se cambian.
Se puede observar que la resolución es de 30 frames per second, con un bitrate máximo de 3750 y un submuestreo de croma aplicado de 4:2:0.
Para el cálculo del número de MacroBlocks de una imagen se hace uso del ancho y altura de la imagen, teniendo en cuenta que cada MacroBlock está constituido por 16 píxels.
𝑊𝑖𝑑𝑡ℎ 𝐻𝑒𝑖𝑔ℎ𝑡 640 480 · = · = 1200 𝑀𝑎𝑐𝑟𝑜𝐵𝑙𝑜𝑐𝑘𝑠 16 16 16 16 Mitjançant la capçalera del GOP: la duració temporal dels 10 primers GOPs.
#𝑀𝑎𝑐𝑟𝑜𝐵𝑙𝑜𝑞𝑢𝑒𝑠 = ▪ El format de presentació és: HH:MM:SS.frame_times Javier de la Rica Comunicaciones Multimedia $ cat Sunset_traze.txt | grep Timecode telematic@telem:~/streams$ cat Sunset_traze.txt | grep Timecode Timecode: 0:00:00.00 Timecode: 0:00:00.15 Timecode: 0:00:01.00 Timecode: 0:00:01.15 Timecode: 0:00:02.00 Timecode: 0:00:02.15 Timecode: 0:00:03.00 Timecode: 0:00:03.15 Timecode: 0:00:04.00 Timecode: 0:00:04.15  Timecode: 0:00:05.00 Timecode: 0:00:05.15 Timecode: 0:00:06.00 Timecode: 0:00:06.15 La cabecera de GOP contiene la información temporal del vídeo.
Time Code: hora:min:seg.#imag También sirve para saber cuándo se puede hacer un cambio de calidad.
▪ Mitjançant la capçalera del frame: el tipus de codificació de cada imatge, el patró de codificació per GOP, donant els valors N i M, i la posició temporal de cada imatge en el GOP.
$ cat Sunset_traze.txt | grep 'picture_coding_type\|reference' telematic@telem:~/streams$ cat Sunset_traze.txt | grep 'picture_coding_type\|reference' temporal reference: 0 picture_coding_type: I  temporal reference: 3 picture_coding_type: P temporal reference: 1 picture_coding_type: B temporal reference: 2 picture_coding_type: B temporal reference: 6 picture_coding_type: P temporal reference: 4 picture_coding_type: B temporal reference: 5 Javier de la Rica Comunicaciones Multimedia picture_coding_type: B temporal reference: 8 picture_coding_type: P temporal reference: 7 picture_coding_type: B temporal reference: 11 picture_coding_type: P temporal reference: 9 picture_coding_type: B temporal reference: 10 picture_coding_type: B temporal reference: 14 picture_coding_type: P temporal reference: 12 picture_coding_type: B temporal reference: 13 picture_coding_type: B temporal reference: 2 picture_coding_type: I  temporal reference: 0 picture_coding_type: B [...] Tipo de codificación de cada imagen: Se aplican las técnicas.
Intra-Coding (I) Predictive-Coding (P) Bidirectional Predictive-Coding (B) Éste tipo de codificación requiere mucha más CPU que en imagen. Cada trama se comprime de forma independiente al resto de tramas ofreciendo una edición no lineal.
En el presente ejercicio se trabaja con GOPs abiertos para codificarlos, ya que no se encuentra una P adicional al final de cada GOP. En caso de querer cambiar posteriormente la calidad de cada GOP por separado, sí será necesario cerrarlos y trabajar en grupos cerrados.
Patrón: I B B P B B P B B P B B P B B I B B P B B P B B P B B […] N = 15 (IBBPBBPBBPBBPBBI) - Distancia de I a I.
M = 3 (IBB - PBB) (Distancia de I a P o de P a P) Posición temporal de cada imagen: En el primer GOP en el analizador saldrá que tiene menos imágenes que el resto. En cuestión tendrá N-2 imágenes. No obstante, en el presente caso se puede observar que el primer GOP tiene exactamente el mismo número de Javier de la Rica Comunicaciones Multimedia imágenes que el resto, ya que el codificador lo ha arreglado poniendo una secuencia PB por el medio.
Al añadir los B se introduce un retardo por proceso de codificación y decodificación en la posición temporal de cada imagen. El precio a pagar a parte de dicho retardo es la necesidad de más memoria, ya que se necesita una I y una P para codificar, y más CPU. Por otra parte, se gana una reducción del ancho de banda.
Éste retardo se puede observar, ya que el orden de captura no es el mismo que el orden de decodificación: El orden de captura sería IBBPBBPBBPBBP […]. EN cambio, el orden de decodificación es IPBBPBBPBB […]. Éste retardo es debido a que las imágenes B no pueden ser codificadas sin haber sido codificadas antes una imagen anterior I y una posterior P, con lo que se espera a codificar una imagen P posterior para luego codificar las B correspondientes. Sin embargo, es necesario guardar el orden original para reproducir de forma correcta el vídeo.
▪ Mitjançant la capçalera de l’slice: el pas de quantificació per slice $ cat Sunset_traze.txt | grep quantiser quantiser scale code: 7 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 5 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 6 quantiser scale code: 6 Javier de la Rica Comunicaciones Multimedia quantiser scale code: 5 quantiser scale code: 7 La cabecera del slice permite resintonizar en caso de errores. Normalmente se mete en un paquete IP.
Se puede observar que el paso de cuantificación varía, ya que se ha forzado una tasa de salida constante. Así pues, el cuantificador debe adecuar el paso de cuantificación en función de la tasa de salida.
Dicho paso de cuantificación indica la complejidad de la imagen: A mayor complejidad, menor será el paso de cuantificación, para así perder la menor cantidad de información posible.
b.
Utilitzant les comandes cat, grep i cut, representa els valor que pren el codificador fent servir el programa de representació gràfica xmgrace.
( http://plasma-gate.weizmann.ac.il/Grace/doc/UsersGuide.html ) $ cat Sunset_traze.txt | grep quantiser | cut -f6 -d " " > quantizer_sunset.txt $ xmgrace -legend load quantizer_sunset.txt Indica el valors mínims i màxims que pren el codificador.
Como se ha podido observar el paso de cuantificación va variando. En el presente gráfico se puede ver que el codificador toma los valores entre aproximadamente 4 y 8, salvo al principio que toma valores como mínimo 3.
Javier de la Rica Comunicaciones Multimedia B. Fent servir el programari per codificació de vídeo MPEG-2 1. Compressió amb el programari ffmpeg Comprova prèviament les opcions del programari amb l’enllaç: https://www.ffmpeg.org/ffmpeg.html a.
Codifica en mpeg2 amb pas de quantització Q=1.
$ ffmpeg-086 -i ed_hd_512kb.mp4 -vcodec mpeg2video -g 1 -bf 0 -qscale 1 -vframes 1500 -psnr -vstats_file sta_ed_N1_M1_Q1 ed_N1_M1_Q1.m2v Analitza la complexitat del vídeo relacionant el bitrate amb la entropia de les imatges: time=00:01:02.45 bitrate=3714.5kbits/s $ bitrate ed_N1_M1_Q1.m2v | xmgrace Duration: 00:00:02.21, bitrate: 104857 kb/s En el gráfico adjunto se puede observar que mientras más complejidad (y por tanto, mayor entropía y menor paso de cuantificación), menor es el bitrate.
b.
Codifica en YUV (raw vídeo) $ ffmpeg-086 -i ed_hd_512kb.mp4 -vframes 1500 ed.yuv Indica el rati de compressió obtingut en la compressió mpeg2video fent servir la grandària dels fitxers: frame= 1500 fps= 43 q=0.0 Lsize= bitrate=29445.1kbits/s 224648kB time=00:01:02.50 video:224648kB audio:0kB global headers:0kB muxing overhead 0.000000% $ ls -l Javier de la Rica Comunicaciones Multimedia Se puede observar que el tamaño del archivo original ed.yuv es de 230040000 y por tanto el ratio de compresión es de aproximadamente 8.
230040000 𝑅𝑎𝑡𝑖𝑜 = = 7.9 29000287 c. Torna a codificar en mpeg2 amb N=1 i M=1 canviant el pas de quantificació a q=6 i, també, amb N=12 i N=36 amb codificació predictiva M=3 i pas Q=6. Compara el nivell de compressió resultant amb el casos anteriors.
$ ffmpeg-086 -i ed_hd_512kb.mp4 -vcodec mpeg2video -g 1 -bf 0 qscale 6 -vframes 1500 -psnr -vstats_file sta_ed_N1_M1_Q6 ed_N1_M1_Q6.m2v time=00:01:02.45 bitrate=1725.0kbits/s video:13152kB audio:0kB global headers:0kB muxing overhead 0.000000% $ ffmpeg-086 -i ed_hd_512kb.mp4 -vcodec mpeg2video -g 36 -bf 2 qscale 6 -vframes 1500 -psnr -vstats_file sta_ed_N36_M3_Q6 ed_N36_M3_Q6.m2v time=00:01:02.45 bitrate= 560.7kbits/s video:4275kB audio:0kB global headers:0kB muxing overhead 0.000000% $ ffmpeg-086 -i ed_hd_512kb.mp4 -vcodec mpeg2video -g 12 -bf 2 qscale 6 -vframes 1500 -psnr -vstats_file sta_ed_N12_M3_Q6 ed_N12_M3_Q6.m2v time=00:01:02.45 bitrate= 623.3kbits/s video:4752kB audio:0kB global headers:0kB muxing overhead 0.000000% Javier de la Rica Comunicaciones Multimedia ed_N1_M1_Q6.m2v: 𝑅𝑎𝑡𝑖𝑜 = 230040000 = 17 13467794 ed_N36_M3_Q6.m2v: 𝑅𝑎𝑡𝑖𝑜 = 230040000 = 52.54 4377885 𝑅𝑎𝑡𝑖𝑜 = 230040000 = 47.27 4866039 ed_N12_M3_Q6.m2v: Mientras menor sea el valor de N, es decir, el número de imágenes en un GoP, menor será la distancia entre imágenes codificadas intra-frame (I), y por tanto se obtendrá una mejor calidad (=Ratio más pequeño) 2. Extreu el bitrate temporal de les codificacions mpeg2 anteriors, amb Q=1 i Q=6, mitjançant el programa bitrate, de la forma; $ x="1";y="1";z="1"; bitrate ed_N$x\_M$y\_Q$z.m2v > bitrate_ed_N$x\_M$y\_Q$z [mpegvideo @ 0x863e800]max_analyze_duration reached [mpegvideo @ 0x863e800]Estimating duration from bitrate, this may be inaccurate Input #0, mpegvideo, from 'ed_N1_M1_Q1.m2v': Duration: 00:00:02.21, bitrate: 104857 kb/s Stream #0.0: Video: mpeg2video, yuv420p, 426x240 [PAR 1:1 DAR 71:40], 104857 kb/s, 24 fps, 24 tbr, 1200k tbn, 48 tbc stream: 0 = 0 () Frame Rate: 24 $ x="1";y="1";z="6"; bitrate ed_N$x\_M$y\_Q$z.m2v > bitrate_ed_N$x\_M$y\_Q$z [mpegvideo @ 0x8cba800]max_analyze_duration reached [mpegvideo @ 0x8cba800]Estimating duration from bitrate, this may be Javier de la Rica Comunicaciones Multimedia inaccurate Input #0, mpegvideo, from 'ed_N1_M1_Q6.m2v': Duration: 00:00:01.02, bitrate: 104857 kb/s Stream #0.0: Video: mpeg2video, yuv420p, 426x240 [PAR 1:1 DAR 71:40], 104857 kb/s, 24 fps, 24 tbr, 1200k tbn, 48 tbc stream: 0 = 0 () Frame Rate: 24 $ x="12";y="3";z="6"; bitrate ed_N$x\_M$y\_Q$z.m2v > bitrate_ed_N$x\_M$y\_Q$z [mpegvideo @ 0x9678800]max_analyze_duration reached [mpegvideo @ 0x9678800]Estimating duration from bitrate, this may be inaccurate Input #0, mpegvideo, from 'ed_N12_M3_Q6.m2v': Duration: 00:00:00.37, bitrate: 104857 kb/s Stream #0.0: Video: mpeg2video, yuv420p, 426x240 [PAR 1:1 DAR 71:40], 104857 kb/s, 24 fps, 24 tbr, 1200k tbn, 48 tbc stream: 0 = 0 () Frame Rate: 24 $ x="36";y="3";z="6"; bitrate ed_N$x\_M$y\_Q$z.m2v > bitrate_ed_N$x\_M$y\_Q$z [mpegvideo @ 0x950c800]max_analyze_duration reached [mpegvideo @ 0x950c800]Estimating duration from bitrate, this may be inaccurate Input #0, mpegvideo, from 'ed_N36_M3_Q6.m2v': Duration: 00:00:00.33, bitrate: 104857 kb/s Stream #0.0: Video: mpeg2video, yuv420p, 426x240 [PAR 1:1 DAR 71:40], 104857 kb/s, 24 fps, 24 tbr, 1200k tbn, 48 tbc stream: 0 = 0 () Frame Rate: 24 Representa gràficament els resultats en una gràfica amb el programari xmgrace: $ xmgrace -legend load -batch bitrate-graph.dat bitrate_ed_N1_M1_Q1 bitrate_ed_N12_M3_Q6 bitrate_ed_N36_M3_Q6 bitrate_ed_N1_M1_Q6 Explica, de forma comparada, els valors que prenen les diferents corves de bitrate representades.
Javier de la Rica Comunicaciones Multimedia Por un lado, la curva de color negro corresponde a una codificación totalmente intra (N=1, M=1, Q=1), y por tanto la calidad obtenida es ideal. Dicha curva viene definida por la complejidad y el movimiento de las tramas, y por tanto en las zonas en las que hay más movimiento y por tanto alta entropía, se aumenta el bitrate.
Por otro lado, para la curva de color azul, en la que únicamente se le ha aumentado el paso de cuantificación respecto a la anterior, se pierde información y por tanto calidad, pero se gana en bitrate. Es decir, se necesita un bitrate menor para transmitir la misma cantidad de frames.
Por último, en las curvas de color rojo y verde, en las que se ha aumentado considerablemente el número de tramas por GoP, y por tanto hay codificaciónbidireccionalmente predictiva y predictiva, ya que M=3, se puede observar que no es muy efectiva para las zonas en las que hay varios cambios.
Se puede observar que la probabilidad de error es mayor para la curva de color verde que para la roja, es decir, mientras más frames se codifiquen por GoP, mayor será la probabilidad de pérdida.
3. Analitza per separat els bits de cada frame per cada mode de codificació (I, P o B) i compara temporalment el seu valor. Genera per cada mode de codificació un fitxer de grandària de les frames de la forma: $ X="I" ;cat sta_ed_N12_M3_Q6 | grep "type= $X" | cut -f2,5 -d "=" | cut -f1 -d "s" | sed 's/q=//' > ed_type_$X\_frame_size.txt $ X="P" ;cat sta_ed_N12_M3_Q6 | grep "type= $X" | cut -f2,5 -d "=" | cut -f1 -d "s" | sed 's/q=//' > ed_type_$X\_frame_size.txt $ X="B" ;cat sta_ed_N12_M3_Q6 | grep "type= $X" | cut -f2,5 -d "=" | cut -f1 -d "s" | sed 's/q=//' > ed_type_$X\_frame_size.txt Després representa amb una única gràfica els tres fitxers Javier de la Rica Comunicaciones Multimedia $ xmgrace -legend load ed_type_I_frame_size.txt ed_type_P_frame_size.txt ed_type_B_frame_size.txt Explica quan és més efectiva la codificació predictiva P o B en funció de la activitat de les escenes o complexitat de les imatges.
La codificación predictiva ocupa menos espacio que la codificación intra. La codificación bidireccionalmente predictiva (B), introduce vectores de movimiento hacia ambos sentidos, siendo muy útil en situaciones en las que aparecen objetos nuevos en una escena y no se pueden predecir únicamente con la predicción backwards (P).
Sin embargo, la codificación bidireccionalmente predictiva (B) tiene el inconveniente de introducir un cierto retardo en la decodificación, ya que necesita tener en memoria tramas I y tramas P, y por tanto, para los sistemas interactivos como pueden ser videoconferencias, sería preferible únicamente una codificación predictiva simple (P).
4. Comparació per diferents passos de quantificació a.
Codifica amb Q = 4, 8, 15, 25 la seqüència de referència “ed_N1_M1_Q1.m2v” fixant el pas Q en cada cas de la forma: $ Q=4; ffmpeg-086 -i ed_N1_M1_Q1.m2v -vcodec mpeg2video -g 6 -bf 1 -qscale $Q -psnr -vstats_file sta_ed_N6_M2_Q$Q ed_N6_M2_Q$Q.m2v frame= 1500 fps= 77 q=4.0 LPSNR=Y:41.69 U:50.10 V:49.37 *:43.12 size=7732kB time=00:01:02.45 bitrate=1014.1kbits/s video:7732kB audio:0kB global headers:0kB muxing overhead 0.000000% Javier de la Rica Comunicaciones Multimedia $ Q=8; ffmpeg-086 -i ed_N1_M1_Q1.m2v -vcodec mpeg2video -g 6 -bf 1 -qscale $Q -psnr -vstats_file sta_ed_N6_M2_Q$Q ed_N6_M2_Q$Q.m2v frame= 1500 fps= 73 q=8.0 LPSNR=Y:37.54 U:47.81 V:46.86 *:39.07 size= 4113kB time=00:01:02.45 bitrate= 539.4kbits/s video:4113kB audio:0kB global headers:0kB muxing overhead 0.000000% $ Q=15; ffmpeg-086 -i ed_N1_M1_Q1.m2v -vcodec mpeg2video -g 6 -bf 1 -qscale $Q -psnr -vstats_file sta_ed_N6_M2_Q$Q ed_N6_M2_Q$Q.m2v frame= 1500 fps= 68 q=15.0 LPSNR=Y:34.14 U:46.24 V:44.87 *:35.75 size=2425kB time=00:01:02.45 bitrate= 318.0kbits/s video:2425kB audio:0kB global headers:0kB muxing overhead 0.000000% $ Q=25; ffmpeg-086 -i ed_N1_M1_Q1.m2v -vcodec mpeg2video -g 6 -bf 1 -qscale $Q -psnr -vstats_file sta_ed_N6_M2_Q$Q ed_N6_M2_Q$Q.m2v frame= 1500 fps= 64 q=25.0 LPSNR=Y:31.83 U:45.32 V:43.65 *:33.47 size= 1733kB time=00:01:02.45 bitrate= 227.2kbits/s video:1733kB audio:0kB global headers:0kBmuxing overhead 0.000000% Fent servir els resultats presentats al terminal pel codificador en cada cas, estableix amb una taula: el rati de compressió (en relació a la grandària del fitxer YUV), el PSNR de la seqüència i el bitrate mig.s Para calcular el ratio de compresión es necesario conocer el tamaño del fichero creado y el tamaño del fichero YUV.
El tamaño del fichero YUV es de 230040000 bits.
Por tanto, el ratio de compresión será el cociente del tamaño de dicho fichero con el tamaño del fichero correspondiente en cada caso.
Por ejemplo, para el primer caso, con Q = 4, el ratio será el siguiente: 𝑅𝑎𝑡𝑖𝑜1 = Q Ratio PSNR bitrate (Kbits/s) 4 3,17 43,12 1014,1 230040000 = 3.71 7732𝑘𝐵 · 8𝑏 8 6,99 39,07 539,4 15 11,85 35,75 318 25 16,59 33,47 227,2 Javier de la Rica Comunicaciones Multimedia Realitza una gràfica separada per cada una de 3 magnituds (rati de compressió, PSNR i el bitrate mig), mitjançant el programari gnumeric, de la forma: Figure 6: PSNR i rati de compressió en funció de Q Ratio de Compresión en función del paso de cuantif, Q PSNR en función del paso de cuantificación Q Bitrate en función del paso de cuantificación Q Javier de la Rica Comunicaciones Multimedia Explica les gràfiques obtingudes.
A medida que se aumenta el paso de cuantificación Q, la compresión del archivo multimedia es mayor, y por tanto el ratio de compresión aumenta.
Paralelamente, puesto que la compresión es mayor, se pierde más información, motivo por el cual el PSNR decrece a medida que Q aumenta.
El bitrate también es inversamente proporcional al paso de cuantificación, puesto que para un paso de cuantificación mayor, el bitrate disminuye considerablemente.
b.
Compara els valors resultants de bitrate i PSNR processant els fitxer d’estadístiques generats durant cada codificació (sta_ed_N6_M2_Q?) mitjançant els scripts: $ extract-bitrates.sh telematic@telem:~/work/mpeg-system$ extract-bitrates.sh Q : 4 output file -> bitrate_ed_N6_M2_Q4 Q : 8 output file -> bitrate_ed_N6_M2_Q8 Q : 15 output file -> bitrate_ed_N6_M2_Q15 Q : 25 output file -> bitrate_ed_N6_M2_Q25 $ extract-psnrs.sh telematic@telem:~/work/mpeg-system$ extract-psnrs.sh Q : 4 output file -> psnr_ed_N6_M2_Q4 Q : 8 output file -> psnr_ed_N6_M2_Q8 Q : 15 output file -> psnr_ed_N6_M2_Q15 Q : 25 output file -> psnr_ed_N6_M2_Q25 Representa amb dos gràfiques el bitrate i PSNR de tots els resultats de les codificacions fent servir: $ xmgrace -legend load -batch bitrate-graph.dat bitrate_ed_N6_M2_Q4 bitrate_ed_N6_M2_Q8 bitrate_ed_N6_M2_Q15 bitrate_ed_N6_M2_Q25 & $ xmgrace -legend load -batch psnr-graph.dat psnr_ed_N6_M2_Q4 psnr_ed_N6_M2_Q8 psnr_ed_N6_M2_Q15 psnr_ed_N6_M2_Q25 & Comenta la dependència dels resultats en funció de la complexitat de la seqüència i el pas de quantificació aplicat.
Javier de la Rica Comunicaciones Multimedia Bitrate en función del paso de cuantificación PSNR en función del paso de cuantificación En el presente caso se observa el bitrate en función de la complejidad y del paso de cuantificación. Se puede observar que a medida que aumenta el paso de cuantiificación, disminuye el bitrate. Por otro lado, a medida que éste último (bitrate) disminuye, también disminuye el PSNR.
Conclusión: Paso de cuantificación (Q) alto → Bitrate bajo → PSNR bajo Paso de cuantificación (Q) bajo → Bitrate alto → PSNR alto Javier de la Rica Comunicaciones Multimedia 6.3.2 Codificació CBR i VBR Transcodifica la seqüència BigBuckBunny_640x360.mp4 a mpeg2 utilitzant el programa ffmpeg de les següents maneres: CBR - Constant Bit Rate $ ffmpeg-086 -ss 500 -i BigBuckBunny_640x360.mp4 -s 640x360 -aspect 16:9 -vcodec mpeg2video -g 12 -bf 2 -b 1000k -minrate 1000k -maxrate 1000k bufsize 500k -psnr -vframes 9000 -vstats_file sta_BB_CBR_N12_M3_1M BigBuckBunny_V_640x360_N12_M3_CBR_1M.m2v frame= 2317 fps= 30 q=2.8 LPSNR=Y:29.25 U:47.88 V:47.01 *:30.98 size= 11780kB time=00:01:36.50 bitrate=1000.1kbits/s dup=0 drop=88 video:11780kB audio:0kB global headers:0kB muxing overhead 0.000000% VBR - Variable Bit Rate $ ffmpeg-086 -ss 500 -i BigBuckBunny_640x360.mp4 -s 640x360 -aspect 16:9 -vcodec mpeg2video -g 12 -bf 2 -qscale 8 -psnr -vframes 9000 -vstats_file sta_BB_VBR_N12_M3_Q8 BigBuckBunny_V_640x360_N12_M3_VBR_Q8.m2v frame= 2317 fps= 40 q=8.0 LPSNR=Y:36.47 U:46.91 V:46.60 *:38.03 size= 18152kB time=00:01:36.50 bitrate=1540.9kbits/s dup=0 drop=88 video:18152kB audio:0kB global headers:0kB muxing overhead 0.000000% 1. Observa els detalls de les codificacions fent servir el programari mpginfo per cada cas (CBR i VBR): $ mpginfo BigBuckBunny_V_640x360_N12_M3_XXX.m2v CBR - Constant Bit Rate telematic@telem:~/work/mpeg-system$ mpginfo BigBuckBunny_V_640x360_N12_M3_CBR_1M.m2v BigBuckBunny_V_640x360_N12_M3_CBR_1M.m2v Mpeg 2 Video File Estimated Duration: 01:36.51s Aspect ratio 1/1 (VGA) Not interlaced, chroma format: 4:2:0 Size [640 x 360] 24.00 fps 1.00 Mbps VBR - Variable Bit Rate telematic@telem:~/work/mpeg-system$ mpginfo BigBuckBunny_V_640x360_N12_M3_VBR_Q8.m2v BigBuckBunny_V_640x360_N12_M3_VBR_Q8.m2v Mpeg 2 Video File Estimated Duration: 01.42s Aspect ratio 1/1 (VGA) Not interlaced, chroma format: 4:2:0 Size [640 x 360] 24.00 fps 104.86 Mbps Javier de la Rica Comunicaciones Multimedia Comenta els resultats obtinguts.
Se puede observar que la diferencia entre la codificación CBR y VBR reside en la cantidad de bits por segundo.
Por un lado, cabe destacar que en el caso de CBR (Constant Bit Rate), las tramas por segundo están fijadas a una velocidad constante (1Mbps en este caso), permitiendo así una cuantificación variable según la complejidad de la escena.
Por otro lado, en el caso del VBR (Variable Bit Rate), en lugar de fijar el bitrate se fija el paso de cuantificación Q, dejando el bitrate variable en función de la complejidad de la escena. Esto permite una calidad mayor requiriendo a cambio un tiempo mayor de procesamiento.
2. Analitza els fitxers de resultats estadístics a.
Calcula i compara el bitrate suavitzat de les dues codificacions $ cat sta_BB_CBR_N12_M3_1M | skipfilter.sh 8 25 12 62.5 > bitrate_BB_CBR_N12_M3_1M $ cat sta_BB_VBR_N12_M3_Q8 | skipfilter.sh 8 25 12 62.5 > bitrate_BB_VBR_N12_M3_Q8 $ xmgrace -legend load -batch bitrate-graph.dat bitrate_BB_VBR_N12_M3_Q8 bitrate_BB_CBR_N12_M3_1M Comparación bitrate CBR y VBR..
Se puede comprobar fácilmente que para el caso del CBR (Constant Bit Rate) se obtiene un bitrate constante, mientras que para el VBR se obtiene un bitrate variable que dependerá de la complejidad de la escena en concreto, necesitando un bitrate mayor para aquellas escenas más complejas con más variaciones (y por tanto, una entropía mayor) Javier de la Rica Comunicaciones Multimedia b.
Compara gràficament el pas de quantificació suavitzat en funció del temps aplicat durant les codificacions $ cat sta_BB_CBR_N12_M3_1M | skipfilter.sh 4 25 12 12 > quant_BB_CBR_N12_M3_1M $ cat sta_BB_VBR_N12_M3_Q8 | skipfilter.sh 4 25 12 12 > quant_BB_VBR_N12_M3_Q8 $ xmgrace -legend load -batch quant-graph.dat quant_BB_VBR_N12_M3_Q8 quant_BB_CBR_N12_M3_1M Comparación cuantificador CBR y VBR.
Se puede observar como la cuantificación es perfectamente constante en el caso de VBR, mientras que para CBR la cuantificación caría en función de la complejidad de la escena.
c.
Compara gràficament el PSNR suavitzat resultant de les dues codificacions en funció del temps $ cat sta_BB_CBR_N12_M3_1M | skipfilter.sh 6 25 12 12 > psnr_BB_CBR_N12_M3_1M $ cat sta_BB_VBR_N12_M3_Q8 | skipfilter.sh 6 25 12 12 > psnr_BB_VBR_N12_M3_Q8 Javier de la Rica Comunicaciones Multimedia $ xmgrace -legend load -batch psnr-graph.dat psnr_BB_VBR_N12_M3_Q8 psnr_BB_CBR_N12_M3_1M Comparación PSNR entre CBR y VBR.
Con los resultados obtenidos hasta el punto actual, se puede deducir que, en el caso del CBR, ya que el paso de cuantificación Q varía en función de la complejidad y por tanto la calidad de la imagen varía con dicho paso de cuantificación, CBR tiene mayor error, y por tanto un menor PSNR cuando aparecen escenas de alta complejidad.
Análogamente, en el caso de VBR, ya que el paso de cuantificación es completamente constante independientemente de la complejidad de la escena en un momento determinado, el error producido es menor que en CBR, y por tanto obtiene una PSNR mayor en las escenas de mayor complejidad.
Javier de la Rica Comunicaciones Multimedia 6.4 Capa de sistema MPEG-2 Transcodifica la seqüència amb vídeo i àudio de mpeg4 a mpeg2 utilitzant el programa ffmpeg: $ ffmpeg-086 -i BigBuckBunny_640x360.mp4 -s 640x360 -aspect 16:9 -vcodec mpeg2video -g 18 -bf 3 -b 2000k -minrate 2000k -maxrate 2000k -bufsize 500k -psnr -acodec mp2 -ab 192k -vframes 1200 -f vob BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg frame= 1200 fps= 10 q=5.6 LPSNR=Y:36.63 U:40.32 V:42.26 *:37.69 size= 13560kB time=00:00:49.95 bitrate=2223.5kbits/s video:12215kB audio:1172kB global headers:0kB muxing overhead 1.288855% Visualitza el contingut de l’Stream de Programa resultant: $ ffplay BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg Javier de la Rica Comunicaciones Multimedia 6.4.1 Anàlisi de Program Stream Avalua els resultats de la multiplexació de Programa a partir dels resultats dels següents programaris: A.
tcprobe $ tcprobe -X -i BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg * container: format: MPEG program stream (PS) source: 'BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg' frames: 0 duration: 0:00:00.000 SCR reset: 1 * video track #0: format: MPEG-2 frame size: 640x368 aspect ratio: 1:1 (asr=1) frame rate: 24.000 (frc=2) bitrate: 2000 kbps starting PTS: 1.0000 frame time: 41 ms * audio track #0: track id: 0 format: 0x50 channels: 2 sample rate: 44100 Hz bits for sample: 16 bitrate: 192 kbps starting PTS: 1.0000 A/V sync hint: 0 frames/0 ms subtitles: no B.
bbdmux $ bbdmux BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg bbdmux - version 1.9, by Brent Beyeler (beyeler@home.com) speed increases by, Apachez and Christian Vogelgsang Scanning for stream id's, press control-c to quit ...
File BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg is an MPEG-2 Program Stream Found stream id 0xE0 = Video Stream 0 Found stream id 0xC0 = MPEG Audio Stream 0 Javier de la Rica Comunicaciones Multimedia Found stream id 0xBE = Padding Stream Summary: MPEG Packs = 6780 System headers = 170 Padding Stream packets = 1, total bytes = 421 MPEG Audio stream 0 packets = 595, total bytes = 1200587 Video stream 0 packets = 6185, total bytes = 12508167 C.
mpgtx $ mpgtx -i BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg Mpeg 2 Program Stream File [Video/Audio] Muxrate : 2.31 Mbps Estimated Duration: 50.71s Checking all time stamps (This may take a while.) ...
Time line seems to be ok.
Aspect ratio 1/1 (VGA) Not interlaced, chroma format: 4:2:0 Size [640 x 360] 24.00 fps 2.00 Mbps Audio : Mpeg 1 layer 2 192 kbps Stereo, D.
dvbsnoop 44100 Hz No emphasis (Consulta: http://dvbsnoop.sourceforge.net/) $ dvbsnoop -s ps -nph -npd -ph 0 -pd 9 -if BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg >traze_1.txt * container: format: MPEG program stream (PS) source: 'BigBuckBunny_V_640x360_N6_M2_CBR_2M+A_CBR_MP2_192k.mpg' frames: 0 duration: 0:00:00.000 SCR reset: 1 * video track #0: format: MPEG-2 frame size: 640x368 aspect ratio: 1:1 (asr=1) frame rate: 24.000 (frc=2) bitrate: 2000 kbps starting PTS: 1.0000 frame time: 41 ms * audio track #0: track id: 0 format: 0x50 channels: 2 Javier de la Rica Comunicaciones Multimedia sample rate: bits for sample: bitrate: starting PTS: A/V sync hint: subtitles: 44100 Hz 16 192 kbps 1.0000 0 frames/0 ms no Editant el fitxer de continguts: $ gedit traze_1.txt & Respon a les següents qüestions: a. Tipus de paquets multiplexats identificats pel camp: Stream_id Se pueden encontrar cuatro tipos de paquetes multiplexados a lo largo del Fichero:.
0xba - Pack Header Code – MPEG pack start (PS) 0xbb - System Header Code – MPEG system header start (PS) 0xc0 - MPEG-1 o MPEG-2 audio stream 0xe0 - MPEG-1 o MPEG-2 video stream b. Quan és la grandària dels paquets PES d’àudio i vídeo, per què tenen aquestes mides en el Program Stream en format “vob”? PES_packet_length: 2028 Vob: son los archivos que almacenan los contenidos de un DVD. No ocupan más de 1GB.
c. On s’indica que hi ha un únic stream d’àudio i un de vídeo? El número de streams de audio y vídeo que hay se encuentra en la cabecera del MPEG system header start (PS), y corresponde a audio_bound y videobound Javier de la Rica Comunicaciones Multimedia d. En els paquets d’àudio quan apareix el camp: PTS, per què serveix? Presentation Time Stamp (PTS): Indica cuando una unidad de acceso debe ser reproducida.
e. En els paquets de vídeo quan apareix el camp: DTS, per què serveix? Decoding Time Stamp (DTS): Indica cuando el paquete debe ser decodificado (únicamente en el caso de vídeo) f.
Quin element permet sincronitzar l’àudio i el vídeo. On es codifica aquest element? El element que permite sincronizar el audio y el vídeo es el ESCR (Elementary Stream Clock Reference). Éste se encuentra en la cabecera del paquete PES.
6.4.2 Anàlisi de Transport Stream A. Genera un Single Transport Stream amb un únic Elementary Stream d’àudio i analitza el resultat: Generació: $ ffmpeg-086 -i sintel_trailer-1080p.mp4 -vn -acodec mp2 alang eng -mpegts_service_id 21 -mpegts_pmt_start_pid 0x0100 -mpegts_start_pid 0x0200 -mpegts_original_network_id 16 metadata service_provider="Telematic Provider" -metadata service_name="Audio Channel Sintel" -f mpegts sintel_audio_16k.ts ffmpeg version 0.8.6, Copyright (c) 2000-2011 the FFmpeg developers built on Nov 16 2011 15:58:04 with gcc 4.5.2 configuration: --prefix=/usr/local libavutil 51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2. 0. 0 / 2. 0. 0 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/telematic/work/mpegsystem/streams/sintel_trailer-1080p.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 creation_time : 1970-01-01 00:00:00 title : Sintel Trailer artist : Durian Open Movie Team encoder : Lavf52.62.0 copyright : (c) copyright Blender Foundation | durian.blender.org description : Trailer for the Sintel open movie project Duration: 00:00:52.20, start: 0.000000, bitrate: 2240 kb/s Stream #0.0(und): Video: h264 (High), yuv420p, 1920x1080, 2108 kb/s, 24 fps, 24 tbr, 24 tbn, 48 tbc Metadata: creation_time : 1970-01-01 00:00:00 Stream #0.1(und): Audio: aac, 48000 Hz, stereo, s16, 126 kb/s Metadata: creation_time : 1970-01-01 00:00:00 [mpegts @ 0xa3e1040] muxrate VBR, pcr every 4 pkts, sdt every 200, pat/pmt every 40 pkts Output #0, mpegts, to 'sintel_audio_16k.ts': Javier de la Rica Comunicaciones Multimedia Metadata: service_provider: Telematic Provider service_name : Audio Channel Sintel major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 creation_time : 1970-01-01 00:00:00 title : Sintel Trailer artist : Durian Open Movie Team description : Trailer for the Sintel open movie project copyright : (c) copyright Blender Foundation | durian.blender.org encoder : Lavf53.4.0 Stream #0.0(eng): Audio: mp2, 48000 Hz, stereo, s16, 64 kb/s Metadata: creation_time : 1970-01-01 00:00:00 Stream mapping: Stream #0.1 -> #0.0 Press [q] to stop, [?] for help size= 448kB time=00:00:51.96 bitrate= 70.6kbits/s video:0kB audio:406kB global headers:0kB muxing overhead 10.263664% 1. Analitza els resultats obtinguts amb el programari: $ tsinfo sintel_audio_16k.ts Reading from sintel_audio_16k.ts Scanning 1000 TS packets Packet 2 is PAT Program list: Program 21 -> PID 0100 (256) Packet 3 is PMT with PID 0100 (256) Program 21, version 0, PCR PID 0200 (512) Program streams: PID 0200 ( 512) -> Stream type 03 ( 3) 11172-3 audio (MPEG-1) ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng Found 48 PAT packets and 24 PMT packets in 1000 TS packets $ bbdmux sintel_audio_16k.ts bbdmux - version 1.9, by Brent Beyeler (beyeler@home.com) speed increases by, Apachez and Christian Vogelgsang Scanning for PID's, press control-c to quit ...
File sintel_audio_16k.ts is an MPEG-2 Transport Stream Found Found Found Found PID PID PID PID 0x0011, 0x0000, 0x0100, 0x0200, Other Stream Program Association Table Stream Other Stream stream id 0xC0 = MPEG Audio Stream 0 Summary: MPEG Transport Packets = 2438 PID 0x0000, Program Association Table packets = 58, total bytes = 10672 PID 0x0011, Other packets = 12, total bytes = 2208 PID 0x0100, Other packets = 58, total bytes = 10672 PID 0x0200, MPEG Audio stream 0 packets = 2310, total bytes = 415680 Javier de la Rica Comunicaciones Multimedia $ dvbsnoop -s ts -tssubdecode -nph -npd -ph 0 -pd 9 -if sintel_audio_16k.ts >traze_sintel.txt Editant el fitxer de continguts: $ gedit traze_sintel.txt & 2. Respon les següents qüestions: a. Quants programes són anunciats a la PAT d’aquest Transport Stream. Quin números de programa (o identificador) tenen assignats? Hay un único programa anunciado en la PAT del TS. Dicho programa tiene el número 21 (0x0015) con PID: 256 (0x0100).
b. On queden descrits els fluxos audiovisuals que formen part d’un programa en concret. Per l’únic programa d’aquest transport stream, quin identificador fan servir els packets de transport que porten la descripció dels fluxos?. Quants fluxos té aquest programa i de quin tipus?.
Los flujos audiovisuales que forman parte de un programa en concreto quedan descritos en los paquetes PMT (Program Map Table).
En este caso, los paquetes de transporte que llevan la descripción de los flujos para el único programa del presente flujo de transporte utilizan el identificador Program_map_PID 256 (0x0100).
El programa tiene un único flujo de audio y ningún flujo de vídeo.
c. El paquets de transport que porten la informació audiovisual, quin identificador tenen associat?. Quin percentatge de paquets de transport són d’informació audiovisual?.
Elementary_PID: 512 (0x0200) size= 448kB time=00:00:51.96 bitrate= video:0kB audio:406kB 10.263664% global 70.6kbits/s headers:0kB muxing overhead Javier de la Rica Comunicaciones Multimedia 𝐴𝑢𝑑𝑖𝑜 𝑆𝑖𝑧𝑒 406𝑘𝐵 = = 0.9062 → 90.62% 𝑇𝑜𝑡𝑎𝑙 𝑆𝑖𝑧𝑒 448𝑘𝐵 d. On s’indica el flux que porta el rellotge de referència temporal que sincronitza el programa? El flujo que lleva el reloj de referencia temporal PCR (Program Clock Reference) que sincroniza el programa y por tanto tiene el PCR_flag activado (con un 1) corresponde al primer paquete TS e. Quina grandària tenen els paquets de transport? Por Definición, los paquetes de transporte TS, provinentes de una previa fragmentación de los paquetes PES, deben tener una medida de 188 Bytes, de los cuales 4 Bytes corresponden a una cabecera.
Esto se puede comprobar en el fichero de estudio observando el tamaño directamente: f.
Per formar el primer paquet PES d’àudio, quants paquets de transport es fan servir?. Com podem saber que hem rebut tots els paquets de transport per reensamblar els paquets PES d’àudio? Mediante el contador de continuidad continuity_counter podemos saber cuando hemos recibido todos los paquetes TS necesarios para reensamblar un paquete PES.
En este caso, se puede observar que se reensambla un paquete PES cuando dicho contador llega a 15, así que son necesarios 16 paquetes de transporte TS para reensamblar un paquete PES.
g. Els paquets PES d’àudio quin identificador d’stream tenen associat?. Quins paquets PES d’àudio porten les marques temporals de presentació PTS? Javier de la Rica Comunicaciones Multimedia B. Creació de Múltiple Transport Streams Fase preliminar: Preparació dels Simple Transport Streams a multiplexar 1. Transcodifica les seqüències amb vídeo i àudio de mpeg4 a mpeg2 Transport Stream utilitzant el programa ffmpeg: $ ffmpeg-086 -i BigBuckBunny_640x360.mp4 -vcodec mpeg2video -g 6 -bf 1 -qscale 6 -psnr -acodec mp2 -ab 192k -alang eng -vframes 1200 -mpegts_transport_stream_id 0x9111 -mpegts_service_id 10 mpegts_pmt_start_pid 0x0101 -mpegts_start_pid 0x300 -metadata service_provider="Telematic Provider" -metadata service_name="CM BBB HQ Channel" -y bbb_HQ.ts frame= 1200 fps= 18 q=6.0 LPSNR=Y:37.39 U:41.21 V:42.88 *:38.45 size= time=00:00:49.95 bitrate=2061.7kbits/s 12573kB video:10328kB audio:1172kB global headers:0kB muxing overhead 9.329817% $ ffmpeg-086 -i BigBuckBunny_640x360.mp4 -vcodec mpeg2video -g 6 -bf 1 -qscale 31 -psnr -acodec mp2 -ab 32k -alang eng -vframes 1200 -mpegts_transport_stream_id 0x9222 -mpegts_service_id 11 mpegts_pmt_start_pid 0x0102 -mpegts_start_pid 0x400 -metadata service_provider="Telematic Provider" -metadata service_name="CM BBB SQ Channel" -y bbb_SQ.ts frame= 1200 fps= 25 q=31.0 LPSNR=Y:29.71 U:35.90 2845kB time=00:00:49.95 bitrate= 466.4kbits/s V:38.50 *:31.08 size= video:2309kB audio:195kB global headers:0kB muxing overhead 13.568947% $ ffmpeg-086 -i sintel_trailer-1080p.mp4 -s 640x360 -vf "crop=640:256:0:52" -vcodec mpeg2video -g 6 -bf 1 -qscale 6 psnr -acodec mp2 -alang eng -ab 192k -vframes 1200 mpegts_transport_stream_id 0x9333 -mpegts_service_id 20 mpegts_pmt_start_pid 0x0103 -mpegts_start_pid 0x400 -metadata service_provider="Telematic Provider" -metadata service_name="CM Sintel HQ Channel" -y sintel_HQ.ts frame= 1200 fps= 5 q=6.0 LPSNR=Y:42.71 U:47.87 5319kB time=00:00:49.95 bitrate= 872.3kbits/s V:47.67 *:43.84 size= video:3609kB audio:1171kB global headers:0kB muxing overhead 11.273395% Referència: http://www.ffmpeg.org/ffmpeg-formats.html\#mpegts-1 http://www.waveguide.se/?article=creating-dvb-tcompatible-mpeg2-streams-using-ffmpeg 2. Analitza els resultats obtinguts amb els programes d’ anàlisi pel següent cas: $ tsinfo bbb_HQ.ts Reading from bbb_HQ.ts Scanning 1000 TS packets Packet 2 is PAT Program list: Javier de la Rica Comunicaciones Multimedia Program 10 -> PID 0101 (257) Packet 3 is PMT with PID 0101 (257) Program 10, version 0, PCR PID 0300 (768) Program streams: PID 0300 ( 768) -> Stream type 02 ( 2) H.262/13818-2 video (MPEG-2) or 11172-2 constrained video PID 0301 ( 769) -> Stream type 03 ( 3) 11172-3 audio (MPEG-1) ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng Found 48 PAT packets and 24 PMT packets in 1000 TS packets $ bbdmux bbb_HQ.ts bbdmux - version 1.9, by Brent Beyeler (beyeler@home.com) speed increases by, Apachez and Christian Vogelgsang Scanning for PID's, press control-c to quit ...
File bbb_HQ.ts is an MPEG-2 Transport Stream Found Found Found Found Found PID PID PID PID PID 0x0011, 0x0000, 0x0101, 0x0300, 0x0301, Other Stream Program Association Table Stream Other Stream stream id 0xE0 = Video Stream 0 stream id 0xC0 = MPEG Audio Stream 0 Summary: MPEG Transport Packets = 68485 PID 0x0000, Program Association Table packets = 1623, total bytes = 298632 PID 0x0011, Other packets = 325, total bytes = 59800 PID 0x0101, Other packets = 1623, total bytes = 298632 PID 0x0300, Video stream 0 packets = 58211, total bytes = 10575871 PID 0x0301, MPEG Audio stream 0 packets = 6703, total bytes = 1200587 3. Analitza el contigut extraient la informació del multiplex i observant la informació amb l’editor de text: $ dvbsnoop -s ts -tssubdecode -nph -npd -ph 0 -pd 9 -if bbb_HQ.ts >traze_bbb.txt $ gedit traze_bbb.txt & Respon les següents qüestions: a. Quans programes són anunciats a la PAT d’aquest Transport Streams.
Quins números de programa (o identificador) tenen assignats? Nos volvemos a encontrar con un único programa, con el número 10 y su PID 257 (0x0101) Javier de la Rica Comunicaciones Multimedia b. Quans fluxos té aquest programa i de quin tipus? En este caso nos encontramos con dos flujos; un flujo de audio y otro flujo de vídeo.
c. Quin és el flux que porta el rellotge de referència temporal que sincronitza el programa? El reloj de referencia temporal que sincroniza el programa PCR (Program Clock Reference) lo lleva el flujo de vídeo, ya que es un paquete de dicho flujo el que tiene el flag de PCR activado.
d. Per formar el primer paquet PES de vídeo, quans paquets de transport es fan servir? C. Generació de Múltiple Transport Streams: Comprova prèviament les opcions del programari: iso13818ts -h 1. Stream multiprograma $ iso13818ts -F 20 -I 1 --ts bbb_HQ.ts 10 30 0xE0 0xE0 --ts bbb_HQ.ts 10 30 0xC0 0xC0 --ts bbb_SQ.ts 11 31 0xE0 0xE0 --ts bbb_SQ.ts 11 31 0xC0 0xC0 >bbb_multiprogram.ts Analitza el resultat obtingut amb el programa d’anàlisi: $ tsinfo bbb_multiprogram.ts Reading from bbb_multiprogram.ts Scanning 1000 TS packets Packet 1 is PAT Program list: Program 30 -> PID 0102 (258) Program 31 -> PID 0100 (256) Multiple programs in PAT - using the first Packet 2 is PMT with PID 0102 (258) Program 30, version 1, PCR PID 0103 (259) Program streams: PID 0104 ( 260) -> Stream type 04 ( 4) 13818-3 audio (MPEG-2) ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0103 ( 259) -> Stream type 02 ( 2) H.262/13818-2 video (MPEG-2) or 11172-2 constrained video Found 6 PAT packets and 1 PMT packet in 1000 TS packets Javier de la Rica Comunicaciones Multimedia 2. Compara subjectivament els resultats de les codificacions anteriors: $ vlc bbb_multiprogram.ts --program 30 $ vlc bbb_multiprogram.ts --program 31 Javier de la Rica Comunicaciones Multimedia Quin programa es veu millor? Per què? Se puede observar que el programa 30 se visualiza mejor que el programa 31. Esto es debido a que el stream utilizado no es stream multiresolución.
3. Stream multiresolució $ iso13818ts -F 100 -I 2 --ts bbb_HQ.ts 10 30 0xE0 0xE0 --ts bbb_HQ.ts 10 30 0xC0 0xC0 --ts bbb_SQ.ts 11 30 0xE0 0xE1 --ts bbb_SQ.ts 11 30 0xC0 0xC1 > bbb_multiresolution.ts Analitza el resultat obtingut amb el programa d’anàlisi: $ tsinfo bbb_multiresolution.ts Reading from bbb_multiresolution.ts Scanning 1000 TS packets Packet 1 is PAT Program list: Program 30 -> PID 0100 (256) Packet 2 is PMT with PID 0100 (256) Program 30, version 1, PCR PID 0102 (258) Program streams: PID 0104 ( 260) -> Stream type 04 ( 4) 13818-3 audio PID 0103 ( 259) -> Stream type 04 ( 4) 13818-3 audio ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0102 ( 258) -> Stream type 02 ( 2) H.262/13818-2 constrained video PID 0101 ( 257) -> Stream type 02 ( 2) H.262/13818-2 constrained video Packet 29 is PMT with PID 0100 (256) - content changed Program 30, version 1, PCR PID 0102 (258) Program streams: PID 0104 ( 260) -> Stream type 04 ( 4) 13818-3 audio ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0103 ( 259) -> Stream type 04 ( 4) 13818-3 audio ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0102 ( 258) -> Stream type 02 ( 2) H.262/13818-2 constrained video PID 0101 ( 257) -> Stream type 02 ( 2) H.262/13818-2 constrained video (MPEG-2) (MPEG-2) video (MPEG-2) or 11172-2 video (MPEG-2) or 11172-2 (MPEG-2) (MPEG-2) video (MPEG-2) or 11172-2 video (MPEG-2) or 11172-2 Found 2 PAT packets and 13 PMT packets in 1000 TS packets 4. Compara subjectivament els resultats de les codificacions anteriors: $ vlc bbb_multiresolution.ts Javier de la Rica Comunicaciones Multimedia D. Genera un altre Transport Stream compost pels streams de sistemes anteriors: 1. Multiplexa els streams de la forma: $ iso13818ts -F 1000 -I 5 --ts sintel_HQ.ts 20 51 0xE0 0xE0 --ts sintel_HQ.ts 20 51 0xC0 0xC0 --ts bbb_multiresolution.ts 30 50 0xE0 0xE0 --ts bbb_multiresolution.ts 30 50 0xE1 0xE1 --ts bbb_multiresolution.ts 30 50 0xC0 0xC0 --ts bbb_multiresolution.ts 30 50 0xC1 0xC1 > multiplex.ts Analitza el resultat obtingut amb el programari d’anàlisi: $ bbdmux multiplex.ts bbdmux - version 1.9, by Brent Beyeler (beyeler@home.com) speed increases by, Apachez and Christian Vogelgsang Scanning for PID's, press control-c to quit ...
File multiplex.ts is an MPEG-2 Transport Stream Found Found Found Found Found Found Found Found Found PID PID PID PID PID PID PID PID PID 0x0000, 0x0102, 0x0103, 0x0104, 0x0100, 0x0101, 0x0105, 0x0106, 0x0107, Program Association Table Stream Other Stream stream id 0xE0 = Video Stream 0 stream id 0xC0 = MPEG Audio Stream 0 Other Stream stream id 0xE0 = Video Stream 0 stream id 0xE1 = Video Stream 1 stream id 0xC0 = MPEG Audio Stream 0 stream id 0xC1 = MPEG Audio Stream 1 Javier de la Rica Comunicaciones Multimedia Summary: MPEG Transport Packets = 107089 PID 0x0000, Program Association Table packets = 51, total bytes = 1047 PID 0x0100, Other packets = 63, total bytes = 2709 PID 0x0101, Video stream 0 packets = 58025, total bytes = 10538655 PID 0x0102, Other packets = 50, total bytes = 1650 PID 0x0103, Video stream 0 packets = 20850, total bytes = 3696019 PID 0x0104, MPEG Audio stream 0 packets = 6663, total bytes = 1199232 PID 0x0105, Video stream 1 packets = 13589, total bytes = 2364752 PID 0x0106, MPEG Audio stream 0 packets = 6703, total bytes = 1200587 PID 0x0107, MPEG Audio stream 1 packets = 1095, total bytes = 200097 $ tsinfo multiplex.ts Reading from multiplex.ts Scanning 1000 TS packets Packet 1 is PAT Program list: Program 51 -> PID 0102 (258) Program 50 -> PID 0100 (256) Multiple programs in PAT - using the first Packet 2 is PMT with PID 0102 (258) Program 51, version 1, PCR PID 0103 (259) Program streams: PID 0104 ( 260) -> Stream type 04 ( 4) 13818-3 audio (MPEG-2) ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0103 ( 259) -> Stream type 02 ( 2) H.262/13818-2 video (MPEG-2) or 111722 constrained video Found 2 PAT packets and 1 PMT packet in 1000 TS packets 2. Comprova el funcionament amb : $ vlc multiplex.ts --program 50 Javier de la Rica Comunicaciones Multimedia $ vlc multiplex.ts --program 51 Al ser multiplex, se puede comprobar como para cada uno de los canales se transmite un archivo multimedia distinto.
3. Desenvolupa un esquema per descriure l’estructura de l’stream de transport generat, fent servir els resultats anteriors i complementat per l’anàlisi del resultat de: $ dvbsnoop -s ts -tssubdecode -nph -npd -ph 0 -pd 9 -if multiplex.ts >traze_TS.txt analitzant el fitxer de text: $ gedit traze_TS.txt & Nota: Han de quedar ben especificats els identificadors dels programes i els dels seus fluxos elementals empaquetats. Dibuixa les taules PAT i PMT fent servir tots el identificadors i indica la codificació de cada flux elemental.
PAT (PID = 0) :_________ Programa PMT Programa 50 0100 Programa 51 0102 PMT 1 (Programa 50) _________ Flujo PID Vídeo 1 0101 Vídeo 2 0105 Audio 1 0106 Audio 2 0107 Javier de la Rica Comunicaciones Multimedia PMT 2 (Programa 51) ________ Flujo PID Vídeo 1 0103 Audio 1 0104 4. Demultiplexa un Elementary Stream de vídeo de la forma: $ ts2es -pid 0x0101 multiplex.ts -stdout | ffplay - $ ts2es -pid 0x0104 multiplex.ts -stdout | ffplay - Javier de la Rica Comunicaciones Multimedia a. Indica les característiques del fluxos demultiplexats, en cada cas, segons l’esquema desenvolupat anteriorment.
El primer flujo que se ha demultiplexado corresponde al flujo de vídeo del programa 50, mientras que el segundo flujo que se ha demultiplezado corresponde al flujo del programa 51.
b. Explica les operacions que du a terme un descodificador de TDT quan demultiplexa un programa i reprodueix el vídeo i l’àudio.
Un decodificador de TDT se encarga de multiplexar los flujos de audio y vídeo de los programas correspondientes. Recibe los flujos seleccionados con ayuda del PCR y la identificación de cada uno de los paquetes, y se encarga de sincronizar los dos flujos, decodificarlos y reproducirlos simultáneamente.
E. Envia i rep el Transport Stream fent servir dos terminals en el host, presentant un programa concret: term2$ nc -l 8000 -t | mplayer -tsprog 51 term1$ tsplay multiplex.ts 127.0.0.1:8000 -tcp Reading from multiplex.ts Connecting to 127.0.0.1 via TCP/IP on port 8000 Writing to 127.0.0.1 via TCP/IP Input appears to be Transport Stream Using 'exact' TS packet timing (by looking-ahead to the next PCR) Packet 1 is PAT Program list: Program 51 -> PID 0102 (258) Program 50 -> PID 0100 (256) Multiple programs in PAT - using the first Packet 2 starts PMT with PID 0102 Program 51, version 1, PCR PID 0103 (259) Program streams: PID 0104 ( 260) -> Stream type 04 ( 4) 13818-3 audio (MPEG-2) ES info (6 bytes): 0a 04 65 6e 67 00 Languages: eng PID 0103 ( 259) -> Stream type 02 ( 2) H.262/13818-2 video (MPEG-2) or 11172-2 constrained video Taking timing information from PID 0x103 Transferred 107087 TS packets in total Started output at Tue Apr 19 03:16:33 2016 Finished output at Tue Apr 19 03:17:15 2016 Elapsed time 42.0s Output 107089 TS packets Javier de la Rica Comunicaciones Multimedia Analitza subjectivament l’impacte dels errors en la visualització. Fes algunes proves des d’el terminal 1 per diferents probabilitats de error (10-2, 10-3 i 10-4), fent per exemple: term1$ MEAN_BURST=1000; tsplay multiplex.ts 127.0.0.1:8000 tcp -drop $MEAN_BURST 1 on MEAN_BURST ( =100, =1000, =10000) és l’invers de la probabilitat d’error de packet TS del sistema de transmissió.
MEAN_BURST Javier de la Rica Comunicaciones Multimedia MEAN_BURST=100 MEAN_BURST=1000 MEAN_BURST=10000 DISTORSIÓN Javier de la Rica Comunicaciones Multimedia Se puede observar como a medida que se aumenta el valor de MEAN_BURST hay menos distorsión en la imagen, y mientras menor sea el valor de MEAN_BURST, mayor distorsión.
...