Newsgroup: it.comp.software.divx
Titolo: Corruption!

Ragasuoli,
analizzo un dvx con Mpeg4modifier e a circa il 41%
mi restituisce il seguente errore
"the AVI is corrupt (chunk ends after its containing list)"
e anche DRF Analyzer mi dice esserci 1 dropped frame...
provo quindi a salvare il solo video con VirtualDubMod
come "old" AVI 1.0, riapro con Mpeg4modifier ma stavolta
l'errore e' diverso, sempre allo stesso punto
"this is not a valid MPEG-4 video (startcode not found
at beginning of frame)"
Idee? suggerimenti? esorcismi? grazie... ;)

 Idee? suggerimenti? esorcismi? grazie... ;)
ti ricordi quel programmino "zero-byte.exe" che ti dissi di
scaricare?
ti riporta per caso un valore "zero-byte" diverso da 0 su
quell'AVI?

 quell'AVI?
Hi great Frank,
su quale avi? su quest'ultimo o su quello da 29,9xxfps
che aveva frames doppioni? quello la' restituiva zero,
te lo scrissi qui sull'enneggi', forse non ero stato chiaro.
Un'altra cosa Frank: che caspiterina sono i "warp point(s)",
che quando il lettore standalone li trova da' di matto?
Li elimino senza riencodare? grazie e rigrazie, geniaccio.

 Li elimino senza riencodare?
mi sa di no, ma non ne sono per niente certo

 mi sa di no, ma non ne sono per niente certo
ok riencodero' anche questo,  processore mio oggi lavori :)

 for unreadable frames con Vdubmod
"45 frames masked (1 frame bad, 44 good but undecodable)"
God only knows who's the moron that made this masterpiece...

 God only knows who's the moron that made this masterpiece...
puo' anche darsi che il file in origine fosse buono e che abbia
subito una mutazione durante un trasferimento...
magari puoi evitare di ricodificarlo, presumendo che quei 45
frames siano consecutivi potresti selezionarli e tagliarli via

 subito una mutazione durante un trasferimento...
"The attack of the mutant dvx", mi mancava! :)
seriamente, riprovero' col trasferimento, visto che ho ricordato
di aver avuto un miniblackout con off/on improvviso, che quindi
avvalora il tuo sospetto. grazie!
 

 avvalora il tuo sospetto. grazie!
i sistemi p2p usano funzioni "hash" per controllare l'integrita'
dei file, ma per vari motivi possono nascere "mutazioni" (file
che differiscono per qualche bit da quelli originali), e tali
mutazioni possono diffondersi anche piu' degli originali.
ad esempio, alcuni programmi p2p possono essere configurati in
modo da ignorare i fallimenti nei controlli di integrita' (questo
perche' molte persone preferiscono avere prima possibile un file
che "comunque si vede, perlopiu'..." piuttosto che doverne
riscaricare dei pezzi).
tempo fa presi da "gnutella" un vecchio concerto (un AVI molto
diffuso, che si scarica velocemente), e nella parte finale c'erano
molti frame corrotti... eppure il trasferimento era andato a buon
fine (la funzione "sha1" del file coincideva con quella riportata)
e non era nemmeno un problema di cattiva codifica: era proprio il 
file che era diverso dall'originale, che dopo qualche mese ho
ritrovato sotto forma di torrent: il nome del file era un po'
diverso (i nomi dei file sono quelli che subiscono le maggiori
mutazioni; sembra che la gente si diverta un casino a
rinominarli :-)), ma la lunghezza in bytes era la stessa...
in casi come questi si puo' usare un "trucco", cioe', per prima
cosa si fa creare al client bittorrent il contenuto "vuoto"
(nel mio caso mi aveva creato il file avi, di 0 bytes) e si
esce subito da bittorrent; poi si copia sopra al file vuoto il
file (corrotto) che gia' si aveva, e si fa ripartire il client,
che si lamenta con un messaggio come questo:
"Could not load fastresume data: Fastresume info doesn't match
file modification time. Will perform full hash check."
a questo punto individua i chunk in cui fallisce il test
dell'hash e tenta di scaricare dagli altri peer _solo_ quelli,
sostituendoli a quelli bacati.
in questo modo, in poco tempo si riottiene il file integro
senza doverlo scaricare da zero.

 senza doverlo scaricare da zero.
Sorvolando sul fatto che dovrei rileggere 7/8 volte questo
tuo escamotage per sperare in una corretta applicazione, :)
sono gia' quasi a meta', comunque devo ammettere che almeno
a me pare un incidente assolutamente rarissimo.
Sara' che sono un amante dell'anticaglia a 23,976fps (you
know what I mean) ma i miei oggetti del desiderio sono
sempre perfetti ;)

 a me pare un incidente assolutamente rarissimo.
forse e' raro sulla rete edonkey (che usai troppo poco per
potermene fare un'idea), ma sulla rete gnutella e' un fenomeno
molto diffuso: impostavo una ricerca (diciamo "rocky horror
picture show", tanto per fare un esempio), e dopo un po' mi
veniva una lista di risultati... su tale rete i file sono
univocamente individuati dal loro hash sha1, quindi, anche
se nei risultati compaiono file con nome diverso, vengono
"aggregati" per sha1; il punto e' che molto spesso, si
formano piu' aggregazioni diverse di quello che dovrebbe essere
lo stesso file; in altre parole: esistono piu' file condivisi,
aventi tutti la medesima lunghezza e un nome simile, ma che
differiscono per sha1. questo vuol dire che una parte di
tali file ha sicuramente subito una mutazione (e' corrotto), e
nonostante cio' continua a essere condiviso e diffuso...
spero di essermi spiegato :-)

 spero di essermi spiegato :-)
Meglio di Piero Angela. Ma quel che mi fa pensare che col muletto
NON sia la stessa cosa (files corrotti ma malgrado cio' condivisi)
e' che p.e. il file in oggetto ha 212 (duecento12) fonti, e per
definizione dovrebbe essere il medesimo file per tutti: possibile
che nessuno si sia accorto che 2 secondi "quasi-clou" sono bacati???
Anyway, a domattina l'ardua sentenza...

 Anyway, a domattina l'ardua sentenza...
Aggiornamento: e' proprio il file in origine ad essere corrotto,
cioe' NON si era rovinato durante il trasferimento malgrado il blackout.

 cioe' NON si era rovinato durante il trasferimento malgrado il blackout.
mi pare restino due possibilita':
1) il file e' nato corrotto, nel senso che l'encoder usato per crearlo
   era bacato;
2) il file e' nato sano, ma in qualche modo e' saltata fuori quella
   copia corrotta (forse un errore durante un trasferimento, o chissa'
   cos'altro...), il cui proprietario l'ha messa in condivisione e
   si e' diffusa al posto dell'originale sano
comunque, non c'era un modo per assicurarsi se il primo trasferimento
era andato a buon fine?
quando usavo gnutella, il programma (gtk-gnutella) memorizzava le
informazioni relative ai file che scaricavo, quindi bastava controllare
che l'hash del file corrispondesse con quello memorizzato...

 era andato a buon fine?
Non saprei, non ho avuto alcun "warning" ne' avvisi ne' report infausti
di alcun genere. E a ragione a quanto pare, poiche' il secondo file
si e' rivelato null'altro che copia identica del precedente.
Ora devo (tentare di) sistemarlo, ahime'...