Canon HDSLR video - codecid, NLE softid, workflow

[MartinV]

Viimaste nädalate jooksul loetu ja nädalavahetuse eksperimentide põhjal suht lõputu teema, nii et tegin omaette topicu.

Ehk siis Canoni kaamerate Quicktime (.mov) wrapperis olev H.264 video ei ole NLE-dele kuigi söödav materjal - kuigi Quicktime player ja VLC mängivad seda suhteliselt muretult (Q9550-ga CPU usage <20% (VLC), <30% (QT)), siis Sony Vegase timeline'i peale veetuna on kiirus u 10 fps, mis on väga nutune; ma saan aru, et sama probleem on ka teistes NLE-des. Tegelikult ma ei saa aru, miks isegi lihtne mahamängimine ilma ühegi editita probleem on, kuigi niipaljukest mõistan, et selline interframe formaat nagu H.264 on edimise jaoks paha, sest seal tuleb konkreetse kaadri saamiseks alati x hulk ümbritsevaid kaadreid dekodeerida.

Seega on vaja nn. intermediate codecit, millesse video edimiseks võimalikult kvaliteetselt materjal ümber kantida. Variandid sõltuvad platvormist ja NLE softist (Maci peal nt. on kõige popim ProRes).

Windowsi peal on tüüpkonfid sellised:
Premiere: Cineform või DNxHD
Vegas: Cineform või DNxHD
Edius: Canopus HQ
Pinnacle: ?

Ise jõudsin Vegaseni nii, et MattiasS soovitas ja siis ma ei hakanud muid proovimagi; Pinnacle'i pani Mihkel ka juba paika :) Tegelikult Pinnacle on huvitav, sest Pinnacle Studio 14 kohta väidavad miskid netitegelased, et see sööb 5D/7D videot ilma mingi konvertimiseta, lihtsalt pilla timeline'ile ja läheb. Tore oleks, kui keegi prooviks, ise lõpuks ei viitsinud, sest ei jaksanud imedesse uskuda ja hakkas tunduma, et see on ikka suhteliselt consumer bloatware, trial download oli 2Gb :) (vs Vegas Pro 160 Mb). OTOH, Pinnacle on nüüd Avid-i peres, seda äkki Mihkel respectiks ikkagi? Nevermind, downloadin juba :)

Ediusest ei tea suurt midagi ja Premiere on kah suur ja üpris kallis, kui osta tahaks. Ühesõnaga ma konkurentidest väga palju ei teagi, Vegas tundus lihtsalt suht no-nonsense ja intuitiivne, nii et ei hakanud edasi kaevama.

Järgmine samm on seega codec - Cineform või DNxHD. Cineform on parem, aga maksab $130, DNxHD on tasuta.

Cineform tundub parem, sest:

• ta teeb .avi faile, mis performivad Vegases paremini kui DNxHD Quicktime failid.
• encode'itud failid on väiksemad (algfail 90Mb, CF: 290Mb, DNxHD: 490Mb)
• encode'imine on kiirem (sama 17 sek algfail, CF: 14 sek, DNxHD: 37 sek)

Kvaliteedivahet ja tulemuseks oleva faili muditavust ei oska veel hästi hinnata; DNxHD-l saab kvaliteeti ja failisuurust ka alla tõmmata, kiirust see eriti ei mõjuta.

Algatuseks siis sedasi, peale ülaltoodu on veel igasugu jaburaid detaile, mis nende konverimiste käigus mingitpidi mängida võivad, 29.97 vs 30 fps, Canoni iseäralik nägemus video lubatud värviväärtustest (miski 16-235 vs 0-255 teema per värvikanal) jne :/

[MartinV]

Aa, proovimiseks saab 5D/7D sample toorvideo'id reviewsaitidelt ja hunnik 5D klippe on siin:
http://www.limelighthd.tv/canoneos/

[MartinV]

Pinnacle ka ära proovitud ja ongi suht consumer lahendus nii heas kui halvas. Ja tõepoolest, 5D/7D otse kaamerast .mov-e võib timeline'ile lihtsalt niisama vedada ja mängib küll - selles osas teeb ta midagi Vegasest õigemini. Mingeid dissolve'e ei suuda kohe mängida, need vajavad renderdamist, aga ta teeb seda ise taustal suht intelligentselt - kohe ei näita neid, aga natukese aja pärast juba funkab. Klipi värvikorrigeerimine mängib ka ilma renderdamiseta. Tea, ta vist üldse kandib taustal kogu video mingisse oma kodekisse, aga laias laastus see igatahes töötab.

