VirtualDubb

Hur får man TMPGEnc Plus 2,5 att spara i Mpeg4/DivX/Xvid format? Eller kör du nå´t annat Auhtoring prog?

Jag har följande video codec:ar installerade: DivX 3.2 Fast MPEG-4 DivX 3.2 Low MPEG-4 DivX 5 Pro DivX 4.12 FFDshow PICVideo Lossless JPG PICVideo MJPEG PICVideo Wavelet 2000 Xvid MPEG-4

mfl.

Reply to
Dataspider
Loading thread data ...

hmm. du har ungefär samma uppsättning codec som jag numera :-)

jag använder inte TMPGenc alls om jag just inte skall göra en DVD-skiva med Mpeg2-ström.

Jag använder Virtual dub att skapa Mpeg4/DivX/Xdiv-filer som simpla datafiler genom att selektera rätt kompression under meny 'video' och därefter 'save as' - glöm inte att ställa in för komprimera ljudet med lame eller anna codec under 'audio' etc. innan.

- där kan du också justera tiden mellan bild och ljud om läppsynken inte är bra, vilket tyvär händer allt för ofta i Boxerutsändningarna (men aldrigt i dom analoga utsändningarna...)

Jag kör dessutom 2-pass på videon genom att spara två gånger med med ändring i videocompressionens inställning mellan första och andra 'save as'.

I 'save as' så har du en lite ruta du kan bocka för att senarelägga tugget och på så sätt klippa ur reklam, spara flera olika delar från samma råfil vid samma tillfälle och sedan låta det tugga över natten utan att man behöver stå och vakta det hela.

i varje 'save as' med batch ibockad så spars alla inställningar i avseende valda filter och kompressioner för just det fallet, så man kan ändra, spara, klippa ut, spara etc. och därefter köra batch med 'job controll'

/TE

Reply to
Torbjörn Ekström

det betyder att delar av Intervideo trots allt startar i bakgrunden och låser upp captureenheten, och när du trycker på ikonen så starta appikationen blixtnabbt - tror du, men i själva verket bara gör sig synlig på skärmen.

det är många program i windows som 'tjuvstartar' i delar för att sedan upplevas som snabbstartande av användaren - här avslöjades genom att programmet låste videocapture-enheten så att virtual dub inte kan använda det...

/TE

Reply to
Torbjörn Ekström

