Zowel xvid als divx wijgeren 16:10

[anoniem]

Op 1 of andere manier wijgeren xvid en divx codec om een 16:10 filmpje te enconden (via virtual dub). Bij xvid een unknown error en bij divx een unsupported frame size of output. Iemand een oplossing? Gaat 16:9 wel werken?

[anoniem]

In avi's, en in het bijzonder alle mpeg4 varianten zoals divx en xvid , geld dat de resolutie zowel horizontaal als verticaal geheel deelbaar moet zijn door 16, breuken zijn dus niet toegestaan. Maar zelfs dan nog kun je in de problemen raken (vooral de oudere codec varianten)en derhalve word er vaak geadviseerd om de resolutie deelbaar door 32 te aan te houden alhoewel het vaak toch wel met "deelbaar door 16" lukt. 720x576 is dus ok want beide zijn deelbaar door 16(45x16=720 en 36x16-576) Maar 500x375 is niet ok want 500/16=31.25 en 375/16=23.43 , dat zijn dus geen hele getallen als uitkomst. 16:9 of 16:10 maakt dus niets uit ,als de resolutie maar deelbaar is door 16.

[anoniem]

Dat is wel lastig omrekenen dan of niet? Stel ik doe 1680/16=105 Dan is bijvoorbeeld x10=1050. Om dan met de andere helft op /16 uit te komen EN in de juiste verhouding is vrijwel onmogelijk:S. Ik heb overigens opgenomen op "half size" dus als het goed is 840x525 (wat inderdaad niet deelbaar door 16 is).

[anoniem]