Kasutajaliides on optimeeritud selleks, et lihtsalt klippe järjest timeline'ile pillata, aga igasugune finetuning (transitionite täpsed kestused-paigutused, envelope'id, jne) tundub PITA või üldse võimatu olevat.

Ehk siis suhteliselt sujuv, aga üpris nuditud kasutuskogemus.

[MartinV]

Väike update: on olemas veel üks tasuta codecilahendus, Matroxi VFW codecid:

http://buildyourown.wordpress.com/2010/ ... ox-codecs/

Plussid:
Tasuta
AVI formaat, mida Vegas meelsamini sööb
Failisuurused ja konvertimiskiirus dnxhd-ga võrreldavad või isegi etemad
Olemas ka 1080p30, mida dnxhd ei toeta

Miinused:
See Prism konvertimissoft minul 1080p failidega päris normaalselt ei tööta, artiklis mainitud pseudo-resize trikk kipub ikkagi reaalselt videot paari piksli jagu muutma-croppima-resize'ima (pilt hüppab natuke, kui originaaliga timeline'il kohakuti panna).

[MartinV]

Niipalju veel segadust nendest vahecodecitest, et kõik nad muudavad värvi/gammat/heledust-kontrasti originaaliga võrreldes, konvertisin:

dnxhd kahe erineva "värvitõlgendusega"
matrox kahe erineva "värvitõlgendusega" läbi kahe erineva konverteri

ja panin nad originaaliga koos timeline'ile - konverteerimissoftist matroxi puhul eriti vahet polnud, aga muidu olid kõik klipid erinevad

Ja erinevad playerid (VLC, WMP, QT) näitavad ka orginaalfaili erinevalt ja samuti ka vegasest eksporditud veebisuuruses .mp4 faili. Ja ka Flash player veebis näitab faili oluliselt tumedamalt kui nt. VLC, WMP on vist võrreldav.

Ühesõnaga vastikult palju segadust, millest muud pääsu vist hetkel pole, kui mingi silmajärgi talutavat tulemust andva workflow väljatöötamine ja selle järgimine.

[MartinV]

Kui juba halamiseks läks, siis rabasin prooviks Premiere Pro CS5 triali, aga see risu on mingite kinnikeeratud projektipresettidega ja nende hulgas HDSLR-ile sobivaid presette eriti nagu pole. Eks ma veel raalin natuke, mingi pooletoobise projektisetupiga tundus 7D faile isegi ilma CUDA toeta talutavalt mängivat, aga Vegas tundub ikkagi märksa intuitiivsema interface'iga.

In other news, Vegas 10 Pro kuulutati välja ja peamine feature on:


...wait for it...


3D

Kodulehel pole sellest sõnagi, aga pressiteates on väikses kirjas ka miski "improved video DSLR support", mis iganes see siis poleks.

Positiivsema poole pealt on seal mingi stabiliseerimisfeatuur, mis võib ju isegi tore ja kasulik olla.

Aga 3D??!! Olgu Cameron neetud!

[Tom]

Martin mida see fps teema üldiselt tähendab?
Näiteks:
• 1920 x 1080p (24fps)
• 1280 x 720p (30, 25, 24fps)
• 640 x 424p (30, 25fps)

Missugune see fps peaks olema, et teles või kinos või veebis oleks vaadatav. Kas kino, tele ja veebis jaoks eraldi fps standardid?

[MartinV]

Sellele küsimusele vastamisel on ka väga erinevaid võimalikke keerukuse tasandeid kahjuks

Väga lihtne:
Kino: 24 fps
TV Euroopa (PAL) 25/50 fps
TV USA / Jaapan (NTSC) 30/60 fps

Keerulisem:
Kino: ma saan aru, et katik käib filmi näitamisel filmi eest kaks korda läbi, üks kord kaadri vahetumise ajal ja teine kord niisama, st kaadrisagedus on 24 fps, aga valguse vilkumise sagedus on 48 Hz, mis on suurema sageduse tõttu vähem vilkumisena tajutav. Olevat ka 3x ehk 72Hz lahendusi.

