Ga naar inhoud

Capturen video--> bewerking film --> omzetten naar VCD


Aanbevolen berichten

Ik heb nu al een aantal films omgezet naar VCD. Echter ik zit met een probleem. Wanneer ik een videoband(hi8 bandje) wil importeren (naar AVI)dan gebruik ik meestal PICVIDEO(als codec) Aangezien ik met Windows 98 werk heb ik dus de beperking van 2Gb. Nu kan ik ook meteen capturen naar DivX. Maar wanneer ik uiteindelijk de bewuste AVI heb en deze wil bewerken met Virtual Dub(filters, knippen, logootje) dan moet ik dit opnieuw weer saven/omzetten naar AVI. Bij DivX heb ik dan een probleem want waar stel ik dan de bitrate op in(Low motion codec) Daarna zet ik het om met TEMPEnc wat geen problemen opleverd. Mijn vraag is nu? Met welke compressie moet ik werken in Virtual dub als ik DIVX als bronmateriaal heb, en welke als dit PICVIDEO is? Welke van de twee is beter?
Link naar reactie
Je benadert het probleem van de verkeerde kant. omdat windows98 niet groter dan 2 GB aankan ga je capturen in divx of mjpeg op lage kwaliteit/bitrate zodat je files niet groter dan 2 GB worden, je laat zo heel veel kwaliteit liggen...... Divx is al per definitie niet zo'n best formaat om in te capturen vanwege het feit dat niet iedere frame een keyframe is, knippen en plakken wordt zo al weer moeilijk, tevens is de systeem belasting van divx capture veel hoger dan die van mjpeg en dus kan je ook daar problemen krijgen. Gebruik in ieder geval mjpeg, dan maar op een lagere kwaliteit zodat je binnen de 2 GB blijft. beter: Je moet zien te capturen in een zo hoog mogelijke kwaliteit(mjpeg of huffyuv) en dat levert welliswaar grote files op maar daar is een oplossing voor, tenzij je ook schijfruimte te kort hebt..... Je zal in virtualdub moeten capturen mbv de "segmented capture" mogelijkheid die in vdub zit. Je doet dit op de volgende manier: ga naar File/set capture file en kies een naam en plaats voor je capture file, doe dit bij voorkeur in de root van je 2e harde schijf of partitie dus bv.: D:capture.avi. ga dan naar; capture/capture drives... , klik op "add spill drive" , klik op de lege plaats onder "path" en je kunt dan daar de locatie van je capture file intypen, zoals in dit voorbeeld dus; D: Klik dan op; capture/enable multisegment capture. Het instellen van segmented capture is daarmee klaar en zal er voor zorgen dat tijdens capture de avi automatisch en naadloos wordt opgedeeld in brokken van 2 GB je zult alleen nog de verdere zaken zoals resolutie,kleurformaat enz enz moeten instellen maar dat moet geen probleeem opleveren, neem ik aan. De segmenten kan je daarna openen in virtualdub door het eerste segment te openen, virtualdub zal automatisch herkennen dat er meer segmenten zijn en deze er automatisch aan plakken. hierna komt de truuk van het opnieuw saven en/of toevoeren aan TMPGenc. saven doe je met file/save segmented avi en dit betekent natuurlijk hercompressie plus weer een film verdeelt in brokken van 2 GB, hier heb je dus niet veel aan. Je kunt beter de avi rechtstreeks toevoeren aan tmpgenc zonder hem eerst op te slaan, maw. de uitvoer van vdub rechtstreeks koppelen aan de invoer van tmpgenc. Je kunt dit doen door vdub in "frameserver" mode te zetten. Open het vdub config scherm "auxsetup.exe" en klik op; install handler. Open daarna je avi in vdub, doe al handelingen,filters enz enz en ga daarna naar ; file/start frame server, klik daarna op start waarna er een "save" box opent , save je avi met een nieuwe naam+ de extentie VDR ,dus bv capture.vdr De avi wordt nu ge-frameserved naar het bestand capture.vdr, als een andere aplicatie dit bestand opent dan is het alsof je gewoon de voledige avi opent. Je kunt nu vdub minimaliseren(niet sluiten!) en TMPGenc openen, open vervolgens de vdr file in TMPGenc en codeer op de normale wijze naar vcd met 1 toevoeging: je zult in TMPGenc de totale lengte van de avi moeten opgeven (aantal frames)zodat tmpgenc aan het einde van de avi zal stoppen met coderen,de frameserver blijft immers door serven ook als er nix meer is door te geven is, als je tmpgenc dus geen lengte opgeeft om te coderen zal ie aan het einde van de avi gewoon doorgaan met het coderen maar dan met zwarte frames zonder inhoud. Dus: geef in tmpgenc de lengte van je avi op: setting/advanced/source range(vinkje zetten en erop dubbelklikken), zet de start-frame op 0 (invullen)en zet de end-frame op het aantal frames-1(invullen), probeer niet te scrollen met de tijdlijn of te klikken op "move to end frame of move to start frame,dat gaat niet!,gewoon de waardes invullen en daarna op ok klikken. Voor een avi van 1000 frames vul je dus als end-frame 999 in. Als je nu tmpg laat encoden zal de avi vanuit vdub rechtstreeks worden door gestuurd naar tmpgenc. Je wilt perfecte kwaliteit vcd/svcd? , dit is de manier...... [ Dit Bericht is bewerkt door: rwilligen op 2002-03-07 20:03 ]
Link naar reactie
Richard, Ik heb de captureprocedure (zowel met mjpeg als huffyuv) verricht.Dus ook de "segmented capture"(add spill drive en multisegment capture) Maar Virtual dub doet helemaal niets(zandlopertje blijft in beeld maar er wordt niets gecaptured) Ik moet met ctrl+ALt+del dit scherm verwijderen. Wanneer ik de segmented capture niet uitvoer dan wordt er wel netjes gecaptured. Ik doe dus iets verkeerd. Op mijn E-partitie wil ik uiteindelijk de AVI-file hebben Dus ik kies file/set capture. E:film.avi Daarna kies ik natuurlijk de compressie(audio en video(mjpeg of huffyuv)) vervolgens add spill drive(klik onder path en vul daar in e:film.avi) Vervolgens aanklikken enable multisegment capture. Naar mijn mening doe ik dit goed of....
Link naar reactie
Eh nee , ik denk niet helemaal... Je vult als path bij de spildrive in E:film.avi en dit is niet correct, mogelijk veroorzaakt dit het probleem. Je moetbij path invullen E: Immers : de naam heb je al gegeven onder "set capture file" Normaal gesproken zou vdub bij een dergelijke pad fout een error geven "capture file not found"maarwellicht kan het programma ook wel gaan hangen, gebruik je een recente versie van vdub ? (1.4.8 ofzo). tevens : capture je wel met F6 ? ----> voor het gebruiken van segmented mode kan je alleen capturen met F6(capture/capture video F6)de andere capture mode F5 (capture/capture video(compatability mode) F5) is niet bruikbaar bij segmented capture. Je zit er niet ver vanaf, nog ff doorzetten.... Een kleine tip ; wat ik ALTIJD doe als ik iets nieuws ga proberen op video gebied is het systematisch werken in stapjes, 1 ding tegelijk en als uitgangs punt altijd iets doen waarvan ik zeker weet dat het goed werkt. Dus capture tests doe ik altijd op een zo klein mogelijke resolutie(bv 160x120 oid.) met 24 bit RGB kleur en een codec waarvan ik weet dat ie bij mij goed werkt (bv huffyuv,pic video of indeo 5 en voor de audio PCM/cd kwaliteit), zo weet ik zeker dat een evt probleem niet daar zit. Als alles dan goed werkt verhoog ik de diverse waardes naar datgene wat ik wil doen maar wederom weer 1 stap tegelijk, dus eerst de resolutie verhogen, testen, dan de codec veranderen,testen, evt filters toevoegen, testen. Het lijkt een hoop werk maar als je er ff voor gaat zitten dan lukt het me meestal zo wel in een uurtje ofzo. Laatste tip: als je de juiste instellingen hebt gevonden : opschrijven, de test avi's verwijderen, even defragmenteren en rebooten voordat je de echte capture gaat beginnen.
Link naar reactie
Richard, Je hebt gelijk. De instelling moet inderdaad zijn E: Stom van me! Ik heb jou een mailtje gestuurd(hotmail)met daarop de instellingen die ik kan kiezen met mijn Matrox Marvel G450 E-TV kaart Ik kan capture nu in 353x288 in YuY2 setting. Of is het slim on RGB setting te capturen. Ik heb daar eigenlijk niet zoveel verstand van. En in wat voor formaat kan ik het beste capturen? Wat lijkt jou het meest geschikte?
Link naar reactie
kopie van email aan jouw: Hoi Rene, Uiteraard kan jij ook capturen in rgb formaat. Of het voordelen geeft?, weet ik niet, jij hebt een matrox kaart en ik heb daarmee geen ervaring. Bij een wintv (BT848) kaart werkt het als volgt : de data wordt door de tv kaart in YUY2 gemaakt en blijft zo, als je RGB 24 kiest dan wordt deze door de tv kaart software matig gemaakt uit de YUY2 data. De eventuele winst in kleur-diepte is dus min of meer bedrog want wat er niet is kan je ook niet (software matig) maken... Of dat ook bij een matrox kaart zo is? ik weet het niet... Wat is dan het voordeel? , nou je avi is in RGB24 en alle codec's die er bestaan gaan correct , zonder problemen, met deze avi's om. Rare problemen zoals het op z'n kop staan van het beeld (gebeurt wel eens met bv een yuy2 avi coderen naar mpeg1/2) zal je met een RGB avi nooit krijgen. Voor het testen met codec's, programma's,encoders enz is het dus handig om eigenlijk altijd een stukje ongecomprimeerde RGB24 video op je harde schijf te hebben staan, het liefst van een hoge resolutie/kwaliteit. Wat is dan het voordeel van YUY2? , nou het is een kleurformaat wat minder data gebruikt dan RGB24(scheelt ongeveer 1/3) en daardoor zul je makkelijker kunnen capturen. Tevens werkt een codec als de huffyuv veel sneller met yuy2 data als met rgb en dus zal dat ook minder van je cpu vragen en kleinere files opleveren. Het nadeel van YUY2?, het kan theoretisch minder kleurinformatie bevatten dan RGB24 en heeft bij veelvuldig hercomprimeren de neiging uitgelopen kleuren te krijgen, bij bv. een rood en blauw vlak naast elkaar zal het rood wat gaan overlopen in het blauw met als resultaat een paarse rand in het midden, de scherpte van het beeld heeft er dus wat onder te lijden. Verder is het zo dat iedere video editter werkt in RGB24, als je dus een yuy2 video opent in vdub dan zet deze de video dus eerst om in rgb (full-proccesing mode) en pas daarna gaat ie met de video aan de gang, bij het saven wordt vervolgens de rgb data weer terug gezet in YUY2 en dat is nou juist wat het kleur verloop en verlies veroorzaakt. Dat is de theorie..... in de praktijk: als je maar niet je YUY2-video 2 of 3 x in vdub opent en weer saved met hercompressie dan is er nix aan de hand.... Als je tijdens het capturen in vdub op RGB24 ziet dat de cpu belasting gevaarlijk dicht bij de 90% komt: stap over op YUY2 en je zult zien dat je minder systeem belasting krijgt, als het in RGB allemaal prima gaat: houden zo! Voor het testen zou je dus kunnen kiezen: RGB24 met 1/8 resolutie of QCIF (CIF = 352x288, QCIF=quarter-cif= 176x144)(cif= Common Intermediate Format=zijn 2 formaten speciaal ontwikkeld voor video conferencing en vcd uiteraard, in principe moet iedere codec kunnen werken op QCIF) De keuze tussen rgb en yuy formaten (evenals compressie formaten) is er 1 die met het steeds sneller worden van systemen vanzelf makkelijker wordt : over 2 jaar hebben we allemaal een 10 GHZ systeem met 500 GB harddisk en kunnen we gewoon capturen in ongecomprimeerde rgb met dvd resolutie...... Gr Richard Aanvullend : als je wilt coderen naar vcd is het beste(eenvoudigste)om te capturen in 352x288 (CIF format), voor het coderen naar svcd capture je in 704x576 en geeft in tmpgenc in de wizzard op dat dit je bron formaat is, als het goed is zal tmpg de mpeg voorzien van het juiste pel aspect en correct resizen naar 480x576. Een dvd player(hard of software)zal als het goed is de video in het correcte formaat (4:3)laten zien [ Dit Bericht is bewerkt door: rwilligen op 2002-03-09 00:40 ]
Link naar reactie
(Kopie van E-mail bericht naar Richard) 13 GByte groot is nu mijn AVI bestand na capturing mbv MJPEG compressie(PICVIDEO) instelling 19 Ja, je leest het goed! 13 Gigabyte groot is mijn film geworden(dit is 45 minuten speeltijd) Ik schrok me rot. De limietbeperking van 2 GByte is nu geen probleem meer. Ik heb gecaptured met MJPEG(PICVIDEO instelling 19 of is dat te hoog??????) 704 x 576(PAL) is de resolutie instelling. Mijn CPU belasting was tijdens capturen steeds maximaal onder de 80%. Maar toen het capturen klaar was stond er bij CPU usage(in Virtual Dub) 100%. Ik vind de uiteindelijke AVI file wel heel erg groot. Op het einde van het capturen kreeg ik ook een foutmelding(ongeldige bewerking) rood rondje met wit kruis. Hij gaf aan iets van MMTASK (in detail stond er MMtask en kernell32.dll) Ik denk dat ik m'n PC iets te zwaar heb belast. Ik heb een AMD 1 Ghz (Asus A7 K133 bord) met 384Mb Ram geheugen. (twee harddisk : een is 40 Gbyte 7200rpm de andere is 8 Gbyte 5200 rpm) Het einde van de film kan ik echter in de segmenten niet terug vinden. Het laatste stukje van de film is dus niet gecaptured. Oh Ja ik kan niet capturen met huffuv compressie. Dit vindt mijn systeem niet zo leuk. Ik krijg meteen een ongeldige bewerking. En kan m'n systeem meteen hardwarematig uitzetten. Trouwens met MJPEG compressie instelling 19, doet die dat dus ook, alleen gebeurd dit op het einde van capturen. Moet ik misschien instelling 18 nemen. Welke instelling gebruik jij??? Ik heb het idee dat m'n systeem het niet prettig vind wat ik nu dus doe!! Heb je nog suggesties voor de late zaterdagavond! Groeten René
Link naar reactie
Kopie e-mail aan rene, Hoi Rene, 13 Gb is nix, ik maak avi's van 75 GB, welkom in videoland....... :smile: Als je de ruimte ervoor hebt is het ook alleen maar een tijdelijk probleem, immers: na de capture zet je de grote avi om in vcd of divx oid en daarna kan je de grote avi weggooien. Om je een idee van grote te geven: een dv camera met firewire maakt voor iedere 9 minuten 2 GB aan en hier is nix aan in te stellen, dat staat dus gewoon vast. dat ie crasht aan het einde van de avi is wat minder maar denk ik geen probleem van een te hoge belasting, doet ie het wel goed bij bv 30 ,20 of 10minuten capture? -----> dan is de belasting kennelijk niet te hoog...... Mogelijk gaat vdub in de fout of (waarschijnlijker) de capture driver. Een ander probleem kan warmte ontwikkeling zijn, wordt je pc niet te warm? , je kan dit testen door gebruik te maken van de test-capture optie in vdub ( capture/test video capture (internal)), vdub doet dan of ie aan het capturen is maar schrijft de avi niet weg,je simuleert dus zo de capture zonder dat je harde schijf volloopt. Je zou bij wijze van test de zijwand van je kast kunnen halen, fannetje er voor zetten en weer proberen en kijken of het dan wel goed gaat. vergis je niet in de warmte ontwikkeling tijdens capture; de pc loopt op nagenoeg vollast en moet dit vele tientallen minuten vol zien te houden, zelfs bij het spelen van games gebeurt dit zelden continu langer dan 30 minuten, daarna neem jij ( en je pc) meestal een rust pauze. als virtualdub of de capture driver in de fout gaat dan is hier weinig aan te doen, een update kan het verhelpen maar als die er (nog) niet is komt het dus neer op de wetenschap dat je gewoon niet meer dan 30 minuten continu kan capturen, is goed mee te leven dacht ik zo...... Een lagere instelling in Picvideo zal er ook weinig aan veranderen denk ik alhoewel je met 80% aardig in de buurt komt van de "gevaarlijke" zone waarbij je dropped frames gaat krijgen, een verlaging naar bv 18 kan dus geen kwaad en het verschil in kwaliteit is niet erg veel. Capture je nu in rgb of in yuy2? als je captured in rgb zou je yuy2 kunnen proberen, de kwaliteit is daarmee dus wel ietsje lager maar als het goed is de cpu belasting veel lager waardoor je in picvideo toch met stand 19 of zelfs stand 20 kan werken en de uiteindelijke kwaliteit toch weer hoger is. ik werk bijna altijd op stand 20, yuy2 kleur of met huffyuv in yuy2, de rgb modes hebben bij mij geen zin omdat de wintv kaart in eerste instantie toch altijd werkt in yuy2 mode. Verder gebruik ik deze capture alleen voor tv uitzendingen en dus moet ik meestal toch wel een lagere waarde in pic kiezen omdat anders mijn 80 Gb schijf volloopt. voor het capturen van camera gebruik ik mijn DC10+ en hier is weinig aan in te stellen, je kiest een datarate en 1 van de 2 resoluties en that's it. Het niet kunnen capturen met huffyuv is een incompatabiliteit tussen de capture driver en huffyuv,of het een gemis is? je vind 13 GB al groot, met huffyuv worden de avi's een factor 2 groter..... je kunt proberen om de capture-kleurinstelling te veranderen naar yuy2 en in de codec een vinkje te ztten bij " always suggest RGB format for output", als dit ook niet helpt dan is het helaas pindakaas.... Frameserven: veel mensen snappen het principe maar niet daarom zal ik het nog een keer uitleggen. Bij frameserven wordt de uitvoer-module van het ene programma verbonden met de invoer-module van het andere programma. Dit verbinden gebeurt dmv. het server-bestand in het geval van vdub is dat dus het *.vdr bestand. het vdr bestand zelf bevat geen data maar is een soort doorgeef-luikje dat de data uit vdub haalt en doorgeeft aan tmpgenc. Dat doorgeven gebeurt op aanvraag/levering-per frame-basis, dwz: iedere keer als tmpgenc 1 frame nodig heeft zal vdub hem leveren, Zie het dus als internetten; als jij(tmpgenc) contact maakt met een server(vdub) en vraagt om een document(avi-frame) dan zal de server(vdub) deze naar jouw(tmpgenc) versturen. het daadwerkelijke frameserven begint dus pas op het moment dat jij op "start" drukt in tmpgenc,pas dan zal hij beginnen met het vragen om frames en pas dan zal vdub de frames gaan 'frameserven" aan tmpgenc en hij doet dit dus frame voor frame totdat hij ze allemaal heeft gehad 1 lastig probleem met frameserven is dus dat je tijdens de configuratie van tmpgenc niet alvast kan kijken hoe het eruit gaat zien, alle preview-opties die er zijn moet je dus NIET gebruiken, immers: voor een preview heeft tmpgenc frames nodig en in plaats van dat ie er zelf naartoe kan lopen en ze laten zien moet ie eerst aan vdub vragen of ie de desbetreffende frame kan krijgen. Als jij dus in tmpgenc met de range optie de lengte van de avi aangeeft (-1 frame)op bv 175065 en klikt op "move to end frame" dan zal zoals in het vb. hieronder tmpgenc aan vdub vragen om frameno : 175065, vdub kan echter niet in 1 keer daarnaar toe gaan; hij zal ALLE frames aflopen en serven aan tmpgenc totdat ie bij frame no: 175065 is en pas dan stoppen. In dit voorbeeld geval betekent dat dus dat ie 175065 frames oftwel 116 minuten video moet "doorspoelen" voordat ie bij de desbetreffende frame is, als je dan ook weet dat frame serven niet zo heel snel gaat dan komt het er dus op neer dat je in dit geval 2 uur moet wachten voordat ie een preview van frame 175065 kan laten zien. In de praktijk betekent dit dat het LIJKT alsog tmpgenc vastloopt(crasht) maar dit is dus niet zo. Als je dus wilt gaan werken met de frameserver raad ik je aan om het eerst uit te proberen met een heel klein stukje video (zeg 3 minuten oid.), je zal dus ff met vdub een klein stukje van je avi moeten afknippen en saven en daarna frameserven aan tmpgenc om mee te proberen. het frameserven van een avi naar vcd mbv. vdub en tmpgenc zal iets langer duren dan het omzetten van een gewone avi naar vcd, je wint echter de stap van het saven van je avi in vdub en aangezien dit ook wel enige uren kan duren is de totale winst in tijd aanzienlijk en daarbij heb je het kwaliteits voordeel dat je de avi niet opnieuw vanuit vdub saved met hercompressie Theoretisch zou je dus met ieder programma de *.vdr moeten kunnen openen en de avi moeten kunnen bewerken/openen/afspelen, helaas is dit niet zo,bv. mediaplayer verdomt het, panasonic encoder doet het weer wel, windows mediaencoder doet het weer niet, real-encoder doet het wel..... Gr Richard
Link naar reactie
Nu jullie toch zo diep in gaan op capturen heb ik ook 'n vraagje. Ik ben als beginneling al 'n tijdje aan 't capturen met een pinnacle pctv pro kaart. Meestal gebruik ik virtualdub voor het capturen. Nou heb ik bij het capturen altijd 'last' van ongeveer 1 dropped frame per 10 minuten video, de cpu belasting komt er nooit boven zo'n 65% en is meestal een stuk lager. Nu is die dropped frame niet zo erg, maar mijn vraag is of dit normaal is. Of ligt dit aan de software (misschien in combinatie met)of hardware. Ik heb ook andere capture-software gebruikt, maar ik krijg toch minimaal 1 dropped frame per 10 min. Ik heb op dit moment 256 mb geheugen, is dit misschien te weinig? Groetjes Marcel
Link naar reactie
helemaal perfect is het niet maar het is wel heeeeel weinig. de oorzaak kan overal zitten. allereerst kan de capture driver een ingebouwd mechanisme hebben dat voorkomt dat audio en video uit sync raken, de driver doet dit door op het gewenste moment 1 of meerdere frames te droppen, ik weet dat sinds de "ontdekking" van deze methode bij pinnacle ze hem bij bijna alle capture kaarten toepassen die een gescheiden audio en video input hebben. het is niet uit te schakelen en sowiezo; zou je dat wel willen? want audio/video de-sync is heel wat vervelender dan 1 lost frame op de zoveel duizend. Ontdekken is overigens een verkeerd woord: ze hebben het idee gestolen/gekocht van Marcus Zing de maker van de uitstekende capture-util "AVI-I_O" Dan kan er nog een actie in je systeem voorkomen die op regelmatige basis terugkomt die even het hele systeem of een deel dat nodig is voor de capture voor zichzelf wil hebben, het thermisch calibreren van de harde schijf is zo'n actie. Door het opwarmen v/d schijf zal deze naar verloop van tijd een calibratie uitvoeren waardoor hij even geen data kan wegschrijven, als je HD dan ook nog een wat kleinere databuffer heeft dan verlies je 1 of meerdere frames afhankelijk van hoe lang de calibratie duurt, hoe groot je buffer is die dit moet opvangen en hoe groot de afzonderlijke videoframes zijn. Bij een datarate van 3 MB/sec en een buffer van 512 KB(goedkope of wat oudere schijf) mag de schijf 0,16 seconde stoppen met schrijven alvorens de buffer leeg is en er frames gaan vallen, bij een buffer van 2 MB (is op dit moment bij de meeste nieuwe schijven de standaart)is dit al 0.6 seconde en is de kans op lost frames dus al veel minder. Je zou dit kunnen voorkomen door je systeem geruime tijd te laten "opwarmen" voor je begint met capturen. verder kunnen zaken als virusscanners en firewalls en andere achtergrond programmas ook roet in het eten gooien, voor het capturen moet je deze dus uitzetten/disablen via ctrl+alt+del
Link naar reactie

Om een reactie te plaatsen, moet je eerst inloggen

Gast
Reageer op dit topic

×   Geplakt als verrijkte tekst.   Herstel opmaak

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

  • Populaire leden

    Er is nog niemand die deze week reputatie heeft ontvangen.

  • Leden

    Geen leden om te tonen

×
×
  • Nieuwe aanmaken...