Newsgroup: it.media.video.produzione
Titolo: Aggiungere bytes a una clip senza renderla illeggibile

Ciao NG,
 
Quesito un po' tecnico ma gluglu non mi restituisce niente
di utile, provo qui.
 
In un software di rinomina automatica che sto scrivendo
avrei la necessità di avere un identificativo univoco per
ogni clip. L'unico dato quasi sempre univoco che non
cambia col nome file è la sua dimensione, solo che ho già
scovato alcune clip differenti ma di uguale dimensione su
disco.
 
Potrei aggirare il problema prendendo l'hash di ciascun
file e complicando un po' il software ma prima di
ripiegare su questa soluzione una possibilità più semplice
sarebbe di modificare il file video aggiungendo un
differente numero di bytes a caso dopo la fine.
 
Questo però potrebbe rendere il file illegibile se per
caso dopo i vari campi di header che sicuramente ci sono,
il formato si aspetta un numero esatto di bytes; per
esempio il formato potrebbe prevedere una serie di dati
all'inizio tra cui il numero di frames, si conosce la
dimensione di ciascun frame e il lettore potrebbe voler
controllare che il numero di bytes dall'inizio dei frames
sia quello prevedibile. Dubito che sia così perché non
credo esista in giro alcun equivalente video di una bitmap
ma possono esserci centomila altri motivi del perché ci si
aspetti una dimensione esatta.
 
Se esistessero non oltre 3-4 formati video potrei
prendermi i protocolli di ciascuno e studiarmeli, ma son
tantissimi e la strada è impraticabile. Però esiste la
possibilità che questo problema non sia io il primo ad
averlo, che qualcuno su questo NG l'abbia in qualche modo
almeno sfiorato e che ne sappia qualcosa.
 
Grazie per eventuali info
 
Apx.
 
-- 
"Caro, la bambina sta piangendo. Vado a cambiarla"
"OK; se riesci, trovane una che dorma di notte"
 

 
"Archaeopteryx" <cor.bonukFANCULOSPAM@libero_NOMAIL_.it> ha scritto nel 
messaggio news:pl41ug$d6d$1...@gioia.aioe.org...
Ciao NG,
 
Quesito un po' tecnico ma gluglu non mi restituisce niente
di utile, provo qui.
 
 
LucaMabat 
 
 


??? Non ho capito, commissa'.... :/


 ??? Non ho capito, commissa'.... :/
 
 
E' un richiamo (credo), però il buon commissario ha preso  il ng per fb 
dove  tagghi le persone, quelle vedono e arrivano
O no? :-)

 O no? :-)
 
:D verooooo!
Cmq credo che l'unico sia Luca, ma col cavolo che legge le nostre 
implorazioni da quaggiu' :((( 
 
 

 ha scritto nel messaggio 
news:pl4e1i$mve$1...@solani.org...

io prverei sul gruppo FB 'vita di un montatore video'... 
 
 

 video'...
 
Ci sono iscritto ma mi sembrano più orientati al "fare".
Però è anche vero che ci sono bei cervelli, se non ne esco
provo lì...


Uhmm... Nell'audio, gli mp3 possono contenere un'immagine jpg,
 come la copertina del disco...
 
 
-- 
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

 un'immagine jpg, come la copertina del disco...
 
Sì, coi video è altrettanto interessante. Se apri una clip
video con notepad++ vedi che ci sono anche stringhe ASCII
intercalate o solitamente alla fine come commenti interni.
Il problema è che questo non esclude che un formato video
possa prevedere il controllo della dimensione.
 
Esempio, a inizio file lascio uno spazio di alcuni bytes
in cui memorizzare la dimensione, faccio tutta la
codifica, magari inserendo anche la stringa JPG della
copertina, commenti utente, stringa che contiene le info
sul software di codifica e appena finito di scrivere
tutto, torno all'inizio scrivendo la dimensione del file
appena generato. Alcuni protocolli fanno questo, anche per
una verifica incrociata dell'integrità del file. Se accade
anche nel video la strada che sto valutando è
impraticabile e mi resta solo l'hash dei file per
risolvere le ambiguità.


 aggiungendo un differente numero di bytes a caso dopo la fine.
 
