Newsgroup: it.comp.software.divx
Titolo: parser H.264

Mi sono finalmente deciso ad aggiungere ad "avinaptic" la
possibilita' di analizzare i bitstream di tipo H.264 (AVC).
Non ho intenzione di scrivere un parser completissimo, ma
almeno quel tanto che basta per estendere l' "analisi DRF"
anche a questo tipo di codifica, e riportare qualche altra
informazione significativa.
Stasera ho gia' scritto tutto quello che serve (mi sono basato
fortemente sul software di riferimento "JM" scritto dagli
stessi estensori di H.264), ma domani controllero' tutto, e ho
ancora molti dubbi; sono ancora troppe le cose che non conosco
di H.264...
Vorrei rassicurare Andres del fatto che ho gia' completamente
risolto il problema delle differenze nei file Matroska,
quindi, dalle prossime versioni non dovrebbe piu' capitargli
che sui matroska con AVC gli vengano stampati messaggi del
tipo "il frame e' privo di NAL". In pratica, l'analisi dei
bitstream AVC dovrebbe essere identica sia che si tratti di
AVI che di Matroska (e in futuro, quando lo aggiungero',
anche di MP4).
Adesso vorrei esporre alcuni miei dubbi.
Il primo riguarda i parametri di quantizzazione (qp), che in
H.264 variano nel range 0 - 51.
In MPEG-4 tali parametri variano nel range 1 - 31.
In H.264 pero' hanno un "peso" diverso, perche' viene usata
una trasformata e un tipo di quantizzazione differente;
questo riassume la questione:
-------------------------------------------------------------
H.264's quantization parameter (QP) is on a logarithmic scale.
The mapping is approximately  H264QP = 12 + 6*log2(MPEGQP). 
For example, MPEG at QP=2 is equivalent to H.264 at QP=18
--------------------------------------------------------------
quindi, pensavo di memorizzare tali parametri nelle stesse
strutture che ho usato per MPEG-4 ASP, usando i valori
equivalenti.
In questo modo, nel rapporto avremo una distribuzione di
valori abbastanza simile a quella di MPEG-4, con la differenza
che adesso, ogni riga comprendera' piu' di un valore di QP.
La stessa cosa dovrebbe valere per il grafico, che sara' quindi
su scala logaritmica (quella di adesso, per MPEG-4, e' su scala
lineare).
Puo' andare bene cosi', o qualcuno ha idee migliori?
Altro mio dubbio e' questo: in H.264 ci sono questi tipi di
frames:
  P_SLICE,
  B_SLICE,
  I_SLICE,
  SP_SLICE,
  SI_SLICE
che razza di roba sono gli ultimi 2?
Prima di implementare il parser, avrei dovuto studiare lo
standard :-)
Altro dubbio, e con questo, per ora, finisco:
analizzando un filmatino di prova, e facendomi stampare
alcuni dati che risultano dall'analisi dei primi 10 frames,
ottengo questo:
------------------------------------------------------
frame di tipo 2, frame num = 0, structure = 0, qp = 23
frame di tipo 0, frame num = 1, structure = 0, qp = 26
frame di tipo 0, frame num = 2, structure = 0, qp = 26
frame di tipo 0, frame num = 3, structure = 0, qp = 26
frame di tipo 0, frame num = 4, structure = 0, qp = 26
frame di tipo 0, frame num = 5, structure = 0, qp = 26
frame di tipo 0, frame num = 6, structure = 0, qp = 26
frame di tipo 0, frame num = 7, structure = 0, qp = 26
frame di tipo 0, frame num = 8, structure = 0, qp = 26
frame di tipo 0, frame num = 9, structure = 0, qp = 26
------------------------------------------------------
questo e' perfetto, perche' coincide con il file delle
statistiche generato da x264.
Va notato che i frame di tipo 2 sono i frame I, mentre
quelli di tipo 0 sono P; structure = 0 vuol dire che si
tratta di un frame intero (in altre parole, non si tratta
di un "field" di una codifica interlacciata), il resto
dovrebbe essere chiaro...
Ebbene, se provo su un altro filmato H.264, ottengo questa
roba:
------------------------------------------------------
frame di tipo 2, frame num = 0, structure = 0, qp = 16
frame di tipo 2, frame num = 0, structure = 0, qp = 16
frame di tipo 0, frame num = 1, structure = 0, qp = 22
frame di tipo 0, frame num = 1, structure = 0, qp = 23
frame di tipo 1, frame num = 2, structure = 0, qp = 22
frame di tipo 1, frame num = 2, structure = 0, qp = 23
frame di tipo 0, frame num = 2, structure = 0, qp = 22
frame di tipo 0, frame num = 2, structure = 0, qp = 23
frame di tipo 1, frame num = 3, structure = 0, qp = 22
frame di tipo 1, frame num = 3, structure = 0, qp = 23
frame di tipo 0, frame num = 3, structure = 0, qp = 22
frame di tipo 0, frame num = 3, structure = 0, qp = 23
frame di tipo 1, frame num = 4, structure = 0, qp = 22
frame di tipo 1, frame num = 4, structure = 0, qp = 23
frame di tipo 0, frame num = 4, structure = 0, qp = 22
frame di tipo 0, frame num = 4, structure = 0, qp = 23
frame di tipo 1, frame num = 5, structure = 0, qp = 22
frame di tipo 1, frame num = 5, structure = 0, qp = 23
frame di tipo 0, frame num = 5, structure = 0, qp = 22
frame di tipo 0, frame num = 5, structure = 0, qp = 23
------------------------------------------------------
innanzitutto, sembra che nei primi 10 frames analizzati
ci siano 20 "slices" contenenti immagini.
Poi la numerazione e' assai strana...
Non riesco a capirne la logica...
Eppure l'analisi dovrebbe essere corretta, perche' l'ho
confrontata con l'analisi del decoder di riferimento
(che alla fine da' un risultato corretto) e i dati
coincidono...
A intuito direi che questi dati riportati dovrebbero
riferirsi a 10 frames, ma mi sfuggono i dettagli. Non
so nemmeno quali valori di qp assegnare ai frames in
questione...
Qualcuno ne sa di piu' e puo' spiegarmi come stanno le
cose?
-- 
Home page: 
http://fsinapsi.altervista.org

 risolto il problema delle differenze nei file Matroska,
Questo vuol dire che sarà possibile anche il demux?
Purtroppo per le questioni riguardanti la struttura dei frames non ti
posso aiutare... ;/
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Forse, come sai, gli affari portano denaro, ma l'amicizia quasi mai.
Jane Austen

 Questo vuol dire che sarą possibile anche il demux?
dipende da cosa vuoi estrarre e cosa ne devi fare


 dipende da cosa vuoi estrarre e cosa ne devi fare
Estrarre audio e video per poi unirgli un altro audio facendolo diventare
un AVI. ;)
-- 
Saluti, Kap - 
http://www.lordkap.it

 un AVI. ;)
