Spørsmål om video komprimering

[Bjerknez]

Dette er på vei til å bli ganske så avansert for mitt vedkommende men selv om det sikkert er rett i det dere sier her, så får ikke jeg den samme opplevelsen med Premiere Elements 12 som den dere antyder.

 

Kan godt hende at Premiere Elements 12 suger gullfisk på denne biten, men det er nå det programmet jeg bruker, og ut fra hva jeg har, så bør vel CBR holde i lange baner tror jeg.

 

Nå ikke engang "videogeeks" klarer å se nevneverdig forskjell på to identiske videoer så tror jeg nok både jeg selv og familie/venner og andre som vil se videoene mine på Youtube for morroskyld blir fornøyde.

 

Det kan godt være at man kan komprimere en video langt mer effektiv ved å gjøre noen dypdykk i komprimeringsmetoden og kanskje også bruke egne programmer for dette, men jeg er nok ikke helt der.

 

MIN konklusjon så langt er at VBR1 og VBR2 (spesielt sistnevnte) er bortkastet å bruke i Premiere Elements på de videoene jeg har testet de på. CBR gjør det enklest, filstørrelsene ligger midt på treet i forhld til VBR1/VBR2 og hvis man ser på filstørrelse kontre videokvalitet alene, så vinner CBR i mine øyne. Dessuten så går det fortere og konvertere med CBR også og man slipper å tenke på Target/Maximum bitrate etc.

Endret 2. november 2013 av Bjerknez

[xRun]

Videoene starter med sort bilde, men fader straks til bilde. Det betyr at første keyframe ikke inneholder noen detaljer, så encoderen må vente på neste keyframe før hele bildet med alle detaljer tegnes opp. Forskjellen ligger i hvordan de forskjellige modusene plasserer keyframes, hvor følsom de er for sceneskift osv. I tillegg til komplette keyframes finnes det bidireksjonelle frames og andre ting.

 

Edit: mtp. at keyframes er en type frames som opptar mye plass, og alle andre typer frames opptar mindre plass, vil jeg tro at det er langt ferre keyframes i den videoen som har minst filstørrelse, som også er problemvideoen her. VBR2 er normalt egnet til å spare bitrate ved bla. å plassere keyframe dynamisk etter behov. Iblant dukker dette problemet opp og gir sånne resultater spesielt ved myke sceneskift hvis encoderen ikke trigger keyframes der den burde, og dermed ikke plasserer en eller flere ekstra slike frames med kortere mellomrom.

 

Det er ikke godt å forklare hvorfor denne forskjellen oppstår, annet enn at forskjellige encodere og moduser håndteres på litt forskjellige måter i forskjellige programmer. Som sedsberg skriver er jeg også litt usikker på hvor god encoderen i Premiere er. Premiere støtter en rekke forskjellige kodeker, noen bedre enn andre. En kunne trolig løst det ved å justere profilen Premiere bruker under eksporten.

 

Jeg ville faktisk prøvd en annen encoder som en mulig løsning. Kanskje fordi jeg er mer fortrolig med Handbrake, men jeg holder en knapp på at den ville gjort en bedre jobb her. Den er også spesielt godt egnet til h.264 (kodeken) og inkluderer en open source utgave av encoderen kalt x.264.

Endret 2. november 2013 av xRun

[Bjerknez]

Jeg ser hva du skriver og skjønner hva du mener her, men jeg holder meg nok til Premiere Elements 12 og CBR tror jeg. Enkelt og greit. Dessuten så voldtar jo Youtube videoen allikevel.

 

Nå har jeg vertfall fått litt forståelse av hvordan dette funker og i mitt tillfelle så funker ikke VBR1/VBR2 like bra som CBR samlet sett.

 

Takker uansett for all hjelp så langt!

her er det mye nyttig info

 

PS! Videoene i denne tråden kommer til å bli slettet ganske snart da dem tar opp mye plass på serveren. De som ligger på Youtube vil også bli slettet da det jo bare er videoer som er lastet opp for testens skyld.

 

Det skal sies at jeg også har kjørt en del tester selv som jeg ikke har publisert og jeg synes rett og slett CBR gjør den beste jobben i mitt tillfelle.

[Pc Lynet]

Fint at du sletter alle videoene på Youtube slik at de som søker opp denne tråden igjen ikke får se eksempler...

Endret 2. november 2013 av Pc Lynet

