Tutto è possibile

Tag: codec Pagina 1 di 2

Blackmagic Raw 1.5 è il diavolo?

Nel 2001 naque il primo codec interpiattaforma e slegato dall’hardware, Cineform, nel 2005 fu potenziato per offrire la possibilità di importare fotografie raw di diversi brand e convertirle in un filmato raw compresso visually lossless con metadata attivi e modificabili realtime, successivamente l’encoder fu in grado di convertire tutti gli altri formati raw nati SUCCESSIVAMENTE in Cineformraw con diversi flavour di compressione e qualità supportando fino al 16k stereoscopico.

Oggi nel 2019 quasi ogni Brand ha la sua codifica Raw, a partire Arriraw, Redcode, SonyRaw, PanasonicRaw, l’anno scorso l’introduzione di ProresRaw che permette il recording in formato ProresRaw direttamente dalle camere che escono in raw da SDI sui recorder Atomos e pochi altri, fino al recente Braw di blackmagic.

A Ibc 2018 Blackmagic design lancia la palla nel campo del raw, introducendo il loro codec proprietario braw (blackmagic raw) nel mondo del broadcast e del cinema con una certa forza dirompente, e soprattutto disponibile subito, dallo stesso giorno con il firmware in beta 6.0 per la UrsaMiniPro, il nuovo aggiornamento di Davinci Resolve 15.1 per supportarlo e la promessa che a breve sarà disponibile anche per la nuova camera, pocket 4k e così è stato con il firmware 6.2, ma nel contempo toglieva la registrazione Dng.

La differenza tra il Dng e il Braw è evidente e chiara, il dng è uno standard fotografico, peraltro abbandonato dai suoi stessi creatori nel 2016, piegato alle necessità dei video, mentre il Braw è un moderno codec raw pensato per le immagini, dove convivono le diverse necessità di lavoro di un codec video di fascia alta e le richieste di fascia bassa.

La presentazione del Braw è stata abbastanza curiosa, dove GrantPetty ha scherzato sul fatto che con un codec così leggero non servono più le schede video esterne di decodifica, ironeggiando sul fatto che le producono loro per Apple.

Come sempre l’innovazione porta pro e contro, fautori e osteggiatori, fino al parossismo, ma essendo un pragmatico, preferisco fare una analisi meno tecnica (quella la lascio alla fase finale) e più pratica.

 

CONTRO

  • leggermente meno nitido del CDNG (meno aliasing sui dettagli)
  • a forti compressioni ha artefatti sui dettagli fini
  • meno compatibile nelle applicazioni rispetto al CDNG (ma licenza free per la sua implementazione).

PRO

  • il rapporto peso qualità è incredibile
  • la minor incidenza di falsi dettagli e aliasing permette una maggior fluidità di ripresa-riproduzione del movimento
  • il nuovo sistema di demosaicizzazione ottimizza e migliora la cattura della struttura dell’immagine riducendo artefatti come FPN
  • la parziale demosaicizzazione applicata in camera permette una maggior leggerezza di lettura sui dispositivi
  • richiesta di minor velocità di scrittura permette uso di storage meno costoso e poter registrare più a lungo con minor consumi
  • i vantaggi del raw senza il peso del raw in tutti i sensi
  • registrazione di segnale 12 bit log con metadata attivi
  • possibilità di incorporare LUT e altri elementi di preview non distruttiva
  • possibilità di trimming non distruttivo da Resolve per tagliare i file raw ed esportarli in raw senza ricompressione (non tutti i raw, non tutti gli NLE lo permettono).
  • possibilità di export dei singoli frame raw senza ricompressione per test, Dit working etc con passaggio di pochi dati.

Dopo qualche mese dalla sua presentazione esistono già diverse applicazioni professionali a supportarlo come Resolve immediatamente, Nuke, Scratch, Premiere e Mediaencoder tramite plugin esterno, la lista sta crescendo rapidamente grazie al fatto che chiunque può implementare la gestione del braw nel proprio software gratuitamente, al contrario di ogni altro codec raw nato sulle telecamere che richiede un pagamento di licenze anche per la semplice lettura perchè si devono usare gli sdk proprietari.

Per coloro che vogliono testare il codec, possono scaricare dei sample dalla pagina Blackmagic Raw