Het is niet onmogelijk maar het aantal geldige combinaties voor 1 aspect ratio verhouding is beperkt, als je wat naar de eigenschappen van videos kijkt die je wellicht zelf op harde schijf hebt staan afkomstig van anderen zul je ontdekken dat deze bijna altijd dezelfde resoluties hebben. Saillant detail daarbij is natuurlijk dat nagenoeg alle platte schermen van tegenwoordig de meest idiote desktop resoluties hebben, voornamelijk het gevolg van productie-zuinigheid en vaak niet de gangbare 16:9 verhouding aanhouden maar iets wat er op lijkt, zoals in jouw geval 16:10. Als je dan zelf scherm afbeeldingen gaat capturen raak je in de problemen als je deze wilt omzetten naar een gangbaar compressie formaat. Maar ook bv de full-hdtv resolutie 1920x1080 volgt niet de x16 regel, er zijn dus codec's die geen last hebben van het fenomeen of het vereenvoudigen tot "deelbaar door 4" wat natuurlijk veel meer werkbare combinaties opleverd. Ik weet dat iig Microsoft WMV(in een recente versie) de deelbaar door 4 regel aanhoud en ook VC1 (=onderdeel van wmv3) en H264 moet deelbaar door 4 zijn, kortweg; de meeste moderne formaten zijn ruimer in de specificaties. De formaten die al langer bestaan hebben last van de :16 regel. De oorzaak is de mpeg compressie quantisatie matrix die uitgaat van blokken pixels van 16x16, deze matrix is de basis van de wiskundige berekening die de codec nodig heeft om het beeld te "vereenvoudigen" en zo data kwijt te raken waardoor het bestand kleiner wordt in data omvang. Je kent het fenomeen ook wel alleen de relatie is je nooit opgevallen: als je video te ver comprimeerd krijg je de bekende "blokjes" in je video, weet je wel? ---> die blokjes zijn 16x16 pixels groot.... Dus zal het hele beeld opgebouwd moeten zijn uit blokjes van 16x16. Met een modernere codec kun je als je erg goed en nauwkeurig kijkt ontdekken dat in de blokjes van 16x16 pixels weer blokjes zitten van 4x4 pixels. Het rijtje voor 16:9 is: 256 x 144 512 x 288 768 x 432 1024 x 576 1280 x 720 1536 x 864 1792 x 1008 2048 x 1152 2304 x 1296 2560 x 1440 2816 x 1584 3072 x 1728 Het rijtje voor 16:10 is: 128 x 80 256 x 160 384 x 240 512 x 320 640 x 400 768 x 480 896 x 560 1024 x 640 1152 x 720 1280 x 800 1408 x 880 1536 x 960 1664 x 1040 1792 x 1120 1920 x 1200 2048 x 1280 2176 x 1360 2304 x 1440 2432 x 1520 2560 x 1600 2688 x 1680 2816 x 1760 2944 x 1840 3072 x 1920 Ik denk dat je er goed aan doet om de resolutie 1024x576 aan te houden als eindformaat. Dat is gewone PAL 16:9 met de verticale resolutie van een dvd en de horizontale resolutie van square-pixel PAL 16:9, evt omzetten naar dvd zal dan ook geen probleem geven en mooie kwaliteit opleveren en de resolutie is iets hoger dan wat je hebt dus zal kwaliteitsverlies door verschalen tot een minimum beperkt blijven(iig niet zichtbaar) De vraag wordt dan natuurlijk , hoe? Ik zou je werkwijze aanpassen door na het capturen als eerste de video te verschalen en plakken/knippen naar je eindformaat, je kunt dan op de video huff-yuv codering toepassen wat de grootte aanzienlijk beperkt maar wel de volle kwaliteit houd en zo kun je comfortabel en met behoud van kwaliteit de video dan verder bewerken in AP of een ander programma. Je zult daarvoor de video moeten verschalen in Virtualdub blijf capturen in je 1/2 scherm resolutie van 840x525. Open de video in virtualdub en ga: video/filters: add- resize invullen; width:921.6 (let op; een punt en geen komma) Height:576 mode:precise bicubic (A=0.60) expand frame and letterbox width: 1024 height: 576 Je krijgt zo een gangbare video met aan de zijkant twee zwarte balken wat miz altijd beter is dan er wat vanaf hakken(=verlies van inhoud) Wil je toch hakken dan moet je het volgende doen; Resize filter: widht: 1024 height: 576 Bicubic (A=0.60) Na het instellen van het filter klik je in de filterbox op "cropping" en stel je de Y1 en Y2 offset op 26 pixels, klik op OK, het resize filter zou dan moeten vermelden: 840x473 1024x576 [Precise bicubic [A=0.60]] Klik weer op ok en dan de compressie instellen. Kies de Huffyuv v2.11 codec en stel in: YUY2 compressian: predict median[best] RGB compression: <-- Convert to YUY2 De RGB video die virtualdub aan de codec levert wordt zo eerst omgezet door de codec naar YUY2 kleuren en vervolgens door huff in yuy2 mode gecodeert, dit levert de hoogste compressie op. Als deze video niet door premiere wordt gegeten kun je in de codec een vinkje zetten bij "always suggest RGB format for output" Als dat niet werkt zul je de RGB compression method moeten veranderen naar "predict gradient [best], dit gaat helaas ten koste van de compressie ratio en dus zal je video groter worden maar daar is helaas niets aan te doen In volledige YUY2 mode kan de huff codec een ratio bereiken van 4.5:1 en in RGB mode een ratio van 2.5:1 Er zijn uitzonderingsgevallen waarbij de huffyuv codec niet goed werkt en het bestand zelfs groter kan worden dan ongecomprimeerde rgb; videobeelden waarbij geen verandering is in beeld tussen de frames onderling (zogeheten null-frames)-bv een opname van je bureaublad terwijl je niets doet) leveren typisch een avi op die groter is dan het origineel. het lijkt me duidelijk dat in dergelijke gevallen je de codec niet moet gebruiken, je kunt dan overstappen op de Lagarith codec die hiervoor speciaal is geoptimaliseerd en dergelijke video juist enorm kan comprimeren( 24 uur video van een statisch bureaublad in 1 MB!) Als de YUY2 mode werkt in premiere en je helemaal kwaliteit-bonanza wilt gaan kun je de RGB naar YUY2 omzetting niet door de codec laten doen maar door Vdub zelf, dit levert nog iets hogere compressie op en minder kleur-conversie fouten maar voor het verschil moet je wel paranoia op kwaliteit zijn :wink: : Ga in Vdub naar video/color depth en stel de decompression op "autoselect" en de "output format to compressor/display" op 4:2:2 YCbCr [YUY2] Dan als allerlaatste kun je nog het volgende overwegen: je tft scherm heeft welliswaar een "native" resolutie van 1680x1050 maar je bent niet verplicht in deze resolutie te werken. Je zou je videokaart driver natuurlijk ook meteen in 1024x576 kunnen zetten, dat scheelt een hoop werk. Uiteraard is de weergave op je scherm dan hopeloos onscherp en lelijk en klopt de apect ratio niet helemaal maar daar heeft de gecapturede video geen last van (!), die is in een perfect kloppende 1024x576. Bijkomend voordeel is dat je game/aplicatie soepeler loopt en je capture programma de resolutie niet "on-the-fly" moet halveren maar zo de ruwe pixeldata uit de videobuffer op de harde schijf kan gooien; levert veel hogere kwaliteit op en nog minder systeem belasting waardoor je wellicht zelfs direct kunt capturen met HUFF-yuv compressie. Je hebt dan in 1 keer een video op de goede resolutie, van de absoluut hoogst haalbare kwaliteit in een bescheiden dataomvang. Als direct capturen met huffyuv compressie toch teveel cpu belasting geeft en je hebt een multicore cpu kan dat komen omdat huffyuv niet multicore geoptimaliseerd is, je kunt dan nog de Lagarith codec overwegen . De Lagarith codec is een voortborduursel op de hufyuv codec en is wel multicore geoptimaliseerd maar dan weer helaas niet zo snel als huffyuv. Het voordeel van multicore precessing kan opwegen tegen de wat minder snelheid van de codec of niet, is een kwestie van proberen.... Uiteindelijk is de compressie van Lagarith wel beter dan huffyuv met zo'n 25%. Op een singlecore systeem is de lagarith codec absoluut trager en niet aan te raden. Lagarith: http://lags.leetcode.net/codec.html Je loopt dan waarschijnlijk tegen het probleem aan dat deze resolutie niet voorkomt in het rijtje van kiesbare formaten van je videokaart driver maar er zijn tooltjes voor die de resolutie kunnen toevoegen aan het rijtje waardoor je hem wel kan kiezen.(check het videokaarten forum en vraag naar zo'n tooltje) Eea gebeurt dan "op eigen risico" maar dat risico is verwaarloosbaar aangezien windows in eerste instantie bij het kiezen van een nieuwe resolutie altijd zegt "wilt u de instellingen behouden?- terugzetten in 10-9-8-7-enz seconden" Mocht bij het kiezen van deze "rare" resolutie je scherm op zwart gaan dan hoef je dus alleen maar te wachten tot 10 en je scherm keert weer terug in de oude werkende resolutie en kun je dus concluderen dat deze methode helaas niet gaat werken. Als de rek er wat betreft CPU belasting in je systeem voor aanwezig is zou je hetzelfde verhaal kunnen proberen maar dan in de HDTV resolutie 720p, dat is 1280x720 Als het even meezit heeft je monitor een speciale ingebouwde stand voor deze resolutie om deze toch goed en zonder rafels weer te geven. Het zou me niets verbazen als dit lukt want de resolutie halvering van fraps die je nu gebruikt is (waarschijnlijk)een bilinear resize filter welke behoorlijk wat cpu last veroorzaakt. Dat filter hoeft dan niet meer gebruikt te worden waardoor er cpu tijd vrijkomt die je dan kunt gebruiken voor de huffyuv compressie. Denk er wel om dat met dergelijke resoluties je verwerkingstijd in premiere aanzienlijk omhoog gaat en als je uiteindelijke doel een dvd of youtube is dan heeft het geen zin, je uitvoer zal naar HD-wmv/divx/xvid/bluray oid moeten zijn.