[sedsberg]

Eksemplene var jo såpass uklare at det ikke var stort hjelp i dem uansett. Konklusjonen for dette spesifikke tilfellet står jo fremdeles tydelig her.

[Pc Lynet]

Ingenting er mer irriterende enn å finne en forumtråd, der trådstarter har spurt om noe fått noen svar og så skriver nevermind I fixed it uten å nevne hvordan.

Jeg kan forstå at han vil fjerne fra servern sin, men YT er gratis.

[Bjerknez]

Fint at du sletter alle videoene på Youtube slik at de som søker opp denne tråden igjen ikke får se eksempler...

Beklager, men jeg gidder ikke å ha slike "tullevideoer" liggende på youtube kannalen min. Håper du skjønner det?

 

EDIT:

Dessuten så er de videoene på Youtube null verdt i denne sammenligningen da Youtube sin egen komprimering ødelegger alt sammen uansett.

 

 

Eksemplene var jo såpass uklare at det ikke var stort hjelp i dem uansett. Konklusjonen for dette spesifikke tilfellet står jo fremdeles tydelig her.

Jeg føler jeg har gjort så godt jeg kunen for å få laget denne testen så god som mulig gjennom å bruke Premiere Elements 12 med de forskjellige komprimeringstypene. Videoene som liggerpå min server er helt ukomprimerte (utover den komprimeringen Elements har gitt) og jeg skjønner ikke helt hvorfor disse videoene er håpløse i en sammenligning?

 

Det er ikke noe Formel1 løp dette, men et gutterace i gata.

 

Alt kan sikkert bli bedre, men det jeg ville vite hva som lønte seg å bruke i mitt tillfelle samt en generell forklaring på hvorda nde forskjelligekomprimeringsmetodene virker.

 

Jeg har fått svar på alt dette, og ut fra svarene jeg har fått så må jeg danne min egen konklusjon til slutt og jeg tror vi med hånden på hjertet kan si alle sammen at CBR gjør en god jobb her og mer enn god nok til mitt bruk?

 

Det som skuffet meg mest var at jeg ikke kunne fremtsille noen gode eksempler på hvorfor man bør velge VBR1/2 da begge disse skuffet på vær sin måte i grunn.

 

Nå har jeg uansett brukt mye tid på dette pg føler jeg selv kan roe meg ned og bruke CBR.

 

Jeg gir dermed ballen videre til dere, slik at dere kan vise meg den store fordelen med å bruke VBR1/2 ovenfor CBR. ALtså ikke videoer hentet fra Youtube som allerede er voldtatt, men egne videoer med egen komprimering.

Endret 2. november 2013 av Bjerknez

[Pc Lynet]

Hvorfor skal vi bruke vår fritid på å overbevise deg Bjerknez?

[Bjerknez]

Hvorfor skal vi bruke vår fritid på å overbevise deg Bjerknez?

Hvis du ikke vil bruke din fritid på det, så la vær. Ikke noe værre enn det.

 

For de av dere som har lyst derimot, så fyr løs.

 

EDIT:

Hvorfor snakker du forresten for alle og ikke bare deg selv?

Endret 2. november 2013 av Bjerknez

[Pc Lynet]

Jeg snakker for meg selv. Jeg spurte hvorfor skal vi bruke fritiden vår på å overbevise deg Bjerknez?

Du har allerede fått veldig gode svar og du har fått svar på det du spør om. Men du har ikke satt deg godt nok inn i stoffet til at du forstår at svaret allerede foreligger.

 

Jeg synes som en høflighetshandling at du iallefall bør laste eksempel videoene dine opp til en "tullekanal" slik at de fortsatt vil være synlige. Jeg svarer på spørsmål på ett forum fordi jeg tror flere kan ha nyttet av det. Da er det ganske egoistisk å slette info fordi det ikke er "showoff" nok synes jeg.

[Bjerknez]

Jeg snakker for meg selv. Jeg spurte hvorfor skal vi bruke fritiden vår på å overbevise deg Bjerknez?

Du har allerede fått veldig gode svar og du har fått svar på det du spør om. Men du har ikke satt deg godt nok inn i stoffet til at du forstår at svaret allerede foreligger.

 