In occasione del IBC2019 Blackmagic Design rilascia il kit 1.5 del BlackMagic raw, il kit contiene SDK, player e test per dischi Braw e … plugin per Premiere, AfterEffects e Avid per leggere agilmente il codec al di fuori delle applicazioni Blackmagic! Così che oggi buona parte degli editor sono in grado di leggere nativamente il codec BlackMagic Raw.

Inoltre stupendo tutti i detrattori del codec, rilascia il nuovo Video Assist HDR a 2500 nits con la capacità di registrare in Braw da camere NON BMD, dalla Panasonic Eva e dalla Canon C300 MkII!

I falsi miti sul Raw in generale e non solo su questo Raw
Se è compresso non è raw!

l’affermazione denota ignoranza, in tanti punti, a partire dal fatto che nessuna camera registra il 16bit lineare che catturano i sensori, ma lo codificano e comprimono in vario modo dentro raw 14bit logaritmici (in fotografia) o raw 12bit logaritmici (nel cinema), sia per questioni pratiche di flusso dati, sia per gestione fisica della massa di dati che non compressi sarebbero ingestibili.

Dato che qualcuno potrebbe dubitare delle mie parole, delle parole di Blackmagic visto loro lo regalano (ricordiamo che tranne pochi esempi high end, tutti gli altri vi fanno pagare saltamente la registrazione non fortemente compressa, figuriamoci il raw) meglio mettere uno screengrab dal sito Red, i primi a dotare una camera di codec raw proprietario e spesso usate per shooting miliardari dove non ci sono limiti di mezzi, eppure per L’Uomo ragno ritenevano buona una compressione 5:1 visually lossless, e la non compressa che tutti auspicano per i loro lavori da caricare sui social non era adatta…

la cosa divertente è che quello che gli amatori ritengono un problema, ovvero la morbidezza delle immagini, è qualcosa che molti dop di fascia alta auspicano conoscendo bene i problemi degli eccessi di nitidezza, spesso vengono scelte compressioni maggiori per mantenere più morbide le immagini.

Ovviamente c’è compressione e compressione, la maggior parte delle persone per compressione pensa sempre a quella distruttiva di streaming e company non a compressione più intelligente.

Se è parzialmente demosaicizzato non è raw!

il braw, se la gente avesse la competenza e l’intelligenza per leggere l’sdk di Blackmagic vedrebbe cosa accade e perchè si parla di demosaicizzazione parziale, ma se lo potesse fare, non scriverebbe certe sciocchezze.

Ogni raw ha il suo workflow di lavoro, processi fatti in camera e processi fatti nel software, con vantaggi e svantaggi.
Un codec è raw se permette :

  Braw
la gestione delle matrici separate si
il controllo reale di iso e altri paramentri in post si
il controllo del bilanciamento colore in post si
registrazione dei 12 bit log per matrice si

quindi se il codec offre tutte queste opzioni è un codec raw.

Si è bello ma non lo leggo dal software XYZ!

altra affermazione opinabile visto che anche gli altri codec non sono ben letti (con eccezione di Red) in modo ottimale dai vari NLE, anzi spesso richiedono la creazione di proxy con i software dedicati. Normalmente ai montatori non si danno gli originali, ma i giornalieri con Lut applicate, se si parla di raw o log, quindi il problema non sussiste.

Oggi Bmd vende tre camere con il Braw, la UMP e la Pocket4k e 6k, vendute con licenza completa di DavinciResolve, ovvero il miglior software per lo sviluppo Raw e in particolare Braw, oltre che buon editor, postproduction etc etc… Con il VideoAssist 12g si può registrare in Braw anche dalla Canon C300 MKII e Panasonic EvaOne.
Se si vuole lavorare in un altro software Resolve prevede dal pannello media il sistema di ingest e conversione in altri formati, si può già fare una precolor oppure gestire direttamente la color e mandare il filmato sviluppato all’applicazione NLE.

 

La piccola rivoluzione relativa all’introduzione del Braw ha creato tanti osteggiatori, per chi ha dubbi e ha bisogno di più test scientifici e ben pensati, potete visitare il sito di Frank Glencairn sul post relativo alla qualità del Braw.

