Newsgroup: it.comp.software.divx
Titolo: Togliere Packed Bitstream in modalità batch

ciao a tutti, dopo un po' di tempo torno a scrivere su questo gruppo...
Mi ritrovo una serie i cui episodi sono encodati con packed bitstream, 
vorrei sapere se esiste un programmino tipo MPEG Modifier che possa 
processarli in modalità batch, altrimenti mi toccherebbe modificarli uno 
per volta.
ciao,
2m23

, 
cioè una versione da linea di comando di MPEG Modifier che può essere 
eseguita per creare dei file .bat, ma mi rimane un dubbio: sulle FAQ di 
Giubbe c'è scritto che il tag in user data deve essere convertito, per 
esempio, da divx999b000p in divx999b000n. Siccome MPEG Modifier toglie 
la "p" e non la sostituisce, ci possono essere problemi???
ciao,
2m23

 problemi???
molto probabilmente non ci saranno problemi.
Probabilmente non ci sarebbero problemi nemmeno se lasciasse invariata
la scritta in "user data". Cio' che conta e' che il bitstream venga
riscritto in modo corretto
-- 
Home page: 
http://fsinapsi.altervista.org

Frank Sinapsi ha scritto:

capisco, pensavo che MPEG Modifier si occupasse soltanto di riscrivere 
lo user data...
in questo caso un'altra curiosità: perchè Giubbe consiglia quella 
modifica e non dice di selezionare solamente "unpack" lasciando lo user 
data impostato da MPEG Modifier??? a che serve quella "n"? ;)
ciao,
2m23

2M23 ha scritto:

esiste eccome, si chiama STVMux, è free e lo trovi sul mulo, scarica 
l'ultima versione, 1.40 beta
fa anche molto di + ma va bene per fare quello che serve a te
STVMux
PREMESSA:
Il programma e' nato come semplice script DOS che usavo io personalmente 
per non dover usare VDM su 20 e piu' file con le stesse operazioni 
ripetitive. Ho deciso quindi di riscriverlo con interfaccia grafica per 
renderlo piu' semplice ed intuitivo.
DESCRIZIONE:
L'utilizzo ideale di questo programma e' l'unione dei file AVI con i 
rispettivi file audio rilasciati per le serie TV.
Il programma e' dotato di interfaccia grafica e per il mux si basa su 
VirtualDubMod.
Il funzionamento e' molto semplice, basta selezioanre un certo numero di 
file AVI, indicare dove si trovano i file audio da muxare ed indicare la 
cartella di destinazione. A questo punto basta premere START e verra' 
eseguito il mux.
Il programma cerca in automatico il numero dell'episodio e della 
stagione e lo associa al file audio da muxare (leggere il manuale 
allegato per maggiori informazioni). Se sono presenti piu' 
corrispondenze viene richiesta una selezione.
Sono presenti opzioni come: la conversione del video a 25 o 23, la 
possibilita' di cambiare interlave, delay e preload, la possibilita' di 
mantenere e rimuovere la traccia audio originale, la pulizia del nome 
del file risultante, la rimozione del packet bitstream (solo dalla 1.40 
Beta in poi) ed altre cose che comunque consiglio di vedere manuale 
allegato.
NOTE:
- Il programma necessita di Netframework 2.0, nel manuale trovate il 
link dove scaricarlo.
- Il programma non tocca i file originali, quindi non ci sono 
possibilita' di perdita di dati.
ed2k://|file|STVmux.1.40.Beta.Release.061215.rar|1820006|97E08DF8C0473D8A48319D1FE800C975|/

 fa anche molto di + ma va bene per fare quello che serve a te
lo conoscevo, ma ero fermo alla versione 1.3qualcosa. l'ho usato in 
passato ed è molto utile...
magari l'autore potrebbe registrare un dominio gratuito su altervista 
per farsi reperire più facilmente e pubblicare gli aggiornamenti...
grazie mille, ora lo provo, magari questo non riscrive gli user-data (a 
quanto ho letto alcuni quando vengono privati della "p" finale sono 
indigesti ai lettori stand-alone, forse per questo motivo giubbe 
consiglia di cambiare la "p" in "n").
ciao,
2m23

 data impostato da MPEG Modifier??? a che serve quella "n"? ;)
