Newsgroup: it.comp.software.divx
Titolo: tagliare un divx in qualsiasi posizione (avidemux2)

e' possibile tagliare un divx in qualsiasi posizione (non
necessariamente in corrispondenza di un keyframe), senza
doverlo ricodificare?
ebbene, la risposta e': si'! :-)
ringrazio Alberto per averlo segnalato!
ammetto che fino a pochi minuti fa ero abbastanza scettico
su questa feature di "avidemux2", ma adesso mi sono convinto.
ho preso un film codificato con XviD (in futuro ripetero' la
prova con altri codec, in particolare con il DivX ufficiale),
e mi sono fatto stampare le posizioni occupate dai suoi
keyframes; riporto qui le prime 10 righe di tali posizioni:
------------------------------------------------------------
0 250 500 517 767  1017  1267  1517 1767 2017 2267 2517 2767
2821  3071 3321 3571 3703 3710 3715 3791 3792 3815 3837 3894
4066 4177 4386 4633 4883 5133 5363 5613 5856 6106 6144  6249
6298 6338 6387 6637 6735 6822  6850 6882 6967 7080 7123 7169
7228  7329 7380 7454 7497 7531 7569 7620 7689 7884 7927 7984
8038 8081 8130 8170 8205 8277 8308 8338 8366 8382 8414  8447
8499 8525 8590 8641 8710 8801  8834 8914 9016 9071 9203 9295
9341  9377  9412  9500 9535 9663 9830 9923 10019 10145 10395
10467 10694 10944 11083 11321 11471 11673 11853 12046  12211
12461 12658 12908 12975 13225  13346 13596 13628 13878 14128
------------------------------------------------------------
come e' ovvio, il primo (0) e' un keyframe; il secondo
keyframe e' alla posizione 250, e il terzo alla 500; questo
e' facilmente spiegabile, perche' nei primi 20 secondi del
film c'e' la sigla ed e' facilmente comprimibile, poi c'e'
un cambio di scena e il codec ha generato il terzo keyframe
alla posizione 517.
a questo punto ho scelto una "zona" sulla quale analizzare
il comportamento di avidemux2:
mi sono spostato fino al frame 8831, che viene riportato
correttamente come keyframe, poi, cliccando su "next keyframe"
arrivo a 8834, poi 8914 ecc.
poi mi sono posizionato sul frame 8811 e l'ho marcato come
"inizio selezione" (N.B. si tratta di un b-frame), poi mi
sono posizionato sul 8919 e l'ho marcato come "fine selezione".
poi ho salvato la selezione.
il programma mi chiede se voglio abilitare la "smart copy",
rispondo si' e lui mi chiede di impostare un fattore "Q"
(2-31), lascio il valore di default (4).
l'impressione che ho avuto e' che abbia codificato (non con
XviD, ma con il codec mpeg-4 di libavcodec!) soltanto i
frames nel range [8811,8833], e che abbia fatto un "direct
stream copy" dei successivi...
c'e' da osservare che il segmento salvato ha 108 frames
(8919-8811); questo vuol dire che uno dei due estremi non
e' stato incluso (presumo il secondo...).
adesso mi faccio stampare le lunghezze (in bytes) dei frames
compresi nel range [8811,8919], nel film originale;
ecco qua:
---------------------------------------------------
8811 ( 1207) 8812 ( 3549) 8813 ( 1083) 8814 ( 6816)
8815 (  887) 8816 ( 3477) 8817 ( 1133) 8818 ( 6357)
8819 (  578) 8820 ( 3159) 8821 (  772) 8822 ( 6278)
8823 (  807) 8824 ( 5454) 8825 (  590) 8826 ( 2292)
8827 (  480) 8828 ( 5722) 8829 (  693) 8830 ( 4654)
8831 (  277) 8832 ( 1995) 8833 (  242) 8834 (21541)
8835 ( 5155) 8836 (  720) 8837 ( 4740) 8838 (  469)
8839 ( 2932) 8840 (  277) 8841 (  918) 8842 (  206)
8843 ( 2752) 8844 (  205) 8845 ( 2838) 8846 (  230)
8847 ( 1258) 8848 (  203) 8849 ( 3211) 8850 (  255)
8851 ( 2268) 8852 (  263) 8853 ( 1986) 8854 (  184)
8855 (  949) 8856 (  118) 8857 ( 2217) 8858 (  206)
8859 ( 1914) 8860 (  174) 8861 ( 1449) 8862 (  178)
8863 ( 3032) 8864 (  223) 8865 ( 2114) 8866 (  195)
8867 ( 2202) 8868 (  196) 8869 (  852) 8870 (  151)
8871 ( 2538) 8872 (  309) 8873 ( 2251) 8874 (  252)
8875 ( 1040) 8876 (  120) 8877 ( 2638) 8878 (  285)
8879 ( 2549) 8880 (  313) 8881 ( 1980) 8882 (  273)
8883 ( 1162) 8884 (  203) 8885 ( 2902) 8886 (  245)
8887 (  777) 8888 (  112) 8889 ( 2139) 8890 (  247)
8891 ( 1623) 8892 (  190) 8893 (  871) 8894 (  176)
8895 ( 2696) 8896 (  170) 8897 ( 1434) 8898 (  209)
8899 ( 2561) 8900 (  242) 8901 ( 1960) 8902 (  170)
8903 ( 1751) 8904 (  194) 8905 (  851) 8906 (  125)
8907 ( 2482) 8908 (  149) 8909 (  937) 8910 (  132)
8911 ( 3615) 8912 (  266) 8913 ( 1965) 8914 ( 9107)
8915 ( 1973) 8916 (  239) 8917 ( 4095) 8918 (  535)
8919 ( 1223)
---------------------------------------------------
le lunghezze in bytes sono i numeri riportati tra
parentesi e si riferiscono al frame indicato alla loro
sinistra.
si puo' notare come, in questo range siano presenti solo
due frames e sono facilmente individuabili a occhio come
quelli piu' grandi: 8834 (21541 bytes) e 8914 (9107 bytes).
tutti gli altri sono p-frames e b-frames (questi ultimi
sono quelli che in media occupano meno spazio...).
adesso analizzo il segmento salvato da avidemux2.
per prima cosa mi faccio stampare le posizioni dei suoi
keyframes:
------------------------------------------------------------
0 23 103
------------------------------------------------------------
osserviamo che 23=8834-8811 e 103=8914-8811
cioe', il secondo e il terzo keyframes del segmento si trovano
esattamente nelle stesse posizioni del film originale.
adesso mi faccio stampare le lunghezze dei frames del
segmento:
---------------------------------------------------
   0 (10686)    1 ( 2983)    2 ( 1250)    3 ( 3109)
   4 ( 1300)    5 ( 2761)    6 ( 1446)    7 ( 3165)
   8 (  756)    9 ( 2540)   10 ( 1237)   11 ( 2970)
  12 ( 1034)   13 ( 2482)   14 (  919)   15 ( 1954)
  16 (  737)   17 ( 2550)   18 (  812)   19 ( 2191)
  20 (  469)   21 ( 1293)   22 (  955)   23 (21541)
  24 ( 5155)   25 (  720)   26 ( 4740)   27 (  469)
  28 ( 2932)   29 (  277)   30 (  918)   31 (  206)
  32 ( 2752)   33 (  205)   34 ( 2838)   35 (  230)
  36 ( 1258)   37 (  203)   38 ( 3211)   39 (  255)
  40 ( 2268)   41 (  263)   42 ( 1986)   43 (  184)
  44 (  949)   45 (  118)   46 ( 2217)   47 (  206)
  48 ( 1914)   49 (  174)   50 ( 1449)   51 (  178)
  52 ( 3032)   53 (  223)   54 ( 2114)   55 (  195)
  56 ( 2202)   57 (  196)   58 (  852)   59 (  151)
  60 ( 2538)   61 (  309)   62 ( 2251)   63 (  252)
  64 ( 1040)   65 (  120)   66 ( 2638)   67 (  285)
  68 ( 2549)   69 (  313)   70 ( 1980)   71 (  273)
  72 ( 1162)   73 (  203)   74 ( 2902)   75 (  245)
  76 (  777)   77 (  112)   78 ( 2139)   79 (  247)
  80 ( 1623)   81 (  190)   82 (  871)   83 (  176)
  84 ( 2696)   85 (  170)   86 ( 1434)   87 (  209)
  88 ( 2561)   89 (  242)   90 ( 1960)   91 (  170)
  92 ( 1751)   93 (  194)   94 (  851)   95 (  125)
  96 ( 2482)   97 (  149)   98 (  937)   99 (  132)
 100 ( 3615)  101 (  266)  102 ( 1965)  103 ( 9107)
 104 ( 1973)  105 (  239)  106 ( 4095)  107 (  535)
