Newsgroup: it.media.video.produzione
Titolo: m2t a Beta Sp

Disponendo sia di Avid Xpress 5.0 con Mojo e Decklink SP quale workflow mi
consigliate per ottenere un passaggio su Beta sp di buona qualita'?
Ho provato a fare un avi non compresso e a farlo uscire dalla BM, ma
l'audio ha circa 2 frame di ritardo.
poi ho importato l'm2t direttamente in un progetto PP BM, ora sto
renderizzando la timeline.
L'alternatica sarebbe quella di collegare direttamente la cam, via
component al Beta.
Altre soluzioni?
Grazie. 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 component al Beta.
questa.
D.

 Grazie. 
_____________________________________________________________
L'audio che esce dalla scheda audio del Pc non è di 2, ma di 5/6
frames in ritardo.  E' normale.
L'audio in uscita dalla BMD (Black Magic Design) al Betacam SP
è perfettamente in sincrono e della massima qualità.

 è perfettamente in sincrono e della massima qualità.
Io ho scoltato l'audio in uscita dal beta, di un Avi non compresso
convertito dall'm2t.
Cosi' facendo il tutto era fuori sync di circa 2 frame.
Ciao.


 
Tu hai "scoltato" male.

 Cosi' facendo il tutto era fuori sync di circa 2 frame.
Ivan come riesci a sentire un fuori sincro di 2 frames, ossia meno di un 
dodicesimo di secondo? Impossibile. 

Derrick-Maigret ha scritto:


Ho un suono di referimento su un taglio, magari a livello di labiale
sembra tutto ok ma la percezione generale ne risente.
Almeno a me fa questo effetto, poi può essere che sono 3 frame, dubito 4.


 Tu hai "scoltato" male.
Guarda che un fuori sync lo riconosco piuttosto velocemente, magari non
erano 2 frame, sicuro non 5 ma era fuori sync.


 dodicesimo di secondo? Impossibile.