Dove mostra dei test pratici nei quali la differenza reale tra i diversi flavour di compressione è relativa, ma la qualità generale resta molto alta contro una serie di richieste generali veramente irrisorie.
Man mano che passa il tempo aggiungo qualche frame estratto a caso dagli shooting, senza denoise, per far capire quanto la qualità anche compressa sia eccezionale sia come dettaglio che pulizia dell’immagine.

Zuppa di codec 3 controrumors pro Apple e pro Microsoft

In passato con precendenti articoli dedicati ai codec dei sistemi operativi, ho parlato di conoscenze di base con Zuppa 1, di come non serva installare codec esterni per montare in Zuppa 2, ho parlato dei Digital Intermediate in Flussi Digitali, e di codec Audio in Ac3 siamo a piedi, oggi siamo qui a chiarire un fatto che recentemente ha creato un certo numero di rumors, di chiacchiere da bar inutili, e soprattutto preoccupazioni ingiustificate, ovvero l’annuncio di Apple che dai sistemi operativi dopo Mojave, 10.14, non saranno più supportati i codec Cineform, DnxHr, e altri considerati obsoleti.

Facciamo un paio di semplici domande: oggi sono supportati? NO!!!
come si può leggere sui formati supportati da FinalCutProX sulla pagina di Apple.

Ma ovviamente saranno supportati dal sistema operativo? NO!!!
Nè Apple Osx, nè Windows da Xp all’ultimo Win10 supportano tali codec.

Quindi ci sono pagliacci in giro che parlano a vanvera spaventando e mettendo rumors inutili e inutilmente provocatori? Si purtroppo questa è la verità….

la premessa

Da infiniti anni, i sistemi operativi avevano il supporto per un numero limitato di file e di codec multimediali implementando al loro interno codec necessari per vedere tali file dalle utility di sistema, nel tempo i diversi codec si sono ridotti notevolmente a pochi codec, e molti non sanno, che spesso erano stati installati da applicazioni di terze parti, ad esempio Windows non ha mai pagato le royalties per la lettura dei film in Dvd, codec mpg2, quindi senza l’installazione di un player dvd il lettore multimediale di windows non era in grado di leggere nessun dvd, dava errore dicendo Codec non supportato, ma nessuno ci faceva caso perchè leggeva i dvd da… un player dvd, quindi installando il programma si installavano i codec nel sistema.

Sia sotto Windows che sotto Mac la maggior parte dei codec video è sempre stata aggiunta come terza parte, e spesso anche se supportati direttamente esistevano codec di miglior qualità (la tedesca MainConcept ha fatto business su questo prima di vendere i suoi codec a Adobe).

Chiunque abbia lavorato nel video negli ultimi 20 anni conosce l’innumerevole quantità di codec, pacchetti, varianti di codec ha dovuto installare per supportare una o l’altra camera durante l’editing video.

Oggi girando prettamente in h264 e varianti, tutto sembra per magia supportato e quindi tutto compatibile (che poi non è vero perchè h264 a seconda del decoder software hardware può essere letto con piccoli errori e differenze qualitative).

La realtà, oggi 1 dicembre 2018

Apple con il sistema operativo successivo a Mojave abbandonerà completamente il framework Quicktime 32bit, e completerà il passaggio iniziato anni fà a AvFoundation framework 64bit, con il risultato che tutti i software collegati al vecchio framework smetteranno di funzionare.

Cineform, dnxHD/Hr e molti altri codec erano implementati nel sistema installando esternamente delle risorse che si appoggiavano al vecchio QuicktimeFramework.

Ora noi abbiamo un problema? No, la situazione è come era prima, perchè si implementavano i codec come terze parti nel sistema per vedere da finder o da altri programmini i filmati, ma i software importanti implementano internamente i codec senza dover dipendere dal sistema, come ho spiegato negli articoli zuppa di codec precedenti.

Un buon flusso di lavoro prevede che tutto il lavoro sia fatto in modo ordinato ed efficiente tramite i software di ingest ed editing, per fare una rapida cernita del materiale, introdurre tramite metadata le informazioni di lavoro, e organizzare il materiale copiandolo, transcodificandolo e gestendolo senza dover passare per il sistema operativo.

