Newsgroup: it.comp.software.divx
Titolo: Divx e progressiva dissincronia audio

Ciao!
Mi è capitato di realizzare dei divx partendo da una fonte dati analogica.
Leggendo il divx sul lettore da tavolo pian piano l'audio si sfasa con il
video. Dopo circa 1h di visione l'audio 'arriva dopo' circa due secondi il
video. 
A cosa è dovuto ? 
Un bitrate video troppo alto ? (2000kb/s ... non so se sia troppo, ma
penso che siamo in media per una buona qualità video)
Una bitrate audio troppo alto? Di solito comprimo l'audio mp3 in modalità
CBR 256kb/s. Forse è un pò altino ? Forse anche un 192 può andare bene ?
non so..
La cosa strana è che avevo 'spezzato' un avi bello grande in due parti
uguali. Il problema si verifica su entrambi le parti dopo 45m o 1ora di
divisione. Anche l'inizio della seconda parte inizialmente è ok. A riprova
che il file AVI non è danneggiato, è solo un problema di lettura del
lettore da tavolo.
Come elimino il problema? Il codec usato è divx6.
Ciao e grazie 1000 per eventuali info!
-- 
--
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 lettore da tavolo.
quindi sul pc e' tutto ok...
magari posta tutte le informazioni rilevate da GSpot, giusto per vedere
se c'e' qualche valore anomalo (framerate strano o qualcos'altro...)
se l'audio tende ad arrivare sempre piu' in ritardo, visto che dici
che hai fatto un'acquisizione, mi e' venuta un'idea... potrebbe
trattarsi di "zero-length frame", di cui parlavo appunto in un altro
thread: durante le acquisizioni, per motivi di mantenimento del
sincronismo tra audio e video, i programmi usano inserire duplicati
di frame; il problema che riscontrai tempo fa e' che il mio lettore
stand-alone non rispettava tale tipo di frame (invece di aspettare
per il tempo necessario, li skippava, e quindi il video tende ad
andare un po' piu' veloce dell'audio...). non e' detto, pero', che si
tratti del tuo caso.

 andare un po' piu' veloce dell'audio...).
ho appena fatto un esperimento, e ti confermo che il mio lettore
(con il firmware migliore che ho) non rispetta i "zero-byte" frame.
ho codificato lo stesso filmato con due comandi quasi identici,
facendo in modo che il primo avesse molti "zero-byte" frame (in
numero pari a un sesto del totale), e il secondo non ne avesse
nessuno (mi e' bastato aggiungere l'opzione "-vf harddup" in
mencoder).
ebbene, i due filmati sono riprodotti in maniera identica sul pc,
ma il lettore stand-alone riproduce in modo sincronizzato solo il
secondo! il primo lo riproduce a velocita' piu' elevata e quindi
l'audio ritarda progressivamente rispetto al video.
il problema e' questo; supponiamo che i frame del filmato siano
fatti cosi':
1) primo frame
2) secondo frame (uguale al primo)
3) terzo frame
4) quarto frame (uguale al terzo)
5) quinto frame
un programma di codifica potrebbe codificare solo il primo, il
terzo e i quinti, e rappresentare i due duplicati con "zero-byte"
frame per risparmiare spazio.
un player corretto dovrebbe comportarsi cosi':
istante 1 -> visualizza il primo frame;
istante 2 -> vede zero-length, cioe' duplicato, quindi non fa
             niente, ma ASPETTA fino all'istante 3;
istante 3 -> visualizza il terzo frame;
istante 4 -> vede zero-length, cioe' duplicato, quindi non fa
             niente, ma ASPETTA fino all'istante 5;
istante 5 -> visualizza il quinto frame;
il mio lettore stand-alone, invece si comporta cosi':
istante 1 -> visualizza il primo frame;
istante 2 -> vede zero-length, che non supporta, quindi visualizza
             il terzo frame;
istante 3 -> vede zero-length, che non supporta, quindi visualizza
             il quinto frame;
l'errore consiste nel fatto che non aspetta!
quindi il video scorre piu' velocemente di quello che dovrebbe.
non so quale programma permetta di controllare se un filmato
contenga degli "zero-byte" frame, per ora l'unico modo che ho
trovato e' quello di usare "mplayer" con una riga di comando
come questa:
mplayer z1.avi -v -v | grep "len:     0"
le opzioni "-v" "-v" servono per aumentare il livello di
verbosita' di mplayer, mentre "grep" serve per filtrare
eventuali messaggi che contengono la sottostringa "len:     0"
(ci sono 5 spazi tra i due punti e lo 0);
se il filmato ha "zero-byte" frame, vengono stampate delle
righe del tipo:
12273:  00dc     0  0000000000F48C3A  len:     0  ...
se invece non ne ha, non viene stampato niente.
secondo me, potresti controllare se i tuoi filmati hanno questa
peculiarita', perche' in effetti il problema di asincronia
potrebbe anche derivare da questo...