Newsgroup: it.comp.software.divx
Titolo: AVInaptic - ariaggiornamento

Qualcuno mi ha chiesto di fare un unico zip comprendente tutto
il pacchetto...
Sul sito, adesso, trovate la nuova versione che puo' essere
scaricata in forma completa (uno zip con l'eseguibile e tutte
le librerie, grande circa 3,6 MB), oppure come prima.
Queste sono le modifiche dell'ultima versione:
- ho migliorato il riconoscimento dei tipi di file (AVI e MKV);
- ho migliorato le info ricavate dai file MKV;
- quando rileva un filmato che ha il chunk 'google', alla voce
  "Tipo di contenitore" viene scritto "AVI Google" (questo tipo
  di AVI non viene letto dai lettori da tavolo che ho provato;
  dai vostri, non ne ho idea...);
- nei casi in cui e' presente il chunk 'google', e' possibile
  adesso usare una nuova voce di menu Misc->Salva_senza_'Google'
  che permette di risalvare il filmato senza il chunk 'google';
- i sottotitoli SRT vengono ora estratti in modo corretto dai
  file MKV (e' possibile scegliere se lasciarli in UTF-8 oppure
  convertirli in iso-8859-1 per usarli con i lettori da tavolo).
Va tenuto presente che la funzione "Salva senza 'Google'" l'ho
implementata in modo molto rozzo (in poco tempo): essa si limita
a risalvare il filmato togliendo il chunk fastidioso
(e apportando le minime modifiche per rispettare il formato AVI).
Comunque, se il filmato di partenza e' corretto, anche il
risultato dovrebbe essere corretto.
Sarebbe stato molto meglio scrivere un nuovo muxer AVI, in
modo da garantire la correttezza del filmato salvato in tutti
i casi; ma per fare cio' e' necessario molto piu' tempo, e non
so quando riusciro' a farlo. (Nel caso in cui lo faro', potro'
togliere quella opzione, che non sara' piu' necessaria...).
Ricordo che l'estrazione (demux) delle tracce dai file MKV,
attualmente funziona correttamente solo per:
- audio MP3;
- aucio AC3;
- audio DTS;
- sottotitoli SRT.
In tutti gli altri casi, si ottiene semplicemente lo stream
memorizzato nel MKV, che non e' completo (vanno aggiunte delle
informazioni durante il demuxing).
Forse aggiungero' il supporto anche per l'estrazione corretta
degli audio OGG Vorbis e AAC.
Le prossime versioni saranno rilasciate molto piu' di rado...
Cosi' rompero' un po' meno le scatole con tutti questi
annunci :-)
-- 
Home page: 
http://fsinapsi.altervista.org

 Cosi' rompero' un po' meno le scatole con tutti questi annunci :-)
Ce ne fossero di annunci così sul NG! ;)
-- 
Saluti, Kap - 
www.lordkap.it
 - ¥'s Fan #01 - 
www.pianetalibri.com
 - VCC
Uno scandalo è quella cosa che metà della gente ama inventare e a cui
l'altra metà ama credere. - Paul Chatfield

Queste sono le modifiche dell'ultima versione:
Devo dire che sta diventando molto molto bello :-)
Tanto pere fare concorrenza totale al DRFanalyzer, non č che
riusciresti a visualizzare il valore medio mentre si allunga la barra
percentuale? E poi l'altra cosa che manca (ma serve giusto per farsi
un'idea dei punti piů ostici di un film) č il grafico DRF..
Ma forse sono proprio queste le cose che rendono piů lento il
DRFanalyzer...
-- 
Paradoxally,
Jan AxHell

 DRFanalyzer...
no, non sono queste, la generazione dei grafici di per se' richiede
frazioni di secondo. Quasi tutto il tempo viene speso nell'analisi
del bitstream mpeg4, che e' abbastanza complessa (l'analisi dei
bitstream H.264 e' ancora piu' complessa, e non l'ho ancora fatta,
l'ho soltanto iniziata e rimandata a quando avro' voglia/tempo...).
Considera che, per ogni frame, non si conosce la posizione in cui
e' memorizzato il DRF, altrimenti si andrebbe direttamente li' a
leggere quel valore :-)
Invece no, bisogna decodificare tutta la parte di bitstream che
lo precede, e per di piu' lo hanno messo proprio alla fine
dell'header VOP!
Ti riferisci ai due grafici che si vedono nella pagina
http://www.geocities.com/analyzerdrf/index.html
 ?
