Newsgroup: it.comp.software.divx
Titolo: Conversione DIVX->DIVX a bitrate variabile con autoGK

Salve,
sto tentando di convertire con autoGK un AVI in un altro AVI di dimensioni
diverse. Il video originale ha bitrate variabile, e probabilmente questa 
e` la ragione per cui il video di output ha l'audio de-sincronizzato.
Il problema avviene indipendentemente dalla versione di autoGK (ho 
provato anche con l'ultima, 2.45). Nelle preferences di vdubmode ho 
attivato la modalita` "By default try processing MP3 VBR streams like 
nandub" (che in passato in situazioni analoghe aveva avuto successo), ma 
il risultato non e` cambiato. Quali altri opzioni delle preferenze 
biosogna cambiare?
Grazie

Riff raff ha scritto:

Secondo me il problema non è che il video sia stato codificato a bitrate 
variabile quanto che la traccia audio lo sia stata. Potresti provare a 
demuxare il tuo avi originale separando video e audio (virtualdub lo fa) 
e ricodificando quest'ultimo a bitrate costante. VirtualDub ha 
conclamate difficoltà con il bitrate variabile nelle tracce audio. Non a 
caso poi tu stesso dici che in passato "processando l'audio vbr..." 
risolvevi il problema.
Una volta ricodificato l'audio riuniscilo al video originale e riprova a 
codificare con agk e vedi che succede...
Ciao.
-- 
Michele

 
Ok, grazie mille; provero` cosi`.

Ok, grazie mille; provero` cosi`.
Aspetta. Il tuo AVI è un DVDmux? Se lo è può essere diverso il
framerate del video rispetto all'audio, ed è una cosa (e devi cambiare
il framerate nel menu video). Se non lo è, prima di perdere ore, fai
una prova empirica che dura un minuto:
apri l'AVI con VDub, imposta direct stream copy nel menu video, e in
quello audio apri le proprietà della traccia audio e metti 520 nel
preload e 13 nell'interleave, poi salva.
A volte basta questo. Se no, ok, passa a quello che ti ha detto
Michele.
-- 
Paradoxally,
Jan AxHell

 preload e 13 nell'interleave, poi salva.
Una mia curiosità: quei valori da dove scaturiscono?
E poi perchè dovrebbe perdere delle ore? Per ricodificare l'audio? Un pc 
con non più di dieci anni non penso ci impieghi più di 10 minuti...
Lui cmq alla fine aveva comunque intenzione di ricodifcare tutto il 
filmato se non sbaglio... :)
Ciao.
-- 
Michele

filmato se non sbaglio... :)
Parlavo sia di quello che della tua risposta.
Preload/Interleave
160ms/60ms 
64ms/64ms 
250ms/64ms 
500ms/64ms 
80ms/80ms (soprattutto per AC3 2.0 192kbps) 
90ms/90ms 
96ms/96ms 
120ms/120ms 
128ms/128ms (soprattutto per AC3 5.1 448kbps) 
500ms/128ms 
160ms/160ms (soprattutto per AC3 5.1 384kbps) 
256ms/256ms (soprattutto per AC3 2.0 224kbps)
160ms/2frames 
500ms/3frames
520/13frames (soprattutto per MP3 CBR/ABR con video a 25fps)
-- 
Paradoxally,
Jan AxHell

 520/13frames (soprattutto per MP3 CBR/ABR con video a 25fps)
Si. Questa tabella non mi è per nulla nuova e da qualche parte, tempo 
fa, devo averla letta anche io.
A questo punto non c'è altro da fare che provare, per il nostro amico 
intendo... ;)
Ciao.
-- 
Michele

 fa, devo averla letta anche io.
quella tabella serve a poco o nulla :-)
Ad esempio, in caso di audio MP3 VBR (o ABR), il tipo di muxing e'
obbligato (il muxer genera sempre un chunk audio per ogni frame MP3)
quindi anche modificando le impostazioni preload/interleave in VDub si
ottiene sempre lo stesso risultato (le impostazioni vengono ignorate).
In caso di audio CBR, in realta' non c'e' l'esigenza di forzare
valori cosi' precisi; basta non usarne di troppo sballati.
In genere, per non avere problemi basta un preload di circa mezzo
secondo e un interleave pari a un numero di video frames compreso
tra 1 e 12 (cioe' compreso tra 40 ms e circa mezzo secondo)
-- 
Home page di Frank: 
http://fsinapsi.altervista.org
Home page di Giubbe e FAQ: 
http://giubbe.altervista.org

tra 1 e 12 (cioe' compreso tra 40 ms e circa mezzo secondo)
Credimi, ho usato i valori che ho consigliato su diversi divx
scaricati dalla rete e sono passati da inutilizzabili (alcuni si
bloccavano se si saltava avanti col player) a perfetti. Come ho detto,
è una prova empirica, sulla carta avrà poco senso, ma a me è stata
utilissima. :-)
-- 
Paradoxally,
Jan AxHell

 bloccavano se si saltava avanti col player) a perfetti.
succede regolarmente anche a me, ma nei miei casi il rimedio e'
dovuto al remux corretto di un mux scorretto, non ai valori in se'.
Hai provato a rimuxare piu' volte usando valori un po' diversi
(purche' non sballati)?
Ad esempio, alcuni muxer sbagliano sistematicamente il mux di
audio VBR (gli effetti sono quelli che dici), e in tali casi basta
semplicemente rimuxare (con un muxer corretto) e si ottengono
risultati perfetti; tuttavia, in tali casi, i valori impostati di
preload e interleave vengono ignorati dal muxer


(purche' non sballati)?
Penso di aver fatto entrambe le cose, ma ormai è un pezzo che non mi
capita, onestamente non mi ricordo la casistica. Cmq quando ho
cambiato i valori, non ho rimuxato niente. Il remux (senza cambiare
valori) l'ho fatto in genere quando aprendo l'AVI da VDub mi appariva
il msg che la traccia audio era tronca di tot byte all'inizio. VDdub
in qualche modo la riparava, perchè dopo la direct stream copy era a
posto.
-- 
Paradoxally,
Jan AxHell

 cambiato i valori, non ho rimuxato niente.
e' proprio qui il punto.
Non puoi cambiare i valori di preload/interleave senza rimuxare :-)
Puoi impostare il ritardo di una traccia senza rimuxare, perche'
quello e' un valore memorizzato in un campo di una struttura che
fa parte degli headers di un AVI.
Ma "preload" e "interleave" non sono valori memorizzati nell'AVI,
sono parametri che indicano al muxer come deve muxare l'AVI.
In pratica procedi cosi': apri l'AVI con VirtualDubMod, imposti
i valori di preload/interleave, e risalvi in direct stream copy.
Se non risalvi, non hai fatto nulla.
Risalvando, viene appunto effettuato il remux, ed e' il remux che
mette a posto il file :-)
I valori di preload/interleave non sono importanti al punto da
dover usare valori ben precisi, a seconda dei casi.
In realta' vanno bene valori che sono compresi in un range
abbastanza ampio.
L'obiettivo e' quello di ottenere un AVI che possa essere letto
da un generico lettore in modo sequenziale, cioe' senza dover
fare spostamenti improvvisi in posizioni diverse del file.
Ad esempio, usando un interleave troppo alto, si ottiene un basso
numero di chunk audio molto voluminosi, quindi un lettore dovrebbe
avere un buffer molto grosso per contenere tali chunks; se quello
che ha non e' sufficiente, e' costretto a fare operazioni di
seeking avanti e indietro per il file. Questo puo' essere un
problema per alcuni lettori, specialmente lettori da tavolo, in
cui tipicamente cio' provoca salti, asincronie, blocchi...
Comunque, ci sono tipi di audio per cui il tipo di muxing e'
"obbligato" (come per MP3 VBR o ABR): cioe' un muxer che funziona
in modo corretto e' obbligato a muxare l'AVI in un modo ben
preciso, quindi in quei casi cade del tutto il concetto di
preload/interleave. In altre parole, anche se tu imposti valori
diversi, devi ottenere sempre lo stesso risultato (il muxer, per
ottenere un risultato corretto, deve ignorare le tue impostazioni).
Nel caso della persona che ha iniziato il thread, se con la
ricodifica ottiene un AVI desincronizzato, la soluzione e'
molto semplice:
gli basta estrarre l'audio MP3 dall'AVI di partenza e rimuxarlo
al video ricodificato.
Se l'AVI di partenza era sincronizzato (e non aveva ritardi
impostati sulle tracce), allora in quel modo dovra' ottenere
necessariamente un AVI sincronizzato (nella ricodifica la durata
del video resta invariata). Se in quel modo non ottiene un
risultato sincronizzato, allora il muxer ha muxato male, e gli
conviene provare a muxare con un altro programma...


mette a posto il file :-)
Ah, allora ok, ho rimuxato senza saperlo. :-) 
Facevo la differenza rispetto a quando prendo una traccia audio a
parte e la attacco/sostituisco manualmente all'AVI.
-- 
Paradoxally,
Jan AxHell