Beiträge von Darksoul71

Zitat

In einem richtigen Vergleichstest taucht AQE leider nicht auf. Dafür sind die Mitglieder des hauseigenen Forums ziemlich euphorisch, vor allem bei niedrigen Bitraten.

Hm, was meint hier richtiger Vergleichstest ?

AQE kann man runterladen und z.B. "gegen" QuEnc und HCEnc bei der selben Quelle antreten lassen. Schon hat man einen Vergleich. Die Nutzung von AQE ist leider nicht sehr selbsterklärend, weil der Encoder ausschließlich mit ECL Files (kompatibel zu CCE 2.66 ?) arbeitet, aber dafür gibt es entsprechende GUIs, welche im AQE Forum zu finden sind.

Ich habe AQE zu meinen reinen Analogzeiten exzessive in Verbindung mit OPV Encoding bei niedrigen Bitraten eingesetzt und fand die Qualiät gerade bei niedrigen Bitraten (<= 2 MBit für HalfD1 ) sehr gut. Dagegen kamen QuEnc und HCENc nie an (meine Meinung).

Wenn man sich nicht über die lange Encodingzeit aufregt, dann erhält man einen Encoder, der IMO für niedrige Bitratenencodings prädestiniert ist. Für alles mit ausreichend Bitrate ist es ziemlich egal, ob man QuEnc, FreeEnc, HCEnc oder AQE verwendet.

@Urviech: "Aber das kennt man ja ..."
Sorry, aber das würde ich mir verkneifen. Erstmal ausreichend testen und dann selbst ein Urteil bilden.

Nachtrag:
Hier findet sich PsychoRep´s AQEGUI:
http://psyrep.tripod.com/id10.html

Einen schöne Vergleich zwischen den ganzen Encodern kann man sehr schön mit einer guten DVD Quelle machen. So habe ich das damals gemacht. Einfach eine schwierig zu encodende Stelle suchen (viel Bewegung mit vielen Details wie z.B. die Foyer Szene in Matrix mit der Ballerei). Dann entsprechend auf das Zielformat resizen und in diversen Bitraten mit allen interessanten Encoder durchrechnen. Schon kann man schön vergleichen, was der Encoder liefert.

Bei mir waren es irgendeine Szene aus Blade 2 mit folgenden Auflösungen:
720x576 (16:9)
720x576 (4:3 resized)
352x576 (4:3 resized)

Bitraten: irgendwas von 1500 kBit bis hoch zu 6 MBit
Als Encoder kamen HCEnc, QuEnc, FreeEnc und AQE zum Zuge.

Für meinen Geschmack sahen alle bei "ausreichend" Bitrate ziemlich gut aus, aber gerade bei den niedrigen Bitraten kann AQE mehr "rausholen" als die anderen Encoder. Leider habe ich nicht mehr das AutoIt Script, welches ich damals zu erstellung der ganzen Videos genutzt habe (wer ist schon so Balla das von Hand zu machen ? ;)). Sonst hätte ich es gerne geposted....

@Koperinikus:
AQE arbeitet zur Optimierung der Q-Matrix mit DCTune. Für meine Begriffe funzt das sehr gut und ich habe noch keinen Encoder gefunden (ausser dem Canopus Procoder), der bei wirklich niedrigen Bitraten noch so gute Qualität liefert wie AQE. Einzig das Handling mit den ECL-Files is ein bissi nervig (und das er von DVD-RB Free nicht richtig unterstützt wird).

Näheres zu DCTune hier:
http://vision.arc.nasa.gov/dctune/

Ei, schlimmstenfalls bleibt doch immer noch einfach entweder den eventuell bestehenden TV Out der GraKa (was bei Spielen auch nicht immer geht) bzw. einen externen VGA2PAL Konverter zu nutzen und dann einfach auf VHS / mit TV Karten und zweitem Rechner / sonstwie analog aufzunehmen.