Cioe', il "DRF Graphic" (a zone verde, gialla, rossa) e il
"Frame Size graphic"?
Posso generare anche quelli... e' facile e incide poco sui tempi
di elaborazione.
L'informazione visiva fornita dal "DRF Graphic" non e' piu'
significativa del DRF medio e della deviazione standard, e quindi
non e' molto utile; in pratica, se il codec si e' comportato bene,
la deviazione standard dovrebbe essere molto bassa (il che equivale,
in termini del grafico, ad avere una striscia colorata rettangolare).
Il secondo grafico (Frame Size graphic) dovrebbe mostrare la stessa
informazione del grafico visualizzato da avinaptic (Grafico del
bitrate medio parziale), con la differenza che questo e' una specie
di "integrale" dell'altro, quindi appare in una forma diversa (ma
secondo me piu' utile, perche' rispecchia le situazioni in cui si
e' trovato a prendere le decisioni il "rate control" del codec;
nel caso di passata multipla, i punti piu' "difficili" del film
sono quelli in cui la curva sale verso l'alto).
Per finire, ti ricordo ancora una volta che questi parametri
(drf medio e deviazioni standard) risultano "falsati" nel caso di
codifica XviD con b-frames (il famoso motivo per cui non riuscivi
ad accontentare DRFanalyzer, pur ottenendo risultati molto buoni).
Come avevo gia' spiegato, in mpeg4 si usano due matrici di
quantizzazione diverse, una per I-frame, l'altra per P e B.
La seconda ha valori piu' grandi della prima. Il motivo e' che i
frame I sono piu' "importanti", perche' sono il riferimento
iniziale di tutto il segmento (fino al prossimo frame I), e in
generale togliere dettagli dal frame I puo' degradare la qualita'
dell'intero segmento (in teoria non e' una conseguenza necessaria,
ma in pratica accade questo...). In mpeg4 i B-frame sono l'ultima
ruota del carro e non sono presi come riferimento di nessun altro
frame, ed e' piu' "tollerabile" sacrificarne la qualita', rispetto
agli altri tipi. Per questo, in assenza di specifiche opzioni, per
i B-frame XviD usa DRF piu' grandi (suppongo che anche DivX faccia
cosi').
Per farti un esempio, se codifichi in XviD a quantizer costante 2,
senza specificare altre opzioni, per default viene usato il
quantizer DRF=2 solo su frames I e P, mentre sui B viene usato il
valore DRF=4.
La conseguenza e' che non otterrai DRF medio=2 e deviazione=0
(come ci si aspetterebbe) ma DRF medio maggiore di 2, e deviazione
maggiore di 0.
Un'altra cosa importante da osservare e' che, sebbene i frames
I e P abbiano tutti DRF=2, le matrici di quantizzazione usate
sono diverse, quindi i dettagli rimossi dai P sono maggiori di
quelli rimossi dagli I, per cui c'e' un po' di "falsamento" dei
dati statistici anche senza usare B-frames...


 >'analisi dei
 >bitstream H.264 e' ancora piu' complessa, e non l'ho ancora fatta,
 >l'ho soltanto iniziata e rimandata a quando avro' voglia/tempo
implementa questa funzione e il tuo programma avra' una ESPLOSIONE di 
utilizzatori...
Dimmi se vuoi, e quando, che faccia una recensione sul forum inglese doom9
ciao
BHH

non e' molto utile;
Ti faccio notare che quel grafico copre solo 20 secondi di filmato: se
si fa scorrere la barra in mezzo, si vede a colpo d'occhio se ci sono
parti di film con valori sballati: in quel modo si sa subito a che
minuto/secondo č il problema e si puň guardare il filmato in quel
punto e decidere se č una cosa grave o no. L'alternativa č guardarsi
il film per intero, cosa che prende moooolto piů tempo :-) 
-- 
Paradoxally,
Jan AxHell

 Dimmi se vuoi, e quando, che faccia una recensione sul forum inglese doom9