---------------------------------------------------
come si puo' osservare, i primi 23 frames (da 0 a 22)
del segmento non corrispondono per niente ai
corrispettivi del file originale (in particolare, il
primo, che e' un keyframes, e' bello grosso), mentre,
a partire dal frame 23 (il primo keyframe successivo
al taglio), le lunghezze coincidono perfettamente.
questo conferma la mia prima idea, cioe' avidemux2 ha
usato un codec (non XviD, ma libavcodec) per ricodificare
a quantizer costante (Q=4, che mi aveva fatto scegliere...)
il solo segmento [8811,8833].
la cosa che non sapevo e che mi ha colpito di piu' e' che
un filmato "ibrido" come questo risultasse tranquillamente
riproducibile dai vari players...
si puo' osservare anche che i primi 23 frame presentano
caratteristiche diverse dal resto del filmato (ad esempio,
sono cosituiti da un I-frame seguito da soli P-frame,
mentre nel resto sono presenti anche B-frame secondo uno
schema del tipo IBPBPBP... (anche se sono memorizzati
come IPBPBPB...)).
una cosa buffa e' che lo stesso avidemux2, quando apre il
segmento, resta confuso dall'assenza di b-frames:
--------------------------------------
 checking for B-Frames...
Seems it does not contain B-frames...
 End of B-frame check