Keine Leistungsverluste beim Spiel, aber Verluste in der Aufnahmequalität.

Zitat von LigH

Von DVD-Shrink gibt es eine deutsche Version, die nur mit unverschlüsselten DVDs arbeitet. Und nur um die geht es dir, richtig?

Ausschließlich um die Variante ging es mir

Zitat von bergh

Du redest von spezialisierter Hardwrae.

Ich rede von spezialisierter Hardware, wenn ich sage, dass ich mit ner HVR1100 und Mainconcept PVR mit ganz guten Ergebnissen aufgenommen habe ? Hm...das musst du mir näher erklären.

Zitat von bergh

Als die Teile vor ein paar Jahren auf den Markt kamen hatten die schnellsten 2,5 GHZ und da war das die Harwareanforderung.

Also als ich mit noch mit meinem Athlon XP2800+ (< 2GHz) und ner Cinergy 400 per WinDVR gecaptured habe, fand ich das Ergebnis ziemlich gut. Keine Ruckler, usw. Allerdings hatte ich damals keinen DVD-Röster und deswegen war ich nicht an MPEG2 Captures interessiert.

Zitat von bergh

Und Eine analog Karte ohne HW Encoder mit einer USB Lösung mit Hardware-Encoder zu vergleichen ?
Sorry aber der Sinn dieser Übung entzieht sich mir.

Und wenn dich jemand fragt wie gut die Qualität seiner HVR1100 bzw. deren Analogchip ohne Hardwareencoder gegenüber dem Hardware Encoder ist den du besitzt ? Ergbiet der Vergleich dann für dich einen Sinn ?

Und ja, die PVRs sind sehr gut !

Der Karl:
Re-Moin,

ist schon klar, dass das "q&d" ist, wobei ich der Meinung bin, dass das Ergebnis für viele "Normaluser" durchaus ausreicht. Wer mehr will, muss sich halt einarbeiten. Deswegen auch mein 2ter Tipp mit der Hardware Encoderkarte und TMPEG DVD Author.

Und gerade weil Full-D1 nicht auf ne DVD passt, habe ich 352x576 getestet und auch "empfohlen".

Für knapp 140.- € (74.-€ für DVD Author 2.0 / 66 € PVR150) kriegst du ne "Rundum Sorglos"-Lösung. Wenn zwei Filme mal nicht ganz auf ne Scheibe passen, dann "quetscht" man sie halt mit "DVD Schrumpf" (oder darf man das noch beim Namen nennen ? )

Auf allle Fälle ist das was da hinten raus kommt IMO besser als alles was dieser < 400.- € DVD-Rekorder Stehalleinschrott produziert. Von den Editing Möglichkeiten mal ganz abgesehen.

Der Mainconcept PVR macht auch bei Full D1 und 3-4 MBit noch ne ganz gute Figur. Es ist doch eher persönliche Ansichtssache, was "gut" ist. Ich denke da nur an meinen Paps, der nach dem Anschließen eines DVB-T Receivers bei ner Tante meinte, dass das Bild gut sei...brrrr....

Gruß,
D$

Zitat von bergh

Meine Vermutung ist, daß wie bei allen anderen Analog >Capturen> MPG Programmen die Streams nicht wirklich 100% kompatibel sind, weil so etwas selbst bei einem 3000 MHZ Rechner immer noch schwierig ist.

Meeeeep, falsche Antwort !

Warum sich dieses Gerücht nur immer noch so hartnäckig hält ?

FIO: Ich hatte letzten die Hauppauge HVR-1100 von meinem Chef zum Testen des DVB-T Empfangs mal ausgeliehen.
Da sich mein Chef dafür interessierte wie gut die HVR-1100 gegen einen analogen Hardwareencoder (in meinem Falle PVR USB2.0) abschneidet, habe ich kurzerhand einen kleinen "Trippletest" gemacht:
1) HVR 1100 in MJPEG gecaptured und mit TMPEGEnc runtergerechnet
2) HVR 1100 in Echtzeit MPEG2 gecaptured
3) PVR USB 2.0 mit Hardware MPEG2 Codec gecaptured.