ti ringrazio, ma prima devo riscrivere tutte le stringhe/messaggi
all'interno del programma: le riscrivero' in due sole lingue, italiano
e inglese, in modo che al lancio si possa selezionare la lingua;
nello zip mettero' due file batch (avinaptic-ita.bat), con comandi del
tipo: "avinaptic --lang=ita" oppure "avinaptic --lang=eng"
E' la prima idea che mi e' venuta in mente... ne hai di meglio?
Ciao e grazie


 il film per intero, cosa che prende moooolto più tempo :-) 
hai ragione, puo' essere utile.
Io tendo a pensare a codifiche fatte in proprio, nelle quali si
suppone di ottenere una deviazione bassa... Tuttavia, se capita per
le mani un filmato di cui non si sa nulla, puo' essere utile vedere
in quali zone sono stati usati DRF alti che possono aver degradato
troppo la qualita'...
Per implementare quel grafico (DRF Graphic) potrei fare cosi':
l'analisi resta esattamente com'e' ora, a cui pero' devo aggiungere
la memorizzazione di ciascun DRF in relazione al tempo.
In questo modo, il tempo necessario per l'analisi restera' invariato,
perche' la memorizzazione di tali valori e' del tutto trascurabile
rispetto al resto.
Poi dovro' scrivere un nuovo pezzo di programma, che gestisca una
finestrella tipo quella di DRFanalyzer, magari con il solo "DRF
Graphic" e una "slide" per selezionare la "zona" (di 20 secondi?)
del filmato di cui si vogliono vedere i DRF...
Ci devo pensare un po'...
Ciao e grazie


 il film per intero, cosa che prende moooolto piů tempo :-) 
ho implementato una prima versione del "Grafico DRF" (l'altro grafico
sarei propenso a non metterlo, a meno che io non mi convinca della
sua importanza :-))
Per vedere il "Grafico DRF" si procede cosi':
- per prima cosa, si clicca su Statistiche->Analisi_DRF e si aspetta;
- in seguito, si puo' cliccare su Statistiche->Grafico_DRF.
A questo punto si apre una nuova finestrina, che dovrebbe somigliare
a quella di DRFanalyzer... non ho mai visto DRFanalyzer, cosi' ho
dovuto basarmi esclusivamente sugli screenshots che compaiono nella
pagina web: ho cercato di farlo simile, con gli stessi colori, ma
puo' darsi che il giallo e il rosso, e altri dettagli, siano un po'
diversi... pazienza! :-)
Ho un po' tirato via... dovro' sistemare alcuni dettagli
I segmenti neri rappresentano i frame di tipo I.
Trascinando lo slide, ci si sposta all'interno del filmato (il
grafico viene continuamente ricostruito in tempo reale: ti avevo
detto che richiedeva minuscole frazioni di secondo... tuttavia
l'ho testato solo sotto linux, e spero che sotto windows non
risulti inutilizzabile!).
I bottoni con le freccine hanno questo significato:
- quelle blu permettono semplicemente di spostarsi al "segmento"
  precedente o successivo del filmato (la durata dei segmenti e' data
  dalla larghezza del grafico; se il framerate e' 25 fps, i segmenti
  durano 20 secondi);
- quelle arancioni permettono di spostarsi al prossimo o precedente
  frame che e' stato codificato con un DRF maggiore o uguale alla
  soglia impostata (modificabile con l'apposito spin button).
Vediamo un esempio pratico, per chiarire come si utilizza.
Supponiamo che il DRF medio sia "accettabile" (diciamo compreso tra
3 e 5), ma quello massimo sia un po' alto, diciamo 9 o superiore.
Questi valori ci suggeriscono che il filmato in media non sia
codificato malissimo (in media...), ma potrebbero esserci frame
di qualita' abbastanza degradata.
Quindi, impostiamo la soglia a un valore tipo 6 oppure 7 (o quello
che piu' si preferisce), e poi si clicca sulle frecce arancioni
per individuare il prossimo o il precedente frame che abbia un
DRF maggiore o uguale alla soglia.
Se, cliccando su una delle frecce arancioni, non si sposta di un
millimetro, vuol dire che in quella direzione non ci sono frame
che soddisfano quella proprieta' (sarebbe meglio se venisse una
finestrina informativa?).
Con questa tecnica, diventa molto semplice individuare le zone
che sono state codificate con DRF grandi (queste, poi, andranno
controllate "a occhio", come mi avevi detto).
Naturalmente, impostando la soglia a 0 o 1, qualsiasi frame
soddisfa la condizione, quindi cliccando sulle frecce arancioni
si ottengono spostamenti di un frame per volta.
Un'ultima precisazione: quando si clicca su una freccia arancione,
il riferimento e' il "frame attuale" (che e' il primo a sinistra
nel grafico).
Il tempo (hh:mm:ss) che compare alla sinistra dello slide e' quello
che corrisponde al "frame attuale"; quello a destra corrisponde
all'estremo destro del grafico (non corrisponde necessariamente
a un frame, perche' il filmato potrebbe finire prima di quel tempo).
Se ti vengono in mente altre idee o osservazioni, o miglioramenti,
fammi sapere... se mi piacciono e sono facili, ne terro' conto :-)
Ciao e grazie


