Jump to content

Recommended Posts

Under kodningen av MPEG-2 med renderingsmotorn CinemaCraft SP2, har jag märkt hur stort område komprimering till MPEG-2 egentligen är.

 

Är bara lite nyfiken av vad som menas med följande:

 

1. Quantization Matrixes ? (Tabell bestående av en massa siffror, ser ut som en kalkulation av något slag ?)

 

2. IPPBPPPBBPPPBBB ( står i en följd av varandra bestående av bokstäverna "I" , "P" och "B"

(anar något om I-Frames, B-Frames etc etc. Vad menas med det ?

 

Tackar för seriösa svar!

Link to post
Share on other sites
  • 3 weeks later...

1. Quantization Matrices

Helt riktigt så är det något som används vid en kalkylation av något slag.

Det är lite svårt att förklara och jag vet inte om jag själv förstår helt och hållet men matriserna används som ett slags gränsvärde för hur mycket av bildinformationen som ska kvantiseras, d.v.s. räknas om till siffror i MPEG-2 filen grovt sagt. Längst upp till vänster motsvarar DC-nivån eller ett slags medelvärde. Sedan ju längre åt höger man går så desto högre horisontella frekvenser gäller det (eller ju mindre detaljer längs en horisontell linje). går man neråt i tabellen så är det vertikala frekvenser. Går man till ett värde någonstans mitt i tabellen är det en kombination av horisontella och vertikala frekvenser.

 

I praktiken betyder det att det ofta är ett högt värde i matrisen längst ner i högra hörnet eftersom både hög vertikal och hög horisontell frekvens alltså innebär mycket små detaljer i bilden. Små detaljer är svårare att se så där kan man kasta bort mer bildinformation utan att ögat ser det. Brus t.ex. är bestående av mycket små detaljer. MPEG-kompressionen går nämligen ut på att kasta bort så mycket som möjligt av den bildinformation som ögat inte kan uppfatta och på så sätt få ner filstorleken och därför vill man kasta bort mer av små "osynliga" detaljer men behålla de grövre detaljerna.

 

Nu finns det två matriser. Intraframe och interframe. Den ena gäller en hel bild typ som en jpg-bild (d.v.s. I-frame) medans den andra matrisen gäller delbilderna mellan I-frame, d.v.s. P-frame och B-frame som är skillnader från senaste I-frame grovt sett. Nu minns jag inte exakt vilken matris som är inter och intra men den som är längs till vänster i encodern är den som gäller I-frame och alltså är den viktigaste eftersom alla andra bilder refererar till denna.

 

2. IPPBPPPBBPPPBBB ser lite konstigt ut tycker jag. Normalt brukar det vara IBBPBBPBBPBB och det brukar aldrig vara mer än 2 stycken B på rad. I är något som kallas intraframe eller I-frame och kan jämföras med en vanlig jpg-bild. Det är alltså hela bilden som sparats ner. P är en bild som är baserad på skillnaderna mot närmast föregående P-frame eller I-frame (beroende på vad som var innan). B är en bild som är baserad på rörelsevektorer, både framåt och bakåt mot närmaste P-frames eller I-frame. Så för att avkoda en sådan grupp av bilder (GOP = group of pictures) måste man först ha I-bildrutan och sedan räknar man ut eftefröljande P-bildruta genom att lägga på skillnaderna mot I-rutan. Först därefter kan man applicera rörelsevektorer som finns i B-rutorna för att räkna ut hur mycket bilden flyttat sig vid tidpunkterna för B-rutorna och på så sätt få fram dessa bildrutor. Sedan fortsätter det med att räkna ut nästa P-ruta och b-rutorna däremellan och så vidare. När GOP är slut så kommer nästa I-frame och så vidare. Man behöver alltså en buffer som lagrar bildrutorna när de beräknas innan man kan skicka ut dem i rätt ordning (man vill ju visa B-rutan innan P-rutan som behövs för att kunna rökna ut B-rutan).

 

Allt detta är mycket bättre förklarat här (men tyvärr på tyska):

http://www.edv-tipp.de/gastbeitraege/kika001_dct.htm

 

Så hur ska man utnyttja detta då?. Tja det jag sett så lönar det sig sällan att ändra GOP-strukturen från default när man håller sig inom DVD-standarden. Har man extremt hög bitrate skulle man kanske kunna få bättre kvalitet genom att skippa B-frames och kanske till och med köra enbart I-frames men då blir det ungefär likvärdigt med DV-komprimering eller Mjpeg och detta är alltså långt högre än DVD-standardens bitrate. Har man extremt låg bitrate skulle man kanske kunna tjäna på att lägga in fler B-frames och färre I-frames, men jag har för mig DVD-dtandarden inte tillåter mer än max 2 stycken B-frame i rad (jag är osäker på detta) och dessutom finns en max GOP-längd på 15 bilder för PAL och 18 bilder för NTSC enligt DVD-stanarden. Det krävs alltså mycket mer data för en I-frame än vad en P-frame kräver. Detta är ju inte så konstigt om man tänker sig en stillastående kamera där bakgrunden inte ändrar sig (t.ex. i en studio) och det sitter en gubbe stilla framför kameran och bara pratar. Då behöver P-frames bara innehålla bildinformation om gubbens ansikte (skillnaderna finns ju bara där något ändrar sig i bilden). B-frame innehåller ännu lägre data eftersom man här även tar hänsyn till hur bildinformationen rör sig i bilden (om t.ex. kameran sakta panorerar så kan stora delar av bilden återskapats efter man flyttat bilden motsvarande bit tillbaka som rörelsevektorerna visar). Jag tror att det som är kvar efter att man flyttat runt bildens delar såsom rörelsevektorerna visar och därefter tar skillnaderna mot framförvarande och bakomvarande P-frame är vad som blir kvar att behålla i filen för denna B-frame, förutom själva rörelsevektorerna då.

 

Så detta medför då att I-frame ofta har bättre kvalitet än P-frame och sämst kvalitet har B-frame. Men något som är vikltigt här är att P-frame har bättre kvalitet i förhållande till datamänden än I-frame och B-frame har bättre kvalitet i förhållande till datamängden jämfört med P-frame. Det hela går ju ut på att komprimera ner datamängden utan att förlora onödigt mycket bildkvalitet...

 

Allting är en jättestor kompromiss kan man säga.

 

Men kan man ha någon nytta av kvantiseringsmatriserna då?

Ja men det är en ganska krånglig vetenskap. Men generellt sett så genom att ändra kvantiseringsmatrisen till högre värden (ofta då särskilt ner mot högra nedre hörnet eftersom man då i princip filtrerar bort brus och små detaljer) så kan man komprimera hårdare utan att det blir så mycket kvantiseringsstörningar i bilden (alltså fyrkanter). Men å andra sidan så tar man ju även bort de fina detaljerna så det blir på bekostnad av en suddigare bild.

Det andra scenariot är om man har en video som är lätt att komprimera och/eller man vill använda hög bitrate då kanske man vill behålla extra mycket detaljer i bilden. MPEG-2 komprimeringen kan nämligen bli mättad, man får inte ut mer än en maximal kvalitet när kvantiseringen åkt ner till minimum. Då kan man utnyttja kvantiseringsmatriserna genom att sänka värderna oh liksom plana ut det hela så att det blir mindre skillnader mellan nedre högra hörnet och övre vänstra hörnet. Då ökar kvantiseringen igen och man kan utnyttja den högre bitraten (eller den mer lättkomprimerade videon) till att få med den extra bildkvaliteten!

 

Ja det hela är fråga om kompromisser. Man bör också tänka på att vissa mtriser passar bättre till viss typ av video. För komprimering av interlaced DV från videokamera till DVD så har en matris som kallas "mb1 interlaced DV" funkat bra för mig. Men denna matris kräver hög bitrate för att det ska bli bra, t.ex. 8 Mbit/s.

 

Länk (tyvärr också på tyska): http://forum.gleitz.info/showthread.php?t=82

Link to post
Share on other sites

En closed GOP slutar alltid på en P-frame vilket betyder att varje GOP är fristående, d.v.s. ej beroende av första frame i nästa GOP. Teoretiskt sett ska closed GOP vara en fördel vid redigering då man kan klippa ut den och använda någon annanstans utan att förlora någon bildruta. Open GOP slutar på B-frame och dessa är ju beroende av nästföljande I-frame i nästa GOP för att kunna avkoda sista bildrutan av typen B.

 

Så här kan en closed GOP se ut: IBBPBBPBBPBBP

Och detta är en open GOP: IBBPBBPBBPBB

 

Men normalt sett har det mindre betydelse vilket man väljer men closed GOP är inte riktigt lika effektivt komprimeringsmässigt. För att göra multi-angle DVD (alltså när man kan välja olika kameror för samma scen vid uppspelningen) så krävs det closed GOP har jag för mig.

 

Jag är dålig på de strukturella skillnaderna mellan MPEG2 och MPEG4. Det är väl komplexare algoritmer i MPEG4 som gör det mer effektivt men samtidigt mer krävande att avkoda.

Link to post
Share on other sites

Tack för ditt svar angående GOP.

Jag har sedan några år använt closed och har läst kommentarer om det i andra user groups utan att kunna finna vare sig fördel eller nackdel med någondera. Har heller aldrig fått rapport om problem med avkodningen så fortsätter med closed tills vidare. Dessutom lär väl MPEG4 ta över allt mer med tiden.

Jag ser att du nyligen är registrerad men uppenbarligen inte någon nybörjare - åtminstone inte när det gäller teknik.

Link to post
Share on other sites

Underbart att se någon med så mycket kunskap!

Ännu mer underbart är att du använder kunskapen för att hjälpa andra!

 

Har mitt i allt detta ytterligare en fråga:

 

Vad menas med DC-nivån ? dvs: "Intrablock DC-Precission" ?

Finns i tre olika lägen: 9bit, 10bit och slutligen 11bit som är icke DVD kompatibel.

 

Har lite smått hört om att det har med bildkvaliten i helhet att göra ?

Till exempel, om det finns "slow-mo" rörelser i bilden, så skulle det hjälpa att höja DC-Precission till 10bit istället för 9bit (default) för att framställa bättre bild ?

Link to post
Share on other sites

Jag har hållit på med video i datorn på hobbynivå seda år 2001 tror jag och eftersom jag är intresserad av videokomprimering (särskilt i MPEG-2 till DVD) så snappar jag upp en del. Att jag är elektronikingenjör i grunden och läst en del signalbehandling i skolan hjälper väl en del när man ska försöka förstå hur det funkar.

 

Då jag ser MPEG-2 mer som ett slutformat och sällan använder det just för redigering så kör jag alltid med open GOP för att tjäna en aning kvalitet (men skillnaden är liten så det kvittar nog i praktiken). Jag har heller inte märkt några problem med avkodningen så det är väl en smaksak vilket man prioriterar (kvalitet eller redigerbarhet).

 

Det jag hört om DC-nivån "Intrablock DC-precision" är att det kan göra att långsamma fade-in/fade-out effekter ser snyggare ut om man har fler bitar. Eller om man har små variationer i bilden, exempelvis en blå himmel eller en mörk skugga där små skillnader i nivå syns i bilden så kan det också bli bättre med hög DC-precision. Mycket möjligt att det kan hjälpa att öka DC-precisionen vid slow motion effekter också då det är ett långsamt förlopp.

 

DVD-standarden tillåter 8, 9 eller 10 bitar DC-precision. Nackdelen är att om många bitar används till DC-precision så blir det färre bitar över till annat om man har en begränsad bitrate. Någonstans går gränsen då det lönar sig att öka DC-precision. När man kodar MPEG-2 till DVD lönar det sig sällan att ha mer än 9 bitar DC-precision. Har man låg bitrate för att klämma in mycket speltid på en skiva kan man gå ner till 8 bitar DC-precision för att få lite bättre kvalitet. Själv har jag satt gränsen någonstans runt 5 Mbit/s när jag går upp från 8 bitar till 9 bitar. Återigen kommer man in på att MPEG-2 komprimering är en jättestor kompromiss, ökar man kvaliteten i ena ändan förlorar man det i andra ändan och det gäller att välja en kompromiss som syns minst för ögat. Personligen har jag svårt att se några skillnader i praktiken för olika DC-precision men en del människor ser tydligt skillnaderna.

Link to post
Share on other sites

Aha!

 

Har sedan flera år tillbaka hållt mig på 10-bitars.

Antar att det hela med kvalitetspåverkan för DC-värdet också varierar från renderings motor till renderings motor ?

 

En annan bekant sade även att mjukvarurendering kan i "vissa" fall få bättre resultat än hårdvarurendering på exempelvis svindyra Stradis eller Toshiba kort som realtidskodar MPEG-2.

Dock tar det ju betydligt längre tid!

Kan det stämma ?

 

Låter logiskt för mig då mjukvarurendering kan ske i flera pass

till skillnad från hårdvarurendering där signalen skickas i ett pass ?

Link to post
Share on other sites

Jag vet inte riktigt hur pass det skiljer mellan olika renderingsmotorer med olika värden på DC-precision. Jag tror det bör ge ungefär samma utslag då det mer är frågan om hur noggrannt den kan göra beräkningarna, men å andra sidan är det ju många parametrar som påverkar slutresultatet. Med andra ord - jag vet inte...

 

Men allmänt sett så visst är det skillnad i överlag i kvalitet mellan olika MPEG-2 kodare. Personligen gillar jag HCEnc, Canopus Procoder och Mainconcept encoder. Just nu är min favorit faktiskt gratisprogrammet HC Encoder dels för den fina kvaliteten men även för att det är lätt att scripta i BAT-filer. Lite lustigt att ett gratisprogram är minst lika bra som de svindyra konkurrenterna.

 

Ett litet tips är att själv testa korta videoklipp med olika inställningar och se om man själv kan märka någon skillnad. Jag menar testa med 8 bitar, 9 bitar och 10 bitar och se hur det blir. Testa sedan med någon annan MPEG-2 kodare och se hur det blir. Ser du ingen skillnad, ja då kvittar det väl. Ser du skillnad då vet du vad du ska välja sedan.

 

Jag har ingen erfarenhet av dyra hårdvarurenderingsprylar (jag är ju bara en hobbypulare) men jag tror att den stora skillnaden är kvaliteten på ursprungsmaterialet. Har man råd med dyr hårdvarurendering har man kanske råd med dyra kameror och så vidare. Skit in ger skit ut. Sitter man med gamla VHS-band som råmaterial så lär det ju inte bli bra resultat vad man än gör om man säger så.

 

Man bör i alla fall kunna klara av samma saker i mjukvara som dessa svindyra kort kan men som sagt det kan ju ta längre tid. Å andra sidan kan man med dagens snabba datorer utan problem rendera MPEG-2 i realtid men då kanske man kompromissar en aning på kvaliteten. Som hobbypulare kan man nog leva med det, jag brukar kompensera med högre bitrate så att jag ligger på max enligt DVD-standarden, alltså ca en timme speltid per DVD-skiva. Och när man ligger så högt i bitrate så lönar sig det inte med fler pass heller egentligen.

 

Är du nöjd annars med Cinemacraft? Det var längesedan jag testade det programmet och då bara i en testversion (ligger långt över min budget att köpa det). Men jag tyckte inte jag lyckades få jättebra resultat. Visst det blev helt OK för progressiv video (typ för långfilmer) men för interlaced video från min videokamera blev det inte lika bra som t.ex. Canopus Procoder eller Mainconcept encoder. Jag testade även TMPGEnc Plus och var inte nöjd med det heller. Canopus Procoder ger snyggt resultat, kanske aningen softat men rent och fint om man säger så. Mainconcept encoder gillar jag då man kan finjustera massor av saker i avancerade alternativ och resultatet blir bra från videokameran (med interlaced och hög bitrate i alla fall).

Kör även ganska mycket med HCEncoder i kombination med avisynth och det funkar jättebra. Eftersom HCEncoder även är gratis så är det en klar vinnare för hemmapularen, mer prisvärt än så blir det ju inte.

Link to post
Share on other sites

Intressant!

Jag är dock 100%igt nöjd med CinemaCraft! Underbara slutresultat varje gång.

En äldre version av CinemaCraft SP2 jämfördes i ett test med flera andra mjukvaru renderingsmotorer år 2004.

 

http://digitalcontentproducer.com/mag/video_mpeg_encoder_shootout/index.html

 

För tillfället producerar vi en "behind the scenes" video åt en större videoproduktion som nyligen blev färdig. En hel del snabba panoreringar och tiltningar i videon, samt en limiterad bitrate omkring 5,5 mbit/s säger mig att använda ett par extra pass i renderingen än normalt sätt.

 

Är och kommer alltid att förbli petig med slutresultatet.

Dock "ser" ögat förbättrad kvalité vid använding av flera pass under renderingen. Å andra sidan är det alltid så, vill man se en förbättring, så upplever ögat det hela som det.

Link to post
Share on other sites

Det jag hört är att över 3 pass i CCE är knappt märkbar förbättring och efter 5 pass så ger det ingen skillnad så du behöver i alla fall inte köra mer än 5 pass. Kör du progressiv video? CCE lär ska vara bättre på progressiv video och lite sämre på interlaced.

 

Testen i länken verkar fokusera på låg bitrate och förmodligen progressiv video. Gör man samma test med högre bitrate och interlaced video kan man kanske få andra resultat. Det bästa är att testa lite själv och jämföra med en typen av video man själv jobbar mest med. Man ska inte lita på vad andra säger, det kan mycket väl vara dold marknadsföring bakom det hela...

Link to post
Share on other sites
Det jag hört är att över 3 pass i CCE är knappt märkbar förbättring och efter 5 pass så ger det ingen skillnad så du behöver i alla fall inte köra mer än 5 pass. Kör du progressiv video? CCE lär ska vara bättre på progressiv video och lite sämre på interlaced.

 

Testen i länken verkar fokusera på låg bitrate och förmodligen progressiv video. Gör man samma test med högre bitrate och interlaced video kan man kanske få andra resultat. Det bästa är att testa lite själv och jämföra med en typen av video man själv jobbar mest med. Man ska inte lita på vad andra säger, det kan mycket väl vara dold marknadsföring bakom det hela...

 

Helt korrekt ang. marknadsföringen!

Jag outputar till stor del i Interlaced video (För DVD video).

Har och är även väldigt nyfiken på flera frågor ang. Progressiv / Interlaced video.

Bland annat har denna frågan uppkommit under flera trådar:

Låt oss säga att en video filmas i Progressivt 25P, videon skall vid slutrenderingen ändå renderas som Interlaced video om den skall användas som en universiel DVD för att visas på TV etc, eller? ( bottom eller upper kvittar då videon i grunden är Progressivt ).

 

Jag påstår detta då standard CRT TV inte visar progressiv scan som det skall visas.

De flesta "plattTv" De-Interlacar ofast interlaced bildmaterial vid uppspelning, samt de flesta mjukvaru uppspelarna på datorer De-interlacar också vid uppspelning.

 

Så rent generellt , för största kompabilitet av videon, är det alltid bäst att slutrendera som Interlaced, då jag efter tester vid slutrendering till Interlaced video, inte märker någon skillnad i videon även om den i grund var progressiv!

 

Vill gärna ha en klar syn över det hela!

Link to post
Share on other sites

Har man enbart progressiv video i hela filmen så ska man ange det som progressivt vid MPEG-2 kodningen. Anledningen till detta är att dels så instrueras mjukvaruspelare att de inte behöver försöka göra deinterlace och på så sätt riskerar man inte försämra kvaliteten vid uppspelning på progressiv display och dels så görs olika optimeringar vid MPEG-2 kompressionen beroende på om man markerat interlace eller inte.

 

Exempelvis brukar man vilja göra "alternate scan" vid interlaced MPEG-2 eftersom det är mera optimerat för interlaced video. Alternate scan är inte riktigt lika optimalt för progressiv video där man istället brukar vilja ha zig-zag scanning.

 

Å andra sidan så är de flesta DVD-spelar-programvaror intelligenta nog att ändå inte göra någon bildförsämring när de försöker göra deinterlace på progressiv video eftersom de ofta kör smart-deinterlacing ändå. Så skillnaden är väl mest zig-zag eller alternate scan då. I CCE kan du välja zig-zag och alternate scan oberoende av interlace-flaggan men å andra sidan interlace-flaggan är just bara en flagga som talar om att nu så är det interlace-kodat.

 

I praktiken funkar det ändå ganska bra även om man kodar progressivt som interlace (i alla fall för oss som anväder PAL-formatet eftersom båda formaten har 25 frames per sekund). Exempelvis så kör ju digital-TV-utsändningarna alltid med interlace-flaggan aktiverad oavsett vad som egentligen sänds ut. Men jag anser att man bör optimera för progressiv video när man vet med sig att det verkligen är progressivt format. Däremot vid realtids-kodning av TV-inspelningar så kan det ju variera hejvilt (exempelvis plötsliga reklaminslag i interlaceläge som avbryter en progressiv långfilm) och då gör de ju rätt i att koda allt i interlace-läge om man säger så. Kan ju även vara vettigt om man lagt in videoeffekter vid redigeringen ovanpå progressiv video då de ofta blir mjukare och finare i interlace-läget då man har 50-delbilder per sekund istället för 25 helbilder för dessa effekter (scrollande text och liknande).

 

Jag tror inte du förlorar mycket kvalitet om du kör interlace-läge även för progressiv video men man bör vara medveten om att det kan göra en viss skillnad.

 

EDIT: Det finns förresten ytterligare ett interlaceläge vid MPEG-2 kodning som är ganska annorlunda. Det heter field based encoding och där separeras halvbilderna till dubbla bildhastigheten, alltså 50 bilder per sekund för PAL. Detta läge lär vara optimalat för interlaced video men inte så bra för progressiv video. Nu kan dock inte CCE koda i detta läge men däremot Canopus Procoder har det. Jag har testat det och det ger jättebra kvalitet, men det kan vara sämre kompabilitet med DVD-spelare. För att Canopus field based encoding ska vara någorluna kompatibelt så bör man välja en videokälla med "top field first" och upplösning 720x576 för PAL. Är utgångsmaterialet DV får man alltså göra om det från bottom field first till top field first exempelvis med avisynth innan man öppnare det i Procoder för field based encoding.

 

Det vanliga interlace-läget som CCE använder är faktiskt 25 helbilder per sekund där halvbilderna sammanflätats till helbilder (det är därför de så kallade interlacing artifakterna uppstår). För att bevara dessa interlace-linjer så bra som möjligt har man kommit på alternate-scan som tydligen ska vara optimalare än zig-zag.

Link to post
Share on other sites

Det jag då inte förstår är att om jag nu skulle välja att slutrendera progressivt material i Progressive-MPEG-2 för visning på TV, skulle inte det ge en "hackig" eller form av väldigt eftersläpande bild på vanliga CRT TV som ej har stöd för progressiv bildvisning ?

 

Har gjort en del tester ang detta, samt kommit fram till att slutrendera i Interlaced även om materialet i fråga är progressivt, är den bästa lösningen även om detta kanske kan ge sina nackdelar, som du beskrev!

 

Bör man slutrendera sitt progressiva material som Progressiv MPEG-2 ?

Även om effekter / creditrolls är tillagda ? Tycker personligen att en creditroll i Progressivt är mer "inlevelserik" att se på än en Interlaced. Det hela ser så matt ut i Interlaced med sluttexter.

 

Samt. slutrenderas till exempel större SF filmer för DVD i Interlaced eller Progressivt ?

Link to post
Share on other sites

DVD-spelaren gör om den progressiva bilden till videosignal som en CRT-TV förstår även om det har kodats som progressiv MPEG-2. Det blir inte mera hackigt eller släpigt jämfört med att komprimera progressiv video till MPEG-2 med interlace-flaggan satt i encodern. Du kommer inte att märka någon skillnad. Däremot har man interlaced videokälla som man kodar till MPEG-2 utan att ha satt interlace-flaggan och korrekt field order då riskerar man att få problem med "field order" i TVn, alltså DVD-spelaren vet inte viket av fälten som ska spelas före det andra och då kan det verkligen bli hackigt.

 

Jag är lite nyfiken på vilket sätt det blir bättre när du komprimerar progressiv video som interlaced? Jag kanske har missat något intressant här!

 

Lägger du till effekter I creditrolls så kan du ju göra det progressivt också och då kan du alltså koda till progressiv MPEG-2. Däremot om ditt redigeringsprogram får för sig att lägga till effekterna som interlaced så riskerar du att få problem med "field order" om du inte har kodat hela videon som interlaced (se ovanstående beskrivning om hur ryckig uppspelningen kan bli). Jag tycker att texter och liknande som scrollas horisontellt blir snyggare när det spelas upp i interlace-format på en CRT-TV (de flyter mjukare fram då, särskilt om scrollningen går snabbt, typ aktiekurser på ekenominyheterna). Däremot vid vertikal scrollning som eftertekter så blir konturerna på bokstäverna snyggare när det är progressivt även om det blir lite hackigare rörelse.

 

Rent allmänt så tycker jag man får skarpare och tydligare video när den är progressiv även när det visas på CRT-TV, och detta oavsett om det kodats som progressivt eller interlaced. Däremot sker detta på bekostnad av att rörelser blir mer hackiga. Nu har ju ofta biofilmer lagom mycket rörelseoskärpa för att dölja denna hackighet och så har de bra kontroll på inspelningen och undviker att göra så att det ser alltför hackigt ut. Så det är väl därför man inte störs av fenomenet när man kollar på film på TV.

 

Min gissning är att större SF-filmer för DVD har slutrenderats progressivt. Oavsett vilket så är ju själva bilderna på filmen progressiva eftersom filmkameror inte arbetar med interlacing. Alltså själva bildrutorna i MPEG-2 filen ser likadana ut efter avkodning oavsett hur interlace-flaggan är satt. Har de någorlunda koll så har de använt zig-zag scanning för att optimera för progressiva bilder och i så fall kvittar det faktiskt vad interlace-flaggan står inställd på. Jag brukar inte hålla på med DVD-rippning av SF-filmer så jag har inte studerat hur deras videoströmmar ser ut. Däremot spelar jag in mycket digital-tv och där kör som alltid med interlace-kodning oavsett om de sänder progressiv video eller inte. Men jag har sett att vissa kanaler kör med zig-zag scanning och interlace-flaggan satt, det kanske är kanaler som visar mycket progressivt material men med vissa interlace-inslag emellanåt, eller så har de bara ställt in encodern fel.

Link to post
Share on other sites

Aha!

 

Field order har varit en stor fiende på tidigare dagar =).

Men som alltid spelas DV Interlaced in med bottom field first. Och därefter har jag alltid utgått efter bottom field first som slutrenderings metod på MPEG-2.

I fortsättningen kommer jag att prova slutrendera allt progressivt material som progressiv MPEG-2 i väga av dina rekommendationer!

 

Dock har det alltid rekommenderats att slutrendera sitt material efter post som Progressivt om materialet enbart skall användas för visning på dator eller projektor, detta då ÄVEN om materialet i grund var inspelat som Interlaced. Detta är möjligen korrekt då datorskärmar baseras på Square Pixels, hur det är med projektorer är jag mindre säker på ?

 

Något jag fått om bakfoten ?

Link to post
Share on other sites

Oj vad du är uppe tidigt på morgonen!

 

För visning på dator så kan man göra om interlaced till progressivt genom att använda ett deinterlace-filter innan man renderar till progressiv video. Om man inte gör deinterlace och renderar med progressiv inställning i MPEG-2 encodern då får man interlace-mönster i videobilden när man tittar på datorn.

 

Men man kan förstås låta datorn göra deinterlace vid avspelningen också och då kan den ju visa interlace-format så att det ser bra ut även på en dator. DVD-spelarprogrammen i datorer har ju inbyggda deinterlace-funktioner. Det underlättar i så fall att det är interlace-flagga satt i MPEG-2 strömmen så att avkodaren automatiskt kan känna av detta, annars så kan man i och för sig aktivera deinterlacing manuellt. Exempelvis VLC verkar strunta i deinterlacing oavsett vad interlace-flaggan står på så där får man manuellt gå in på "Avfläta" och välja något av alternativen.

 

Slutsatsen är att man ska ställa in encodern så att ingen avkodare blir lurad. Är det progressiva bilder så ställ den på progressivt. Är det deinterlaced video som ska komprimeras så ställ den också på progressivt. Är det interlace-video som ska behållas som interlace så ställ in interlace med lower field först om källan är DV. Apropå ingenting upptäckte jag igår att HDV är top field first till skillnad mot DV som är lower field first, ja bara för att krångla till det liksom...

 

Vet du att videon alltid ska visas på dator eller annan progressiv display så för all del gör deinterlace. Ofta är de deinterlace-funktioner man kan göra vid renderingen mer avancerade än de som måste ha prestanda för att fungera i realtid vid uppspelningen. Men är det tänkt för DVD t.ex. så är det många som spelar av det på spelare kopplade till TV-apparater och då är det bättre att behålla eventuell interlacing ifrån källan. Tittar man i datorn får man som sagt utföra deinterlacingen vid uppspelningen istället.

 

Eller jo förresten, en sak som kan vara värd att veta är att interlaced video kräver högre bitrate än progressiv video. Så ett trick om man ska klämma in väldigt mycket speltid på en DVD kan vara att offra interlacingen och göra deinterlace och komprimera det progressivt istället med de nackdelar det innebär i fråga om sämre flyt i bilden men med mindre komprimeringsstörningar som fördel. På den gamla goda tiden när jag gjorde SVCD-skivor så var det ofta lönt att deinterlacea interlaced video innan komprimeringen till MPEG-2 just på grund av den extremt låga bitraten i förhållande till upplösningen. Interlacing kräver kanske 30% mera bitrate än progressiv video.

 

Ett annat trick för lång speltid är att minska upplösningen. DVD-standarden tillåter halv-D1 formatet vilket för PAL innebär 352 horisontella punkter och 576 vertikala. Vid extremt låg bitrate (alltså långa speltider på DVD-skiva) så kan man teroretiskt halvera bitraten utan att bildkvaliteten försämras men på bekostnad av en detaljfattigare bild förstås. Men i praktiken så syns kompressionsstörningarna mera vid en lägre upplösning så man kan kanske klämma in 3 timmars speltid istället för två timmar på en singel-lager DVD med detta trick. Gör man dessutom deinterlace så kan man nog klämma in uppemot 4 timmar i acceptabel kvalitet. Nästa trick är att göra brevlådeformat med svarta kanter upptill och nertill i en 4:3-bild och då kan man sänka bitraten ytterligare något, kanske 4,5 timmar på samma skiva. Men allt det här sker ju på bekostnad av sämre upplösning i bilden.

 

Jag minns på SVCD-tiden (alltså innan jag skaffade min första DVD-brännare) så kunde man använda upplösningstricket istället för deinterlace-tricket. Det gick att skapa spelbara SVCD-skivor med 352x576 istället för SVCD-standardens 480x576 i upplösning. Detta format med lägre upplösning kallades CVD. Tack vare den lägre upplösningen så kunde man få något bättre kvalitet vid samma låga bitrate så att det med nöd och näppe gick att köra med interlaced video, särskilt om man gjorde XCVD, alltså överskred standardens bitrate något. Min DVD-spelare klarade 3 Mbit/s utan problem och då blev det ganska bra och jag kunde få in 30 minuter interlaced MPEG-2 per CD-skiva. Viserligen funkade inte dessa skivor i så många spelare men det dög för att lägga över lite från min DV-kamera för att kolla i min DVD-spelare. Jag tror att det var tack vare allt trixande man fick hålla på med för att få det att funka på CD-skivor som jag lärde mig mycket om MPEG-2 komprimering. Sedan när man kunde slänga in skiten på DVD blev ju allt mycket enklare. Visserligen fick man lära sig en massa om DVD-menyer och andra nya saker vad som gäller för DVD-standarden men själva videokodningen blev ju lättare när man inte blev så himla begränsad i bitrate och upplösning.

 

Nu känns det som deja-vu när HD-formaten börjar komma på allvar. Man trixar och donar för att få till spelbara format i HD-upplösning istället. Känns som man får lära sig lite om MPEG-2 i HD-upplösning, h.264, VC-1 och liknande så man kan börja göra HD-DVD format på DVD-skivor, så kallat 3X DVD. Men ännu har jag varken HDTV eller HD-DVD-spelare. Däremot har jag en TviX M400P hårddiskspelare som klarar vissa format i HD-upplösning och så fick jag ju min nya HDV-kamera i förrgår. Upptäckte att min TviX-spelare tyvärr var för klen för HDV på grund av bitraten så jag fick koda om det till lägre bitrate med hjälp av HC Encoder. Då uppstod problemet hur man muxar tillbaks elementär-strömmarna till TS-format men jag löste det med diverse omvägar (först muxa till VOB med Rejig och sedan konvertera detta till TS med projectX). Min TviX-spelare klarade tydligen max 22 mbit/s i 1080i, retligt nära HDV-standardens 25 mbit/s...

 

Apropå det, känner ni till några bra programvaror för HD-DVD eller Blu-ray authoring som inte kostar skjortan? Är lite sugen att lära mig mer om detta.

Link to post
Share on other sites

Angående HD-DVD och BluRay authoring letar jag personligen som en galning efter program.

Har av diverse skäl valt att fördjupa mig inom HD-DVD authoring, där det i nuläget endast existerar Sonic Scenarist samt DVD Studio Pro för professionellt bruk.

När vi kommer till BluRay authoring så finns där lite fler val.

Ett program att rekommendera vore Roxio DVDit Pro HD.

Riktat till semi-pro samt väldigt användar vänligt.

 

Skall läsa vidare i ditt föregående inlägg nu, mycket text ! :)

 