Testade 700 meg från fysisk 80 GB till fysisk 160 GB tog prick 2 min. Testade 700 meg från fysisk 160 GB till fysisk 80 GB tog prick 2 min. Bägge gångerna pendlade CPU 5-10% Ljudet försvinner i bruset från alla fläktar :-( Får väl börja leta efter read/write cachar

Reply to
Dataspider

Det får bli sysinternals om jag orkar i framtiden. Tittade som hastigast i processlistan men hittade inget konstigt att slå ihäl. Funkar ju med denna nödlösning.

Reply to
Dataspider

Miro ger 2738 kb/s ( video ) - 6144 kb/s Rextest ger 9142 kb/s Vad säger detta ? Att diskarna ( eller diskhanteringen ) är sega som Torbjörn antyder?

Reply to
Dataspider

Hmmm, ja dvs tvärtom. Jag har bockat i rutan "Disable Windows write buffering". Tar jag bort bocken så hänger datorn när jag startar capturing.

Reply to
Dataspider

ok, jag har också bockat då filskrivningsprioriteten blir helt galet med stora skrivblock ganska sällan om windows själva få styra detta, och sådant sabbar capturingen stenhårt.

att det hänger för dig kan bero på dålig drivrutin till capturekortet och tex en lång skriving till HD så kanske man har stackat på flertal interrupt på varandra från capturekortet (då diskkrivning har högre prioritet) - och är inte drivrutinen skriven för denna situation så kan man få sådana här lägen med fel som inget biter på utan kräver omstart

- HW-nära drivrutiner ligger på systemnivå och är utanför användarens och även OS:s kontroll då den är en del av OS:t

(Det är mer eller mindre standard att capturedrivrutiner är buggiga och ursla i funktion då dom förmodligen har satte en högnivåprogramerare på att klia HW, - för detta kräver en viss typ av lågnivåfolk med rätta 'ögonen' om detta skall bli bra nämligen)

/TE

Reply to
Torbjörn Ekström

dom flesta moderna diskar klarar > 30000 kb/s så något sitter mellan helt klart.

du har bara 10-20% av den teroetiskt möjliga hastigheten och förklarar varför det inte fungerar med Huffyuv, som vill ha runt 15 Mb/s.

Reply to
Torbjörn Ekström

tillägg: värdena låg runt 32 Mbyte/s när jag provade rextest på min dator, medan mirotest verka otillförlitligt och verkar slå i tak vid just 6144 Kb/s med ibland uppåt 32 Mbyte/s då och då...

misstänker att mirotest skrevs vid en period då > 10 Mb/s var en våt dröm...

/TE

Reply to
Torbjörn Ekström

Dual CPU-system då? Eller de nya dual core-sakerna som är på G?

Borde inte ett sådant system, som ju nu är på väg att bli tillgängligt för "vem som helst", kunna klara att köra systemprylarna på en processor/core och capture på den andra processorn/coren?

--
May all spammers die in horrible pains!
Wanna e-mail me? Well, peter_e is correct, but the rest is obviously bogus...
 Click to see the full signature
Reply to
Peter Emanuelsson

Nytt test:

Miro ger 2738 (video) - R/W 6144 kb/s Rextest ger R- 46 MB/s W- 44 MB/s

Testade 700 meg från fysisk 80 GB till fysisk 160 GB tog prick 25 sek. Testade 700 meg från fysisk 160 GB till fysisk 80 GB tog prick 25 sek. Bägge gångerna pendlade CPU 15-25% Ljudet försvinner i bruset från alla fläktar :-( Hittade "Enable write caching" :-)

BIOS - enable 32 bit to maximize the IDE HD transfer rate - OFF Vågar man ändra detta eller skruvar man upp HD:na så man får installera om allt? Typ som ändra LBA som kan sabba diskarna "on the fly"?

Nu skall jag börja om och testa capture igen.

Och nu är det söndag kväll och kan bara konstatera att man suttit framför datorn hela helgen utan att gå ut i det fina vädret. Tur att chefen för hushållet inte är hemma....

Reply to
Dataspider

jo säkert, om du kan övertyga OS:t som kör detta - för det är där största problemet finns.

windows är en general purpose OS som inte är riktigt bra på något (men heller inte riktigt dåligt även om det fins dom som hävdar det). Att bygga in realtidkärna står nog inte högst på dagordningen för MS även om det är just detta som behövs när man håller på med inspelning från analoga världen.

Istället så buffrar och komprimerar man i insamlingsenheterna om möjligt (se bara på externa USB-videocapturekort) så att man får tillräkligt slak gummisnodd mellan verkligheten och hur OS kan ta hand om eventen.

Och när det inte går så börja man bygga hårdvarustöd som DMA etc. då det är lättare att få till än att få MS att rucka sina OS och programdesign (eller snarar brist på denna på den här nivån)

- se på hårddiskar,ljud och högprestandaenheter som SCSI och Firewire. man ser det också som UART där man fick bygga in 8-16 bytes buffer för att OS inte kunde garanterat ta hand om datat inom tid etc. etc

så, även om HW ger möjlighet för väl så avancerade hantering och realtidsmöjlighteter, så kommer det att dröja länge innan dominerande OS kommer att stöda det rent generellt.

Har man bråttom så är nog linux den enda alternativet - då den redan idag håller på att fostras upp inom embeddedvärlden och idag verkar knappast finnas några andra alternativ än embedded windows inom vissa segment.

(bla. har virusrisken svalkat av viljan att använda embedded windows och CE för tex instrumentbruk - i allafall från kundsidan... både HP och R/S grinar illa när man tar upp detta samt tar upp kravet på att kunna få ut vektoriserat beskrivna screendumpar

- något som HP var väldigt bra på tills man började med windows och nu får man bara ut väldigt fula 640x480-bitmapdumpar trots att den mätmässiga upplösningen är mycket högre, samt att man tappar utritningsordningen. En HPGL-plott beskrev kurvan i Smith-diagrammet med sina 801 eller 1601 punkter vare sig den var frimärksstor eller A3-storlek samt att punkterna och upplösningen var där det behövdes - dvs i knorren i mitten och glesare där det var ointressant)

/TE

Reply to
Torbjörn Ekström

Bara ett litet klargörande, CE-kärnan har riktiga realtidsfunktioner vilket inte NT-kärnan har. Detta var egentligen grundförutsättningen för att Windows öht skulle kunna bli ett "Embedded-OS" till sådana tillämpningar.

I övrigt tillhandahåller CE ett väldigt litet urval av NT-kärnans funktioner och ungefär likadant är det om man tittar på API i usermode, väldigt många funktioner är starkt begränsade eller finns inte alls i Win32 eller .NET under CE. De flesta med textparametrar accepterar dessutom bara Unicode-text, under NT finns alltid en Unicode- och en ANSI-version och under 9x/ME endast ANSI. Dessa skillnader är väl några av orsakerna till att virushotet mot CE inte har varit särskilt stort egentligen, det är väl mest fel av typen JPEG-renderingsbuggen i GDI+ eller mailmaskproblematik som skulle kunna drabba CE-plattformen också, men oftast krävs det då att virusmakaren har tagit särskild hänsyn till CE.

--
Olof Lagerkvist           sm6xmk
ICQ: 724451                     @ssa.se
 Click to see the full signature
Reply to
Olof Lagerkvist

givetvis har mer 'främmande' arkitektur gentemot dom dominerande OS större chans att klara sig från angrepp (det är väl därför man ser så lite på Linux och windows CE -speciellt om det är på annan CPU-plattform som ARM.

i det avseende så är det väldigt likt bilologin :-)

Nu är det tyvär inte windows CE i mätinstrument utan någon variant av embedded NT4 eller W2k och med användningsområden där trovärdighet (dvs kalibrering) är den viktigaste parameter mot kund, så kopplar man inte in nätverkskabeln och kör windows uppdate en gång i veckan precis... nu har man hamnat i sådant läge att nästan man inte ens vågar koppla in nätverkskabeln bara för att skriva ut screenshot då en krachad mätinstrument ger mer än acceptabel avbräck i verksamheten om de skulle bli angripna då dessa är jäkligt dyra saker... (> halv miljon styck)

krasst sett så har Windows sårbarhet för angrepp gjort den omöjlig att ha som OS i kritiska tillämpningar som mätinstrument etc.

- speciellt av embedded typ där det aldrig görs några uppdateringar då hela certifieringssviten spricker samt att läget blir oklart mellan leverantör och brukare om det blir strul i samband med windows uppdate

- det handlar nämligen inte om det blir strul i samband med update utan 'när'... IMHO.

(några av leverantörerna har faktiskt erkänt 'off the record' att detta är ett problem, speciellt då inom högskola och universitetsmiljö där näten inte är så stängda som önskat...)

--
om jag skulle vara strateg hos HP, R&S etc. så skulle jag plocka ur 
windows som OS så fort det bara går inom instrumentparken - och kanske 
 Click to see the full signature
Reply to
Torbjörn Ekström

Ok, det är alltså Embedded-versionen av NT på vanlig Intel-plattform som används i instrumenten du talar om, det hade jag ingen koll på måste jag säga, jag hade fått uppfattningen av att det var CE just för att CE har realtidsfunktioner (och är rätt säker på att jag läst något om CE i mätinstrumenttillämpningar någonstans för ett tag sedan).

Kommer spontant att tänka på att Embedded NT 4 används i Föreningssparbankens uttagsautomater och i samband med att någon av applikationerna i den började äta väldigt mycket minne efter en uppdatering så började automaterna visa en dialogruta som talade om att man bör öka växlingsfilens storlek...

Det känns dock som att det borde gå att åtminstone undvika att sådana saker syns ut på skärmen om man har hela NTs funktionalitet att tillgå vilket man faktiskt har i Embedded NT. Man kan t ex skapa sessioner enligt Terminal Server-modell med separata inmatnings- och bildskärmsenheter till olika tillämpningar som körs vilket väl hade varit rätt smart att göra i en uttagsautomat... (Det hade inte gått att göra i CE.)

Det är i såna lägen man känner sig tvungen att avaktivera alla klient- och servertjänster i den inklusive att avaktivera NetBIOS helt och istället köra utskrifterna över lpd och på det sättet strypa Windows möjligheter att smitta ner sig med allt som cirkulerar där ute. Men jag misstänker att man måste göra det själv och att installationen från början är inställd med flera nätverksprotokoll, NetBIOS och en drös livsfarliga tjänster installerade och aktiverade?

Egentligen ser jag väl personligen inte att Windows i sig är problemet här. Jag kan mycket väl förstå att man vill skriva själva programmen i maskinerna för Windows i dagens läge med tanke på allt som finns tillgängligt för en Windows-programmerare när det gäller utvecklingsverktyg och bibliotek men som vanligt har man väl gjort felet att inte analysera/inte bry sig om vad slutanvändarna egentligen behöver och vill ha. Med tanke på att det finns Windows i många prylar i dag där man inte har en chans att upptäcka att det är just Windows under skalet så tycker jag inte det känns rimligt att Windows skulle vara en begränsande faktor för användargränssnitten. Alltså det bör vara fullt möjligt (och egentligen inte ens krångligare) att göra lika enkla användargränssnitt som det var innan Windows gjorde entré.

Men detta är väl egentligen också en "sjukdom" som beror på att Windows är lite för stort, programmerare behöver inte göra praktiska och lättanvända saker och motivera detta, bara man skriver för Windows så verkar det räcka ungefär som om det vore enda kravet från kunderna. Jag tycker tyvärr att Linux är på väg att gå åt samma håll eftersom det dyker upp mer och mer skräp där också där programmen endera har bra användargränssnitt _eller_ fungerar rent tekniskt men inte både och samtidigt. Det som behövs är nog större och tydligare krav från kunderna med fokus på användargränssnitt, tekniska krav och helt enkelt en grundläggande analys av vad sakerna ska användas till och vad användarna förväntar sig att det ska klara osv, något som känns väldigt bortglömt.

Jag har sett många förvånade säljare från programföretag när jag har köpt in program till olika tillämpningar i industrin och låtit slutanvändare granska användargränssnitten och själv tittat på tekniska krav och begränsningar och fått reaktioner i stil med "vi har x tusen kunder på det här programmet och ingen har klagat på användargränssnittet förut" eller "nej vadå client-server? Det här programmet körs bara på varje dator där det ska användas och det jobbar mot en utdelad katalog på en server och den katalogen måste alla anslutna användare har fulla rättigheter till" osv. Såna här saker har fått mig att mer och mer inse att Windows lider lite av att nästan vilka somhelst även helt okunniga inom t ex användargränssnitt kan skriva program och ändå sälja det enbart för att programmet körs i Windows. Det är programmerare som uppenbarligen har struntat i att analysera krav på användargränssnitt eller studera Microsofts eller andra programmerares rekommendationer för hur ett Windows-program ska utformas rent tekniskt eller användargränssnittsmässigt.

--
Olof Lagerkvist           sm6xmk
ICQ: 724451                     @ssa.se
 Click to see the full signature
Reply to
Olof Lagerkvist

+Olof Lagerkvist wrote

Gör det egentligen det ? ..Det känns spontant som att windows är ett ganska udda val när det kommer till Embedded-system.

Visst, några mobiltelefoner som knappt funkar (inte för att symbian funkar så mycket bättre då) och säkert ett och annat mätinstrumet och så, men i övrigt ?

Reply to
Glenn

Den känslan beror väl mer på vad man har för egna erfarenheter av Windows. Egentligen är det är väldigt mycket mer mångsidigt OS än många tror.

Oj, massvis, i de flesta fall har du ingen möjlighet att upptäcka att det är Windows. Telefonautomater, biljettautomater, såna där infopoints vad dom nu kallas med peka-och-trycka-kartbilder i en automat, som sagt också bankers uttagsautomater, olika typer av skrivare och etikettmaskiner och en hel massa industrimaskiner av olika slag. Med det märks inte i de fall det faktiskt fungerar bra, det är nog därför många inte reagerar över hur mycket Windows faktiskt används inom dessa områden.

--
Olof Lagerkvist           sm6xmk
ICQ: 724451                     @ssa.se
 Click to see the full signature
Reply to
Olof Lagerkvist

+Olof Lagerkvist wrote

Menade mer att man inte ser det på så många sådana ställen.

Dom infoterminalerna vi kör på jobbet kör linux+X dock :)

Jo, man har ju sett en del windowsfelmeddelanden i dom, plus att dom blivit slöare när dom joxats ner med en massa flashig grafik :(

Faktum är att jag ALDRIG sett windows i sådana områden, jag har kanske inte så stor erfarenhet angående det men jag har jobbat ett antal år med digitala kopiatorer,faxar och skrivare, och där är det motorolabaserat och inget windows så långt ögat kan nå i dom märken jag skruvat med, det ser snarare ut att vara BSD-baserat. (Ganska logiskt val iofs)

En kompis skruvar med industrirobotar, samma sak med dom, motorola och ingen windows..

Intel är ju inte heller speciellt stora vad det gäller embedded iofs, och microsoft har ju sitt stora fokus på x86.

Reply to
Glenn

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.