fammi sapere... se mi piacciono e sono facili, ne terro' conto :-)
Allora: intanto è una scheggia, sia come analisi che come scorrimento,
e poi il tastino per andare direttamente ai frame a DRF = "N" è
ottimo.
Due "issues": ho notato che alcuni filmati scaricati da internet hanno
i titoli di coda completamente a DRF = 16, e questo mi pare venga
calcolato nella media. Se è così, è meglio che metti la possibilità di
ignorare gli ultimi minuti di un filmato, come fa DRFAnalyzer.
Inoltre, ma questa è una scemenza, quando è attiva la finestra del
grafico, questa non resta in primo piano, cosicchè può finire dietro a
quella principale di AVInaptic, la quale però resta inattiva. Per
qualche secondo temevo si fosse bloccato, mentre in realtà non avevo
chiuso il graifco che era finito dietro ai dati. :-) 
-- 
Paradoxally,
Jan AxHell

 chiuso il graifco che era finito dietro ai dati. :-) 
non e' affatto una scemenza, ma una grande seccatura. La versione
Linux e' ok: per evitare interferenze, ho impostato le finestre come
"modali" e "transienti".
La persona che fece il porting windows di quel toolkit grafico (Tor
Lillqvist) implemento' le finestre modali, ma non transienti, quindi
non restano in primo piano (come dovrebbe essere).
Comunque cerchero' di usare un "trucco"... Definire uno "stack" di
finestre: se una finestra riceve un segnale che indica che e' passata
in primo piano, ed essa non coincide con il top dello stack, allora
vuol dire che e' inattiva, e basta che rimetta in primo piano la
finestra sul top... dovrebbe funzionare...
Un'altra cosa da fare e' trovare il modo di abilitare il
"copia & incolla" del testo.
Vedro' di farle nella prossima.


> chiuso il graifco che era finito dietro ai dati. :-) 
a questo problema ho cercato di rimediare con qualche "trucchetto",
ma non sono sicuro che adesso sia meglio di prima. Se e' peggio,
ditemelo e lo rimetto com'era