EDIT: Du skrev i ditt föregående inlägg att om det inte sker en De-Interlace process på progressiv video innan slutrendering som Progressiv som skall användas för visning på datorskärmar etc, så skulle det uppstå interlace render. Måste faktiskt påpeka att det inte stämmer i mina fall av slutrenderingar av progressiv video (utan de-interlace) för visning på till exempel datorskärmar. En De-interlacing har aldrig krävts för mig ?

Link to post
Share on other sites

Deinterlace behövs inte om källan är progressiv video, Deinterlace är ju själva processen där man gör om interlaced till progressive om man säger så.

 

Det jag menade är att om man har äkta interlaced video så försvinner ju inte interlace-linjerna om man endast ställer in i MPEG-2 encodern att interlace-flaggan ska sättas. Däremot kan det ju hända att det finns inbyggd deinterlacer antingen i encodern eller redigeringsprogrammet så frågan är om det skett deinterlacing någonstans? Kan även ha gjorts automatiskt av uppspelningsprogrammet.

 

Hur ser det ut om du öppnar dessa videofiler med VirtualDubMod? Det programmet öppnar MPEG-2 utan deinterlacing och man kan granska varje enskild bildruta. Kolla exemplevis en horisontell panorering.

Link to post
Share on other sites

Självklart är jag medveten om din beskriving!

Progressiv video behöver aldrig någon De-Interlacing och är oberoende av field order.

 

Möjligt att renderingsmotorn ( i dåvårande fall Main Concept ) automatiskt De-Interlacade det interlacade materialet vid rendering till Progressivt.

I Dagens läge sker alltid videoinspelningen för mig i Progressivt, samt att jag endast använder mig utav CCE renderingsmotor.

 

Jag använder sällan VD men skall se efter om interlace renderna uppstår på datorskärm, när jag renderat ut grundinspelat interlace material till progressiv video (UTAN De-Interlace process ).

 

Tackar för dina som vanligt snabba och konkreta svar ! :)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...