il campo user data, di per se', non serve a granche': e' una specie
di "firma" che mette l'encoder ed e' utile agli stessi sviluppatori
di tale codec per controllare eventuali problemi con le varie
versioni. Riguardo alle specifiche MPEG-4 non ha un significato
preciso, quindi nessun decoder dovrebbe basare le sue decisioni
sul particolare valore di quel campo.
Comunque, il modo piu' semplice e immediato per soddisfare la tua
curiosita' e' quello di generare alcuni brevi filmatini, uno
con packed bitstream, uno in forma unpacked (ma con user data
uguale al precedente), uno in forma unpacked (con user data privato
della "p" finale), e uno unpacked (con user data dove al posto della
"p" c'e' una "n").
Li masterizzi su riscrivibile, e controlli come si comporta il
lettore con i vari casi.
In una decina di minuti, ti levi la curiosita'


2M23 ha scritto:

io lo uso, fammi sapere
ciao

 fa anche molto di + ma va bene per fare quello che serve a te
A me, quando lo utilizzo *solo* per eliminare il Packed Bitstream, 
crasha :-(
-- 
Willy

 guarda un po'
naaaaa, l'ho installato: serve a convertire tra vari formati... a prima 
vista è un programmone che fa tutto tranne quello che serve a me... ;)
ciao,
2m23

 In una decina di minuti, ti levi la curiosita'
ho fatto le prove coi quattro file e devo dire che su due lettori da 
tavolo che ho, non ho riscontrato differenze tra i file senza PB e con 
user data diversi. mi è sorta però un'altra curiosità: il file segnalato 
come con packed bitstream andava benissimo, come quelli senzaa PB e non 
presentava il solito effetto scattoso che avevo visto sul lettore con 
altri file con PB. com'è possibile?
ciao,
2m23

 altri file con PB. com'è possibile?