Per chi ancora vuol passare per il sistema operativo, basterà che usi una qualunque applicazione come VLC che include già tutti i codec per leggere i file, anche se si lavora in ambito montaggio e post ha più senso usare software di lavoro per vedere il materiale e giudicarlo, che usare player di sistema o altri elementi che possono alterare, mostrare il materiale nel modo non corretto.

La realtà, oggi 11 dicembre 2018

Apple ha trovato un accordo con Adobe riguardo il prores, e nelle nuove release di Adobe Premiere, After Effects, MediaEncoder etc potranno scrivere file in prores anche sotto Windows, a dimostrazione che si vogliono estendere le possibilità e non chiudere come tanti affermano.

H264 standard… mica tanto

Spesso mi sento dire, mi faccia un mp4 che è standard … sorrido e creo un file che so essere compatibile con le esigenze del cliente.

Una volta era più facile distribuire un video, perché i supporti erano più limitati a vhs o dvd, con due standard video PAL o NTSC per distribuire in tutto il mondo.

Oggi ci sono mille e più varianti, ad esempio se si fornisce un supporto solido come il Blu-ray ci sono quelle che vengono indicate come le specifiche di base, e le varianti di formato… che ogni anno cambiano sul sito ufficiale del consorzio, perché a seconda del lettore da tavolo potrebbe essere supportata o no la variante, non dipende dalla data di produzione, o dal brand, anzi alle volte prodotti di marchi meno noti supportano più formati di altri più blasonati.

Lo standard del Blu-ray nasce a 24 fotogrammi al secondo, per rispettare la naturale creazione dei film, senza alterazioni su durata della parte video o alterazione sulla parte audio. Poco dopo la sua nascita è stato subito aggiunto il 23,976 per supportare più facilmente la riproduzione nel mondo Americano e Giapponese (NTSC a 60 hrz). Il codec di compressione di nascita era l’mpeg2 come il dvd (anche se con una variante dedicata all’alta definizione) anche se quasi subito fu introdotto il formato H264 (variante del codec mpeg 4), poi di recente aggiornato al suo successore H265.

Oggi il Blu-ray supporta dal 23,976 24 25 29,97 30 48 50 59,94 60, e neanche tutti in stream progressivo, ma alcuni solo in stream interlacciato per questioni di compatibilità.

Questo per dire come un prodotto che nasceva per uniformare e offrire il massimo della qualità della visione casalinga senza “interpretazioni” si è trasformato nell’insalata dei formati. Inoltre a seconda del monitor, televisore o proiettore su cui si vedono i risultati le immagini saranno più o meno fluidi o naturali.

Quando ci viene chiesto un H264 standard ci viene chiesto il nulla, perché lo standard è molto ampio e a seconda del dispositivo con cui verrà letto verrà INTERPRETATO in modo più i meno fedele.

Lo standard H264 prevede di registrare da un minimo di un segnale 8 bit 4:2:0 ad una serie di informazioni fino a 12bit 4:4:4, cambiare le impostazioni di codifica punto per punto del filmato, gestire più flussi video sovrapposti, alpha, riproduzioni parziali dei dati, cioè ottimizzare in lettura una scalabilità 1:2,1:3,1:4 etc dei pixel, inglobare codice, indici di capitoli, aree sensibili con dati a link e molto altro ancora; peccato che quasi nessun encoder sfrutti tutte queste caratteristiche.

Quando si crea un file H264 la maggior parte degli encoder ci permette solo di impostare il tipo di compressione e i profili, ma niente di più.

Ironicamente invece di usare un prodotto commerciale, la soluzione più versatile anche se meno comoda è il prodotto freeware ffmpeg, un programma a comando di linea che supporta praticamente tutte le funzioni di moltissimo codec sia in ingresso che uscita, ed è disponibile su tutti i principali sistemi operativi, sono state sviluppate diverse interfacce per utilizzare in modo più comodo e flessibile il prodotto.

Considerato che chi arriva ad un articolo di questo tipo di aspetta un suggerimento sugli “standard” vi posso dare dei suggerimenti su come affrontare il discorso e cosa scegliere come impostazioni e cosa influenza qualità e “compatibilità”.

⁃ Riproduzione da televisore o decoder o player multimediale