Quelle war ein Kauf VHS Video (Episode 1, wenn ich mich recht erinnere).

Bei 352x576 als Zielauflösung konnte ich bei halbwegs ordentlichen Bitraten (>= 3.5 MBit/s) keine nennenswerten visuellen Unterschiede an meinem 19" erkennen. Als Capturesoftware für 2) kam der MainConcept PVR zum Einsatz:
http://www.mainconcept.com/site/index.php?id=10199

Ein schönes Stück Software, aber leider pflegen die Spacken von Mainconcept das Ding irgendwie nicht so richtig.

Ach ja, mein Prozzi ist ein A64 3200+ (nominal so irgendwie um die 2GHz, wenn AMD nur endlich mal mit diesem S.... Rating aufhören würde).

Roykova:
Es gibt ne einfache Lösung: Hardware MPEG2 Encoder (z.B. Hauppauge PVR-150) und TMPEG DVD Author kaufen. Dann in DVD konformen Raten / Auflösungen aufnehmen (dafür bietet WinTV2k wunderbar einfache Standardtemplates). Mit TMPEG DVD Author kannst du schneiden und deine DVDs erstellen. Wenn du mehr willst ist eher 2) von BergH anzuraten.

Grüzzle,
D$

trasher:
Da fliegt im VirtualVCR Verzeichnis irgendwo ne Batchdatei. Die registriert die entsprechenden Direct Show Filter (Smart Tee / Flow Meter).

Liest du hier:
http://virtualvcr.sourceforge.net/html/virtualvcr/filters.php

Hm, Huffyuv ist zum Weiterverwursten, sprich Reencoden, halt das Optimum, weil er das Material verlustfrei komprimiert.

Ansonsten würde ich Bergh zustimmen: PIC MJPEG mit Q16-18 langt auch. Kostet aber leider Kohle. ffdshow hat auch nen MJPEG Codec integriert, aber ich weiß nicht was der taugt.

VirtualVCR ?
http://virtualvcr.sourceforge.net/

Zitat

Command line Options
Virtual VCR will allow you to start a capture using the "-capture" command line option, Virtual VCR will start the capture using the default settings if started with the "-capture" command line option.

There are a number of command line options you can use with timed captures:

-capture (This will start Virtual VCR in capture mode)
-channel "X" (This will set the initial channel to X when Virtual VCR starts)
-profile "<file location and name>" (load a profile file when run)
-runfor "time in sec" (Capture for seconds and then stop capture)
-output "<file name>" (Over ride the filename)

virtualvcr.exe -capture -channel "9" -profile "c:\video\test.vcr" -output "d:\video.avi"

Setting up a timed Capture
You can use any mechanism to start Virtual VCR with the "-capture" command line option, the easiest way to do it is using the built in task Scheduler that is available in Windows.

All you have to do is create a new Scheduled Task and use the -capture command line option to get Virtual VCR to start the capture when it is run.

When scheduling timed captured it is best to use the "Insert Time Date Stamp" option, this will add the time date stamp into the file name that is created. This will allow you to easily find captured files in your capture directory, it will also allow you to schedule more than one capture using the same settings without over writing the previous capture file. This option is available under the File Tab of the Settings Dialog.

It is also a good idea to use the "Save Capture Stats" option, this will save a text file with the same name as the capture file but with .TXT appended to the end with all the capture statistics in it. This option is available under the File Tab of the Settings Dialog.

Alles anzeigen

Verschiedene Codecs & Settings lassen sich einfach über Profile realisieren.

Für ne BT Karte sei dir dieser Treiber empfohlen:
http://btwincap.sourceforge.net/

Andere "Schweinereien" gehn natürlich (mit etwas Übung) mit jeder GUI Aufnahmesoftware und Zeugs wie AutoIt, AutoHotKey, WSH, etc.

