Newsgroup: it.media.video.produzione
Titolo: FireWire o USB: stessa qualità?

Gentili amici,
credo che oggi mi abbiano raccontato una balla!
Ho comprato una Sony HC-19, con porta IEEE + USB 2.0.
Il cavetto c'è solo USB, quindi Premiere non me lo vede.
Se scarico la cassetta DV con la USB e poi importo il file in Premiere,
ottengo la stessa qualità di che se scarico con la IEEE direttamente da
Premiere?
Grazie a quanti vorranno intervenire.
P.S.: Non è per i 5 Euro del cavo, ma non mi va di prendere la macchina e
cercare un negozio che lo venda. :)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


La firewire ha una velocità di 400MB, mentre la USB è di 480, però non e
consigliata per l'editing avendo una minore banda.....la qualità di
acquisizione è uguale, perchè è come se scaricassi files......
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ..la qualità di acquisizione è uguale, perchè è come se scaricassi files......
Al 99% l'USB serve per le foto e per filmati stile webcam.
--
Sign in allestimento...

 Al 99% l'USB serve per le foto e per filmati stile webcam.
Aggiungo solo che con l'USB2 ci sono piu' probabilita' di perdere frame,
quindi, in questa evenienza, la "qualita'" del filmato acquisito degrada
perche' si vedranno alcuni pezzi a scatti.
Ciao,
  Luca

 perche' si vedranno alcuni pezzi a scatti.
Potevi fare a meno di aggiungere questa porcata...se è acquisizione 
digitale e non analogica non è possibile che si perdano dei frame...è un 
passaggio digitale, è come copiare da hard disk => dvd-r ...non si 
possono perdere dei dati per strada...
Come ha detto giustamente Salvo nel 99 % dei casi usb serve solo per il 
trasferimento di foto e filmati webcam.
Saluti
RIC

 digitale e non analogica non è possibile che si perdano dei frame...
E possibile si, anche via Fireware, che garantisce meglio il flusso rispetto 
alla USB. Anche vero che è una bassa possibilità.
Hai mai acquisito digitale??? 
-- 
______________________________________________________
Luc (32,CO) - TV: Sony KV32FX65E - DVD: Sony DVP NS310
CAMERA: Panasonic NV DS38 - AMPLI: Kenwood KRF V5580DS
______________________________________________________

 digitale e non analogica non è possibile che si perdano dei frame...
E possibile si, anche via Fireware, che garantisce meglio il flusso rispetto
alla USB. Anche vero che è una bassa possibilità.
Hai mai acquisito digitale???
ti do' "man forte" LUC : concordo !!!
a me il programma originale MATROX per acquisire in singoli file le varie
scene registrate sul nastro mi produce il salto di un frame all'interno del
primo secondo di ogni scena ( dopo i primi 15 frame circa )
ciò non accade se uso scenalyzer live
naturalmente intendo usando la firewire !!
con l'informatica non ci sono certezze che tengano : ormai i computer sono
"sistemi" tanto complicati in cui entrano in gioco talmente tanti fattori
per le più piccole attività che appena i programmatori sbagliano ( !! )
saltano fuori comportamenti strani a iosa ...

 possono perdere dei dati per strada...
Questa e' una porcata, non quella che ha detto Luca, quello che dici tu puo' 
essere vero nel caso di periferiche che accedono a velocita' variabile ai 
dati.
Il nastro DV, invece viaggia ad una velocita' costante di 18.812 mm/sec 
producendo un flusso continuo di 25 Mbit/sec.
Dato che il nastro non puo' rallentare, fermarsi e, men che meno, tornare 
indietro se non acchiappi tutti e 25 i Mbit/sec nel momento in cui escono 
dalla FW ti perdi i pezzi...
Certo col FW e' un'eventualita' abbastanza remota, ma in USB (visto che non 
e' un full duplex) c'e' qualche probabilita' in piu'... 