ditemelo e lo rimetto com'era
Lampeggia un po' quando si clicca sulla finestra in background, ma per
me va benissimo.
-------------------------------------------------------------------------------------------------------------
[ Info sul file ]
Nome: La Scuola (1995) [ITA].avi
Data: 30/10/2006 18:47:39
Dimensione: 734,263,296 bytes
[ Info generiche ]
Durata: 01:40:28 (6027.88 s)
Tipo di contenitore: AVI OpenDML
Streams totali: 2
Tipo stream n. 0: video
Tipo stream n. 1: audio
Audio streams: 1
ISFT: VirtualDubMod 1.5.1.1a (build 1155/release)
JUNK: VirtualDubMod build 1155/release
[ Traccia video ]
FourCC: divx/DX50
Risoluzione: 544 x 304
Frame aspect ratio: 34:19 = 1.789473 (~16:9)
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 34:19 = 1.789473 (~16:9)
Framerate: 25 fps
Frames totali: 150697
Stream size: 637,714,521 bytes
Bitrate: 846.353306 kbps
Qf: 0.204710
Key frames: 1311 (0; 24; 252; 502; 662...)
Null frames: 0
Min key int: 1
Max key int: 250
Key int medio: 114.948131
Ritardo: 0 ms
[ Traccia audio ]
Audio tag: 0x55 (MP3)
Bitrate: 115.264 kbps VBR
Canali: 2
Frequenza: 48000 Hz
Chunks: 251162
Stream size: 86,855,328 bytes
Ritardo: 0 ms
[ Info sulla codifica MPEG4 ]
User data: DivX503b830p
Packed bitstream: yes
QPel: no
GMC: no
Interlaced: no
Aspect ratio: Square pixels
Quant type: H.263
Frames totali: 150697
Drop/delay frames: 0
I-VOPs: 1311 (0.869951 %)
P-VOPs: 75300 (49.967484 %)
B-VOPs: 74087 (49.162563 %)
S-VOPs: 0 (0 %)
N-VOPs: 0 (0 %)
Max consecutive B-VOPs: 1
[ Analisi DRF ]
DRF medio: 6.166478
Deviazione standard: 2.374425
DRF max: 17
DRF<3: 22 (0.014598 %)
DRF=3: 8860 (5.879308 %)
DRF=4: 45097 (29.925413 %)
DRF=5: 18775 (12.458692 %)
DRF=6: 10454 (6.937052 %)
DRF=7: 115 (0.076311 %)
DRF=8: 62195 (41.271284 %)
DRF=9: 2321 (1.540166 %)
DRF>9: 2859 (1.897171 %)
I-VOPs DRF medio: 3.630816
I-VOPs Deviazione standard: 1.324335
I-VOPs DRF max: 16
P-VOPs DRF medio: 4.425298
P-VOPs Deviazione standard: 1.714204
P-VOPs DRF max: 16
B-VOPs DRF medio: 7.981035
B-VOPs Deviazione standard: 1.400885
B-VOPs DRF max: 17
[ Analisi DRF 'corretta' (ignorati gli ultimi 2735 frames) ]
DRF medio: 5.975541
Deviazione standard: 1.930985
DRF max: 17
DRF<3: 22 (0.014868 %)
DRF=3: 8860 (5.987983 %)
DRF=4: 45097 (30.478565 %)
DRF=5: 18775 (12.688983 %)
DRF=6: 10454 (7.065279 %)
DRF=7: 115 (0.077722 %)
DRF=8: 62195 (42.034157 %)
DRF=9: 2321 (1.568635 %)
DRF>9: 2859 (1.932239 %)
I-VOPs DRF medio: 3.535741
I-VOPs Deviazione standard: 0.763093
I-VOPs DRF max: 16
P-VOPs DRF medio: 4.211126
P-VOPs Deviazione standard: 0.684118
P-VOPs DRF max: 16
B-VOPs DRF medio: 7.812759
B-VOPs Deviazione standard: 0.673129
B-VOPs DRF max: 17
-------------------------------------------------------------------------------------------------------------
[ Info sul file ]
Nome: Ricordati di Me (2003) [ITA].avi
Data: 5/11/2006 10:34:53
Dimensione: 735,047,680 bytes
[ Info generiche ]
Durata: 01:59:41 (7180.88 s)
Tipo di contenitore: AVI OpenDML
Streams totali: 2
Tipo stream n. 0: video
Tipo stream n. 1: audio
Audio streams: 1
ISFT: VirtualDubMod 1.5.1.1a (build 1639/release)
JUNK: VirtualDubMod build 1639/release
[ Traccia video ]
FourCC: divx/DX50
Risoluzione: 640 x 272
Frame aspect ratio: 40:17 = 2.352941 (~2.35:1)
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 40:17 = 2.352941 (~2.35:1)
Framerate: 25 fps
Frames totali: 179522
Stream size: 618,665,587 bytes
Bitrate: 689.236513 kbps
Qf: 0.158372
Key frames: 2176 (0; 21; 45; 47; 49...)
Null frames: 0
Min key int: 1
Max key int: 300
Key int medio: 82.500919
Ritardo: 0 ms
[ Traccia audio ]
Audio tag: 0x55 (MP3)
Bitrate: 116.792 kbps VBR
Canali: 2
Frequenza: 48000 Hz
Chunks: 299203
Stream size: 104,834,928 bytes
Ritardo: 0 ms
[ Info sulla codifica MPEG4 ]
User data: DivX503b959p
Packed bitstream: yes
QPel: no
GMC: no
Interlaced: no
Aspect ratio: Square pixels
Quant type: H.263
Frames totali: 179522
Drop/delay frames: 0
I-VOPs: 2176 (1.212100 %)
P-VOPs: 61778 (34.412303 %)
B-VOPs: 86166 (47.997192 %)
S-VOPs: 29403 (16.378402 %)
N-VOPs: 0 (0 %)
Max consecutive B-VOPs: 1
Warp points usati: 
    1: 100 %