--------------------------------------
invece i b-frames ci sono, ma dopo :-)
evidentemente, avidemux2 usa il principio euristico di
analizzare i primi frame per capire se abbia b-frame o
meno... (a quanto pare non c'e' scritto da nessuna parte)
sono piacevolmente sorpreso! :-)

 il solo segmento [8811,8833].
ho visto che c'e' scritta la stessa cosa anche nella
documentazione, sebbene in modo poco preciso

 stream copy" dei successivi...
Non per essere pignolo, ma la risposta è no. Esiste un programma che fa
tutto in automatico, ma il DivX (o XviD) ancora non si può tagliere dove si
vuole senza una ricomprensione (almeno parziale). Fino ad ora si dovevano
utilizzare due programmi distinti (o il solo aviutil, in verità), ora si
può fare solo più comodamente, ma la ricomprensione, parziale, resta.
Hai provato il risultato sul lettore da tavolo (oltre che i diversi player
software)?
Bye, Giubbe
-- 
HomePage e FAQ: 
http://giubbe.altervista.org
Inutile scrivere in privato, non ricevo le email

 player software)?
si', e non fa una piega.
quel filmatino della prima prova era troppo piccolo (4 secondi), allora
ne ho fatto un altro (cosi' ho testato anche cosa succede con il codec
DivX ufficiale) di 1611 frames (circa 64 secondi), i cui primi 221 sono
stati ricodificati da avidemux2 (circa 9 secondi); come ho detto sopra,
il lettore stand-alone lo riproduce senza problemi, non riesco neppure
a notare che i primi 9 secondi sono stati ricodificati; l'audio e'
perfetto...
ciao

 che codec usa aviutil, per ricodificare i frame iniziali?
Lo aggiungo senz'altro alle faq.
Mi ero spiegato male. Aviutil non ha la stessa funzione, ma puoi unire due
filmati con bitrate diverso. Io fino ad oggi ricodificavo il pezzettino con
virtualdub e poi univo i due pezzi con aviutil, dato che aviutil può a sua
volta ricodificare è possibile usarlo per entrambe le operazioni.
Ovviamente l'uso di avidemux2 è più facile ed intuitivo, quindi cambierò
metodo.
bye


 metodo.
fai attenzione a usare la versione recente (2.1.2) perche' avevo una
versione vecchia (2.0.22) assai buggata: ne avevamo parlato con Alberto
sul Ng.
io avevo trovato un bug nell'accesso ai frame, mentre Alberto aveva
segnalato un problema nella gestione dei b-frames: le vecchie versioni,
quando avevano a che fare con una sequenza del tipo IBPBPBPBP...
le trattavano come se fosse IPBPBPBPB... (che e' l'ordine in cui sono
effettivamente memorizzate nello stream), e questo produceva un effetto
"avanti e indietro" molto fastidioso...
a un certo punto devono averlo risolto, perche' la versione 2.1.2 si
comporta in modo corretto.
ah, ho anche testato la feature di taglio su un XviD con qpel e b-frames:
tutto ok!
quantomeno sul pc, perche' sul lettore stand-alone non ho provato (non
legge qpel...).
su un segmento di alcuni minuti, avidemux ha ricodificato i primi
232 frame con una sequenza IPPP... (un I-frame seguito da 231 P-frame)
e ha lasciato inalterato tutto il resto.
pensavo che in questo caso non avrebbe funzionato a causa del qpel,
invece mplayer lo riproduce senza battere ciglio...
quindi, e' possibile mescolare parti codificate con e senza qpel?
ciao

 farlo qualsiasi programma.
Intendo video. Virtualdub (ad eccezione di uno che non ricordo come si
chiama) fa storie per un bitrate diverso (mai capito quale è la soglia)