Certo che si possono perdere frames. L'acquisizione video e` un processo
sincrono. Sorgente e destinazione devono andare a pari passo - la sorgente
e` il nastro, che non rallenta e non si ferma, la destinazione e` il PC,
che puo` rallentare/fermarsi a causa di carico sulla CP, sul disco o da
altre periferiche. Su FireWire e` ancora peggio, visto che il device (in
questo caso la telecamera) puo` creare un flusso dati senza l'intervento
diretto della CPU (traffico isocrono).
La` dove non si possono perdere dati e` sui trasferimenti asincroni, per
esempio il trasferimento di foto o di files. Se la CPU non sta al passo,
non richiede dati e la telecamera non li da`.
Ciao,
-- 
        Roberto Divia`              Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110      labour-saving devices the world has ever seen
Route de Meyrin 385               ---------------------------------------------
Case Postale                                Phone:  
+41-22-767-4994
CH-1211 Geneve 23 CERN                      Fax:    
+41-22-767-9585
Switzerland                                 E-Mail: 
Robert...@cern.ch

 e' un full duplex) c'e' qualche probabilita' in piu'... 
25Mbit/sec sono poco piu' di 3 Mega al secondo....com'è possibile che ci 
siano dei problemi con un flusso dati del genere?!?!

 altre periferiche. 
Qual è l'hard disk che potrebbe non reggere 3 mega al secondo?! 
Se si pianta il sistema o ci sono gravi problemi o rallentamenti 
pazzeschi allora ok, ma questi mi sembrano casi un po' limite ed 
anomali..
Anche il trasferimento hard disk -> dvd-r puo' avere dei problemi se 
tiro dei calci al case... :) (anche se è un trasferimento asincrono..)
Non mi spiego come possa funzionare lo stesso il video acquisito "male". 
IMHO non dovrebbe proprio esser letto, almeno si sa subito che c'è un 
problema di acquisizione e si eviterebbero problemi ri-acquisendo il 
tutto.
Saluti
RIC

 ci siano dei problemi con un flusso dati del genere?!?!
Perche' tu stai trattando il trasferimento da firewire come se fosse un
qualsiasi trasferimento dati in cui chi trasmette attende che il ricevente
sia libero e risponda con un magnifico RTS di 232iana memoria e fino a che
quel messaggio non arriva i dati stanno belli in coda ad attendere di essere
trasmessi, oltretutto (e non e' cosi' strano) in caso di errore di
trasmissione il ricevente richiede il re-invio del pacchetto di dati.
Questo perche' quando leggi da un supporto tipo hard disk puoi riempire un
buffer ed inviarlo al ricevente adeguandoti alla sua velocita'.
Quando scarichi un DV, invece, non puoi mettere in pausa il nastro e il
buffer deve essere svuotato alla stessa velocita' con cui si riempie. Dato
che "a volte" il sistema sta' facendo anche altre cose, puo' capitare con
macchine non particolarmente performanti che i dati in arrivo non vengano
bufferizzati tutti o che ci sia un errore di trasmissione, se il ricevente
riesce a correggere i dati tramite il CRC o ad inviare una richiesta di
ri-trasmissione entro il successivo caricamento del buffer di trasmissione
bene, ma in caso contrario i dati sono andati persi e la cosa finisce li'...
Per quanto riguarda l'USB, e' vero che in teoria la velocita' e' superiore,
ma il firewire usa un canale di trasmissione separato da quello di ricezione
(infatti il FW alimentato consta di 6 fili, contro i 4 dell'USB), in questo
modo e' possibile inviare i CRC e gli ACK mentre si ricevono i dati senza
dover aspettare le latenze per il cambio di direzione del canale di
comunicazione; l'interfaccia FW, inoltre, ha una "intelligenza" un po' piu'
"sviluppata" (bleah quante virgolette) di quella dell'USB, il che gli
permette di essere piu' autonoma rispetto a quest'ultima e di gravare meno
sul processore.
E' ovvio che una macchina in buona salute non abbia problemi a trasferire un
flusso DV su FW o USB2, tuttavia qualche task di troppo in background,
applicazioni che occupano molto tempo processore possono influire sul
processo di acquisizione, e quando hai perso un pezzo non puoi tornare
indietro e rileggerlo, l'hai perso e basta!
Non sono pochi quelli anche su questo NG che hanno problemi di acquisizione
anche con macchine potenti; in parte dipende anche dal SW che magari non
riesce ad allocare correttamente i tempi macchina o lo risorse necessarie, o
semplicemente non utilizza un buffer adeguato.
Tanto per chiudere, secondo te un pentium non era sufficiente per garantire
un flusso di 300 (trecento) KByte ("chilobait", 2,4 Mbit/sec) al secondo?
Direi di si, eppure i buffer under-run non si contavano all'epoca
dell'uscita dei masterizzatori 2x (SCSI peraltro).
Non era certo un problema di Hard Disk, ne' di interfaccia, ne' di CPU,
erano problemi di SW, di configurazioni etc. etc.

 ricordi?
Anch'io masterizzavo con un 486, ma avevo sia masterizzatore che hard disk 
SCSI, il nostro conoscente della nota ditta (l'ex capo di littlefly), 
invece, con macchine pentium e dischi IDE riusciva a buttare il 50% dei 
dischi...
In effetti questa lotta USB vs FireWire mi ricorda un po' la lotta IDE vs 
SCSI di quell'epoca. Oh quanti CD in meno si sarebbero potuti buttare! 

acquisizione è uguale, perchè è come se scaricassi files......
alla fire-wire o alla usb arrivano gli stessi dati che vengono copiati 
paro-paro dalla cassetta. Se il nostro pc facesse "solamente" lettura dalla 
porta.... allora non si perderebbe neanche un frame persino col peggiore dei 
programmatori. Ma il punto è che il PC deve fare altro.... nel frattempo... 
e i dati che arrivano alla porta del PC e non vengono letti vengono scartati 
perché occorrerebbe troppa RAM per mantenerli in un buffer e successivamente 
troppe risorse per ri-sincronizzare il tutto...
Se tutto il sistema non è configurato a dovere per leggere da DV capita che 
il sw non legga un fotogramma e aspetti l'incipit del successivo per 
proseguire. Quindi inserisce i necessari <NoFrame> Nello stream DV.
Ad esempio ci sono schede e sistemi che hanno un'inizializzazione che dura 
troppo oltre il buffer della DV e tendono a saltare fotogrammi all'inizio. 
per cui fin che può il pc accumula, poi scarta, poi comincia a catturare in 
sincrono (col solito Buffer+Process Delay Time) fino alla fine.
Ad Esempio catturavo DV senza perdere un solo secondo con Celeron 500 + 128 
Mb Ram e HD 8 Gb DMA attivato.
Quindi a rigore un PIV 1gb Ram e scheda dedicata non dovrebbe perdere 
neanche un fotogramma eppure a volte...
Resta però vero il paradigma che un fotogramma trasferito da nastro a dv e 
viceversa passando per FireWire o USB2 è sempre ugule (finché usiamo il DV 
Nativo nel nostro NLE)
Scusate se sono stato prolisso e spero di essere esaustivo
Riccardo Deserti
-----------------
Broadcast Editor
PC Programmer 

Comunque con il portatile (pentium IV 3,0 Ghz) ho acquisito tranquillamente
su un hard disk esterno collegato con la usb2 (ovviamente sulla firewire
c'era la videocamera). Ho un'altro hard disk esterno firewire e non ho
riscontrato differenze di comportamento (perdita di fotogrammi in cattura,
malfunzionamenti del programma di editing...) tra i due hd. Anche lavorando
sullo stesso progetto salvato negli hd esterni con il portatile e il
desktop.

 dell'uscita dei masterizzatori 2x (SCSI peraltro).
Veramente io non avevo alcun problema con un master scsi 4x su un 
Pentium 200mmx....
Saluti
RIc

 Mi spiego. Ha ragione PremierePRO (Intendo l'utente del ng)
[CUT]
Grazie mille per la spiegazione esaustiva! E' tra le migliori che ho 
ascoltato...
Sono uno degli sfortunati che perde frames per acquisizione DV ed ho 
proposto più volte i mei problemi qui con qualche cenno di soluzione ancora 
da attuare. Speriamo siano quelle buone, visto che questo problema sta 
diventando per me un incubo e ne ho provate tante!
Un paio di thread in cui spiego il problema sono qui:
http://makeashorterlink.com/?W59912ABB
http://makeashorterlink.com/?T2A932ABB
Se ti va di dirmi qualcosa in merito ne sarei più che felice!
Grazie comunque
Ciao
Seth Brundle
-- 
Nothing.
The same thing.
Not a fucking trace.
No bodies, blood, anything. 


Drop del fotogramma --> Sì
infatto Premiere ti avvisa.... e lo fa in maniera semplice, decomprime i 
fotogrammi e se non c'è nulla o poco da decomprimere ecco che "Dropped 
Frame"
Errore nella trasmissione dei dati --> Forse
Nel senso che se i dati vengono corrotti il formato DV che sappia io (anche 
se mi devo rileggere l'Smpte 314) non ha adeguati CRC per la trasmissione da 
verificarne l'integrità. L'unico drop-detector che ho visto l'ho visto 
all'uni ed era sperimentale nel senso che ti diceva se in un fotogramma 
(indipendentemente dalla sua origine) c'era un drop. Dato che questi hanno 
delle caratteristiche. Riconosceva JPeg-like drop (quello del DV e dell'mpeg 
2 per intenderci) oppure "small-helix-scan drop" tipo cassette VHS lette 
male o anche "huge-helix-scan drop" nei nastri beta SP...
Ma ripeto, era sperimentale, lento come la messa cantata.... non pubblico e 
con un catch-rate del 80-90% quindi (per rispondere alla tua domanda) non 
sicuro.
Altro non so

 delivery of data and is targeted to a specific node with an explicit
in italiano
Asynchronous = asincrono
isochronous = sincrono (oppure più aulicamente isocrono, ma moooolto meno 
usato) 


Leggi meglio! Anch'io ho una fiesta 1.1 del 90 (CLX) e sul tachimetro c'è
scritto 220....


 Sono uno degli sfortunati che perde frames per acquisizione DV
Ancora?
Ma hai piu' provato Scenalyzer Live?
E a cambiare lettore/telecamera?
E a provare su un altro PC?
--
Sign in allestimento...

 scritto 220....
Ecco: vedi quanto me ne frega del fondoscala? Non me ne sono mai accorto!
Potevano anche rispariarsi l'inchiostro per scriverlo...
--
Sign in allestimento...

 su un hard disk esterno collegato con la usb2
questo sicuramente si,ma credo si parlasse di acquisizione direttamante via 
usb piuttosto che firewire.
io ho sempre acquisito su un hd usb2,ma sempre via firewire.


 trasmissione da verificarne l'integrità.
Non ho nulla da aggiungere... 

 dovrebbero essere questi problemi...
Una sola domanda: come si fa ad impostare il buffer via software?


 E a provare su un altro PC?
Solo nei prossimi giorni avrò tempo e disponibilità fisica di altri PC.
In realtà confido di più nella soluzione del 98lite (ma sono ancora in
attesa di avere copie di W98 e W95...) e nella soluzione Linux.
Appena farò le prove, a prescindere dal risultato, ne posterò gli esiti.
Nel frattempo continuo a raccogliere informazioni, non si sa mai... :)


 Una sola domanda: come si fa ad impostare il buffer via software?
Non si puo'! (nel 99% dei casi)
E' per questo che i software diversi hanno spesso prestazioni cosi' diverse. 

 transfers are preferable.
Stiamo dicendo la stessa cosa. Un trasferimento asincrono ha bisogno di un
handshake, acknowledge e annesso protocollo. Un trasferimento sincrono ha
i due lati del canale che vanno allo stesso passo, senza bisogno
di protocollo. Il traffico isocrono di FireWire e` di tipo sincrono.


 Non mi spiego come possa funzionare lo stesso il video acquisito "male".