⁃ Riproduzione da computer diretto

⁃ Caricamento online

Anche se sono le situazioni più comuni in realtà aprono mille e più situazioni e varianti, perché in realtà la questione della riproduzione è al 50% dipendente dal file e al 50% dal sistema di riproduzione.

Quando si crea un file “classico” si sceglie la risoluzione, i fotogrammi al secondo, il bitrate e se questo è fisso o variabile.

In generale si deve creare un equilibrio tra i dati al secondo letto dal dispositivo e la qualità finale, questo significa che se si sceglie una compressione fissa vuol dire che ogni fotogramma avrà la stessa quantità di informazioni registrabili, immaginiamo 2000, ma se ho un fotogramma di una persona davanti ad un muro bianco tutti i dettagli vengono dedicati alla persona, se ho 20 persone gli stessi dati vengono “divisi” per registrare, quindi ogni persona al max avrà 100 per registrare i dettagli, quindi l’immagine sarà meno dettagliata.

Questo sistema permette di avere i seguenti caratteristiche:

⁃ Funziona anche su dispositivi più semplici

⁃ Prevedibilità della dimensione finale del file.

⁃ Per migliorare la qualità basta alzare il bitrate globale (entro certi limiti).

⁃ Per migliorare la compatibilità con i vecchi dispositivi basta abbassare il bitrate.

⁃ Non si notano jittering di decodifica dei movimenti perché i fotogrammi non devono essere creati ma sono tutti completi.

Se si sceglie una compressione variabile si imposta un range di dati minimo e massimo, per cui il sistema di compressione esegue due livelli di compressione, sia creando un frame Delta e un frame parziale per cui vengono creati dei gruppi di fotogrammi, con la logica di creare il primo frame intero, il secondo frame memorizza solo la differenza tra il primo e il secondo, il terzo la differenza tra il secondo e il terzo e così via fino al prossimo fotogramma Delta.

Il secondo livello di compressione variabile si preoccupa di distribuire una quantità di dati del gruppo in funzione delle necessità, di quanti dati sono necessari fotogramma per fotogramma, ottimizzando peso e qualità.

Il risultato ha caratteristiche differenti rispetto al primo metodo :

⁃ Con lo stesso bitrate massimale la qualità può essere notevolmente migliore

⁃ Lo stream dei dati è più efficiente via rete

Ma ci sono dei contro :

⁃ Questa lettura chiede cache più grandi e dispositivi più potenti perché i fotogrammi sono creati al volo, non esistono completamente

⁃ Se si vuole andare avanti e indietro nel filmato la richiesta di memoria e potenza sale

⁃ Alcuni tipi di filmati e movimenti possono con alcuni encoder dare risultati peggiori che il primo metodo perché da frame a frame sarà meno coerente come struttura e forma (se si lavora solo con bitrate molto bassi)

⁃ In caso di problemi di stream dei dati si possono vedere dei salti nei movimenti veloci, causando una visione a scatti.

⁃ Su dispositivi più vecchi possono esserci riproduzioni di artefatti (blocchi di movimento etc) che non sono presenti nel filmato originale.

In conclusione :

A seconda del dispositivo più o meno recente si deve creare un h264 con il primo metodo e bitrate bassi se si vuole vedere su ogni dispositivo vecchio e/o poco potente come molti smartphone di basso livello; con dispositivi moderni si può creare video col secondo metodo che a parità di peso offrirà una qualità superiore e con dettaglio e sfumature più efficienti.

 


Di Digital intermediate un must per i corretti workflow di editing e post

Storia dei software di editing

Fin dalla preistoria dei programmi di montaggio c’è sempre stato il problema di gestire il flusso video, in primis per questioni di performance, perché i dati di una pellicola non erano gestibili in tempo reale dai computer degli anni 80, e quindi si lavorava con il concetto dell’Offline, ovvero si creava una copia in bassa qualità del girato, si montava la bassa qualità, poi veniva generata una lista di tagli, e una persona dedicata tagliava e rimontava la pellicola alla vecchia maniera, in moviola con scotch e taglierina. Nel caso del video lo stesso discorso avveniva esportando una EDL (edit decision List) compatibile con le centraline dell’epoca e il video veniva nuovamente montato da zero ripartendo dai nastri.