analizza quel file con PB con il mio programma avinaptic (nel sito in
firma), aprilo e chiedi l'analisi DRF, poi cerca nel rapporto il campo
"Max consecutive B-VOPs".
Molto probabilmente, quel valore dovrebbe essere 1.
Nei filmati in cui il lettore scatta, quel valore dovrebbe essere piu'
grande di 1 (tipicamente 2).
Se non e' cosi', segnalamelo.
Il packed bitstream e' una mostruosita' che fu introdotta da DivX
Networks quando aggiunse i B-frame al suo codec.
Gli estensori degli standard (MPEG e VCEG) trovarono molto presto la
soluzione piu' vantaggiosa per memorizzare uno stream composto da
frame I, P e B, ed e' quello di memorizzare prima i frame riferiti,
poi i referenti (anche se questi verrebbero prima temporalmente).
Ad esempio, supponiamo che la sequenza temporale dei frame sia fatta
in questo modo:
IBBPBBPBBP...
L'ordine di memorizzazione nel bitstream diventa questo:
IPBBPBBPBB...
Questo stratagemma semplifica molto la decodifica. Basta fare una
simulazione di decodifica:
Istante 0:
leggo il frame I, e non emetto niente in uscita
Istante 1:
leggo il frame P, ed emetto il frame I che ho letto all'istante 0
Istante 2:
leggo il frame B, ed emetto il frame B che ho letto adesso (lo
posso fare perche' ho sia il frame I letto all'istante 0, che
quello P, letto all'istante 1, che sono i due referenti del
frame corrente)
Istante 3:
leggo il frame B, ed emetto il frame B che ho letto adesso
Istante 4:
leggo il frame P, ed emetto il frame P che ho letto all'istante 1
Istante 5:
leggo il frame B, ed emetto il frame B che ho letto adesso (lo
posso fare perche' all'istante 4 ho letto il frame P che e' il
suo successivo referente)
e cosi' via...
Come puoi verificare, i frame vengono emessi in ordine
temporalmente corretto. L'unico svantaggio e' che vengono emessi
con un ritardo di un frame, rispetto ai tempi di lettura.
Puoi anche divertirti a verificare che questo processo puo'
continuare indefinitamente, senza avere mai interruzioni nel
flusso di emissione dei frames.
Inoltre, e' facile verificare che la correttezza del processo
e' indipendente dal numero di B-frame consecutivi: io ho fatto
l'esempio con 2 B-frames, ma funziona allo stesso identico modo
anche con un numero diverso.
Questa tecnica di memorizzazione e' efficace, ma il fatto che
introduce un ritardo tra flusso letto e flusso in uscita, lo
rendeva incompatibile con le specifiche delle funzioni delle
vecchie e poco lungimiranti API Microsoft VFW (che non
prevedevano concetti come i B-frames), quindi, i tizi di DivX
Networks, dato che volevano fornire una dll VFW (per motivi vari,
primo fra tutti perche' se non lo avessero fatto avrebbero
rischiato di perdere popolarita' nella comunita' degli
utilizzatori di codec) hanno inventato il famigerato "packed
bitstream": questo consiste nell'impaccare occasionalmente due
frame concreti dentro lo stesso "frame virtuale AVI".
Per farti capire meglio, tornando all'esempio sopra, se nel
primo frame dell'AVI vengono memorizzati sia il frame I che
quello P, quando al decoder (tramite funzione delle API VFW)
arriva il primo frame, lui si trova per le mani i primi due
frame, ed e' come se si trovasse direttamente all'istante 1
(in pratica, salta l'istante 0), e quindi puo' gia' emettere
il primo frame in uscita, rispettando il significato della
funzione VFW.
Questa tecnica ha il vantaggio di rendere MPEG4 con B-frames
compatibile con le API VFW, ma ha alcuni svantaggi:
innanzitutto complica la vita a chi deve scrivere un decoder
(che dovra' rilevare e gestire in modo opportuno questo caso
speciale), poi, ancora peggio, da' luogo a un bitstream non
corretto (per compensare i "frame impaccati", occorre
introdurre dei frame fittizi, chiamati "dummy N-VOP", che
sono coerenti con la sintassi MPEG-4, ma che falsificano il
bitstream da un punto di vista di sequenza temporale: in
pratica, un decoder deve saper distinguere tra N-VOPs "veri"
e "dummy", per gestire in modo corretto i "timecodes").
Gli sviluppatori di XviD, per non essere da meno (immagino per
paura di non poter competere con XviD nell'ambito degli utenti
Windows) fecero altrettanto, cioe' introdussero anche loro
il packed bitstream per poter usare B-frames tramite VFW, con
l'aggravante che XviD permette un numero maggiore di B-frames
consecutivi...
A questo punto, la mia ipotesi e' che i progettisti di alcuni
lettori da tavolo potrebbero aver gestito correttamente i
packed bistream nel caso di un solo B-frame, e gestito male
quelli con piu' B-frame (che si ottengono solo con XviD).
Questa dovrebbe essere la situazione dei lettori basati su
chip Mediatek (i miei lettori gestiscono bene tutti i casi).
Con il diffondersi di piu' recenti codec H.264 (come x264),
l'inadeguatezza delle specifiche VFW si e' fatta ancora piu'
marcata, e questo ha portato in un primo momento alcuni
sviluppatori a creare versioni speciali di x264 per VFW,
(presumo allo scopo di poter continuare a utilizzare VirtualDub
per codifiche con x264), mentre mi pare che la maggior parte
degli appassionati sia adesso orientata ad abbandonare VFW, in
favore dell'uso di specifiche librerie...
Questo vuol dire che a chi e' interessato a codificare in x264,
conviene abituarsi a utilizzare programmi che non usano codec
VFW...