Se il PC scrive, allora e` possibile usare parecchi trucchi per evitare
problemi (rendering, buffering eccetera). Inoltre un disco che legge
ha meno problemi di un disco che scrive...
P.S. Il trasferimento HD->DVD-R e` si asincrono, ma non dal punto di
vista della CPU. Il paragone non regge molto. Pero` e` sempre possibile
creare dei coasters, basta che la CPU non riesca a tenere il buffer del
DVD recorder pieno, cosa che oggi non si vede quasi mai ma *molto*
popolare qualche tempo fa.


 popolare qualche tempo fa.
Non credo conti molto la cpu nella scrittura del dvd-r. In questo 
momento sto scrivendo un dvd-r a 8x e l'uso cpu č del 3 %....
Saluti
RIC

 vecchio..
Il problema non e' tanto la RAM o la velocita' del disco (puo' essere
anche questa se il programma di acquisizione non predispone un buffer
sufficiente per lo scopo o il sistema operativo imposta una cache
limitata), ma e' invece la quantita' di buffer che ha la scheda FireWire.
Quelle di uso comune hanno 2 KiB: quando il buffer raggiunge una
determinata quota (es, la meta'), viene generato un'interrupt e quindi
attivata la procedura di trasferimento dati tramite DMA. Dovendo
trasferire 3,6 MB al secondo, viene generato un'interrupt circa ogni 300
micro secondi. In questi 300 micro secondi ci saranno quasi sicuramente
altri interrupt (almeno quello per l'attivazione DMA per la scrittura su
disco). Se questi interrupt richiedono piu' di 300 micro secondi, il
buffer della scheda si riempie e vengono persi dei pacchetti.
Quindi, se gia' con la Firewire c'e' la possibilita' (remota) di perdere
pacchetti e quindi perdere frame, con l'USB questa eventualita' si
incrementa parecchio, perche':
1) la comunicazione USB e' half-duplex, la comunicazione puo' avvenire in
   una direzione alla volta (o "parla" il PC o il dispositivo)
