Newsgroup: it.comp.software.divx
Titolo: AviNaptic: file non riconosciuto

Ciao.
E' un po' che lo volevo segnalare.
Mi capita spesso che l'analisi drf di un file con estensione mkv non 
venga completata e ne scaturisca un messaggio di errore che recita "file 
non riconosciuto". L'analisi parte, ne viene completato circa il 20-25% 
e poi esce il messaggio.
Chiarisco che il file in questione è perfetto e si vede benissimo 
dall'inizio alla fine senza problemi.
Queste sono le info che compaiono senza l'analisi drf:
[ Info sul file ]
Nome: Video 1080p.mkv
Data: 12/06/2008 00:25:48
Dimensione: 8,213,719,673 bytes (7833.213 MB)
[ Info generiche ]
Durata: 02:34:19 (9259.392 s)
Tipo di contenitore: matroska
Data creazione: 11/06/2008 22:22:22 UTC
Streams totali: 2
Tipo stream n. 1: video (V_MPEG4/ISO/AVC) {video  HD}
Tipo stream n. 2: audio (A_AC3) {video  ITA DD 5.1}
Audio streams: 1
Muxing Application: libebml v0.7.7 + libmatroska v0.8.1
Writing Application: mkvmerge v2.2.0 ('Turn It On Again') built on Mar 
4 2008 12:58:26
[ Dati rilevanti ]
Risoluzione: MOLTO ALTA (1920 x 1080)
Larghezza: multipla di 32 (BENE)
Altezza: multipla di 8 (sarebbe stato meglio 16)
[ Traccia video ]
Codec ID: V_MPEG4/ISO/AVC
Risoluzione: 1920 x 1080
Frame aspect ratio: 16:9 = 1.777777
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 16:9 = 1.777777
Framerate: 23.976024 fps
[ Traccia audio ]
Codec ID: A_AC3
Canali (contenitore): 6
Frequenza: 48000 Hz
Mode: 3 front, 2 rear, 1 LFE
[ Info sulla codifica H.264 ]
SPS id: 0
   Profile: High@L4.1
   Num ref frames: 3
   Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
   Codifica entropica: CABAC
   Weighted prediction: No
   Weighted bipred idc: B slices - implicit weighted prediction
   8x8dct: Sì
Grazie, ciao.
-- 
Michele

 e poi esce il messaggio.
le possibilita' sono tre:
1) un errore dovuto a librerie usate dal programma;
2) lo stream H.264 e' formalmente corretto ma ha delle feature che il
   mio parser non supporta (e finisce per ritenerlo non valido);
3) lo stream H.264 ha delle imperfezioni.
Le discuto una per una.
Per sapere se vale il caso 1) bisognerebbe analizzare lo stesso file
anche da linux con la versione di avinaptic per linux. Purtroppo in
alcuni casi che mi sono gia' stati segnalati e' venuto fuori che lo
stesso file viene analizzato senza problemi dalla versione linux, e nel
modo che dici tu dalla versione windows. Questo e' uno dei motivi che
mi fanno passare la voglia di rilasciare programmi per windows.
Il caso 2 e' certamente possibile e forse il piu' probabile dei tre.
Ma potrebbe valere anche il 3 (anche se dici che viene riprodotto
dall'inizio alla fine senza problemi, questo potrebbe dipendere dal
fatto che i decoder adottano una filosofia "lasca", nel senso che
tendono ad accettare il maggior numero possibile di casi; nel caso di
un programma che ha lo scopo di "validare" un filmato, non di
riprodurlo, vale l'opposto).
Per sapere con certezza se vale il caso 2 o il 3, bisognerebbe
analizzare lo stream con il programma "ldecod" del pacchetto "JM"
che si trova in questa pagina:
http://iphome.hhi.de/suehring/tml
Perche' proprio con "ldecod"?
Perche' e' il validatore ufficiale degli stream H.264. Cioe', e' il
programma rilasciato dai redattori dello standard H.264.
Per fare questo test, ti basta estrarre lo stream video nudo e
crudo dal matroska (usando mkvextract), salvandolo come "prova.264"
e poi passare questo file in ingresso a "ldecod".
Io userei questa linea di comando:
ldecod -i prova.264 -o /dev/null
Lo switch "-o /dev/null", in ambiente unix, ha l'effetto di non
scrivere lo stream yuv al quale non siamo interessati.
Quando questo comando termina bastera' controllare se ha rilevato
errori (questo si vede sia dalle informazioni stampate su
terminale, che dal file log generato).
Se non vengono rilevati errori, vuol dire che lo stream e' perfetto
e quindi che la mia implementazione del parser e' sbagliata (cioe'
quella di avinaptic).
Un caso analogo a questo mi e' gia' capitato in passato, e in quel
caso venne fuori che era lo stream H.264 ad avere vari difetti (anche
il parser ufficiale "ldecod" si interrompeva dicendo che lo stream
era illegale, e anche in quel caso lo stream veniva riprodotto
perfettamente da mplayer che semplicemente skippava le parti
sballate)...
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

 
http://iphome.hhi.de/suehring/tml
Grazie per la risposta innanzitutto.
Io farei volentieri il test ma nella pagina che mi hai linkato non trovo 
una versione binaria per windows (exe). Mi sembra sia tutto da 
compilare, sia per windows sia per unix (linux): come faccio?
Ho provato a cercare in giro quella utility ma senza risultato.
Grazie ancora, ciao.
-- 
Michele

 
http://iphome.hhi.de/suehring/tml
Sai dove posso reperire l'utility o, eventualmente come posso compilarla?
Grazie, ciao.
-- 
Michele

 Sai dove posso reperire l'utility o, eventualmente come posso compilarla?