Ach ja, capturen solltest du zumindest in Huffyuv. Raw is dann doch ein "bisschen" groß

Hi Leute,

freut mich ja, dass hier ein bisschen "Bewegung" reingekommen ist.

Meine Ansatz mit der CQ Methode sieht garnicht so schlecht aus:

22:12:29 >>Starting Calculation for Adaptive Bitrate Distribution (ABD) !
22:12:29 >>Average Filesize for Samples: 1.49 MB
22:12:29 >>Average Bitrate specified in CLI: 3789 kBit/s
22:12:29 >>Filesize for Sample # 0:                  1507265 MB
22:12:29 >>Filedeviation for Sample # 0:             -3.39 %
22:12:29 >>Bitrate Correction Factor for Sample # 0: 1.03388236493116
22:12:29 >>Corrected Bitrate Factor for Sample # 0:  3917
22:12:29 >>Filesize for Sample # 1:                  1196836 MB
22:12:29 >>Filedeviation for Sample # 1:             -23.29 %
22:12:29 >>Bitrate Correction Factor for Sample # 1: 1.23285927432452
22:12:29 >>Corrected Bitrate Factor for Sample # 1:  4671
22:12:29 >>Filesize for Sample # 2:                  1408118 MB
22:12:29 >>Filedeviation for Sample # 2:             -9.74 %
22:12:29 >>Bitrate Correction Factor for Sample # 2: 1.0974330114095
22:12:29 >>Corrected Bitrate Factor for Sample # 2:  4158
22:12:29 >>Filesize for Sample # 3:                  1881345 MB
22:12:29 >>Filedeviation for Sample # 3:             20.59 %
22:12:29 >>Bitrate Correction Factor for Sample # 3: 0.794106821196945
22:12:29 >>Corrected Bitrate Factor for Sample # 3:  3009
22:12:29 >>Filesize for Sample # 4:                  1126985 MB
22:12:29 >>Filedeviation for Sample # 4:             -27.76 %
22:12:29 >>Bitrate Correction Factor for Sample # 4: 1.27763194729656
22:12:29 >>Corrected Bitrate Factor for Sample # 4:  4841
22:12:29 >>Filesize for Sample # 5:                  1429775 MB
22:12:29 >>Filedeviation for Sample # 5:             -8.36 %
22:12:29 >>Bitrate Correction Factor for Sample # 5: 1.08355143808119
22:12:29 >>Corrected Bitrate Factor for Sample # 5:  4106
22:12:29 >>Filesize for Sample # 6:                  1963289 MB
22:12:29 >>Filedeviation for Sample # 6:             25.84 %
22:12:29 >>Bitrate Correction Factor for Sample # 6: 0.74158284997219
22:12:29 >>Corrected Bitrate Factor for Sample # 6:  2810
22:12:29 >>Filesize for Sample # 7:                  1967393 MB
22:12:29 >>Filedeviation for Sample # 7:             26.1 %
22:12:29 >>Bitrate Correction Factor for Sample # 7: 0.738952292787937
22:12:29 >>Corrected Bitrate Factor for Sample # 7:  2800

Hm, sind doch schon ganz schöne Varianzen pro Segment drin.

Zitat von Trekkie2

Hm, beleidigt zu schmollen treibt Dein Projekt sicher nicht voran.

Das solltest du nicht überbewerten. Ich bin, sagen wir mal, offensiv sarkastisch.

Wenn jemand was ablässt ohne die Software ganz ersichtlich nicht mal angetestet zu haben, dann darf ich mich nicht gerade darüber freuen, oder ?

Fakt is ja wohl, dass der Erklärbär (sorry LigH, ich find´s echt geil !) erstmal rein theoretisch geposted hat, oder ?
Das Bedenken ist theoretisch durchaus berechtigt, aber ich stelle immer noch in Frage wie viel davon ein DualCore User merkt, der mit QuEnc^n ausschließlich längere Filme mit ordentlichen Bitraten encodet, oder ?