[ Analisi DRF ]
DRF medio: 5.371016
Deviazione standard: 3.956397
DRF max: 30
DRF<3: 24 (0.013368 %)
DRF=3: 20374 (11.348963 %)
DRF=4: 83683 (46.614082 %)
DRF=5: 4070 (2.267118 %)
DRF=6: 61608 (34.317608 %)
DRF=7: 3643 (2.029266 %)
DRF=8: 0 (0 %)
DRF=9: 0 (0 %)
DRF>9: 6121 (3.409590 %)
I-VOPs DRF medio: 3.630055
I-VOPs Deviazione standard: 1.730085
I-VOPs DRF max: 20
P-VOPs DRF medio: 4.618148
P-VOPs Deviazione standard: 3.543457
P-VOPs DRF max: 20
B-VOPs DRF medio: 6.474119
B-VOPs Deviazione standard: 4.579190
B-VOPs DRF max: 30
S-VOPs DRF medio: 3.849029
S-VOPs Deviazione standard: 0.470134
S-VOPs DRF max: 5
[ Analisi DRF 'corretta' (ignorati gli ultimi 6107 frames) ]
DRF medio: 4.680946
Deviazione standard: 1.151326
DRF max: 30
DRF<3: 24 (0.013839 %)
DRF=3: 20374 (11.748627 %)
DRF=4: 83683 (48.255639 %)
DRF=5: 4070 (2.346957 %)
DRF=6: 61608 (35.526133 %)
DRF=7: 3643 (2.100728 %)
DRF=8: 0 (0 %)
DRF=9: 0 (0 %)
DRF>9: 6121 (3.529662 %)
I-VOPs DRF medio: 3.478200
I-VOPs Deviazione standard: 0.715575
I-VOPs DRF max: 20
P-VOPs DRF medio: 3.818200
P-VOPs Deviazione standard: 0.514272
P-VOPs DRF max: 20
B-VOPs DRF medio: 5.615808
B-VOPs Deviazione standard: 0.897098
B-VOPs DRF max: 30
S-VOPs DRF medio: 3.849029
S-VOPs Deviazione standard: 0.470134
S-VOPs DRF max: 5
-- 
Paradoxally,
Jan AxHell

 DRF max: 30
Stesso discorso di sopra: bisognerebbe controllare se 6107
frames corrisponde piu' o meno al punto in cui inizia la
parte codificata a DRF alti...
Ciao e grazie


parte codificata a DRF alti...
E qui a 1:55:36
Ciao!
-- 
Paradoxally,
Jan AxHell

 me va benissimo.
Confermo che mi sembra un flicker accettabile
Nell'ultima versione (perche' l'ho provato sono in questa), se si interrompe
l'analisi DRF con il tasto "interrompi", se si preme OK nella finestra di
conferma dell'azione, il programma mostra la schermata principale
con la scritta "Filmato non riconosciuto o corretto..."; e' corretto
questo comportamento? Non saprei giudicarlo. Bisogna riaprire il
file per rianalizzarlo da capo.
Se invece si preme annulla nella finestra di conferma, allore il programma
prosegue normalmente.
Volevo aggiungere una cosa che mi sembra non sia apparsa in altri tread.
Se il file da analizzare ha qualche vocale accentata nel nome, Avinaptic
genera un errore (appare una finestra tipo DOS, almeno in windowsXP)
e quando si chiude la finestra di errore il programma termina.
Walter

 e quando si chiude la finestra di errore il programma termina.
questo non lo sapevo!
A questo dovrei riparare con una conversione tra charsets, ma dovro' fare
qualche prova... comunque credo di avere capito...
Ciao e grazie per le segnalazioni


 E qui a 1:55:36
