| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
bergH 
Moderator
Anmeldungsdatum: 14.06.2001
Beiträge: 13672
Wohnort: Am Kamener Kreuz
  |
 Beitrag 20 - Verfasst am: Do Okt 23, 2003 20:17 Titel: |
 |
|
tach auch !
Schön mal wieder was von den MPEg Fetischisten zu hören !
Euch fehlen dei Herausforderungen ?
Kein Problem:
Testet die CQ Vorhersage Programme und schreibt eine Anleitung so Schritt für Schritt, mit Bildern.
[TiefDuck] 
BTW: Nur ein B-Frame ? Mit Spoiler, also tiefergelegt ?
Warum sagt mir das denn Keiner 
Schön von Euch zu "hören".
_________________
Gruß BergH |
|
 |
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
| Beitrag 21 - Verfasst am: Do Okt 23, 2003 21:55 Titel: |
|
|
| Zitat: | | - Requantisieren und dabei die Auflösung verändern (in der Theorie möglich !). Dabei müssen die Motion Vektoren "zusammengefasst" werden. |
Ich sehe zumindest nichts, was generell dagegen sprechen würde. Außer, dass ich bezweifle, dass sowas in der Praxis besser wäre als eine komplette Neuencodierung.
Hm, aber das Nachdenken darüber ist faszinierend. Da wünscht man sich manchmal, Programmierer zu sein. ;)
Ich muss aber gestehen, dass ich mich seit den Recherchen zu Instand Copy nicht mehr wirklich mit dieser Materie auseinander gesetzt habe. Ich gebe aber gerne zu, dass Deine Anwendungsbeispiele einiges für sich haben.
@BergH
| Zitat: | | Testet die CQ Vorhersage Programme und schreibt eine Anleitung so Schritt für Schritt, mit Bildern. |
Die Prinzipien, die dahinter stecken, haben sich ja nicht geändert. Funktioniert auch nicht besser als die Methode, die mb1 mithilfe von AVIsynth mal ansatzweise vorgestellt hat.
Meine eigene Idee, mithilfe von AVISynth und TMPGEncs MVBR-Modus und Picture Type Setting eine Art Mega-2pass-Mode zu entwickeln, scheitert wohl auch daran, dass ich eben nicht programmieren kann.
Manuell habe ich dieses Verfahren längst ausprobiert, und es ist SEHR gut, aber wie gesagt, ohne Tool, dass eine echte Bewegungsanalyse erstellt und darauf basierend die richtigen Framenummern samt errechneten CQ-Wert liefert, ist das witzlos.
An Ideen mangelt's also nicht, was fehlt, ist die praktische Umsetzung.
| Zitat: | BTW: Nur ein B-Frame ? Mit Spoiler, also tiefergelegt ?
Warum sagt mir das denn Keiner |
Na, so neu ist das nicht. Und die Sache mit dem "Spoiler" hab' ich doch schon mehr als einmal erwähnt. Vertrau' mir, es funktioniert. 
BTW: "ReJig"? Was'n dat denn? |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 22 - Verfasst am: Do Okt 23, 2003 22:24 Titel: |
|
|
ReJig ist ein GPL-Tool, mit dem man beliebige m2v-Streams (sogar auch vob-Streams) requantisieren (eindampfen) kann.
Hier der Link zum betreffenden Thread:
http://forum.doom9.org/showthr....d=62849
Hier der Downloadlink:
http://nic.dnsalias.com/ReJig.zip
Source-Link: 
http://nic.dnsalias.com/ReJig_src.zip
Das Tool ist sauschnell und wird immer besser. Es requantisiert außerdem dynamisch, also weniger bei fast motion scenes und stärker bei ruhigen Szenen, was der Qualität (zumindest theoretisch) zugute kommt.
Leider zeigt es bereits bei 70% Endgröße schon eine Menge Blöcke.
Aber wenn man z.B. 2 DVB-Streams, die etwa 300-400 MB zu groß für eine DVD sind, eindampfen will, ist es hervorragend geeignet (bis ca. 10% also). cool, das ist doch was für dich ;)
Na, der liest hier bestimmt nicht mit.
Jedenfalls, da die Sourcen öffentlich sind, lässt sich daraus was machen (nicht für mich, da Programmierer-Analphabet  ).
Da hast du aber bereits was versäumt, Kika 
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
| Beitrag 23 - Verfasst am: Do Okt 23, 2003 22:32 Titel: |
|
|
Klingt ja sehr interessant.
Bislang habe ich sowas zwar nicht benötigt, aber gut zu wissen, dass es das gibt. ;)
| Zitat: | | Da hast du aber bereits was versäumt |
Tja nun, wie ich schon andeutete, hab' ich's 'ne Weile etwas ruhiger angehen lassen. Ich bin seit einiger Zeit eher Mitleser als wirklich aktiver User. |
|
|
shh
Anmeldungsdatum: 01.03.2002
Beiträge: 959
|
| Beitrag 24 - Verfasst am: Do Okt 23, 2003 22:39 Titel: |
|
|
| Zitat: | | - Requantisieren und dabei die Auflösung verändern (in der Theorie möglich !). Dabei müssen die Motion Vektoren "zusammengefasst" werden. |
Ich muss euch leider entäuschen. Das geht nicht.
Wir ändern mal die Auflösung - machen wir es uns mal ganz einfach - von horizontal 704 auf 352. Jetzt möchte man meinen, man muss nur die X-Komponenten vom Vektoren halbieren, und fertig. [ich lasse jetzt mal das Neucodieren der restl. blocks weg]
Irrtum.
Die Bewegungskompensation arbeitet ja makroblockweise. Hat man jetzt einen Vektor der besagt "dieser Macroblock gehört im folgenden Bild DAhin", dann stimmt für eine geringere Auflösung *nichts* mehr, weil ja immer ein voller Macroblock mit 16x16pixel "verschoben" wird.
Bei unserem Beispiel von 704x576 zu 352x576 bräuchte man aber einen 8x16 Block für die Bewegungskompensation. Sowas gibt's aber nicht.
Nochmal ganz klar: Beim Verkleinern der Auflösung muss man auch die Grösse der Makroblocks mitskalieren, sonst wird vom Bild zuviel "verschoben". Andere Makroblockgrössen gibt's aber nicht (zumindest nicht in MPEG2 MP&ML)
_________________
shh >>> shh's MPEG-tools |
|
|
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
| Beitrag 25 - Verfasst am: Do Okt 23, 2003 22:50 Titel: |
|
|
OK, denken wir mal nach. Was Du sagst stimmt natürlich. Aber gerade bei genannten Beispiel könnte man von den vorhandenen Macroblocks und den vorhandenen Bewegungsvektoren durchaus Erkenntnisse für das neue Ergebnis übertragen. Die komplette Bewegungssuche kann man sich jedenfalls mit ziemlicher Sicherheit sparen.
Aber ich schrieb ja schon, dass ich meine Zweifel habe, dass das besser wäre als ein Neuencoden.
Möchte man natürlich auf Macroblockebene Croppen, dann dürfte das kein großes Problem sein. |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 26 - Verfasst am: Do Okt 23, 2003 22:53 Titel: |
|
|
Also, es ist doch so
Ich habe einen 16x16 Makroblock. Der besteht aber aus vier 8x8 DCT Blöcken. Daraus lässt sich etwas machen (bzw. existiert bereits 
Leider habe ich die Links zu den theoretischen Abhandlungen nicht auf diesem Rechner parat, hier aber mal ein kleiner Auszug:
| Zitat: | The rigid structure of the 8 by 8 block DCT makes simple operations like translation difficult. The difficulty stems from the fact that the DCT blocks of the processed image do not line up with the DCT blocks of the original image. For example, consider a 16 by 16 block of pixels that is transformed with four 8 by 8 block DCTs. If one wishes to calculate the DCT of an arbitrary 8 by 8 subblock of pixels, one must first calculate the four inverse DCTs, then extract the appropriate subblock, and finally perform the forward DCT operation. The inverse motion compensation developed in [Merh96a] performs this operation directly on the DCT-domain data. This algorithm can be extended to a global translation operation because global translation is a special case of inverse motion compensation in which all the motion vectors have the same value. By exploiting this fact, further optimizations can be performed to increase the efficiency of the translation transcoding operation.
Fast DCT-domain downscaling algorithms have been developed for integer subsampling factors [Merh94]. When downscaling, one 8 by 8 DCT block of the downscaled image is determined from multiple 8 by 8 DCT blocks of the original image. In these algorithms, when downscaling by a factor of N by N, each pixel of the downscaled image contains the average value of the corresponding N by N pixels of the original image. An efficient algorithm was also developed for filtering images in the DCT domain [Merh95]. This method can be used to apply two-dimensional symmetric, separable filters to DCT-coded images. In addition, approximate, multiplication-free versions of the transcoding algorithms described above have also been developed [Merh96b, Nat95]. |
Sogar die GOP-Struktur ist abänderbar (aber mit viel Aufwand, der fast Reencoding der entsprechenden Stellen entspricht).
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
| Beitrag 27 - Verfasst am: Do Okt 23, 2003 23:11 Titel: |
|
|
Jup, sowas in der Art habe ich vor einer Weile auch mal gelesen.
Fakt ist doch, dass auch auf Macroblock- und Blockebene mit Abbildern des Originalbildes gearbeitet wird. Und die kann man ebenfalls Scalieren - sogar vom Prinzip her einfacher, als das mit Pixeln möglich wäre. Ich halte es aber auch für schwierig, das mit den Vektoren in Einklang zu bringen. Denn anschließend habe ich ja ein kleineres Bild, mit weniger Vektoren, die auch noch in der "Richtung" bzw. ihrer Wertigkeit geändert werden müssen. |
|
|
Tsunami
Anmeldungsdatum: 12.02.2002
Beiträge: 1759
|
| Beitrag 28 - Verfasst am: Do Okt 23, 2003 23:18 Titel: |
|
|
| Zitat: |
Meine eigene Idee, mithilfe von AVISynth und TMPGEncs MVBR-Modus und Picture Type Setting eine Art Mega-2pass-Mode zu entwickeln, scheitert wohl auch daran, dass ich eben nicht programmieren kann.
Manuell habe ich dieses Verfahren längst ausprobiert, und es ist SEHR gut, aber wie gesagt, ohne Tool, dass eine echte Bewegungsanalyse erstellt und darauf basierend die richtigen Framenummern samt errechneten CQ-Wert liefert, ist das witzlos.
|
Wir hatten uns schon mal vor einigen Monaten kurz darüber unterhalten, aber das ist dann irgendwie eingeschlafen.
Wie genau machst du das manuell?
Womit erhälst du manuell die richtigen CQ-Werte?
Wie kann man TMPGEnc dann manuell mit diesen CQ-Werten füttern?
Wenn es manuell geht, dann kann man die Tools mit dem Windows Scripting Host oder mit einem eigenen Sendkey-Tool (Code-Teile dazu hatte ich dir damals per mail zugeschickt) fernsteuern.
Am besten schreibst du mal sehr detailiert auf, was du in welcher Reihenfolge mit welchen Tools machst, dann kann man ja sehen, inwieweit man das dann automatisieren kann. |
|
|
shh
Anmeldungsdatum: 01.03.2002
Beiträge: 959
|
| Beitrag 29 - Verfasst am: Do Okt 23, 2003 23:38 Titel: |
|
|
> Ich habe einen 16x16 Makroblock. Der besteht aber aus vier 8x8 DCT Blöcken
Sechs, nicht vier!
Meinst du etwa dies hier:
> The inverse motion compensation developed in [Merh96a] performs this operation directly on the DCT-domain data
Das heisst doch auch nichts anderes, als dass da halt ein spezielles Programm geschrieben wurde, was inverse Bewegungskompensation auf einer höheren Ebene wieder reinrechnet (= man muss das Bild nicht bis zu den Pixeln decodieren)
Dann hat man die Bewegung kompensiert. Ok.
Jetzt kann man (wie der Text sagt) sogar schnelle Algorithmen implementieren, die vielleicht sogar einiges an Zeit sparen... (weil die Bilder nicht komplett decodiert, dann skaliert und dann wieder in die DCT rein müssen.)
Aber:
Das Zeitaufendigste ist ja immer noch die Bewegungssuche, die am Ende auch die meisten Daten spart.
Jetzt weiss man zwar WO Bewegung war (Der encoder fängt halt da an zu suchen - ist etwas schneller), aber man weiss wg der neuen Bildgrösse nicht, ob es überhaupt gut ist an einem bestimmten Punkt noch zu kompensieren. Was vorher gut gepasst hat, kann jetzt unerheblich sein; andere Bereiche können wichtiger sein.
Weiteres Problem (Hauptproblem): Für die neue Bewegungssuche muss man wieder zur Bildebene decodieren.
Dann hätte man sich aber obige Spezialalgorithmen sparen können.
Der einzige Vorteil wäre vielleicht, dass der trancoder weiss, wo er am besten mit der Bewegungssuche anfangen soll. Obwohl die Kompensation anderer, neuer Macroblocks bei einer anderen Auflösung vielleicht wichtiger wäre... tja. Dann halt doch wieder das ganze Bild nach Bewegung absuchen. 
> Sogar die GOP-Struktur ist abänderbar
Klar, das ist "leicht".
Ich denke das kommt auch bestimmt bald. ZB um einige DVB-streams mit langen GOPs zu kürzen (da muss ein P-Frame zu einem I-frame gewandelt, und ein bischen temporal_reference angepasst werden)
_________________
shh >>> shh's MPEG-tools |
|
|
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
| Beitrag 30 - Verfasst am: Do Okt 23, 2003 23:47 Titel: |
|
|
@Tsunami
Manuell bedeutet in diesem Fall, dass ich mich auf meine Erfahrungswerte verlasse und das von Hand eintrage. Unmenschlich viel Arbeit und fehleranfällig, da ich zwar Erfahrung damit habe, aber nicht unfehlbar bin, bei weitem nicht.
Außerdem habe ich bei Tests die Methode benutzt, Ausschnitte des Videos mit diversen Q-Werten zu encoden, um so den Bitratenbedarf und die damit mögliche Bildqualität auszuloten.
| Zitat: | | Wie kann man TMPGEnc dann manuell mit diesen CQ-Werten füttern? |
Das ist im Prinzip einfach. Schau Dir mal die Möglichkeiten an, die TMPGEnc bei Force Picture Type setting bietet. Die gesamten Einstellungen lassen sich als File speichern und auch laden. Ein solches File müsste sich auch extern generieren lassen.
Die Idee, die dahinter steckt, ist folgende:
TMPGENc macht, wie alle anderen MPEG-Encoder auch, keine wirklich globale Analyse im 2pass Mode. Warum das so ist, ist mir nicht ganz klar, aber wurscht. ;)
Es gibt diverse Möglichkeiten, mithilfe von AVISynth eine Bewegungsanalyse durchzuführen. Und zwar wesentlich besser als die Encoder das können und, wenn man will, durch Parameter steuerbar. Das KVCD-Filter-Script basiert z.B. darauf.
Nun geht man also her, und macht mit AVISynth eine genaue Scene-Detection. Daraus ermittelt man eine Statistik, die man relativ leicht in einen AVG-Wert für CQ umrechnen kann (z.B. so. wie DVD2SVCD das macht). Bereits damit hätte man ein probates Mittel für ein gutes Encoding, aber das Spielchen kann man noch weiter treiben, viel weiter.
Wenn ich z.B. weiß, dass ein Film mehr ruhige als Actionszenen hat, kann ich aus dem AVG-Wert mehr machen, nämlich den Actionszenen einen höheren und die ruhigen Szenen einen niedrigeren CQ-Wert zuweisen, und das in Abhängigkeit der Verteilung der Szenen. Statt des starren CQ-Wertes, den DVD2SVCD errechnet, hätte man so schon mal einen variablen Wert.
Ähnliches kann man mit der Bewegungssuche machen, sie nämlich gezielt an die Szenen anpassen.
Auch die Bitrate lässt sich so für jede der Szenen individuell festlegen.
Im Prinzip eine klasse Sache, das Problem dabei ist, all diese Möglichkeiten programmgesteuert zu optimieren. Wann ändere ich nur den CQ-Wert, wann die Bitrate, usw.?
Je mehr ich über dieses Projekt nachgedacht habe, desto schwieriger erschien es mir, irgendwann hab' ich's dann aufgegeben, aber der Traum ist immer noch da. ;)
@mb1
Ich hab' ReJig gerade mal auf eins meiner Videos von Hi8 los gelassen. Es sollte es auf 80% der Größe bringen.
Boah, das Teil ist ja aberwitzig schnell. Allerdings sehe ich auch bei 80% bereits Unterschiede. Die dürften 90% der der Leute aber kaum auffallen. Nicht schlecht, das Programm. |
|
|
Tsunami
Anmeldungsdatum: 12.02.2002
Beiträge: 1759
|
| Beitrag 31 - Verfasst am: Fr Okt 24, 2003 2:25 Titel: |
|
|
| Zitat: |
Das KVCD-Filter-Script basiert z.B. darauf.
Nun geht man also her, und macht mit AVISynth eine genaue Scene-Detection.
|
Könntest du mir mal dieses KVCD-Script zeigen oder zuschicken?
Wie genau macht man mit Avisynth eine Scene-Detection?
Mittlerweile habe ich glücklicherweise ein Avisynth-Plugin, welches tatsächlich im Stande ist, Text auszugeben.
Damit könnte man dann die Framenummern in eine Datei schreiben, in denen die Szenenwechsel stattfinden.
Man könnte auch irgendwie (WIE?) die Bewegungsintensität etc ermitteln und diese dann als Text speichern.
Sobald man diese Texte hat, dann ist es ein Leichtes, daraus ein TMPGENC-Script herzustellen.
Allerdings musst du dann irgendwie eine Tabelle schreiben, in der deine Erfahrungswerte abgelegt sind.
Also abgestuft nach Bewegung etc den jeweiligen CQ-Wert aufschreiben. |
|
|
Kika
Moderator
Anmeldungsdatum: 11.06.2001
Beiträge: 3397
Wohnort: Nahe München
|
|
|
bergH
Moderator
Anmeldungsdatum: 14.06.2001
Beiträge: 13672
Wohnort: Am Kamener Kreuz
|
| Beitrag 33 - Verfasst am: Fr Okt 24, 2003 16:26 Titel: |
|
|
tach auch !
Nur , daß Ihr nicht denk ich lese nicht mit.
Meldung !
@Kika
Nachtrag
Klar habe ich das mit dem Spoiler gelesen und benutze es auch schon , b-Frame Spoilage ~~0 (um 0 herum).
Nur, daß man nur noch ein B-Frame in die GOP haut, war mir :
a.) neu
b.)entfallen
c.) nicht geläufig
Zutreffendes bitte ankreuzen.
Zurück zum Thema (ist sehr interessant):
_________________
Gruß BergH |
|
|
SVCDFan
WM-Tipp König 2006
Anmeldungsdatum: 20.09.2001
Beiträge: 7567
|
| Beitrag 34 - Verfasst am: Fr Okt 24, 2003 17:16 Titel: |
|
|
| Zitat: |
Klar habe ich das mit dem Spoiler gelesen und benutze es auch schon , b-Frame Spoilage ~~0 (um 0 herum).
|
Bei DVD kann man bis zu -10 runtergehen. Das habe ich noch so in Erinnerung...
Wenn wir nur ein B Frame benützen, wie sieht dann die GOP eigentlich aus? 1/7/1 mit Closed GOP ansonsten 1/6/1?
_________________
Gruß SVCDFan |
|
|
mb1
Anmeldungsdatum: 06.06.2001
Beiträge: 3708
Wohnort: München
|
| Beitrag 35 - Verfasst am: Sa Okt 25, 2003 0:49 Titel: |
|
|
Aus meinen Tests habe ich insgesamt drei "gute" GOPs ermittelt.
Ist jetzt in MC 1.4 Notation:
1. 15/3/0: IBBPBBPBBPBBPBB I
2. 14/2/0: IBPBPBPBPBPBPB I
3. 15/1/0: IPPPPPPPPPPPPPP I
Messtechnisch hat bei mir Nr. 3 alles gewonnen. Und sie ist zudem noch doppelt so schnell als beispielsweise die gebräuchliche 1. GOP ...
Qualitativ sichttechnisch kann sie manchmal an bestimmten Sequenzen einen Tick schlechter sein als 1. oder 2., aber nicht wirklich nennenswert.
Wichtig ist, sie funktioniert nur wirklich gut bei hohen Bitraten, z.B. 7.000 avg
In meinem Testbericht (.chm) vor ein paar Monaten habe ich das recht sauber herausgearbeitet.
Wer also eine Stunde DV-Video auf eine DVD bringen möchte fährt am besten mit GOP Nr. 3, da sie neben sehr guter Qualität vor allem herausragende Geschwindigkeit bietet.
Bei einem in hoher Qualitätsstufe langsam arbeitenden Encoder wie dem Procoder spart man sich so etliche Stunden.
Zu beachten ist aber, dass nicht jeder Encoder diese GOP Nr. 3 überhaupt einstellen kann, so z.B. nicht der CCE.
Vielleicht gebe ich mal einen Auszug dieses Tests hier zum besten. Er war extrem interessant und lehrreich (für mich).
Das entscheidende war herauszufinden, ab welchem Wert ein B-Frame (mit starker Kompression) zu klein werden muss für gleichmäßig gute Qualität (im Vergleich zu den dazwischen liegenden größeren P- und I-Frames) bzw. wann erzeugen lauter ähnlich große P-Frames ein mindestens gleichwertiges Bild.
Zu den speziellen Requantisierern noch ein Wort:
Es gibt sie bereits und sie können auch die Auflösung verändern (zumindest vertikale/horizontale Halbierungen), nur ist nicht an sie ranzukommen.
Die Qualität scheint relativ gut zu sein (oberes DVDShrink-Niveau).
Leider besteht noch keine Nachfrage/Interesse ...
Die Leute sind einfach zufrieden, wenn sie DVDs schnell eindampfen und kopieren können
Ich habe da bereits ganz andere (spannendere) Anwendungen im Blick. Der Markt könnte bald boomen, vor allem, wenn man sieht, wie sich HDTV etc. in den nächsten Jahren durchsetzen (zugegeben 5-10 Jahre) wird.
_________________
Grüße
mb1
Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott." |
|
|
Helmut
globaler Moderator
Anmeldungsdatum: 06.05.2001
Beiträge: 30601
Wohnort: Frankfurt
|
| Beitrag 36 - Verfasst am: Sa Okt 25, 2003 10:18 Titel: |
|
|
Vielleicht gebe ich mal einen Auszug dieses Tests hier zum besten
Mach dat
B.T.W.
MC 1.4 ... hast an den Parametern geschraubt ?
> Suchmethode
> Suchbereich
> Quantisierung Matrizes
> Suchbereich für Pixelbewegung
_________________
Wenn mer sich uffreche will: - Eintrachtfan und SPD Mitglied! |
|
|
conan
Anmeldungsdatum: 24.04.2002
Beiträge: 3814
Wohnort: Wohnort
|
| Beitrag 37 - Verfasst am: Sa Okt 25, 2003 18:57 Titel: |
|
|
wäre auch sehr interessiert!
der mc gefällt mir immer besser..
_________________
Das perlt jetzt aber richtig.
------
Nachtisch essen ist der erste Schritt zum Gasgrillen.
---
http://tinyurl.com/d4r54z |
|
|
Helmut
globaler Moderator
Anmeldungsdatum: 06.05.2001
Beiträge: 30601
Wohnort: Frankfurt
|
| Beitrag 38 - Verfasst am: Sa Okt 25, 2003 20:36 Titel: |
|
|
der mc gefällt mir immer besser..
Bin dabei zu experimentieren. Habe mal einen etwas kritischen (teilweise Analog, teilweise DV und ziemlich verrauschte Szenen / Innenaufnahmen, schlechte Lichtverhältnisse) Film sowohl in ProCoder als auch in MC encocdiert. Beim MC bin ich mir nicht sicher ob ich da Optimale Einstellungen vorgenommen habe.
Na ja .. im Ergebnis sehe ich einen leichten Vorteil für den ProCoder (Qualität) .. allerdings zum Preis von ekelhaft langen Encodierzeiten So wie wir ja gehört haben soll der neue ProCoder 2.0 jedoch erheblich flotter sein. Also .. schau mer mal.
_________________
Wenn mer sich uffreche will: - Eintrachtfan und SPD Mitglied! |
|
|
kempfand
Anmeldungsdatum: 26.10.2001
Beiträge: 157
|
| Beitrag 39 - Verfasst am: Sa Okt 25, 2003 21:04 Titel: |
|
|
Der vergleich ProCoder zu MC (oder anderen) ist m. Meinung darum nicht einfach, weil der intern ProCoder filtert (und wohl darum meist so gute Resultate erzielt !). Wurde glaube ich in einem anderen Threat schon von mb1 gezeigt.
Ich habe z.B. Szenen, die mit CCE od. MC 'soso lala' kommen, und mit ProCoder recht gut. Wenn ich die Szenen aber mit entsprechenden Avisynth-Skripten vor-filtere, dann erreiche ich mit CCE (od. MC) fast ProCoder-Niveau.
Gruss,
Andreas |
|
|
|
FAQ
Suchen
Mitgliederliste
Einloggen, um private Nachrichten zu lesen
Profil
Login
Registrieren