per poterlo guardare sui lettori da tavolo :-)
Nei casi piu' semplici, ti conviene usare un programma che effettui il
travaso direttamente da Matroska ad AVI (VirtualDubMod, o Avidemux,
o mencoder).
Se un travaso diretto non e' possibile, bisogna vedere come conviene
procedere, caso per caso...
Un caso abbastanza seccante e' quello di un matroska con video avente
codec ID "V_MPEG4/ISO/ASP".
E' seccante perche' si tratta di un filmato che si potrebbe vedere
sul lettore da tavolo cosi' com'e', ma nella pratica sembra non esistere
ancora un modo per travasarlo correttamente dentro un AVI
(mkvextract 2.0 ancora non lo estrae, e mencoder crea un AVI non
corretto). Forse aggiungero' al mio programma l'estrazione corretta
anche di questo caso (non e' facilissimo perche' occorre analizzare
lo stream mentre lo si estrae, inserendovi delle strutture nei punti
giusti...)


 mentre lo si estrae, inserendovi delle strutture nei punti giusti...)
C'è tempo, per ora! ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Avrai un solo Dio! E chi vorrebbe sobbarcarsi la spesa di due!
Arthur Hugh Clough

 l'estensione in .avi, e al "tuo" Mjpeg2Divx non è piaciuto molto
cio' che estrai non e' un AVI, ma in questo specifico caso uno
"stream elementare" H.264. Tale file puo' essere riprodotto
direttamente da mplayer (in un caso particolare, se nello stream
non e' specificato il framerate, mplayer puo' riprodurlo solo se
si specifica il framerate mediante l'opzione -fps), oppure puo'
essere inserito in un contenitore mediante mencoder oppure in un
mp4 da MP4Box (del progetto GPAC). Ti ripeto che la versione di
"avinaptic" che hai tu, ancora non estraeva il bitstream H.264
nel modo corretto.
Comunque, tu non hai un lettore da tavolo che legge H.264, quindi
vorrai sicuramente ricodificarlo in DivX o XviD, quindi non ti
conviene estrarre il bitstream, ma usare un programma che prenda
in ingresso il matroska e ti crei un AVI con il filmato
ricodificato. Forse puoi usare VirtualDubMod per questo scopo,
sicuramente puoi usare mencoder (o una sua gui).
Questa e' la parte di parser H.264 che verra' utilizzata d'ora
in poi da avinaptic:
http://fsinapsi.altervista.org/tmp/h264.txt
Buona parte del codice (decode_sps, decode_pps, decode_slice)
l'ho scritta ieri sera.
La parte preparatoria (soprattutto la gestione del caso speciale
"matroska") l'avevo fatta nei giorni scorsi.
Visto cosi' sembra una bischerata, ma in realta' e' una bella
mole di lavoro :-)


 mencoder (o una sua gui).