scusami, ora non ho molto tempo...
I programmi lencod, ldecod o li compili da te (ma ovviamente devi
avere un compilatore adatto e saperlo fare) oppure usi una versione
gia' compilata da qualcun altro. Attualmente non hai la possibilita'
di usare anche linux, giusto? Altrimenti, ti darei le versioni compilate
da me e ti chiederei di fare una prova veloce sotto linux...
Una versione ldecod.exe compilata per windows la trovi qui:
http://www.w6rz.net/ldecod.zip
Non so chi l'abbia compilata, ma dovrebbe funzionare (controlla che
non abbia virus, ma mi pare improbabile).
Se hai la possibilita' di compilare da te, ricordati di modificare
il file JM/lencod/inc/defines.h settando a 1 la macro TRACE:
#define TRACE               0       //!< 0:Trace off 1:Trace on
2:detailed CABAC context information
puo' esserti utile...
Stai attento che, dando il comando "ldecod -i prova.264" ti genera
un file ENORME, quindi dovresti usare uno switch del tipo
"-o /dev/null".
Solo che sotto windows non credo che "/dev/null" abbia senso, forse
dovresti usare "NUL" o chissa' cos'altro...
Ad ogni modo, se ti accorgi che sta scrivendo un file enorme, tieniti
pronto a interromperlo (dovrebbe bastare premere CTRL+C)


 dovresti usare "NUL" o chissa' cos'altro...
In windows basta mettere in coda ai parametri la voce NUL. :)
Aspetto tue news in merito all'analisi.
Grazie mille Frank, ciao.
-- 
Michele

 Ti dice qualcosa? A me non dice nulla.. :-D
pare sia andato tutto bene. (Si tratta della versione 12.1, mentre
l'attuale e' la 14.0).
Il pezzetto in questione dovrebbe durare circa 57 secondi.
Dovresti pero' fare anche questa contro-prova:
mkvmerge -o pippo.mkv test.264
poi apri pippo.mkv con avinaptic e chiedi l'analisi drf...
In pratica, se l'analisi di tutto lo stream richiede troppo tempo,
dovresti individuare una parte dello stream in cui avinaptic
interrompe bruscamente l'analisi drf (come succede con il filmato
intero) e poi dare in pasto quella parte a "ldecod". Se questo lo
analizza per intero senza interrompersi e senza stampare messaggi
di errore, allora lo stream e' buono e l'errore e' dentro
avinaptic...


 avinaptic...
Avinaptic si ferma più o meno al 50% (intorno ai 4 Gb). Senti, magari 
dico una cavolata ma non potrebbe essere la dimensione del file, vero?
Te lo chiedo perchè, come ho scritto nel primo post, il caso non è 
isolato e mi succede praticamente con tutti quei file mkv HD che come 
dimensione sono sempre superiori ai 4Gb.
A questo fine ho fatto un test: con mkvmerge ho spezzettato un file mkv 
grande 4.3 Gb in 2 da 2.1 Gb circa e avinaptic ha completato il test con 
successo per entrambi. Ricordo qualche limitazione windows relativa ai 4 
Gb e non vorrei fosse qualcosa del genere.
Trovo avinaptic uno strumento utilissimo e mi spiacerebbe non poterlo 
utilizzare in questi casi...
Grazie mille Frank, ciao.
P.S. Mi spieghi che significa questo tip nell'analisi: "Altezza: 
multipla di 8 (sarebbe stato meglio 16)". Perchè sarebbe stato meglio 16?
-- 
Michele

 multipla di 8 (sarebbe stato meglio 16)". Perchè sarebbe stato meglio 16?
niente. Ignoralo.
Togli la spunta da Misc->Preferenze->Commenti_sulla_qualita'


 Togli la spunta da Misc->Preferenze->Commenti_sulla_qualita'
Lo so lo so come si toglie ma sai, credo sempre che nella quasi totalità
dei casi se qualcosa c'è, e scusa il giro di parole, c'è sempre un
motivo... Deduco quindi che quel commento, come altri, se li hai messi
avrai avuto le tue ragioni (c'entra con il processo di encoding?)... :)
Grazie tante per tua pazienza.
Ciao.
-- 
Michele

 avrai avuto le tue ragioni (c'entra con il processo di encoding?)... :)
si', riguarda il modo in cui i codec suddividono le immagini.
Usando multpili di 16 si facilita un po' il compito (per alcuni codec
sarebbe obbligatorio, per altri no, e comunque sono in grado di fare
un opportuno "padding").
Alcuni lettori da tavolo hanno comportamenti strani con certe
dimensioni. Ad esempio, ho un filmato di risoluzione 640x348
(348=43*8+4) e un mio lettore lo riproduce ma mettendo una strisciolina
verde orizzontale sotto il bordo inferiore. E' fastidioso guardare il
film con quella strisciolina verde... Un altro lettore invece lo
visualizza bene...


 Usando [...]
Capito.


 MinGW č un'altra libreria? E questo futuro ha piů o meno una data? :)
Cygwin e MinGW sono due ambienti che permettono di compilare per
windows dei programmi che inizialmente vengono scritti per altri
sistemi (tipicamente linux). Nulla pero' ti vieta di installare
MinGW e usare quella versione di GCC per realizzare programmi
direttamente sotto windows.
Intendevo dire che, nel caso in cui volessi compilare qualcosa
per windows (non ho nessuna data in programma) dovro' tenere bene
in mente tutti i problemi di incompatibilita' tra Cygwin e i diversi
sistemi windows (soprattutto sui file di grandi dimensioni).
Ognuno dei due (Cygwin e MinGW) presenta vantaggi e svantaggi
rispetto all'altro...