Aber lassen wir das....

Ich habe die ABD Funktion jetzt mal einfach spaßhalber implementiert und werde mal ein paar Tests fahren.

We´ll see...

Kopernikus:
Habe keine Ahnung, ob die Statsfiles so einfach lesen kann. Das wäre natürlich auch ein Ansatz.

D$

seeigel:
"stänkern" steht bewusst in Anführungszeichen ! Ich spreche Ligh generell nicht seine Erfahrung ab, aber achte auf seine Wortwahl:

Zitat von LigH

Die Geschwindigkeit wird es eventuell erhöhen;

Man möge sich diese Aussage auf der Zunge zergehen lassen. Die Geschwindigkeit wird es eventuell erhöhen - QED

Drüben auf doom9 hat Revgen nen Test mit nem 4600+ X2 Dual-Core Athlon gemacht und für analoges, interlacetes Material ca 65% Geschwindigkeitssteigerung erzielt
http://forum.doom9.org/showpost.php?p=825589&postcount=12

Bei progressivem Material über 80%:
http://forum.doom9.org/showpost.php?p=826001&postcount=16

Soviel zum Thema "eventuell". Ist ja wohl klar, dass ich zumindestens 30-40% Geschwindigkeitsteigerung bei diesem Ansatz kriege, wenn ich zwei Instanzen eines Encoders gleichzeitig auf ner DualCore Maschine laufen lasse...

Zitat von LigH

die Qualität aber bestimmt nicht

Ich habe nie davon gesprochen, dass die Qualität "gesteigert" werden soll, aber es bleibt ohne echte praktische Tests (wie in meinem oberen Posting ja geschrieben) einfach Kaffeesatzlesen wie gut oder schlecht so ne Methode funzt. Die Mehrheit der Nutzer von QuEnc^n wird ja wohl kaum 3 min Viva Musikvideos auf nem 16 Core Server mit 1 MBit/s encoden, oder ? :ani_lol:

Ganz im Gegenteil: Die breitere "Masse" (wenn es denn eine gibt) wird wohl eher zu Hause auf nem Dual Core (bestenfalls Dual CPU Dual Core oder Dual Core mit HT) nen Film >= 90 min encoden, oder meinst du nicht ? :ja:

Dedadewegen und gerade weil ich auch (eben erst) mitbekommen habe, dass QuEnc auch CQ kann, denke ich bereits über eine "dynamische" Bitratenverteilung pro Segment nach.

Schon deshalb (man möge mir Encoder Mongo verzeihen) halte ich solche Aussagen wie diese schlichtweg für Käse:

Zitat von LigH

Ein solches Thema wurde bereits unter dem Stichwort "Clustering" besprochen; im Allgemeinen ist das generell wenig geeignet für Videoverarbeitung. Einen wirklichen Gewinn könnte man bei Mehrprozessor-Unterstützung nur in wirklich parallelisierbaren Anteilen des Encodierungs-Algorithmus erreichen, die sind aber eher eng beschränkt und innerhalb von kleinen Bereichen des jeweiligen Einzelbildes, über mehrere Bilder oder größere Flächen hinweg ist eine Parallelisierung kaum möglich.

Direkt auf den Encoding Algorithmus bezogen hat LigH ja bestimmt Recht, dass dieser nicht sehr gut parallelsierbar ist, aber der Segmentansatz ist sehr gut parallelisierbar.

Damit meine ich z.B. die Möglichkeit den ganzen Film per CQ mit Size Prediction zu analysieren und dann mit konstantem CQ Wert die einzelnen Schnippsel encoden. Wo soll da bitte die Quallie leiden ?

...aber gut, ich bin doof und LigH hat Recht.:daumen:

Heya Erklärbär,

ich finde es schade, dass du nicht nochmal "Stellung beziehst".
Weißt du, "stänkern" kann jeder. :nein:

Erinnert mich irgendwie stark an die typischen "Bedenkenträger", die wir in der Firma auch immer sitzen haben. Große Sprüche "Das könnte kritisch sein", "Daran muss man denken" und keine Lösungsvorschläge einbringen. Nicht dass ich dich nach Lösungsvorschlägen gefragt hätte, aber ich würde mir wünschen, dass sich jemand wenn er schon postet auch ein bisschen neutral mit der Materie auseinandersetzt.

Bevor ich mich dazu äußern würde wie und ob "segmented" encoding einen wirklich sichtbaren Impact auf die Qualität hat, würde ich mal eine solide Testreihefahren, z.B.
Quellvideo 30 min / 60 min / 120 min
1-16 Segmente
Bitraten von 1.2 bis 4 MBit.

Dann die finalen Videos mit einem PSNR Tool wie dem PF Comparer mal testen (http://www.mpeg-vs-avi.de/PF%20Comparer.html).

Erst wenn man dann mal ein paar Zahlenwerte hat, kann man sich noch ein bisschen mehr über die Zahlenwerte diskutieren, wie z.B. wie groß ist der Qualliedrop bei n Segmenten und m kBit.

Wie groß der visuell erfassbare Verlust dann ist, wenn z.B. die segmentiert encodete Datei nen PSNR Wert von 70 und die am Stück encodete Datei von 73 hat, dass lass ich jetzt mal dahin gestellt sein.

Alles Andere is Kaffeesatzleserei und Unkenrufen ! :seher:

cu,
D$

P.S.: Danke auch für den Hinweis mit der Cluster-Geschichte. Der Fred war zwar schon ein bischen alt, aber interessanter Lesestoff.

LigH:
Mag ja sein, aber
1) kann ich bei 60-70% Geschwindigkeitssteigerung auf nem Dual Core auf das letzte Quäntchen Quallie verzichten.

2) Quetsche ich meine DVDs nicht so mit analogen Filmen voll, dass ich da erheblich Einbussen erwarte. Wenn du halt ganz weit runter gehst, dann mögen 2x45 min encodeter Film gemerged eventuell eine sichtbar schlechtere Quallie haben als 1x90 min, aber in den Fällen mit 2-4 Segmenten bei 3-4 MBit wage ich zu bezweifeln, dass das sooooo sehr sichtbar ist. Ausser der Encoder wäre zu schlecht.....

3) Nutzt DVD-RB ja das selbe Konzept und da regt sich keiner über Qualität auf.

Zitat

Einen wirklichen Gewinn könnte man bei Mehrprozessor-Unterstützung nur in wirklich parallelisierbaren Anteilen des Encodierungs-Algorithmus erreichen, die sind aber eher eng beschränkt und innerhalb von kleinen Bereichen des jeweiligen Einzelbildes, über mehrere Bilder oder größere Flächen hinweg ist eine Parallelisierung kaum möglich.

Obwohl ich kein Encoderentwickler bin bezweifele ich das jetzt generell einfach mal. Mag sein, dass "mein" Ansatz mit separat laufenden Encodern nicht optimal ist, aber betrachte dir doch die Arbeitsweise im 2 Pass Modus. Im ersten Durchgang wird das Video analysiert. Wer hindert den Entwickler daran mehrere Segmente gleichzeitig zu analysieren ? Analog dazu könnte der Encoder auch mehrere (2 ?) Segmente mit der entsprechenden Bitratenverteilung encoden.

Im Cluster wird das ohne vorherige Analyse vielleicht zu Problemen führen, aber wenn ich z.B. einen Encoding Cluster für DVD-RB bastele wo jede Encoding Node nur das selbe Segment runterrechnet was DVD-RB erstellt hat, dann hast du auch im Cluster keinen Quallieverlust, weil ist ja egal ob nun ein Encoder nacheinander die Segmente encodet oder mehrere parallel. Daran bastele ich übrigens auch grade.