Vedrò se se li beve VDM e poi codifcherò in Xvid a quantizer costante
(con 2 dovrei averne abbastanza).
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Man is ultimately superior to any mechanical device.
Captain Kirk - Star Trek TOS

 (con 2 dovrei averne abbastanza).
con 2 ottieni un risultato abbastanza fedele a quello di partenza;
ovviamente le dimensioni aumenteranno sensibilmente


 nel modo corretto.
Kap, ho messo sul sito una nuova versione che estrae i bitstream
AVC in modo corretto.
Se ripeti l'analisi di ieri con questa versione (quel matroska
della serie giapponese), dovrebbe darti qualche informazione in
piu' sul bitstream H.264 in esso contenuto.
In realta', per ora ti dice ben poco: ho aggiunto al rapporto
solo l'informazione se per i coefficienti quantizzati e' stata
usata una codifica aritmetica (CABAC) oppure a codici a
lunghezza variabile (CAVLC), ma e' pur sempre un inizio :-)
Se nel bitstream c'e' anche un "unregistered user data" (x264
ne mette uno abbastanza dettagliato), allora nel rapporto
dovrebbero comparire anche tali informazioni.
Devo ancora attivare l'analisi DRF per H.264, ma prima devo
risolvere alcuni problemini...
Come avevo anticipato, a partire da questa versione non ci
dovrebbero essere piu' differenze nelle analisi di bitstream
contenuti in contenitori di tipo diverso. In particolare,
l'analisi dovrebbe essere corretta anche per i Matroska.
Se vi imbattete in errori, segnalatameli.


 ovviamente le dimensioni aumenteranno sensibilmente
Quello sarebbe il meno. L'importante sarà l'adattamento dell'audio e il
mux.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
There can be no justice so long as laws are absolute. Even life itself
is an exercise in exceptions. - Captain Picard - Star Trek TNG

 Se vi imbattete in errori, segnalatameli.
Ok, quando ci sarà da lavorarci sopra intensamente farò volentieri il
beta tester.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Tutti i peccati danno dipendenza, e il punto terminale della
dipendenza è ciò che viene chiamato dannazione. - Wystan Hugh Auden

 UID: 3572831912
questo lo puoi estrarre cliccando su Demux->Estrai_un_allegato e
otterrai il file "EVA-FANS.ttf".
Chissa' che caratteri contiene... :-)


 
io no... ma se ti posso aiutare chiama pure !
ciao e grazie ancora !!!!!!!
Andres Zanzani
Cesena, Italy
www.64k.it/andres
 <--- Tutto e oltre per i DivX

 con questi frames ?
non sono ridondanti, contengono parti delle immagini: il decoder
(ldecod), durante la decodifica crea un file enorme contenente la
sequenza di immagini YUV non compresse, e questo file cresce per
ogni "slice" presente nello stream...
Comunque, mentre il log del decoder coincide con l'analisi che
faccio io, nei messaggi che stampa su terminale riporta solo le
informazioni del primo slice; quindi, quando un frame e' composto
da due slice, e il primo ha qp=22 e il secondo qp=23, sullo
schermo viene stampato qp=22.
Con x264 non succede mai, cioe' con tutti i x264 che ho visto,
c'e' sempre un solo slice per ogni frame.
Un'altra particolarita' e' che gli slice SP e SI hanno due parametri
di quantizzazione: oltre al solito qp, hanno anche un secondo
parametro che nei sorgenti e' chiamato qpsp.
Inizialmente, memorizzero' solo il primo qp del primo slice di
ogni frame; se poi scopriro' che in alcuni casi non e' corretto,
cerchero' di porvi rimedio
Ciao


 Chissa' che caratteri contiene... :-)
Mah! Chi lo sa! ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Nell'uomo prudenza, nella moglie pazienza. - Proverbio popolare

 Mah! Chi lo sa! ;)
basta estrarlo e visualizzare il ttf con un font viewer. Qualche
anno fa avevo una mania per i caratteri :-)
Molti ttf pero' non contengono lettere ma simboli di ogni tipo
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

 anno fa avevo una mania per i caratteri :-)
Niente di strano o particolare. Font neanche tanto caratteristici.
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Nel futuro ognuno sarà famoso per quindici minuti. - Andy Warhol

 Sì, credo anch'io. Se mi servirà lo cercherò.
forse MP4 e' l' "AVI del futuro", nel senso che c'e' una buona
probabilita' che in futuro avra' un'enorme diffusione


 probabilita' che in futuro avra' un'enorme diffusione
Appena inizieranno a supportare l'h264... ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - AVINaptic: 
http://fsinapsi.altervista.org
FAQ del newsgroup: 
http://giubbe.altervista.org
Fedeltà: perversa inclinazione verso la propria moglie.
Ambrose Gwinnett Bierce