I primi sistemi di montaggio software utilizzavano il nastro come sistema di archiviazione dati, poi negli anni 80 apparve una evoluzione chiamata EditDroid, fatta creare da un tizio barbuto per montare le sue produzioncine, dato che non era soddisfatto della bassa qualità dell’offline su nastro, Edit Droid era un sistema che utilizzava il Laserdisk come supporto, per cui il computer in realtime leggeva e saltava da un laserdisk all’altro (c’erano più lettori in linea) in modo rapido e con una buona qualità rispetto al nastro, con la soddisfazione del personaggio in questione e il suo amico che girava sempre con il cappello da baseball calcato sulla testa, i due strani personaggi che insistevano tanto sulla qualità e sul portare il montaggio ad un livello maggiore erano Lucas e Spielberg, che erano sicuri della rivoluzione in corso.

Negli anni 90 nacque Avid, il primo sistema di massa per il montaggio Offline, dove anche se si montava materiale in bassa qualità, una finestra da 320*200 pixel, con una compressione molto alta, era un modo rivoluzionario rispetto ai precedenti sistemi perché non richiedeva tutto lo spazio per i lettori dei laserdisk stile EditDroid, aveva una compressione variabile (in un’epoca in cui 120 MEGA di hard disk costavano quanto 5.000 euro di oggi, quindi era fondamentale ottimizzare lo spazio), permetteva di lavorare con strumenti più evoluti rispetto ai precedenti.

Fin dalla sua nascita Avid basò il suo flusso di lavoro su il codec DI Avid, ovvero il materiale originale era convertito in un formato più adatto a lavorare il video, pur mantenendo le informazioni come codici di tempo per il montaggio finale da centraline, codici pellicola per un taglio preciso, strumenti più vicini a quella che era la mentalità dell’epoca di montatori video e cinema.

Con il passare del tempo questo codec di lavorazione si è evoluto fino all’attuale DnxHR che supporta una risoluzione spaziale virtualmente infinita, e può essere codificato in qualità 4:4:4 per essere non solo un codec off-line a codec on-line.

Facciamo un salto in avanti di qualche anno, nascono diversi software di montaggio video e ogni marchio svilupperà il proprio codec di lavoro, che nel tempo si sono evoluti, da codec offline, quindi di bassa qualità, ma alta compressione al principio opposto ovvero un codec DI, Digital Intermediate.

Cos’è il codec DI?

Un codec DI, Digital intermediate è un codec di lavorazione che nasce per essere il modo migliore di gestire il materiale audio video che abbiamo realizzato, un Di nasce per essere :

  • un codec di altissima qualità e livello visivo
  • leggero da usare, leggere e scrivere su qualunque programma
  • supportare profondità colore anche maggiore del file di partenza per agevolare la correzione colore e preservare ogni tipo di informazione.
  • permettere ricompressioni (generazioni multiple) senza perdite apparenti

Anche se la maggior parte dei programmi di montaggio moderni prevedono la possibilità di usare i file nativi, in molte situazioni è molto più efficiente come velocità e qualità convertire i file in un codec DI per gestire meglio il materiale video.

Perchè usare un codec DI

per quanto il nostro sistema di editing sia potente, veloce, ottimizzato, arriveremo sempre al suo limite, o per quantità di tracce, effetti, o per filmati a crescente risoluzione e profondità colore (4k HDR), quindi è importante sapere che possiamo ottimizzare le capacità e potenzialità dei nostri computer sfruttando questo tipo di codec alternativo ai codec originali.
Una buona ragione per usare un codec DI?

  1. possibilità di editare e riprodurre correttamente video pesanti che la macchina non sarebbe in grado neanche di riprodurre
  2. possibilità di editare e manipolare in modo più rapido il video
  3. esportare in un formato non a perdita, ma che conservi la qualità originale senza occupare tutto lo spazio del non compresso
  4. poter usare un codec che non venga INTERPRETATO ma letto direttamente per evitare le strane problematiche che possono nascere con codec h264/5, Mpg di vario tipo etc etc
  5. usare un codec universalmente riconosciuto da ogni programma che acceda ai codec di sistema sui due principali sistemi operativi (MacOsX e Windows), senza doversi legare ad un programma o a un sistema, che in passato ha creato problematiche e incompatibilità di vario genere.

