Digitalisering av video8-band

Detta är klassisk bekymmer - i stort sett alla videoformat som spelades in analogt på band är interlaced och beroende på programkälla så är det synligt eller inte

Är materialet tänkt för BIO-film så är det ofta 'progressivt' då man scannar samma filmruta 2 gånger och inget rör sig mellan dessa två halv-frames medans vanlig TV-produktion och även TV-serie/såpopera spelas in med vanlig videokamera i 50/60 Hz halv-frames takt mot videobandspelare och inte på kemisk film, vilket också innebär att varje halvbild kan vara lite olika gentemot föregående tex. vid kamerasvep (tänk sport med mycket kamerasvep som följa boll i fotboll) då uppdatering är 50 eller 60 ggr i sekunden men med halva antalet linjer i varje frame.

- på en skannande system som TV kommer man undan med detta då linjerna som ritas för den första halvbilden, bleknar bort innan nästa halvbild ritas upp med en linjes förskjutning i höjdled och ögat och framförallt hjärnan sätter ihop dessa 2 bilder som 1 bild med flytande rörelse - men kör man på skärmar och videominne med statisk hållande alla linjer kvar lysande tills de modifieras med ny svep så ser det inte bra ut - och tekniskt sett bör även TFT-skärmarnas pixlar tona ut mot svart inom några enstaka ms sekunder efter varje svep om det skall emulera en CRT-TV perfekt i rörelser vid kamerasvep och 50/60 Hz video-inspelning.

Till detta har man den eländiga, eländiga realtidskonvertering mellan 50 och 60 Hz från tex. direktsändningar från USA för visning i Europa men även DVD-filmer har det för tex. TV-serier i USA som konverterats från NTSC med 60 Hz till PAL-systemet i Europa med 50 Hz vilket ger stutter och ojämna rörelser vid tex. kamerasvep då var 6:e bild skall tas bort i programkällan med 60 Hz mot 50 Hz-systemet med olika mönster då man inte kan/kunde resampla bilderna med hur rörelserna ser ut mellan två olika halvframe, och samma sak åt andra hållet från 50 till 60 Hz där man komprimerar de 5 bilderna i tiden (dvs. visas med något kortare mellanrum) och sedan dubbelvisar en bild också enligt olika mönster för att dölja ryckigheten lite - och det blir också rätt besvärande stutter... och de värsta är DVD-produktioner som både har konverterats från 60 Hz till 50 Hz, tillbaka till 60 Hz igen och sedan mot 50 Hz igen innan de görs till Mpeg för DVD-skiva...

(det är inte helt sant längre - med dagens tekniker som är bakom H264 och H265 kompression så kan man emulera och beräkna var en specifik pixel för objekt som rör sig var den 'borde' befinna sig när man skall rendrera en bild 'mitt i mellan' för 50 Hz visning mellan 2 käll-frames från källan med 60 Hz visning och tvärt om)

---

De flesta videoredigeringsmjukvaror har olika flikar/menyer i olika algoritmer hur man skall hantera interlace, även uppspelningsprogram som VLC och MCP kan man slå på de-interlace med olika algoritmer under uppspelning i realtid.

- men som redan tidigare nämnt gör man eventuellt sådana åtgärder på 'produktions-video', inte på den första inspelningen från källan.

Sedan skall man komma ihåg att göra deinterlace på en 'produktionsvideo' kan se acceptabel ut på en TFT-skärm - men skulle man mot förmodan spela upp igen på en CRT-skärm/tjock-TV igen så kan det se rätt bedrövligt ut och och att köra RAW-versionen ser betydligt bättre ut.

En sak till - Gamma-värdet på en datorskärm och en TV är helt olika och en inspelad videoinspelning som visas på en datorskärm ser färgfattig och tråkig ut samt man ser en massa 'grums' som aldrig syns på en riktig CRT-tjock-TV - en Tjock-TV sminkar upp VHS-videosignalen väldigt bra och det är näst intill omöjligt att få till något som ser lika bra ut på en dator-TFT-skärm - så var beredd på att bli besviken... - och det blir också jättefel om man i videoredigering justerar gammafaktorn så att det ser bra ut på en TFT-dataskärm och sedan spelar upp det på en tjock-TV (eller för den skullen en LCD-TV där man försöker emulera gammafaktorn för en CRT-TV) och det blöder ut på alla sätt...

---

Det som också påverkar är själva inspelningen då det helst skall göras i RAW-format utan komprimering eller använda icke förstörande kompression som huffman-kodning, möjligen JMPEG-kompression (varje bild komprimeras individuellt utan hänsyn till den föregående bilden) med låg kompressionsgrad då högre kompression ger artefakter som passar illa ihop mellan halvframes som vid senare efterbehandling gör att det är svårt att få till en bra 'produktions' version.

Problemet idag att skall man få riktig RAW så behöver man de gammaldags videocapure korten på PCI-gränsnitt och en JMPEG-codec som verkligen hinner att komprimera 50 ggr i sekunden utan att hacka eller missa frames - på win95-tiden var det ett helsike att få till och på den tiden var man tvungen att se till att lagringsdiskarna kördes med DMA och inte med PIO - och DMA var något som MS och windows knappt visste vad det var och en del hårddiskar supportade detta inte heller så bra (Linux hanterade DMA på diskar tidigt och listan med IDE-diskar som inte stödde det och tom gav korrupt data var armslång - HW-stödet för DMA har dock alltid funnits, men ingen har provat det att det fungerar, visade det sig hos somliga av HD-tillverkarna, när även windows-världen forcerades att börja med DMA även på hårddiskarna av prestandaskäl...) ...

Idag när man kör videocapture över USB så sker en komprimering lokalt i dongeln då bandbredden ofta över USB2.0 helt enkelt inte pallar med överföring i RAW-format - inte för att bandbredden i sig inte räcker till (för PAL 720x576/25 Hz upplösning med 12 bit/färg RGB ger ca 15 MB/s) utan för USB-stackens i windows bristande realtids-egenskaper - det finns en anledning till att Firewire/1394 designades och infördes av Apple för garanterad bandbredd och fördröjning och det var just för att hantera videoströmmar utan hack/stutter i RAW-format för inspelning och senare redigering och uppspelning (då ofta mot SCSI-diskar då dessa alltid använde DMA)

Silicon Graphic gjorde i sin tur filsystem XFS just också för att kunna garantera skrivbandbredd inom filsystemet (på snurrdiskar) för videoströmmar och har och kanske ännu fortfarande används mycket inom TV-produktion så att man inte fick stall/stutter och tappade frames. XFS finns idag finns till stora delar implementerad i Linux och det har också visats sig vara ett bra val även för servrar och större NAS.

En sak till som snabbt ruinerar bildkvaliteten vid högre kompression direkt i videocapturekort är om videosignalen innehåller mycket brus eller ostadig, gittrande (darrande) bild med dålig synkning (typisk videoinspelning....), kompressionen ger icke reparerbara skador och artefakter (för att bruset käkar upp en stor del av tillgänglig bandbredd och mindre blir kvar för bildinnehållet och därmed reduceras mer med mer kompressions-artefakter, då brus går inte att komprimera (har maximal entropi) och brusreducering/behandling innan kompression kosta massor av RAM och CPU-kraft och det hinner inte en dongel med) som är svåra att dölja vid den senare videoredigeringen medans har man RAW-inspelning av sin videoinspelning kan man bearbeta med rätt avancerade brusreduceringsfilter som gör bilden mer acceptabel i använda videoredigerings-programmen när man skapar 'produktions'-videon.