Newsgroup: it.comp.software.divx
Titolo: Matroska e "lacing"

Nel contenitore Matroska, gli stream (audio, video, sottotitoli)
vengono memorizzati in strutture chiamate "Clusters".
Ogni cluster puo' contenere un numero imprecisato di "blocchi".
Ogni blocco contiene un frame.
Per ridurre l'overhead, un blocco puo' contenere piu' frames
(in forma compatta, memorizzati uno dietro l'altro), mediante
l'uso di una tecnica chiamata "lacing".
Qui viene descritta la struttura di un blocco:
http://www.matroska.org/technical/specs/index.html#block_structure
In pratica, se ho capito bene, il lacing non viene mai usato per
le tracce video, ma solo per quelle audio.
Quello che mi crea qualche problema e' che ci sono 3 tipi di
lacing:
- Xiph lacing
- EBML lacing
- fixed-size lacing
Bene, ho preso un piccolo AVI/divx e l'ho travasato in matroska:
mkvmerge -o test.mkv test.avi
Usando "mkvinfo" non ottengo alcun indizio sull'eventuale tipo
di lacing usato nel muxing del mkv ottenuto con mkvmerge, quindi
non ho la possibilita' di fare controprove...
Il mio dubbio e' questo:
e' possibile che, nel filmato mkv ottenuto con mkvmerge, per
l'audio mp3, siano stati usati piu' tipi diversi di lacing?
A occhio e croce mi sembra strano, ma e' quello che ho ottenuto
analizzando il mkv con il parser matroska che sto scrivendo:
secondo la mia attuale implementazione, risulta che per tutti i
frame video non e' stato usato il lacing (dovrebbe essere giusto),
mentre per i frame audio viene sempre usato il lacing, ma a volte
viene usato un tipo (EBML) e a volte un altro (non sono sicuro
quale degli altri due):
http://fsinapsi.altervista.org/tmp/lacing.png
(la traccia n. 1 e' il video, la n. 2 e' l'audio)
Se non e' possibile che vengano usati due tipi di lacing diversi
nella stessa codifica, allora ho commesso un errore nella mia
implementazione...
Se invece e' possibile ed e' corretto, per completare il
programma, ho bisogno di sapere quali tipi di lacing sono stati
usati:
il tipo 3 dovrebbe essere EBML lacing (non c'e' ambiguita'
nell'intepretazione dell'ordine dei due bit); il dubbio e' su
quello che nella mia figura viene indicato come 2:
a seconda di come si interpretano i bit della pagina:
http://www.matroska.org/technical/specs/index.html#block_structure
potrebbe essere uno o l'altro tra "Xiph" e "fixed-size"...
Se qualcuno gia' lo sapesse, mi risparmierebbe tutta la fatica di
cercare tra molti esempi per fare tutte le prove e controprove...
Finche' non risolvo questi dubbi, non potro' implementare il
demuxing delle tracce da matroska...
-- 
Home page: 
http://fsinapsi.altervista.org

 demuxing delle tracce da matroska...
ok, ho risolto (dopo innumerevoli prove e controprove... :-)).
In pratica e' il contrario di come e' scritto qui:
http://www.matroska.org/technical/specs/index.html#block_structure
Li' c'e' scritto: i bits 5-6 corripondono a... 01: Xiph, 10: fixed
Uno e' portato a pensare che "01" significhi (bit 5=0, bit 6=1),
invece e' il contrario (bit 5=1, bit 6=0)...
Le uniche documentazioni su Matroska che ho trovato sono quelle e
un PDF di Noe', e sono entrambe piene di imprecisioni... :-)
Ad esempio, su entrambe c'e' scritto che sia i numeri interi che
float sono sempre memorizzati "big endian", invece, alla prova dei
fatti, si presentano diversi casi, alcuni big endian, alcuni little
endian.
Se le specifiche ufficiali non sono estremamente precise, penso sia
vano sperare che il formato venga supportato da aziende che
progettano apparecchi...


 potrebbe essere uno o l'altro tra "Xiph" e "fixed-size"...
Io leggo, per i bit 5 e 6 dell'offset 0x03+:
Lacing
    * 00 : no lacing
    * 01 : Xiph lacing
    * 11 : EBML lacing
    * 10 : fixed-size lacing
Parlo da perfetto ignorante di programmazione e chiedo come mai non si
riesce a capire l'ordine dei due bit 01 e 10.
-- 
Saluti, Kap - 
www.lordkap.it
 - ¥'s Fan #01 - 
www.pianetalibri.com
 - VCC
Infelici sono quelli che hanno tanto cervello da vedere la loro
stupidità. - Fligende Blatter

 invece e' il contrario (bit 5=1, bit 6=0)...
E con questa rispondi alla mia domanda. ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - ¥'s Fan #01 - 
www.pianetalibri.com
 - VCC
La noia è l'uccello del sogno che cova l'uovo dell'esperienza. Un
fruscio tra le foglie lo scaccia via. - Walter Benjamin

 riesce a capire l'ordine dei due bit 01 e 10.
perche' non e' specificato in modo chiaro.
Se guardi piu' su, trovi specificato: "Bit 0 is the most significant bit."
Quindi, nella seguente riga:
0-3     -       Reserved, set to 0
ci si riferisce ai quattro bit piu' significativi del byte in questione.
Secondo tale numerazione, i bit 5-6 sono quelli marchiati con 'x' in
questa sequenza: oooooxxo
Secondo te, scrivendo "01 : Xiph lacing", quale dei due 'x' deve valere 0,
e quale 1?
In mancanza di ulteriori specifiche uno pensa che lo 0 sia il bit 5 (la
prima a sinistra delle due 'x').
Invece e' il secondo.
E non c'e' modo di saperlo, se non facendo un mucchio di prove
(implementando prima in un modo, poi in un altro, e tentando il
demuxing su molti casi in modo tale da coprire tutte le possibilita',
finche' non si capisce come stanno realmente le cose...)
Oltre alle imprecisioni nelle specifiche, come formato mi pare
inutilmente troppo ingarbugliato, ci sono troppe confusioni/commistioni
tra diversi livelli di astrazione che conveniva tenere separati.
Ad esempio, mi chiedo che senso abbia mettere dentro un file che deve
contenere un filmato dei riferimenti ad altri filmati su file esterni
ad esso... son tutte complicazioni che probabilmente non verranno mai
usate...


 ad esso...
In effetti non ha molto senso. Capisco che ci sia stata una ragione per
farlo, ma poi, come giustamente hai osservato tu nel messaggio
precedente, uno standard non chiaro difficilmente verrà implementato e
supportato da un produttore di hardware.
-- 
Saluti, Kap - 
www.lordkap.it
 - ¥'s Fan #01 - 
www.pianetalibri.com
 - VCC
Cerchiamo di essere molto estranei ed educati: estranei come se fossimo
sposati da un bel pezzo ed educati come se non fossimo affatto sposati.
William Congreve