Jeg synes som en høflighetshandling at du iallefall bør laste eksempel videoene dine opp til en "tullekanal" slik at de fortsatt vil være synlige. Jeg svarer på spørsmål på ett forum fordi jeg tror flere kan ha nyttet av det. Da er det ganske egoistisk å slette info fordi det ikke er "showoff" nok synes jeg.

"Vi" og "vår" forteller meg at du snakker på vegne av flere og ikke bare deg selv...

 

Jeg har også sagt at svarene jeg har fått har hjulpet meg mye og jeg har lært mye om hvordan det grunnleggende innen videokomprimering etc. foregår. Jeg har også prøvd (etter beste mulige evne) og lage noen eksempelvideoer, men disse videoene er i følge noen her ikke bra nok til sammenligning og da ser jeg ikke vitsen med at disse ligger ute og tar opp plass og oppmerksomhet.

 

Da er det bedre at noen som faktisk påberoper seg kunnskapen leverer noen eksempler synes jeg, slik jeg har prøvd på. Eller så faller jo hele diskusjonen i mine øyne på to konklusjoner:

 

1. I følge det jeg har erfart fra egne tester som og så er publisert er er VBR1/2 ikke like bra som mange skal ha det til og CBR fungerer best generelt sett.

 

2. Videoene mine er feil esportert og viser et feil bilde av sanneten og det som blir sagt angående hvor bra VBR2 etc. er, er det som gjelder.

 

For mitt vedkommede så er resultatet JEG får det viktigste og frem til noen viser meg konkret hva jeg gjør feil ved å komme med noen eksempler som er selvlagde, så går jeg for ver. 1 av svaret.

 

Ja, jeg har fått mye hjelp og jeg skjønner hva VBR1/2 gjør med videofilen kontra CBR etc. Jeg får dte bare ikke til å stemme med egne forsøk, og det er der mer ekspertise må komme for å overbevise meg.

 

Selv om ikke du har mulighet/lyst/kompetanse til å vise meg, så kan det hende andre her inne har...?

[Trondster]

Er her enig med Pc Lynet - det er tull å ødelegge en eksisterende tråd med å fjerne sammenligningsgrunnlaget vi diskuterte om. Og - ærlig talt - "liggende på din kanal"? Sett dem til å ikke være søkbare, da vel - så de bare er synlige om man har linken til dem.

 

Surfer mye på mobil, og hadde planer om å sette meg ned, se videoene og komme med feedback nå i kveld, når jeg endelig har anledning til å sette meg ved en datamaskin. Men - nå vet jeg om jeg vil gidde å bruke mer av den dyrebare fritiden min eller ikke. Om du så fjerner og sletter videoer så tråden ikke lenger er interessant for andre som kommer til senere og for andre interesserte lesere, så gjør du jo dermed spørsmålet om prioritering ganske enkelt.

Endret 2. november 2013 av Trondster

[Bjerknez]

Det har blitt sagt tidligere i tråden at videoene ikke kan brukes til sammenligning og da er det vel også liten vits? Spesielt med tanke på evaluering av videoer som ligger på Youtube som ikke sier noe som helst om komprimeringen jeg har gjort da Youtube har voldtatt videoene ytterligere.

 

De som ligger på serveren min lar jeg ligge en stund til, men de på Youtube blir fjernet da dem ikke bidrar til noe som helst egentlig.

 

Jeg har også en "dyrbar tid" og jeg synes jeg allerede har brukt mye av den tiden med de videoene jeg allerede har postet. Jeg tror at hvis dere er interreserte nok så vil dere komme med en lignende test, da det er selve komprimeringsmetoden og innstillingene som er feil her i følge noen.

 

Men som sagt. De som ligger på serveren blir liggende, så kan du se på dem om du vil. Er jo de samme videoene, men uten Youtbe sin voldtekt, noe som bør gi deg et bedre utgangspunkt for evaluering.

[xRun]

Nå som jeg endelig har fått anleding til å sette meg ned ved maskinen og en større skjerm, har jeg sett igjennom resten av eksemplvideoene fra ende til ende. Flere ting fremgår av disse, og her er noen av mine observasjoner.

 

1. Samtlige er kodet for lavt til å gi et godt resultat gjennom mer enn deler av videoenes lengde. Dette fører i varierende grad til artefakter som fremstår som en slags pixellering og pulsing som skjer i takt med GOP'ene (grovt sagt bildegruppen fra en keyframe til neste). Til 1080p25 med dette innholdet ville jeg tatt utgangspunkt i 6Mbit (kanskje mer) og justert etter behov slik øynene ser det. 2avg/4max er (alt) for lavt.

 