[anoniem]

Bedankt voor de uitleg:). Exporten naar het eerder voorgestelde formaat lukte overigens en dan krijg je (met premiere cs3) automatisch meteen zwarte balke aan de zijkant. Wil echter af van die zwarte balken dus denk toch dat ik er een stukje laat afschaven;). Ik zou evt ook het spel in kunnen stellen op 1600x900 maar dan moet ik weer opnieuw capturen (wat voor dit item niet meer kan). Xvid zal toch de codec blijven omdat dit 1 van de weinig codecs is (in mijn ervaring) met goede beeldkwaliteit terwijl de size nog aanvaardbaar blijft.

[anoniem]

Als ik vanuit premiere wil exporten naar een random format met als enig doel materiaal aanleven voor virtual dub. Wat is dan de beste optie? Ik ben dan vooral opzoek naar snelle settings zonder kwaliteitsverlies omdat xvid er daarna overheengaat.

[anoniem]

HUFF-YUV is verliesvrij en 1 van de snelste codecs die ik ken en heeft voor een verliesvrije codec nog een heel behoorlijke compressieratio, het is een soort van winzip voor video. Je stelt de codec dan als volgt in: YUY2 compressian: predict median[best] RGB compression: <-- Convert to YUY2 Ik weet niet wat je na premiere nog in vdub wilt doen aan bewerking maar kun je dat niet meteen in premiere doen en gelijk exporteren naar xvid? , scheelt je een bewerkingsgang en tijd.

[anoniem]

Xvid werkt niet zo lekker samen met adobe premiere. Dat venstertje is gebugged en fuctioneerd niet (het status venstertje). Doe verder geen bewerkingen. Ik had nu ff uncompressed, 8bit rbg gedaan en dat is ong 1 gb per minuut en duurt slechts 2 minuten om te exporten. Daarna minuut of 3 recoden dmv virtual dub dus het viel wel mee. Overigens was het slechts een kort filmpje (2min);). Ik ga die huf wel even proberen dan:P. thanks.