Puoi farlo tranquillamente con praticamente qualsiasi formato di file 
video. L'unico formato che io sappia basarsi sulla dimensione del file 
per recuperare l'indice sono gli archivi ZIP.
Mettici pero' dei byte 0, in modo tale da non incasinare il decoder.
 
Se vuoi farlo "pulito" e se sono file MTS/ACVHD (MPEG-2 Tranport Stream), 
puoi aggiungere alla fine un tot di pacchetti NULLI (188 byte per 
pacchetto; se e' AVCHD devi aggiungerci anche 4 byte di intestazione con 
il timestamp del pacchetto, prendi i primi 4 byte [unsigned 32 bit, Big 
Endian] e ci aggiungi 2256, il pacchetto e' di 192 byte totali):
 
Byte 0:     47    (marker MPEG-2 TS)
Byte 1-2:   1f ff (PID pacchetto nullo)
Byte 3:     10    (no crypt, no adaptation field, sequence number 0)
Byte 4-187: ff    (ma puoi metterci quello che vuoi)
 
 
Secondo me, pero', ci sono due modi piu' rapidi per crearsi un numero 
univoco per ogni file (sempre che sia davvero necessario...):
 
1. prendere oltre la dimensione anche la data di ultima modifica (di
   sicuro due file di dimensioni uguali sono stati creati con una data 
   diversa, e comunque la data di ultima modifica la puoi cambiare,
   "touch" per sistemi Unix/Linux, vari programmi tra cui "Attribute
   Changer" per Windows);
2. per ogni file aggiungerci un file di testo (stesso nome, con una
   estensione aggiunta chevuoi tu) nel quale ci inserisci un progressivo
   o un identificativo univico. Se tanto devi modificare il file per
   avere una dimensione "univoca", tanto vale aggiungerne uno.
 
Ciao!
  Luca

 0, in modo tale da non incasinare il decoder.
 
Grazie mille anche di qui in poi, ovviamente ho salvato il
post così lo ripescherò all'occorrenza. La soluzione di
associare un file dati a ciascun file "payload" ha i suoi
vantaggi ma chiaramente la userò se non ne esco. Al
momento quello che suggerisci è praticamente implementato
con sqlite ma anche qui il file db non è sopravvissuto
alla rinomina batch :D E' facile modificare il software ma
è anche un avvertimento di cosa succede quando ci sono
dipendenze esterne.
 
Grazie ancora, sei stato ultra-utile
 
Apx


 questi criteri avevano hash diverso,
 
Se vuoi essere sicuro al 100%, devi fare l'hash di tutto il file e deve 
essere almeno 256 bit (o anche due da 128 bit, e' praticamente 
impossibile trovare una collisione con dimensione/MD4/MD5: le 
combinazioni sono piu' di tutti gli atomi dell'universo!!!!): con il 
controllo di data/dimensione/inode che ti evita di fare ogni volta 
l'hash, l'operazione e' relativamente veloce.
 
Se ti interessa, ti mando il link con il programma.
 
Ciao!
  Luca
 

 Se ti interessa, ti mando il link con il programma.
 
Grazie mille, e anche per il resto della risposta,
potrebbe essere sicuramente una cosa molto utile.
 
 
-- 
"Dovrebbe smettere di praticare auto erotismo."
"Diamine, dottore, perché mai?"
"Perché le sto parlando."
 

 con installato Linux e filesystem BTRFS: 
 
ma tutto 'sto casino non si puň evitare con ZFS? o meglio ancora: non
sono funzioni intrinseche in questo tipo di sistemi? perché fai ancora
il checksum a mano? o ho capito male io?
 
 
-- 
E quindi uscimmo a riveder le stelle.
Erano cinque: mi toccai le palle. [Paolo Pellegrino]

 il checksum a mano? o ho capito male io?
 
Ma infatti: se usi ZFS (meglio ancora BTRFS) il "clone" incrementale del 
filesystem e' intrinseco nel sistema.
Il problema e' quando non hai a disposizione un file system con gli 
snapshot o hai gia' una copia dei file nel sistema di destinazione che e' 
distante parecchi chilometri e/o non facilmente accessibile: in questo 
caso bisogna farlo "casalingo", con checksum e controlli vari sulla data 
di modifica e inode.
 
Nel frattempo, sto sistemando lo script: appena e' pronto mando il link!
 
Ciao!
  Luca