Sry, ich finde der Ansatz hinkt ein bisschen. Mal angenommen QuEnc würde nen "Q"-Encoding Modus bieten und man könnte sowas ähnliches entwickeln wie in D2SRoBa integriert (OPV mit size prediction), dann könnte das "Frontend" den "optimalen" Q-Faktor für den gesamten Film finden und hinterher mehrere Segmente unabhängig vonaneinder mit dem ermittelten Q-Wert vergleichen. Mir kann keiner erzählen, dass sich eine "Q"-Encodingvariante nicht in QuEnc (oder andere Freeware Encoder) integrieren liesse.

HCEnc hat sich leider bei meinen Experimenten mti dem Constant Quantizer Encoding Modus als ungeeignet für die OPV Prediction gezeigt. Mit AutoMatQEnc (bei dem Sapstar sich aber auch um "Kompatibilität" zu CCE bei CQ bemüht) funzt die Prediction schon ziemlich gut und der arbeitet basierend auf der selben Lib wie QuEnc.

Ich denke es gäbe genug praktikable Ansätze: Eventuell einen Encoder mit "Quick First Pass" (analog zum Encoding bei OPV Prediction) der durch encoden von kurzen Samples sowas wie einen "schnellen Überblick" über den Film erhält, also wo viel Action ist und wo wenig und dann sein "Bitratenreservoir" entsprechend verteilt.

Hi Leute,

Hoffe mal, dass das Thema hier reinpasst ! :seher:
Ansonsten bitte an einen der Mods den Fred sonst in die richtige Ecke zu verschieben.

Ich habe gerade die letzten Tests mit QuEnc^n gefahren und denke, dass es bereit für eine Beta Release ist.

Da QuEnc nicht Multiprozessortauglich ist, aber immer mehr Multicore PCs auf den Markt drängen habe ich mir kurzerhand entschlossen ein Frontend zu "bauen", was diese Funktionalität nachrüstet.

Ich hoffe ihr verzeiht mir, wenn ich kurzerhand einfach nur einen Teil der englischen Readme poste:

Zitat

Q: What is QuEnc^n ?
A: A simple AutoIt script which forks "n" instances of QuEnc to enable the owners
of multicore PC systems to get the max performance of their systems.

Q: How does QuEnc^n work ?
A: Short answer: Very simple !
Long answer: It takes the source AVS and generates a separate AVS-segment for each
core, e.g. if you have 4 cores and a video length of 1811 frames then QuEnc^n will
calculate the following ranges:
Calculated Range# 0: 0-453
Calculated Range# 1: 454-906
Calculated Range# 2: 907-1359
Calculated Range# 3: 1360-1811
Now QuEnc^n copies the source AVS four times and adds a Trim to the end of every
temporary AVS-segment, e.g. Trim(0,453) for the first AVS. Then a QuEnc instance
is run for each segment. QuEnc^n will monitor until all QuEnc processes have closed
and then merge all segment under the output name specified in the CLI.

Alles anzeigen

QuEnc^n gibts hier: http://de.geocities.com/dark_soul_71/QuEnc_n.zip

Gruß,
D$

Was für ein Codec ?
Hast du mal MJPEG oder Huffyuv probiert ?

Schneiden der Ränder geht mit AVISynth einwandfrei. Crop (...) danach AddBorders()

Nachtrag:
Lies dir mal den Fred hier durch http://www.discountfan.de/forumneu/read.php?6,27376

Hm, das Medion keine Auskunft gibt, ist ja irgendwo klar, weil sie ja keine Hardware für Endverbraucher verkaufen. Ich würde sowieso diese "tollen" Alles-drauf-und-kann-alles Karten meiden. Da hast du eventuell schnell keine Treiber mehr, sie laufen nicht unbedingt mit den Standardprogrammen, usw.