2. I CBR dukker artefaktene opp langt tidligere i kjøringen. Det er naturlig fordi CBR takler det animerte innholdet dårligere enn det statiske. Den lave bitraten gjør det ekstra tydelig i det animerte innholdet, mens første del av videoen her med statisk innhold ser ok ut.

 

3. VBR1 tar noe hensyn til det faktiske innholdet, og deler ut mer bitrate under kjøringen, og noe mindre til første del. VBR1 deler også ut keyframes mer regelmessig enn VBR2, og takler derfor fadingen i starten bra. Overgangen fra parkert til kjøring takles også bra pga. en mer regelmessig plassering av I, P og B-frames i VBR1 enn hva som skjer i VBR2. Pixelleringen under kjøringen dukker opp senere enn på CBR, og fremstår noe mer dempet.

 

4. VBR2 tar mer hensyn til innholdet, og plasserer I, P og B-frames mer dynamisk langs tidsaksen. Encoderen i Premiere Elements har i dette tilfellet jobbet etter en profil som ikke har vært følsom nok for sceneskift til å dele ut ekstra keyframes til fadingen i starten. Derfor ser den dårligere ut enn på begge de andre her. Overgangen fra parkert til kjøring i andre del er tilsvarende myk, og viser tilsvarende problemer. Kjøringen takles litt bedre, og pixelleringen er derfor tilsvarende dempet ift. CBR, men fortsatt deles for få keyframes ut.

Problemet i denne testen handler mest om to ting: håndtering av endringer i bildet, noen av disse skulle vært håndtert som sceneskift og flere keyframes ville da blitt delt ut. Det ville gjort filen større. I tillegg er det som nevnt for lav bitrate, som fremprovoserer både pixellering og tildels GOP-pulsing i deler av alle de tre testene. Med høyere bitrate-budsjett for kodingen vil du trolig se resultater som er mer i tråd med forklaringene gitt tidligere over hele linjen.

 

 

Til slutt kan det nevnes at noe av problemet her kan være spesifikk til eksport i h.264-format fra Premiere Elements, som er bundlet med MainConcepts forenklede utgave av h.264 referanse-encoderen. Den er litt "dummet ned" i forhold til fullversjonen, og forenklingene blir ekstra synlig ved lave bitrater. Den samme encoderen er også bundlet med fullversjonen av Premiere. Det fins andre kommersielle encodere som kan installeres for bruk med Premiere, men de koster vanligvis litt.

Her kan x.264 som er en open source encoder for h.264-kompresjon være et bedre alternativ. Den er ikke "dummet ned" for bundling, den er gratis, og er inkludert i Handbrake.

 

Edit: En gratis workaround blir da å redigere som normalt i premiere, men eksportere uten kompresjon hvis det er mulig, evt. til MJPG eller tilsvarende med høye settings, som bla. er brukt som "redigeringsformat" i diverse sammenhenger. Deretter hentes denne videoen inn i en bedre encoder, hvorav Handbrake bare er nevnt som et eksempel fordi jeg er fortrolig med den.

Endret 2. november 2013 av xRun

[sedsberg]

3. VBR1 tar noe hensyn til det faktiske innholdet, og deler ut mer bitrate under kjøringen, og noe mindre til første del. VBR1 deler også ut keyframes mer regelmessig enn VBR2, og takler derfor fadingen i starten bra. Overgangen fra parkert til kjøring takles også bra pga. en mer regelmessig plassering av I, P og B-frames i VBR1 enn hva som skjer i VBR2. Pixelleringen under kjøringen dukker opp senere enn på

Hvis du legger merke til filstørrelsen så ser du at VBR1 er på mye høyere bitrate og kan derfor ikke sammenlignes direkte med de andre. Grunnen til at bitraten er satt lav var for å lettere kunne se effektene av CBR, VBR1 og VBR2.

[xRun]

Hvis du legger merke til filstørrelsen så ser du at VBR1 er på mye høyere bitrate og kan derfor ikke sammenlignes direkte med de andre. Grunnen til at bitraten er satt lav var for å lettere kunne se effektene av CBR, VBR1 og VBR2.