I miti sui DI

  1. Ma se converto in perdo qualità….
    la perdita di qualità è relativa alla conversione in formati a perdita, non con i DI che nascono esattamente per preservare e mantenere la qualità orginale.
    La conversione va fatta con software dedicati, mentre spesso la perdita di qualità si nota nell’uso di utility di dubbie origini e/o per uso amatoriale, che per convertire rapidamente usano scorciatoie di vario tipo per accelerare le lavorazioni e quindi scartano informazioni secondo loro non utili.
  2. Ma se converto con il codec DI xxx è più pesante…
    verissimo per il peso sul disco, al contrario sulla CPU, perchè un codec DI converte i frame da GOP (group of picture) in frame completi, per cui occuperà un maggior spazio sul disco, ma il processore sarà sollevato dai compiti di estrazione dei singoli frame ogni volta che si farà play, avanti, indietro, etc e quindi potrà dedicare i processi alla elaborazione e non alla semplice estrazione dei frame.
  3. Perdo tempo a convertire invece che usare direttamente…
    questo è il mito più ridicolo… le persone spesso vedono come tempo perso il tempo di copia e conversione in DI, ma non si accorgono di tutti i rallentamenti che avvengono quando si deve attendere le preview, il calcolo degli effetti, i tempi di analisi durante il montaggio. Usare un DI accelera tutti i processi di rendering e analisi, quindi il tempo di conversione si fa una volta, tutti i tempi di elaborazione durante il progetto vengono sollevati grazie al codec DI.
  4. Ma se poi non posso più leggere il codec XX su un’altra macchina?
    i codec DI nascono per la compatibilità, per cui TUTTI sono installabili GRATIS su ogni macchina windows e MacOsX, e spesso sono già integrati sulle suite dei maggiori prodotti di Editing e Post.
    Ad esempio Adobe e Blackmagic Design hanno acquisito i diritti per fornire di serie con i loro prodotti encoder e decoder per leggere senza installazioni aggiuntive Prores, Cineform, Avid dnxHD/HR, e per quanto riguarda BMD anche i codec GrassValley.
    Se per una qualunque ragione vogliamo visualizzare i file su una piattaforma che non ha questi software è possibile scaricare i codec free per vedere e codificare TUTTI questi codec sui software che leggono dal sistema le librerie dei codec sia sotto MacOsX che Windows, di recente il famoso player free VLC ha aggiunto tali codec nella lista dei decoder.
  5. Se il mio cliente non può installare codec?
    partiamo dal principio che di serie senza codec praticamente si può leggere poco o niente su qualunque sistema operativo, perchè persino l’mpg2 senza un lettore dvd software installato non si può leggere sotto windows perchè non hanno acquistato i diritti, stessa cosa sotto MacOsX che legge i dvd, ma non gli mpeg2 dai software se non ha lui stesso i codec, viene letto giusto l’h264 e poco più.
    Comunque il cliente mica deve vedere i file originali, e/o consegnare il master al cliente, il cliente riceverà il prodotto finito, che sarà un file compresso, non un DI.
    Se il cliente pretende di avere un master o il girato, dovrà anche avere i mezzi per leggerli correttamente… il concetto che non può installare codec non può riguardare la visione il materiale intermedio, e comunque potrà chiedere al reparto IT di installare i codec relativi dato che nessuno di essi offre problemi di compatibilità o rischi di sicurezza (la bufala del quicktime risale ad una versione di quasi 10 anni fà, del 2008, che Apple chiuse ai tempi, l’ultima release del QT per windows non ha nessun rischio di sicurezza).
  6. Qualcuno mi ha detto che è meglio lavorare con i file nativi
    quel qualcuno probabilmente intendeva non comprimere i dati ulteriormente convertendoli in formati a perdita, oppure quando si parla di file raw per la parte del montaggio, ma quando si lavora con quel tipo di dati o si ha un DiT che gestirà il workflow o si saprà bene cosa fare e quindi tutto questo discorso e questa domanda non sarà posta.

 


Pagina 1 di 2

Powered by WordPress & Theme by Anders Norén

error: Content is protected !!