Vielleicht bin ich da immer ein bisschen unvorsichtig, aber was hindert dich daran einfach die Buchsen durchzutesten ? Eine davon wird wahrscheinlich CD-ROM In sein (also da wo bei Medion intern der CD-ROM Audioausgang angeklemmt war). Eine der anderen zwei is dann halt der TV Karten Audioausgang. Lass einfach den Rechner auf, dann klemmst du ein Ende eines CD ROM Audiokabel an den CD Eingang auf deiner Soundkarte (oder deinem Onboard Sound), aktivierst den CD ROM Eingang in der Windows Lautstärkesteuerung, startest deine TV Karten Software (natürlich mit nem Sender aktiviert) und steckst solange das andere Ende des Audiokabels in die Anschlüsse auf der TV Karte bis du den Ton vom Tuner hörst -> fertig !

Bezüglich Videogröße:
Ich würde zumindest 480x576 aufnehmen, wenn das dein Zielauflösung ist. Besser ist aber 704x576.

Mit dem Codec kommt es auf deinen Platz auf der HD an. Am Besten im Hinblick auf Weiterverarbeitung ist immer unkomprimiert bzw. lossless Komprimierung (Huffyuv). Wenn dein Platz eher limitiert ist würde ich zu einem der MJPEG Codecs greifen. Ich persönlich verwende noch ne Version von PIC, der früher gegen Registrierung kostenlos war. Ansonsten bliebe da unter anderem der MJPEG Codec von Mainconcept (Shareware) oder der MJPEG Codec, der in FFDShow integriert ist. Da müsste sich mal jemand anderes dazu melden.

Ich persönlich würde übrigens lieber 352x576 mit 48 kHz nehmen. Wenn du das als "SVCD" bruzzelst können es 99,9% aller Taiwan / China Stehalleins auch abspielen und du kannst es hinterher problemlos auf DVD Mastern, da kompatibel.

Ich will dir beim Encoder nicht reinreden, aber befasse dich mal ein bisschen mit AVISynth und HC Enc. Damit erzielst du (ein bisschen Einarbeitung vorausgesetzt) viel bessere Ergebnisse als mit dem Ulead Geraffel.

@Inc: 32kHz sind aber meines Wissens nach auch DVD Kompatibel (bei DVD als Ziel also ok). Zu Stereoproblematik kann ich nichts sagen :seher:

aldero:
"Multiadapter" kriegst du im Kruschelladen um die Ecke für unter 3 Euro. Ansonsten schau mal bei Woolworth, Walmart, etc. vorbei. Mediamarkt, Saturn & Konsorten lassen sich den Kram nämlich vergolden.

Wenn du partout nicht (wie auch von BergH vorgeschlagen) ein zusätzliches Audiokabel vom VHS Rekorder zur TV Karte schleifen willst, dann bleiben dir nur zwei Optionen:
1) Du schleifst das Tonsignal der TV Karte (das was z.B. auch der Tuner produziert) zu deiner Soundkarte durch. Das geht entweder intern über ein CD Audiokabel oder extern über ein 3.5 mm Klinke auf 3.5 mm Klinke Kabel.

2) Du nimmst den Sound direkt von der TV Karte auf bzw. die TV Karte übermittels ihr Tonsignal über den PCI Bus (wie das funzt weiß ich aber nicht).
Du müsstest ma in dein KTV Einstellungen schauen, ob dir ZoomOut die Option anbietet direkt von der TV Karten Ton aufzunehmen. Ebenfalls musst du das ZoomOut Audio PlugIn "registriert" haben (geht in K!TV).

Bei meiner Cinergy 400 (auch mit Philips Chipsatz) kann ich z.B. auch mit der neuesten VDub Version über den Ton der TV Karte aufnehmen. Eventuell bist du hier aber bei der Samplefrequenz festgelegt (bei der Cinergy z.B. 32 kHz)

Ach so, TV Karten haben zu 99,9% eh nie Cinch Audiobuchsen. Fast immer nur 3.5 mm....

Uff, alten Fred hochhol...

warum nimmst du nicht einfach über den TV Karten internen Soundteil auf ?