Newsgroup: it.media.video.produzione
Titolo: Migliorare acquisizione miniDV

Ciao a tutti,
stiamo parlando di qualità di acquisizione da una telecamera miniDV via 
firewire in formato nativo DV. (solo acquisizione)
Secondo voi la qualità può dipendere dal software utilizzato o dipende solo 
dalla potenza dell'Hardware?
Se il software  influisce, sapete consigliarmene uno ?
Ciao e grazie.


Da nessuno delle due, al massimo dal codec che usa il software, ma non 
dovresti vedere grosse differenze ad occhio nudo.
Propendo per l'ipotesi "riprese brutte".
L' "acquisizione" via firewire NON E' UN ACQUISIZIONE, ma una semplice 
copia di dati digitali.
P.S: E' la milionesima volta che viene detta 'sta cosa sul newsgroup.
-- 
rIO.sK


Puoi provare ad acquisire con un cavo fireware di qualita' professionale 
(anche senza andare sull' esoterico). Cerca nel catalogo Sony, Kwanon o 
Panasonic.
-- 
Prove it... just the facts... the confidential
This case, this case, this case that i...
i've been workin' on so long...
/* JOE CHIP Alpha Ralpha Boulevard */

 (anche senza andare sull' esoterico). Cerca nel catalogo Sony, Kwanon o 
e cosa si deve aspettare? sono sempre file, è una copia bit-a-bit, o 
viene copiato o non viene copiato..il cavo c'entra poco

 P.S: E' la milionesima volta che viene detta 'sta cosa sul newsgroup.
Perchè il video acquisito con Premiere mi sembra migliore rispetto a quello 
acquisito con studio 11 ?
E' un impressione o dipende dal diverso modo di visualizzare il filmato ?
Il file avi generato dalle due applicazioni, in teoria dovrebbe essere 
uguale? 

 
Ottimo consiglio... utile come un frigorifero a legna....
-- 
rIO.sK


Dubito che il codec di pinnacle (e' proprietario, anche se 
compatibilissimo con Microsoft DV) sia cosi' diverso da quello di 
premiere, tanto da farti notare una differenza nella qualita'.
Si, il file generato dalle due applicazioni e' teoricamente uguale, a 
parte il codec appunto. Ma le differenze di codifica dovrebbero essere 
talmente minime da non farti avvertire alcuna differenza.
-- 
rIO.sK

 ha scritto nel messaggio 
news:MPG.2123277...@news.readfreenews.net...

Però se tieni la videocamera più alta rispetto al pc, dovresti migliorare la 
velocità, sperando che non si verifichino intasamenti. Attenzione anche alle 
curve del filo e alle pieghe, che potrebbero frenare i dati. 

 curve del filo e alle pieghe, che potrebbero frenare i dati.
Quando si fa una battuta si mettono gli smileys ;-)
Ciao,
  -- Roberto

, joechip-be-careful@you-spammers-

Potrebbe - ripeto: potrebbe - aiutare se si hanno dei frame persi a
causa di un cattivo contatto. Non cambia la qualita` del risultato ma
potrebbe diminuire la probabilita` di dover ri-acquisire (o scartare
degli spezzoni inutilizzabili). Peccato che di solito il problema e`
(anche) nel connettore lato telecamera e quindi cambiare il cavo serve
a poco :-(
Un cavo mal fatto puo` anche dare problemi di connessione (difficile
collegare la videocamera oppure una telecamera il cui device va e
viene).
A parte questi due punti, una connessione FireWire trasporta
l'informazione bit a bit, quindi HW o SW diversi - se riescono a stare
dietro al flusso dei dati - daranno lo stesso identico risultato.
Ciao,
  -- Roberto


Identico. Prova a visionare l'AVI con un player esterno e vedrai.
Ovviamente presumo che tu abbia acquisito in AVI-DV (occhio: AVI-DV,
un file AVI e` un contenitore, potrebbe contenere - che so - uno
stream MPEG) con entrambi i SW e che non tu non abbia *mai* convertito
il filmato ad un formato diverso...
Ciao,
  -- Roberto

 --
A joe chip gli è partita la virgola mobile... e con questa vi saluto
affettuosamente e (con Vaio, HD est e due progetti caricati) me ne vo in
vacanza il luoghi remoti e lontani dal web...
Buone vacanze
Giuva'
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

a poco :-(
Chiedo scusa per l'emo mancante nel mio precedente post;
comunque il firewire è un trasferimento in protocollo di rete, che ha la 
priorità assoluta sui dati, il che significa che non si possono perdere 
frame per un cattivo contatto, poichè mancherebbe prima di tutto la 
connessione di rete, pertanto non andrebbe a buon fine l'acquisizione.
In sostanza il collegamento viene stabilito al di sopra del trasferimento, 
quindi in caso di falso contatto, ci sarebbe un'insieme di tentativi di 
retry da parte del gestore di rete, con quindi l'invio di una stringa di 
errore al programma di acquisizione, che intrepreterà a modo suo l'errore. 
Pertanto non esiste la probabilità che una cattiva acquisizione derivi da un 
falso o cattivo contatto, ma solamente da problemi legati alla cassetta o 
alla lentezza della macchina che acquisisce.
Se poi il programma di acquisizione decide di considerare comunque valido un 
pacchetto frammentato, sono solamente questioni software. 

 alla lentezza della macchina che acquisisce.
Ovviamente quoto

 Giuva'
A Giuva', prima insinui che mi e' partito il coprocessore matematico, 
poi confessi che tu invece sei partito del tutto, che posso di', buon 
viaggio, no?


 rileggere il nastro di nuovo.
Ma la firewire è una connessione di rete, non un trasferimento dati, 
pertanto il protocollo è quello gestito dal server di rete del sistema, lo 
stesso che viene usato per le schede di rete.
Non puoi perdere fotogrammi, perchè mancherebbe prima di tutto la 
consistenza del protocollo di rete. Infatti, se tu colleghi due macchine in 
rete e trasferisci dati, anche se fai dei falsi contatti, non perderai mai 
dati, ma eventualmente connessione di rete. I pacchetti non arriveranno 
coerenti e quindi il file non sarà trasferito nella sua integrità. Fa parte 
della dinamica di sicurezza delle reti, altrimenti sarebbe un disastro...
Da qualche parte devo avere il diagramma di flusso del protocollo di rete 
100mbits Ethernet; roba vecchiotta...


E chi ha mai parlato di Tci-ip? Come tutti i protocolli di trasferimento, al 
di la del fatto che siano sincroni, asincroni o isocroni, esiste anche un 
protocollo di trasmissione con relativi layer, che permette all'utente di 
usarla in diversi modi e impedisce che durante la trasmissione accadano 
problemi che possono pregiudicare l'integrità dei dati, poichè la 
"connessione di rete" è un layer di basso livello indispensabile. A 
dimostrazione di ciò vi è il fatto che se scolleghi il cavo della firewire, 
il pc ti avvisa che manca la connessione.
Se fosse un'interfaccia "stupida", come tu supponi, tipo una RS232/422, 
allora questo "watch-dog" non vi sarebbe e l'interfaccia continuerebbe a 
ricevere/trasmettere fino a quando il software non si accorge che la 
connessione è fallita, con conseguente acquisizione di dati potenzialmente 
falsi.
Questo tipo di comportamento è stato eliminato da diversi anni proprio con i 
protolli a layer (i primi attorno agli anni 88-90), quindi con interfacce 
"intelligenti", che stabiliscono prima la connessione, poi mandano i 
pacchetti; ad ogni invio viene testata la presenza della connessione, poi 
vengono inviati i pacchetti. Non ti annoio con la strategia di correzione 
dell'errore...
Inoltre, ogni volta che viene interrotta la connessione, viene rinegoziata 
la connessione, pertanto è impossibile mandare dati fasulli con falsi 
contatti, poichè a fronte della mancanza della connessione, viene 
rinegoziato il trasferimento e stabilita la connessione, magari anche con 
una velocità più bassa, poichè una connessione potrebbe anche essere 
influenzata da fonti elettromagnetiche che possono essere eluse cambiando la 
portante.
Ma probabilmente mi sbaglio:
http://www.1394ta.org/Technology/1394DesignTips.pdf
http://www.1394ta.org/Technology/About/1394a_and_b_whitepaperrevised.PDF
da qui poi hai i link per le specifiche tecniche/funzionali. 

 -- 
Veramente di mestiere mi sono occupato a lungo di connessioni e protocolli 
di rete, dalle vecchie 232/422, current loops, sincroni/asincroni, 
differenziali, DSK, SCSI, Ethernet, etc.
Ho letto bene il tuo link, e infatti è spiegato ciò che ti ho detto, e ti 
riporto Wiki:
"La connessione FireWire viene comunemente usata per collegare dispositivi 
di archiviazione o dispositivi di acquisizione video. Viene utilizzato anche 
in apparecchiature di acquisizione audio e video professionali per via della 
ampiezza di banda della connessione, della sua predisposizione a trattare 
flussi multimediali, della capacità di sopportare potenze maggiori e della 
possibilità di stabilire una connessione tra dispositivi senza il tramite di 
un computer."
Stabilire una connessione, e non semplicemente, trasferire i dati. Stabilire 
significa comunque "verificare la connessione" + "negoziare il 
protocollo/servizio" + "trasferire i dati" + "verificarne la veridicità con 
il protocollo di controllo".
"L'interfaccia FireWire è tecnicamente superiore all'interfaccia USB, ma 
questa è molto più diffusa per via dei brevetti. L'Apple e altre ditte 
richiedono il pagamento di brevetti per ogni implementazione della FireWire 
(normalmente 0,25 dollari per l'utente finale). Sebbene siano cifre ridotte, 
molti produttori realizzano prodotti a bassissimo margine di guadagno e 
quindi preferiscono utilizzare la tecnologia USB che, essendo esente dal 
pagamento di brevetti, consente loro di ottenere prodotti più economici.
La FireWire supporta fino a 63 periferiche organizzate in una rete non 
ciclica"
organizzate, appunto, in una rete, pertanto con un protocollo di rete. Non 
si scappa, il protocollo a livello software è prioritario, quindi quando 
viene a mancare la connessione, non si trasferisce, punto e basta. E' una 
regola fondamentale per la sicurezza dei dati. Se fosse solamente 
un'interfaccia, ma non un protocollo, allora si potrebbe perdere i dati.
Ma da diversi anni in informatica ciò non avviene proprio per via della 
strategia dei protocolli; se così fosse, un cavo di rete difettoso potrebbe 
"non garantire" la veridicità dei dati, con una situazione a dir poco 
impossibile per un sistema.
Non entro nel merito del protocollo di verifica degli errori, che anch'esso 
entra a far parte delle strategie messe a punto per evitare di acquisire 
fotogrammi incompleti.
Continuo con Wiki:
"Permette una comunicazione "peer-to-peer" tra i dispositivi. Quindi i vari 
dispositivi possono comunicare tra loro senza dover utilizzare il computer 
come arbitro. Per esempio una videocamera digitale potrebbe riversare il 
filmato video su un hard disk esterno senza l'intervento del computer. 
Supporta il collegamento a caldo e la presenza di più Host tramite una 
gestione degli IP software. Quindi una connessione FireWire può essere 
utilizzate per creare una rete locale tra due computer quattro volte più 
veloce di una normale rete Ethernet a 100 Mbit/s. Il cavo FireWire supporta 
fino a 45 Watt e è quindi in grado di alimentare la maggior parte dei 
dispositivi portatili."
Se hai ulteriori dubbi, cercerò di chiarirteli, ma fidati, una delle buone 
cose della Firewire è proprio la robustezza del protocollo.

 dati dagli apparecchi digitali come videocamere e macchine fotografiche.
Aggiungo che la modalita' isocrona non prevede alcuna correzione degli
errori e nessuna ri-trasmissione (c'e' solo il CRC che ti consente di
capire se il pacchetto e' stato trasmesso correttamente o meno).
Qui vengono descritte le 2 modalita' in modo semplice e conciso:
 
http://articles.techrepublic.com.com/5100-28-1061612.html
"Isochronous transfers are always broadcast in a one-to-one or one-to-many
fashion. No error correction or retransmission is available for
isochronous transfers."
Altro link interessante, con una descrizione schematica dei pacchetti:
 
http://www.aquezada.com/staff/julian/school/ieee1394/
Avete quindi ragione parzialmente entrambi: se da un lato e' vero che al
software applicativo viene segnalata l'anomalia di link mancante o
pacchetto non valido, e' anche vero che gli stessi dati non verranno
ritrasmessi e non c'e' correzione di errore, quindi i dati del pacchetto
sono persi. Sara' poi il programma che decidera' se scartare l'intero
fotogramma o comunque salvare la parte ricevuta (solitamente si scarta
tutto il fotogramma).
Ciao,
  Luca

 -- 
Ma non è il caso delle videocamere, perchè quando le colleghi ad un pc, 
compaiono tra le risorse del sistema, quindi si stabilisce una connessione 
di rete, e sono anche sonsultabili e gestibili dal pannello di proprietà. 
Diversamente nella modalità che indichi tu, non si vedrebbe alcuna 
periferica, ma il tutto si risolverebbe in un semplice trasferimento, tipo 
RS232, per intenderci.
Ovviamente ci vorrebbe un software che gestisca questo protocollo, poichè 
qualsiasi attuale software, se ne frega altamente della periferica, ma fa 
una chiamata al gestore di rete per sapere quali periferiche ha 
sincronizzato.
Non posso escludere che si possa usare anche il protocollo isocrono, ma non 
è il caso di sistemi operativi come Windows o Apple. Secondo me tale sistema 
viene usato solamente nel caso in cui le periferiche siano "stupide", quindi 
tra la videocamera e un disco di backup, per esempio, senza un pc in mezzo. 
In tal caso un gestore di rete sarebbe esagerato, allora si potrebbe 
chiedere alla periferica i dati senza stabilire una connessione di rete; una 
modalità Raw, insomma.

 o Apple. 
Per il trasferimento di materiale DV o HDV attraverso la firewire viene
sempre usata la modalita' isocrona, indipendentemente dal sistema
operativo. Appena colleghi la videocamera, questa viene vista come un
nodo, e puoi chiedergli informazioni o mandare comandi in modalita'
asincrona (tipo AV/C, Audio Video Control, per il controllo del trasporto
- play, stop, rewind, ecc.), in cui ogni pacchetto ha nodo sorgente e nodo
destinazione (quindi una comunicazione peer-to-peer). Quando, invece, la
videocamera sta inviando uno stream, invia pacchetti isocroni che
contengono solamente il "canale": tutti i nodi in ascolto su quel dato
canale riceveranno i pacchetti isocroni, come se fosse una sorta di
broadcast. Se ci sono, ad esempio, disturbi su una tratta e non su
un'altra, un nodo potrebbe ricevere un pacchetto non valido mentre l'altro
nodo lo riceve correttamente. Ovviamente al software viene notificato
l'arrivo di un pacchetto non valido.
La modalita' asincrona e quella isocrona possono coesistere: posso cioe'
mandare un comano AV/C mentre sto ricevendo il flusso dei dati video,
oppure posso collegare la videocamera in cascata ad un hard-disk esterno e
sulla porta del PC ricevero' sia i pacchetti isocroni dello stream DV/HDV
sia i pacchetti asincroni di una eventuale lettura/scrittura
da/sull'hard-disk.
Ciao,
  Luca

 l'arrivo di un pacchetto non valido.
Infatti, pertanto la possibilità di ricevere dei fotogrammi errati a causa 
della rete è solamente una scelta del software; credo che nessuno sia così 
suicida da accettare un bad-packet, quindi è impossibile perdere qualità a 
causa della connessione o di un cattivo cavo. E poichè un fotogramma 
danneggiato sulla cassetta è considerato un pacchetto valido, allora viene 
da se che i fotogrammi rovinati sono solamente dovuti a problemi della 
cassetta, della periferica o della lentezza del pc.
Però c'è anche da dire che ci sono software che leggono i DVD danneggiati, 
ignorando i bad-packet alert, quindi si potrebbe anche scrivere un driver 
per l'acquisizione che ignora i bad-packet, così da poter acquisire in 
blind-mode anche con un cavo difettoso.
Interessante, ma relativamente utile... 

 alla lentezza della macchina che acquisisce.
La mia esperienza dice altrimenti :-(
Ciao,
  -- Roberto

 di rete, e sono anche sonsultabili e gestibili dal pannello di proprietà.
Questo solo per il traffico sincrono. Il traffico isocrono non
ha bisogno di alcun handshake. In teoria il link dovrebbe essere
established, ma niente vieta ad un device che usa la parte
isocrona del protocollo di iniettare dati. Se questi dati sono
buoni, bene. Altrimenti i dati vengono persi e non esiste alcun
metodo per recuperarli se non la ritrasmissione.
Tutte le videocamere DV usano traffico isocrono.
Io vedo due punti oscuri:
- e` possibile che un device il cui link e` established (uso la
terminologia del 1992) e utilizza la banda isocrona del link in
scrittura rimanga con link established anche se il traffico
isocrono ha errori?
- e` possibile che un device il cui link va down continui
imperterrito a trasferire dati usando la banda isocrona?
Per il secondo punto, la risposta dovrebbe essere no (link down,
il controllore dovrebbe rifiutarsi di continuare il
trasferimento).
Per il primo punto, dovrei rileggere lo standard...
In ogni caso, per il traffico isocrono non esiste negotiation
e non esiste retry.
Ciao,
  -- Roberto