2) l'USB non e' basato su interrupt ma deve essere l'host (il PC) che
   "chiede" ad intervalli regolari ai vari dispositivi se hanno dati da
   inviare.
3) Oltre al buffer di memoria dell'applicativo e la cache del disco, oltre
   al buffer del controller USB, si dipende anche dal buffer del
   dispositivo: se il PC per qualsiasi motivo rallenta l'interrogazione
   USB e fa riempire il buffer del dispositivo, se ha una perdita di frame.
Con questi svantaggi, la comunicazione USB sincrona risulta quindi piu'
"fragile", per cui conviene di solito preferire una trasferimento DV da
videocamera tramite Firewire.
Ciao,
  Luca

 E' per questo che i software diversi hanno spesso prestazioni cosi' diverse.
Con GNU/Linux nel 99.9% dei casi si possono impostare due tipo di buffer:
il primo e' quello dell'applicativo, il secondo e' il controllo della
cache in scrittura del sistema operativo. Il secondo, solitamente, si
lascia cosi' come e', tranne in qualche caso (processore un po' lento con
attivata l'anteprima durante l'acquisizione), dove e' bene regolare i
parametri della cache in modo tale da trasferire su disco blocchi piu'
piccoli ma piu' frequentemente, altrimenti il canale DMA del controller
IDE, soprattutto con dischi non recentissimi, rischia di saturare la banda
PCI e quindi riempire o il buffer della scheda Firewire o quello
dell'applicativo (o quello del dispositivo se si trasferisce tramite USB).
Ciao,
  Luca

 controllo della cache in scrittura del sistema operativo. Il secondo,
Io intendevo il buffer utilizzato dall'applicazione di cattura per il 
controllo dell'integrita' di quanto appena trasmesso.
Mi sembra che Scenalyzer si allochi una trentina di mega nella memoria 
fisica per questa operazione... 

 anche questa se il programma di acquisizione non predispone un buffer
[CUT]
Tutto questo thread è favoloso. Da salvare per intero.
Grazie anche alle tue *chiare* delucidazioni, Luca!