Una volta, per un mio errore, avevo 1 fotogramma video in piu' rispetto
all'audio (40ms): dopo averlo visto 2-3 volte, ho avuto la sensazione che
qualcosa non andava con il sincronismo audio-video (non avevo ancora
capito che era un fotogramma in piu'), soprattutto dopo averlo confrontato
con l'originale. Analizzandolo poi in timeline ho capito che era 1 solo
fotogramma.
Un'altra volta mi e' capitato di importare un .m2t "grezzo", separare gli
stream senza averli prima sincronizzarli e poi rimetterli assieme. Solo 2
fotogrammi di differenza, ma subito la senzazione era di un fuori sincro.
Con 1 fotogramma (40ms) solo un occhio-orecchio allenato (e magari dopo
aver visto il filmato qualche volta) puo' accorgersi di un fuori sincro.
Con 2 fotogrammi (80ms) il ritardo, soprattutto sul labbiale, e' molto
evidente, 3 fotogrammi (120ms) direi inaccettabile del tutto. Almeno
questo vale per me.....
Ciao,
  Luca

 dodicesimo di secondo? Impossibile.
si nota, invece... la sensazione è che 'qualcosa non torni'... poi ti 
concentri, ascolti e riascolti e lo becchi. Dammi delle clips con 3 frames 
fuori sync e te li becco tutti al primo colpo.
ciao
Gary 

 Almeno a me fa questo effetto, poi può essere che sono 3 frame, dubito 4.
hai ricevuto la mia mail?
ciao
gary 

 ha scritto nel messaggio 
news:482f4b7e$0$41655$4faf...@reader4.news.tin.it...

non ci credo! Perciò ho messo qui 
http://www.runnersloano.it/test.zip
 
(pronti per il download dopo le 7.55)
2 file brevissimi. Ditemi se sono fuori sincro, e nel caso di quanti ftg. 
Senza metterli in timeline, però! Solo ad occhio! 

 Senza metterli in timeline, perņ! Solo ad occhio!
ispettņ, il materiale compresso per il web č fuori sync di suo, che prove 
vyiu fare u quel modo.
Ti assicuro che, dopo aver montato videoclip in lipsync per tanto tempo, tre 
fotoframmi si vedono eccome e sono pure una misura significativa.
Se non sei conbinto, prova a farla tu la prova: prendi una clip con del 
parlato e quello che parla in primo piano, separa l'audio dal video e shifta 
l'audio di 3 ftg. Poi fuarda attentamente a monitor
Ma ste prove si fanno con materiale serio, non con le compressioni per il 
web
ciao
Gary 

PS = ho scritto senza occhiali, scusa l'ortografia 

 PS = ho scritto senza occhiali, scusa l'ortografia
e non hai scaricato il file, sennò vedevi che non era compresso. Mica sò 
scemo. 

 scemo.
ok, vado al lavoro. Quando torno scarico e provo
ciao
Gary 

 non ci credo! Perciò ho messo qui 
http://www.runnersloano.it/test.zip
"Page not found": li hai gia' tolti?
Ciao,
  Luca

 hai ricevuto la mia mail?
SI, si ricevuta.
Sono incasinatissimo per un lavoro extra che sto facendo,  ma stasera
penso di leggerla.


 "Page not found": li hai gia' tolti?
no scusate, errore di battitura, c'era uno spazio involontario, ora è a 
posto, ops!! 

 "Page not found": li hai gia' tolti?
scusa Luca una domanda al volo, già che sei qui.
Se esco dalla timeline di un editor in mpeg2 (esempio, ma vale per tutti i 
codec) ottengo un risultato, diciamo qualità 10.
Se invece esco in RGB (avi o altro), reimporto l'RGB ed esco in mpeg2, 
ottengo un risultato diciamo 8, comunque inferiore al primo. Provato di 
persona, sono sicuro al 100percento.
Perchè? Non ci arrivo... l'uscita RGB comporta una perdita? Boh! 

 risultato diciamo 8. [...] l'uscita RGB comporta una perdita?
Se parti da un video YUV (o meglio, YCbCr) c'e' di sicuro una perdita non
propriamente trascurabile nella doppia conversione (YCbCr->RGB e
RGB->YCbCr), dovuta ad errori di approssimazione degli 8 bit a
disposizione. L'ideale sarebbe uscire in component non-compresso e poi
re-importarlo: cosi' non dovresti avere alcuna perdita in qualita'.
Ciao,
  Luca

 Ditemi se sono fuori sincro, e nel caso di quanti ftg.
Allora, lo 002.avi e' palesemente fuori sincro, non saprei dire
esattamente quanti fotogrammi, ma sono almeno 4-5.
Lo 001.avi e' difficile da dirsi senza confrontarlo con l'originale. C'e'
pero' quella sensazione di sincronismo non perfettissimo, e, riguardandolo
un po' di volte, io direi 1 fotogramma fuori sincro.
Quanto c'ho azzeccato?
Ciao,
  Luca

 ha scritto nel messaggio 
news:pan.2008.05.18....@infinito.it...

te lo dico dopo che ha postato pure gary, sennņ dirą che lui lo sapeva da 
subito :DDD! 

 subito :DDD!
sono entrambi fuori sync, però su 001 è difficile dirlo, si nota solo una 
leggerissima incoerenza (1-2 ftg?), mentre su 002 la cosa è eclatante, 
sicuramente da 4 a 6 ftg
ciao
gary 

 ha scritto nel messaggio 
news:483063fd$0$40221$4faf...@reader5.news.tin.it...

ok, ecco la soluzione:
001: 2 ftg (come pensavo: impossibile accorgersene, anche sapendolo non da 
effetti visibili, è meno di un dodicesimo di secondo)
002: 7 ftg: visibile, fa  tre decimi e mezzo, è giusto che si veda.
Tornando al 3d, dubito che Ivan per quanto pignolo possa vedere ad occhio 
nudo uno shift di 2 frames, anzi, se lo vede vuol dire che sono molti di più 
imho...

 più imho...
1-2 lascia perplessi
3 si vede
E comunque nel mio post parlavo di 3 ftg, che nella mia esperienza sono il 
limite perchè il fuori sync sia chiaramente avvertito
ciao
gary 

 ha scritto nel messaggio 
news:pan.2008.05.18....@infinito.it...

Si, ma non da 10 ad 8 come voto...
La compressione dovrebbe essere simmetrica verso il basso, c'e' di sicuro 
qualcos'altro che non va', uno dei problemi piu' comuni e' il non 
adattamento dei livelli 0~255 a 16~253. 

 adattamento dei livelli 0~255 a 16~253.
sia...? Cmq è in effetti da 10 a 8, messi fianco a fianco la differenza si 
vede, soprattutto nel dettaglio.
In parole povere, è come se fosse presente un leggerissimo blur. Il colore 
non ne risemte, nessuna dominante apparente, nessun slittamento nella 
saturazione nè nei livelli, almeno non apprezzabile ad occhio. 

 imho...
Mah, secondo me dipende da quante volte lo vedi e quanto lungo e' il
pezzo. Il filmato in cui avevo notato qualcosa che non andava era 10
minuti e ho dovuto rivedermelo almeno una 20ina di volte per capire che
c'era un errore di sincronismo di 1 fotogramma (inizialmente avevo dato
colpa al mio PC che non ce la faceva a decodificare l'H264). Ovvio che ad
una prima visione non ci si fa caso (anche perche' interessa il
contenuto), ma se continui a rivederlo secondo me si nota, magari senza
percepirlo come fuori sincro, ma solo come un "fastidio".
Ciao,
  Luca

 percepirlo come fuori sincro, ma solo come un "fastidio".
Esattamente, come ho gia detto prima.
Poi altra cosa, su dove guardate i  filmati?
Su monito PC o su monitor esterno?
Su quest'ultimo a mio avviso la cosa e' molto piu' evidente.
Mi spiace aver cancellato il file, sarebbe stato utile contare i frame
eccessivi, in ogno caso secondo me erano  2 oppure 3 frame.
Lo so perche' all;'interno del montato ho dei riferimenti precisi, anche
questo mi ha aiutato molto.



No, i livelli influiscono principalmente su colori e contrasto...
Allora c'e' proprio qualcosa che non va', l'esportazione in RGB e' non 
compressa o con qualche codec particolare? 

 ha scritto nel 
messaggio news:48316ad7$0$41653$4faf...@reader4.news.tin.it...

macchè, è uncompressed RGB. Devo vederci chiaro. Ho sempre pensato che 
uscire in RGB, magari un avi con alpha 32bit, fosse il must per poter 
reimportare ed editare a perdita zero, esempio una comp con grafica e 
contributi di vario tipo, settata a pal. Ammetto di non aver mai 
approfondito l'argomento. 

 macchè, è uncompressed RGB.
Secondo me allora e' il passaggio 4:2:0 -> 4:4:4 e l'inverso che
introducono un po' di blur. Con l'esportazione diretta non dovresti avere
questi problemi e quindi la qualita' e' sensibilmente maggiore. Insomma,
se riesci a rimanere sempre nello stesso spazio colore del sorgente, e'
meglio....
Ciao,
  Luca

 ha scritto nel messaggio 
news:pan.2008.05.19....@infinito.it...

sinceramente lk'avevo pensato anch'io, anche se mi sembrava strano ma, non 
essendo il mio campo, non sono in grado di emettere sentenze. Se interessa 
posso mettere in rete 2 frames... 

 posso mettere in rete 2 frames...
Volentieri, magari anche 4: originale, MPEG-2 dall'originale, RGB non
compresso, risultato dopo compressione MPEG-2 dall'RGB.
Ciao!
  Luca

 ha scritto nel messaggio 
news:pan.2008.05.19...@infinito.it...

ok preparo dei tiff e li posto oggi quando torno ciao grazie 

 ok preparo dei tiff e li posto oggi quando torno ciao grazie
Per gli RGB va bene TIFF, ma per l'originale e l'MPEG-2 sarebbe meglio
averli in formativo nativo (anche un solo frame).