TV Euroopa: Sai alguse 50Hz vahelduvvooluvõrgust. Tavaline SD telepilt oli 50i ehk interlaced, 50 korda sekundis tuli pool pilti (iga teine rida), kaadrisagedus seega 25 fps. Enamus Canoni HDSLR-e (550D, 7D, 1D4 ja 60D) võimaldavad PAL seades teha 720p50 HD videot ehk 720 pikslit kõrge pilt tervikuna 50 kaadrit sekundis.

TV USA: Sai alguse 60Hz vahelduvvooluvõrgust. Tavaline mustvalge SD pilt oli 60i. Ohjeldamatu segamudru tekkis värvi-TV'le üleminekul, kui värviinfo "paremaks äramahutamiseks" muudeti kaadrisagedust 1000/1001 jagu ehk 60i-st sai tegelikult 59,94i ehk 29,97 fps.

Lõpptulemus:
Väga palju segadust ja Canoni kaamerate puhul järgmised *tegelikud* kaadrisagedused:

720P 50/59,94 fps (PAL normaalne, NTSC imelik)
1080P 23,976/25/29,97 fps ("kino sagedus" värdja NTSC kordajaga läbi jagatud, PAL normaalne, NTSC imelik)

Ehk siis 25/50 puhul on alust loota, et see on ka alati reaalne sagedus, 24/30/60 puhul peaks kontrollima, et mis see reaalne framerate on; mingid asjad vist kasutavad neid täisarvulisi kaardisagedusi ka (5D2 oli algselt vist 1080p30, mis siis firmware'ga parandati 29.97-ks ja lisati 23.976). Ja siis on palju segadust ja jama, kui keegi kuskil midagi ümardab, valesti tähistab, konverdib vms.

Euroopas telesse oleks vist siis 25/50 kõige õigemad sagedused, veebis on vist savi ja tegelikult saab kaardisageduste vahel konvertida ka, 23.976, 24, 25 vahel lihtsalt pannakse "film" aeglasemalt/kiiremini käima, kuna vahed on nii väiksed; ülejäänutega on igast erinevaid kamme ja lahendusi ning ka potentsiaalseid kvaliteedikao kohti.

Aeglaste (24-30) ja kiirete (50/60) fps-ide vahel otsustab ilmselt subject matter - aeglasemad annavad mingi kinolikuma ilme, aga vajavad suht blurritud üksikuid kaadreid (see sama 180 kraadi reegel säriaja valimisel), et harjumuspärane välja näha, ning ei soosi kiiret actionit ega kaameraliikumisi. Spordi jaoks näiteks 50/60 fps parem.

Kokkuvõttes paras keemia jälle kokku.

Lisainfo:
http://en.wikipedia.org/wiki/Frame_rate
http://en.wikipedia.org/wiki/24p
http://en.wikipedia.org/wiki/Interlace

[Tom]

"The D7000 uses B frames in it's H.264 encoded video" - aga mis teema see võiks olla?
I-frame
P-frame
B-frame

[MartinV]

See on teema sellest, kuidas videot pakitakse, et andmemahud vähegi talutavaks saada. Kõige lihtsam on võtta, et iga kaader on omaette väike foto ja siis pakkida see sama moodi nagu pilte JP(E)G-ks pakitakse. Tulemus on Motion JPEG e. M-JPEG, kus iga kaader on omaette tervik. Seda on (foto)kaameral teoorias lihtne teha, sest üksikuid JPG-sid oskab ta niikuinii teha, video jaoks vaja lihtsalt palju väikseid pilte kiiresti järjest pakkida. M-JPEG-i kasutasid nt D90, D300s ja D3s.

M-JPEG'i miinus on see, et ta pole kuigi efektiivne - videopilt muutub vahel ka ajas vähe, ainult osaliselt või üldse mitte, seega pole mõtet iga kaadrit eraldi pakkida. Tõhusam on pakkida nii, et ainult mõned kaadrid salvestatakse analoogselt M-JPEG'le tervikuna, ülejäänud aga lihtsalt infona sellest, mis eelmise kaadriga võrreldes muutus. Nt. kui kaamera pan'ib, siis on järgmine kaader eelmise suhtes natuke nihkes - enamus infot on sama, ainult ühes servas on natuke uut infot ja vastasservast natuke infot "kadunud". Sarnane lugu on siis, kui mingi objekt liigub muidu suuresti staatilise tausta ees. Samuti on vist võimalik nt fade-to-blacki efektiivsemalt pakkida nii, et salvestub ainult muutus "luma" kanalis, "chroma" e. värviinfo jääb samaks. Kõiki selliseid muudatusi-liikumisi üritavad videopakkijad otsida ja optimaalselt pakkida, nii et see on päris paras keemia jällegi

Tervikkaadrit sisaldavat frame'i nimetatakse I-frame'iks (intraframe, ehk kõik antud kaadri näitamiseks vajalik on olemas antud kaadri sees). Vahepealsed tuletatud kaadrid on P-frame'id (predicted frame) ja need võivad olla tuletatud nii eelnevast I-frame'ist kui ka eelnevatest P-frame'idest.

Et asju keerulisemaks ajada, siis nagu ka JPG-de puhul, jagatakse iga kaader pakkimisel pisemateks plokkideks (4x4, 8x8 või 16x16 pikslit) ja P-frame siis kirjeldab, et mis tükk on pärit millisest eelnevast I- või P-frame'ist ja millise muudatusega (polegi muudatust, liikumine või midagi muud). Mõned uued (nt panniga nähtavale ilmunud) plokid võivad olla ka nullist kirjeldatud.

Ja meie päevakangelane B-frame (bidirectionally predicted frame) tuleb sellest, et leiti, et vahel on kasulik kaadritevahelisi muudatusi defineerida ka järgmiste, mitte ainult eelmiste kaadrite suhtes

Lõpptulemusena näeb video välja järgmine (suvaline AVI, MOV-e GSpot kahjuks ei osanud nii näidata):



(Iga kast on üks kaader, I-frame punane, P-frame sinine, B-frame roheline)

Ehk siis alguses I-frame e. keyframe, kuna järgmisi kaadreid peame ikka tervikpildist tuletama hakkama; siis kaks B-frame'i, mis kasutavad infot nii esimesest I-frame'ist kui ka neljandast kaadrist e. P-frame'ist. See tähendab muuhulgas, et videodekooder arvutab kõigepealt välja esimese kaadri pildi, siis tuletab sellest neljanda P-frame'i ja siis 1. ja 4. põhjal kaks vahepealset B-frame'i. Maha peab ta need mängima mõistagi ikka järjekorras 1,2,3,4. Aga ka failis on nad vist järjekorras IPBB e 1,4,2,3.

P- (ja B-) frame'e kasutavaid codec'eid nimetatakse interframe codeciteks, sest iga kaader pole omaette tervik, vaid tema näitamiseks tuleb dekodeerida hulk vahepealseid kaadreid. Vastand on intraframe codec, nagu alguses mainitud M-JPEG, kus iga kaader on ülejäänutest sõltumatu.

Interframe codecite eeliseks on vähemalt paar korda suurem pakkimisefektiivsus (ehk siis sama kvaliteediga vähem ruumi või samas ruumis kvaliteetsem pilt), kuna see "ajas" pakkimine annab kõvasti ruumisäästu. Miinuseks on suurem keerukus kokku- ja lahtipakkimisel, samuti ei meeldi need interframe codecid montaažisoftidele, kes tahavad kiiret ligipääsu igale konkreetsele kaadrile. Näiteks ülalolevat pilti vaadates - kui me tahame saada ette / manipuleerida P-frame'i, mis on vahetult enne 5. reas paiknevat teist I-frame'i, peame me selleks välja arvutama nelja rea jagu e. sadakond P-frame'i (vahepealseid B-frame'e pole vaja välja arvutada, kuna B-frame'idest enam teisi kaadreid ei tuletata). See on küll ekstreemne näide, sest tegu on mahamängimiseks optimeeritud kõvasti pakitud videofailiga, mitte kaamerast pärit toormaterjaliga.

Sellest värgist läbinärimisel kulus ära hiljuti soetatud raamat:

Compression for Great Video and Audio

Aga saab ka veebist lugeda:

http://wiki.multimedia.cx/index.php?title=Frame_Types
http://en.wikipedia.org/wiki/Video_comp ... ture_types
http://en.wikipedia.org/wiki/Inter_frame

http://www.tested.com/news/motion-jpeg- ... video/667/