1:55:36 = 3600+60*55+36 = 6936 secondi
il punto individuato e':
(179522-6107)/25 = 6936.6 secondi
perfetto. Alle prime due prove, le regole hanno individuato il
punto di inizio dei titoli di coda con un buon grado di
precisione :-)
Direi di lasciarle invariate. Anche perche', anche se un filmato
dovesse avere i titoli di coda codificati a quantizer un po' piu'
alti del resto, se non soddisfano le regole allora non incidono
molto sul risultato, quindi anche se non vengono individuati non
e' tanto importante...


 Ciao e grazie per le segnalazioni
Grazie a te per l'impegno.
Io faro' altre prove a casa stasera; al lavoro uso solo
le ore libere (e non ho files su cui fare le prove).
Ciao,
    Walter 

 le ore libere (e non ho files su cui fare le prove).
nella versione attuale, spero di avere risolto questi problemi:
- apertura dei filmati con lettere accentate nel nome;
- adesso l'interruzione dell'analisi DRF dovrebbe lasciare la
  situazione com'era prima...
per ora non sono riuscito a trovare la causa dell'errore nel
calcolo della nuova distribuzione dei DRF nel caso in cui
vengono ignorati gli ultimi n frames (dovrebbero venire
numeri inferiori, in modo che la somma dei numeri tolti
coincida con il numero dei frames ignorati). Controllero' con
maggiore attenzione...


 vengono ignorati gli ultimi n frames
ecco, l'ho scoperto adesso :-)
Ovviamente era un bug. Nella prossima non ci sara'.
Questo bug non e' particolarmente critico: l'unico inconveniente
e' che i valori della distribuzione (nel caso in cui siano ignorati
i frames finali) possono essere piu' grandi del valore corretto.
In realta', l'unico valore sbagliato e' quello che corrisponde
a "DRF>9"
(mi ero dimenticato che da quel numero vanno tolti _tutti_ i
valori ignorati maggiori di 9, quindi anche 11 12 13 ecc... invece
ci levava solo quelli pari esattamente a 10)



Per questo caso confermo e senza problemi.
Ciao,
    Walter 

 ed appare la scritta:
[...]
la tua precisa descrizione mi e' molto utile.
Questi problemi sono dovuti a differenze tra la versione linux
e quella windows, che per fortuna sono abbastanza limitate.
L'ideale sarebbe scrivere il programma esclusivamente sotto linux
(dove ho un ambiente di sviluppo "confortevole" e procedo molto
speditamente) e in seguito compilare anche per windows. Quando
pero' si manifestano errori solo nella versione windows, la
situazione si fa difficile :-)
Comunque, questo caso delle conversioni dei path sembrerebbe
facile, stasera spero di risolverlo definitivamente.


piccola segnalazione... di poco conto
i tag matroska non li vede vero ?
gli ho dato in pasto un mkv con subs e piu' tracce audio, ognuna di esse 
(subs/audio) ha un nome, ad esempio "Director's cut" (audio) oppure piu' 
semplicemente Inglese / italiano per i subs, il programma mi ha 
riconosciuto la presenza delle tracce ma non e' stato in grado di dirmi 
i tag delle stesse... (e .. ma devo controllare ... i capitoli)
grazie per l'ottimo lavoro !
ciao
Andres Zanzani
Cesena, Italy
www.64k.it/andres
 -> Tutto per Mpeg4

 (e .. ma devo controllare ... i capitoli)
no, i capitoli per ora li ho ignorati. Forse li mettero', dici che
e' importante?
Ho anche saltato completamente gli "attachments" e altre cose...
In pratica ero interessato a un approccio "unificato" con gli AVI,
in modo che l'analisi dei bitstream MPEG-4 ASP funzionasse in modo
identico con contenitori diversi; se in futuro dovessi aggiungere
l'analisi dei bistream H.264 dovrebbe funzionare con qualsiasi
contenitore (se non e' troppo complicato, mettero' anche il
contenitore MP4)


 contenitore MP4)
stai facendo un egregio lavoro. continua cosi ! (noi aspetteremo..)


 applicazione...
sara' la prima cosa che mettero' perche' richiede pochi minuti :-)
Gli attachments sono facili, i capitoli devo ancora capirli...