Jeg tar utgangspunkt i at de angitte parametrene stemmer med det TS faktisk tastet inn. Filstørrelsen er større bla. pga en mer regelmessig utdeling av keyframes, som blant annet gir utslag i at fadingen i starten takles bedre, og overgangen mellom parkert og kjøring takles bedre. Den er også nærmere forventet størrelse med de angitte parametrene. VBR2 ble uventet liten, og noe av grunnen er et lavere antall keyframes, som per definisjon tegner opp hele bildet.

Selv om MainConcepts bundlede encoder er en enklere utgave av referanseencoderen vil høyere bitrate gi bedre resultater. Det er naturligvis når det kniper at problemene blir mest synlig.

[Bjerknez]

Driver å eksporterer en ny video jeg tok idag som jeg har redigert kjapt for å teste. Jeg kommer til å legge ut tre videoer. CBR/VBR1/VBR2. bitraten er satt til 6Mbps (som ønsket lenger opp) på CBR filen og på VBR1/2 så har jeg satt target bitrate til 6Mbps og maximum til 12Mbps.

 

Jeg akter og kun bruke Premiere Elements 12 til dette da jeg vil gjøre dette enklest mulig uten flere programmer.

 

Jeg legger også ved et screenshot av komprimeringsinnstillingene.

 

Videoene kommer straks og innen ca. 30min og blir lastet opp på min server for å forhindre ytterligere komprimering.

Endret 2. november 2013 av Bjerknez

[sedsberg]

Jeg tar utgangspunkt i at de angitte parametrene stemmer med det TS faktisk tastet inn. Filstørrelsen er større bla. pga en mer regelmessig utdeling av keyframes, som blant annet gir utslag i at fadingen i starten takles bedre, og overgangen mellom parkert og kjøring takles bedre. Den er også nærmere forventet størrelse med de angitte parametrene. VBR2 ble uventet liten, og noe av grunnen er et lavere antall keyframes, som per definisjon tegner opp hele bildet.

Selv om MainConcepts bundlede encoder er en enklere utgave av referanseencoderen vil høyere bitrate gi bedre resultater. Det er naturligvis når det kniper at problemene blir mest synlig.

VBR1 ble større fordet det er kun ett pass. Det er da umulig å beregne nøyaktig gjennomsnitlig bitrate. Du kan sette f.eks. 2Mb men hvis det er mye kompleksitet kan gjennomsnittet gjerne komme opp i 4. Er det mye stillbilder kan gjennomsnittet godt komme langt under 2Mb.

[Bjerknez]

Her er videoene:

 

Video 1 - CBR/6Mbps - Filstørrelse: 51.842kb.

http://www.bjerknez.no/video3/cbr-6mbps.mp4

 

Screenshot av innstillingene:

 

Video 2 - VBR1/6-12Mbps - Filstørrelse: 56.446kb.

http://www.bjerknez.no/video3/vbr1-6-12Mbps.mp4

 

Screenshot av innstillingene:

 

Video 3 - VBR2/6-12Mbps - Filstørrelse: 59.828kb.

http://www.bjerknez.no/video3/vbr2-6-12Mbps.mp4

 

Screenshot av innstillingene:

 

Hva mener dere om resultatet?

 

EDIT:

Drit i det som står i "comments" feltet i screenshot'ene. Dette stemmer ikke med de faktiske innstillingene, som dere ser.

Endret 4. november 2013 av Bjerknez

[Bjerknez]

Ser at det plutselig stoppet opp med bidrag i denen tråden og det er jo også forsåvidt greit, men jeg lurer på en liten ting til:

 

Jeg synes ALLE videoene på Youtube mer eller mindre krever rundt 5-6Mbps nettlinje for å klare p spilel av en video i full HD 1920p. Jeg synes dette er litt rart da jeg tror mange har lastet opp vidoer med langt større bitrate enn dette i håp om bedre kvalitet.

 

I den forbindelse så lurer jeg på hvor nødvendig det er å eksportere en fil med over 6Mbps siden man vel mister kvalitet jo mer komprimering Youtube gir videoen.

 

Jeg har lastet opp både 8Mbps og 15Mbps og kan ikke se nevneverdig forskjell på videoene (har slettet dem nå, men kan sikkert prøve igjen)

 

Det jeg lurer på er om Youtube kjører nøyaktid samme mende koprimering på ALLE videoer eller om det er mer avansert programvare som leser innholdet i videofilen og velger komprimering ut fra "exif" data ?