Hallo, ich hatte vor längerer Zeit mal den DivX-Codec auf meinem System installiert und mit Mühe und Not eine funktionierende Konfig zur Aufnahme von TV-Sendungen / Videos hingekriegt. Seit Festplattenwechsel und damit verbundener Neuinstallation von Win. XP und DivX funktioniert das nicht mehr (vermurkste AVI-Dateien), deshalb bin ich jetzt auf Xvid 1.2.2 umgestiegen (OpenSource ist eh vieeeel besser ;-) ). Problem: Xvid hat zig Knöpfe und Regler und ich keine Ahnung von diesem Kram, aktuell sind die Standardeinstellungen drin. Ich muss zugeben das mich Codecs und Co. absolut nicht interessieren, das Ganze soll einfach funktionieren. Google ist deshalb wenig hilfreich, ich hab einfach keine Lust stundenlang seitenweise Forenbeiträge und Tutorials zu analysieren um ein simples Video aufzunehmen. (Anmerkung s.u.*) Frage: Gibt es bewährte Einstellungen für diesen Codec um eine gute Qualität zu erhalten oder sind die Std-Einstellungen schon optimal? Anders gefragt, gibt es Einstellungen die nicht nur die Dateigröße sondern auch die Qualität erhöhen? Die Aufnahme darf ruhig Ressourcen (RAM+CPU+HDD) fressen wenn es was bringt(!), hauptsache ich krieg min. 2Std. auf eine DVD (nicht CD!) und VLC spielt das Ergebnis ab. Noch ein paar Infos: Das Ausgangsmaterial kommt entweder als FBAS(?) per Cinchkabel vom DVB-T-Dekoder oder direkt von der internen TV-Karte, als Bildgröße ist 768*576 (max) eingestellt. PC ist schon älter, hat zwei (bzw. einen Dualcore) Pentium 4 mit 2,8GHz und 1GB RAM drin, dazu ne SATA HDD. Wünsche 'nen guten Start in die neue Woche! ------ (Anmerkung*) (Bevor sich jetzt jemand aufregt und mit Eigeninitiative, Faulheit und Google kommt: Ich gehöre nicht zu den Leuten die einem Problem gegenüber sofort das erstbeste Forum suchen und eine Anfrage hinscheißen in der Hoffnung jemand nimmt ihnen die Arbeit ab. Man muss aber auch nicht alles selber machen und können und das Rad ständig neu erfinden, es gibt Dinge da ist es besser kurz die richtigen Leute zu fragen und gut ist.)
Wenn Plattenplatz keine Rolle spielt: Aufnehmen mit dem huffyuv 2.1.1. (verlustfrei beim komprimieren) Zur DVD umrechnen mit DivXtoDVD 0.5.3. (Freeware) An DVD Rohlingsgröße anpassen mit DVDShrink, Ausgabe als ISO. Brennen mit Brennprogramm Deiner Wahl.
Moin! Naja, keine Rolle ist etwas übertrieben. 2 Std. auf eine DVD sind halt Minimum, etwas mehr ist natürlich nicht schlechter... Ich vermute mal der Quotient Qualität/Bitrate sinkt irgendwann, d.h. es gibt eine maximale sinnvolle Bitrate. Wenn mit dieser Einstellung z.B. 3 Std. möglich sind ist es natürlich nicht sinnvoll mehr Daten zu erzeugen nur um die max. Länge zu verringern ohne Qualitätssteigerung. Ich hab ja auch kein HD-Ausgangsmaterial, irgendwo wird es (wie bei MP3)sinnvolle Grenzen geben. Nur hab ich keine Ahnung von der Sache... Grundätzlich sollen die Video auf der HDD bleiben, auf DVD kommen die nur als Backup. Xvid ist wohl was für fortgeschrittene Nutzer die die Details vom Codec kennen und alles genau einstellen wollen wenn es z.B. auf jedes MB ankommt. Ich suche einfach eine Möglichkeit mal eben ein Video aufnehmen ohne die Rohdaten nochmal neu codieren oder nachbearbeiten zu müssen. Während der Aufnahme soll der PC ruhig arbeiten, dafür soll dann aber eine "fertige" Datei rauskommen welche direkt gebrannt bzw. auf der HDD bleiben kann ohne unnötig(!) Speicher zu fressen. Dass das möglich ist weiss ich, ich brauche "nur" die richtigen Einstellungen... (Hoffentlich ist das verständlich, ich krieg das einfach nicht besser erklärt...)
Ahnungsloser schrieb: > Problem: Xvid hat zig Knöpfe und Regler und ich keine Ahnung von diesem > Kram, aktuell sind die Standardeinstellungen drin. Ahnungsloser schrieb: > Ich muss zugeben das mich Codecs und Co. absolut nicht interessieren, > das Ganze soll einfach funktionieren. In diesem Falle hilft nur "Probieren geht über studieren"... ;) Vor allem da keiner weiß was für dich "gut genug ist", vorallem bei FBAS ist eher das Eingangsmaterial das Problem.
Also, wenn es bei Xvid bleiben soll (ich ging von DVDs als Endprodukt aus), dann variable Bitrate deaktivieren und als Bitrate 1200 bis 1500 Kb/s wählen. Die anderen Einstellungen wirst Du selber ergründen müssen, da ich schon vorher von einer älteren XVid Version (ohne diese endlosen Einstellmöglichkeiten), auf o.g. Verfahren umgestiegen bin. Anhand der Bitrate in Beziehung zur Rohlingsgröße (Tonspur nicht vergessen!) kannst Du Dir übrigens ausrechnen, was auf einen Rohling passt.
Moin! > In diesem Falle hilft nur "Probieren geht über studieren"... ;) Ich hab schon ein bisschen rumgespielt, ehrlich gesagt sehe ich auf die Schnelle oftmals keinen Unterschied zw. den verschiedenen Einstellungen (von denen ich meistens aber auch nicht weiß wozu die gut sind... ;-) ) > Vor allem da keiner weiß was für dich "gut genug ist", vorallem bei FBAS > ist eher das Eingangsmaterial das Problem. Ja, ich hab halt kein HD oder so. Deswegen dachte ich es gibt z.B. eine max. sinnvolle Bitrate und ähnliches. Beispiel: Ich habe 4,38GB und will min(!) 2 Std. aufnehmen. Jetzt kann ich natürlich diese Zahlen in den Rechner hämmern und die Bitrate bei Xvid einstellen, nur... ist das sinnvoll? Liegt die BR vielleicht so hoch das man sie deutlich verringern (und damit die Aufnahmelänge deutlich erhöhen) kann ohne sichtbaren(!) Qualitätsverlust? Ich versuchs nochmal anders zu erklären: Beispiel MP3: Ein Titel mit 64kbps hat eine schlechte Qualität. 128 sind deutlich besser, 256 auch und 320 logischerweise auch. Jetzt könnte man nat. einfach immer 320kbps nehmen, obwohl 256 vielleicht völlig reichen, und so Speicherplatz verschenken. (Jetzt bitte keine Diskussion über MP3-Bitraten... ;-) ) Wie ist das beim Video, wo liegt (ungefähr) das sinnvolle Maximum? Mit dem ungeschulten Auge hab ich da große Mühe das zu erkennen, außerdem hängt das u.U. vom Ausgangsmaterial ab (was für Reportagen ideal ist gibt im Actionfilm schlechte Ergebnisse)??? Und es gibt ja nicht nur die Bitrate, was ist mit den ganzen anderen Einstellungen, "Adaptive Quantization", "Global Motion Compensation" und dieser ganze Kram... Ich suche einfach sinnvolle Durchschnittswerte, es muss doch einen Videofreak geben der empirisch oder wissenschaftlich passende Einstellungen ermittelt hat... Entschuldigt bitte den Roman, irgendwie schaffe ich es nicht meine Gedanken in (wenige!) Worte zu fassen... Das dieser PC-Kram immer so kompliziert ist. :-(
>Bitrate 1200 bis 1500 Kb/s
Danke mhh, das ist doch schon mal eine Hausnummer! Vielleicht melden
sich ja andere Nutzer mit weiteren Richtwerten.
Grundsätzlich ist mir der Codec eigentlich ziemlich egal (Hauptsache der
Kram funktioniert und VLC kommt mit den Daten klar), ich hab einfach
gesucht und bin auf Xvid gestoßen...
Ach Leute, warum muss dieser Schrott immer so kompliziert sein? seufz Xvid erzeugt sebst bei niedrigen Bitraten kein komplett ruckelfreies Video, außerdem stürzt das Prog. regelmäßig am Ende der Aufnahme ab. DivX, was ich früher (alte HDD, s.o.) ab und zu ohne größere Probleme verwendet hab produziert vermurkste AVI-Files:
1 | avi warning: unknown chunk (not loaded) |
2 | avi error: no key frame set for track 0 |
3 | avi warning: cannot get packet header, track disabled |
4 | main warning: PTS is out of range (-10000), dropping buffer |
5 | main warning: PTS is out of range (-32219), dropping buffer |
6 | main warning: PTS is out of range (-33988), dropping buffer |
7 | (VLC Verbosity 1) |
Kann da jemand was mit anfangen? Google findet nichts (oder ich bin zu blöd zum Suchen). "Ohne Komprimierung" liegt in der Größenordnung 1 GB pro Minute(!), völlig inaktzeptabel. Langsam hab ich echt die Sch*** voll, sitze schon den ganzen Tag an dem Mist! Warum ist es heutzutage so schwer ein einfaches Video aufzuzeichen?!?
Ich hab "früher" immer nen MJPEG Codec verwendet, das war problemloser, wobei du bei nem Dualcore definitiv keine Probleme kriegen solltest. Mal ne Frage was (TV/Videocamera?) und womit zeichnest du den auf(Programm/Hardware)?
Moin! Danke für die Hilfsversuche! Das Programm heisst "MeuhMeuhTV" http://sourceforge.net/projects/meuhmeuhtv/ , so ziemlich das einzige womit es damals (s. erster Post) funktioniert hat. Hab schon ein anderes Programm ( http://www.kastortv.org/ ) probiert, damit geht es irgendwie gar nicht... Virenscanner und Co. hab ich auch schon probeweise abgeschaltet, Xvid ruckelt weiterhin. Ich meine mich zu erinnern das Problem schon mal gehabt zu haben, deswegen hatte ich DivX probiert und schlussendlich genutzt. Der ist dem Namen nach auch speziell für DualCore gemacht bzw. dafür geeignet: "DivX ... (2 Logical CPUs)" Den Rest hatte ich oben erwähnt, welche Infos brauchst du noch? (nicht böse gemeint falls es so klingt) >Noch ein paar Infos: Das Ausgangsmaterial kommt entweder als FBAS(?) per >Cinchkabel vom DVB-T-Dekoder oder direkt von der internen TV-Karte (*), als >Bildgröße ist 768*576 (max) eingestellt. PC ist schon älter, hat zwei >(bzw. einen Dualcore) Pentium 4 mit 2,8GHz und 1GB RAM drin, dazu ne >SATA HDD. (*) Der DVB-T Dekoder bekommt die Daten in Wirklichkeit aus der Telefondose, hatte das oben vereinfacht weil es eig. nichts zur Sache tut. Bild+Ton gehen vom Dekoder in den PC (per Cinch), den Tuner der TV-Karte nutze ich sehr selten (eig. nur um einen VCR anzuschließen...) Mich regt die Sache deswegen so auf weil es ja schon mal funktioniert hat, die gleiche Konfig jetzt aber nicht will. Gerade diese Sache mit den AVI-Files und DivX ist merkwürdig, auf den ersten Blick schauen die Dateien im Hex-Editor ganz OK aus (sehr oberflächlich geguckt)...
Die fertige (fehlerhafte) datei mal in VirtualDub einlesen und ohne Rekomprimierung bei Bild und Ton wieder abspeichern. Das behebt manche Fehler.
Danke für den Tipp, geht leider nicht. Hab VirtualDub und Avidemux probiert, ersterer erkennt die Datei gar nicht, letzterer zeigt nur eine grüne Fläche und gesamt 0 Frames...
Bei VirtualDub beim öffnen ein Häkchen bei "ask for extended..." setzen.
Und dann im aufgehenden Fenster nach der Dateiauswahl "Re-derive.." und "Open in Avi-File..." ebenfalls Häkchen rein.
Keine Chance, hab verschiedene Einstellungen ausprobiert, geht alles nicht. aktueller Stand also: -Xvid ruckelt und erzeugt öfters mal einen Absturz -DivX erzeugt vermurkste AVI-Files :-(
Was passiert, wenn Du mit VirtualDub das Aufnehmen machst (Capture AVI)? Wenn das auch nicht hilft, mache es so: Beitrag "Re: Xvid: optimale / sinnvolle Einstellungen ?" und Du musst Dich nicht mehr ärgern, auch wenn Umrechenaufwand dabei ist.
Ahnungsloser schrieb: > Seit Festplattenwechsel Ein krankes Rennpferd kommt selten ins Ziel. Wenn ich die lange Geschichte so lese, dann frag ich mich ob das System überhaupt noch gesund ist und die HD ausreichend schnell die Daten verkraftet. Ein Auge in die Ereignisanzeige usw. könnte evtl. neue Erkenntnisse bringen. Mal Sandra gefragt? http://www.pcwelt.de/downloads/Systemanalysetool-SiSoftware-Sandra-Lite-563205.html
>Was passiert, wenn Du mit VirtualDub das Aufnehmen machst (Capture AVI)? Wusste gar nicht dass das möglich ist! Komme aktuell leider nicht zum Testen, am Wochenende dürfte (hoffentlich) mehr Zeit sein. Ich meld mich! >Wenn ich die lange Geschichte so lese, dann frag ich mich ob das System >überhaupt noch gesund ist und die HD ausreichend schnell die Daten >verkraftet. Dem System gehts eigentlich ganz gut, hab Windows erst vor wenigen Wochen auf eine fabrikneue HDD installiert. Virenscanner und Co. hatte ich (testweise!) abgeschaltet, die fressen u.U. doch einiges an RAM & Performance. Ereignisanzeige ist relativ unauffällig, ein paar Kleinigkeiten sind bei Windows irgendwie immer.
Wenns mit Xvid nicht mehr hinzukriegen ist, dann versuche doch mal einen anderen Codec. Beispielswese H.264 (MPEG-4) scheint eine gute Alternative zu sein, falls Dein PC über ordentlich Rechenpower verfügt. Ich weiss jetzt aber nicht was Du alles installieren musst um gleich echtzeitmässig in diesem Format aufzuzeichnen. Zum konvertieren vorhandener Videos verwende ich x264 http://de.wikipedia.org/wiki/X264
So, endlich mal 5 Minuten Zeit...
>Was passiert, wenn Du mit VirtualDub das Aufnehmen machst (Capture AVI)?
Nach einigen Problemen da ein TV-Bild zu bekommen: Funktioniert schon
ganz gut, sowohl mit DivX als auch Xvid, jeweils mit
Standardeinstellungen. :-)
Optimal ist die Sache aber anscheinend noch nicht, die Anzeige "CPU
Usage" von VirtualDub geht bis auf 133%... Da muss ich nochmal basteln,
außerdem will ich mal mit den Bitraten spielen. "mhh" schrieb von
1200-1500 kB/s, aktuell liege ich wohl darunter, vielleicht geht da noch
was in Sachen Qualität.
Erstmal Danke für die Hilfe, ich meld mich nochmal mit "abschließenden
Forschungsergebnissen" (kann dauern).
@Johnny B.
Lass mal, "ordentlich Rechenpower" ist bei einem mehrere Jahre altem
System vermutlich nicht (keine Ahnung was die aktuellen Modelle
schaffen).
Wie versprochen gehts weiter. Ich gebe mich geschlagen und wähle die langwierigere Methode: Aufnahme mit huffyuv 2.1.1, anschließend ggf. schneiden (Werbung raus usw.) und mit Xvid (eventuell DivX, auf jeden Fall "2-pass") konvertieren, das alles mit VirtualDub. Bisher habe ich nur ein paar Testaufnahmen gemacht, Schnitt und Konvertierung fehlen noch. Die Aufnahme in Echtzeit durch DivX und Co. zu jagen bringt nichts, ich kann einstellen was ich will, entweder die Qualität gefällt mir nicht oder es ruckelt, reine Zeitverschwendung. Die mit huffyuv verlustfrei komprimierten Dateien haben eine einwandfreie Qualität (für ein Analogsignal), belegen allerdings mal eben 20GB pro Stunde... Laut VirtualDub ist die CPU während der Aufnahme nur zu etwa 30% ausgelastet, trotz aktiviertem Virenschutz / ... und anderweitiger Benutzung vom PC (Firefox, MP3 mit VLC). Das ist natürlich prima um vorhandenes Material zu überspielen ohne stundenlang den PC zu blockieren, allerdings hab ich noch ein paar kleinere Probleme : Bei einer Aufnahmezeit von 50 min gibt es 7 "dropped Frames" und 104 "inserted Frames". Was bedeutet das, warum werden da Frames eingefügt? Die aufgenommenen Dateien werden problemlos abgespielt, allerdings stockt das Bild an einigen Stellen und VLC meckert recht ordentlich:
1 | main warning: PTS is out of range (-32998), dropping buffer |
2 | main warning: the mixer got a packet in the past (322653) |
3 | [...] |
4 | main warning: the mixer got a packet in the past (22653) |
5 | main warning: mixer start isn't output start (7991) |
6 | main warning: mixer start isn't output start (8) |
7 | main warning: early picture skipped |
8 | main warning: PTS is out of range (-32979), dropping buffer |
9 | main warning: the mixer got a packet in the past (244649) |
10 | [...] |
11 | main warning: the mixer got a packet in the past (2110) |
12 | main warning: mixer start isn't output start (744) |
13 | main warning: PTS is out of range (-39877), dropping buffer |
14 | main warning: computed PTS is out of range (90124), clearing out |
15 | main warning: PTS is out of range (90009), dropping buffer |
16 | main warning: output PTS is out of range (95361), clearing out |
17 | main warning: PTS is out of range (66789), dropping buffer |
18 | main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 421 ms) |
19 | main warning: early picture skipped |
20 | main warning: PTS is out of range (15021), dropping buffer |
21 | [...] |
22 | main warning: PTS is out of range (-33979), dropping buffer |
23 | main warning: output date isn't PTS date, requesting resampling (48240) |
24 | main warning: buffer is 48239 late, triggering upsampling |
25 | main warning: late picture skipped (5986 > -1532) |
26 | main warning: PTS is out of range (-27832), dropping buffer |
27 | main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 426 ms) |
28 | main warning: computed PTS is out of range (39244), clearing out |
29 | main warning: PTS is out of range (86009), dropping buffer |
30 | main warning: output PTS is out of range (45161), clearing out |
31 | main warning: PTS is out of range (62789), dropping buffer |
32 | main warning: early picture skipped |
33 | main warning: PTS is out of range (15021), dropping buffer |
34 | [...] |
35 | main warning: PTS is out of range (-32979), dropping buffer |
36 | main warning: late picture skipped (68986 > -974) |
37 | main warning: late picture skipped (28986 > -974) |
Direkt nach dem Öffnen der Datei kommt zudem der Fehler
1 | main error: blending YUVA to I422 failed |
2 | [zigfach wiederholt] |
. Das Stocken ist allerdings nicht reproduzierbar, d.h. wenn ich die selbe Stelle nochmal abspiele läuft das Video flüssig. Könnte das mit den eingebauten bzw. verworfenen Frames zusammenhängen? Ich habe wie gesagt noch nicht mit der Konvertierung gebastelt, wenn das Ausgangsmaterial Fehler hat ist das nicht wirklich sinnvoll. Wer hat Ahnung von der Sache und kann ein paar Zeilen dazu schreiben?
Hier noch die Anzeige von VirtualDub am Ende der Aufnahme, hatte mir das extra abgespeichert.
Ahnungsloser schrieb: > Bei einer Aufnahmezeit von 50 min gibt es 7 "dropped Frames" und 104 > "inserted Frames". Was bedeutet das, warum werden da Frames eingefügt? Weil ein Fehler auftritt, welcher aber bedeutungslos (Du merkst nichts davon bei der Wiedergabe) ist. Ahnungsloser schrieb: > Die aufgenommenen Dateien werden problemlos abgespielt, allerdings > stockt das Bild an einigen Stellen und VLC meckert recht ordentlich: Das hängt nur mit der hohen Datenrate zusammen. Das Stocken verschwindet nach der Komprimierung auf das Format Deiner Wahl ebenso wie die Fehlermeldungen dann verschwunden sein dürften. Du brauchst also noch nicht in Panik zu verfallen. :)
mhh schrieb: > Du brauchst also noch nicht in Panik zu verfallen. :) Noch nicht. :-) :-) > Weil ein Fehler auftritt, welcher aber bedeutungslos (Du merkst nichts > davon bei der Wiedergabe) ist. Nur aus Neugier: Was für ein Fehler? Was ich nicht verstehe: Wo kommen die eingefügten Frames her, wird da einfach das Bild kurz angehalten d.h. der vorige Frame kopiert und nochmal eingefügt? > Das Stocken verschwindet > nach der Komprimierung auf das Format Deiner Wahl ebenso wie die > Fehlermeldungen dann verschwunden sein dürften. Ich war mir nicht sicher ob es mit der Benutzung des PC während der Aufnahme zusammenhängt, wollte nur sicher gehen. Wenn die Fehler durch die Konvertierung verschwinden ist ja alles gut, dann kann ich weiterhin den PC während den nächsten Aufnahmen nutzen und mich aktuell erstmal dem nächsten Schritt (schneiden) widmen, mal gucken wie das so funktioniert. Anschließend die richtigen Einstellungen für die Konvertierung finden... Ich will nur sichergehen dass ich alles richtig mache und nicht nochmal neu anfangen muss, deshalb die vielen Fragen. So viel Zeit hab ich auch nicht... Danke für die Hilfe!
Ich verwende für Videos unterdessen immer den Avidemux, da ich mit Virtual Dub nicht immer klar gekommen bin und SUPER (konvertierungs Tool) mir zu gross war. Mit Avidemux gibt es auch gleich einen Video-Kalkulator, in dem du grösse und Dateiformat einspeisen kannst. Dann berechnet er dir gleich, mit welcher Bitrate er konvertieren wird. Was VLC angeht: Bei mir macht er auch manchmal einige Fehler, indem er das Bild nicht sauber wiedergibt und dann ca. 3 sekunden lang alles verpixelt ist, hab aber bisher noch nicht herausbekommen woran das liegt.
Ahnungsloser schrieb: > Nur aus Neugier: Was für ein Fehler? Z.B. werden Frames ausgelassen oder hinzugefügt, um Bild und Ton synchron zu halten in der aufgenommenen Datei. Mit dem Computer andere Sachen zu machen während der Aufnahme ist auf Grund der hohen aufzuzeichnenden Datenrate nicht empfehlenswert. Das kann Probleme machen.
mhh schrieb: > Ahnungsloser schrieb: >> Nur aus Neugier: Was für ein Fehler? > > Z.B. werden Frames ausgelassen oder hinzugefügt, um Bild und Ton > synchron zu halten in der aufgenommenen Datei. > OK, soll mir Recht sein. ;-) > Mit dem Computer andere Sachen zu machen während der Aufnahme ist auf > Grund der hohen aufzuzeichnenden Datenrate nicht empfehlenswert. Das > kann Probleme machen. Grmbl... Ich hab eine Menge Videos zu überspielen und nur einen PC, das ist sehr unpraktisch. Über Nacht kann ich die Sache nicht laufen lassen weil ich im Durchschnitt alle 60-90 Minuten eine neue Aufnahme starten müsste und tagsüber ist der PC so ewig lange blockiert. Grmpf! :-( Meinst du die Fehler im VLC würden verschwinden wenn ich den PC während der Aufnahme komplett in Ruhe lasse? Ich meine an sich funktioniert es ja trotz moderater(!) PC-Nutzung während der Aufnahmen, wäre schon gut wenn ein bisschen Surfen // Musik hören // Programmieren trotzdem möglich ist. Andererseits, 20GB/h sind >5MB/s(!), das ist schon was! Problem ist wie gesagt das ich den Prozess nicht automatisieren kann, sonst wäre das ja kein Problem (über Nacht oder tagsüber wenn ich nicht zu Hause bin). Naja, Pech gehabt. Aktuell bastel ich erstmal mit den vorhandenen Testaufnahmen um mit VirtualDub klarzukommen und den Codec für die endgültige komprimierte Datei einzustellen. Wenn ich mich etwas eingearbeitet habe werden die aktuellen Dateien wohl im Müll landen und ich fange mit den echten Videos an.
Ahnungsloser schrieb: > Meinst du die Fehler im VLC würden verschwinden wenn ich den PC während > der Aufnahme komplett in Ruhe lasse? Versuche das nach der Komprimierung, ob die Fehlermeldungen bleiben. Auch mal 10 min Aufnahmetests machen mit und ohne nebenbei-Benutzung. Jede Hardware reagiert anders. Ich nehme in 720*576 auf, da ist die Datenrate jedenfalls noch höher als bei Dir.
So, bin etwas weiter. Ich stelle fest ein paar Stunden Videos überspielen ist in dieser ach so modernen Welt ein schwieriges Unterfangen... Falls es Jemanden interessiert: Wo war ich beim letzten Mal stehen geblieben? Ach ja, das Rohmaterial und die VLC-Warnungen. Ich hatte mir ein Tutorial für Xvid [1] rausgesucht und wollte das jetzt mal anwenden. Naiv wie ich bin dachte ich diese "2-Pass"-Kompression funktioniert ohne Angabe einer Bitrate, bis ich die letzte Seite des Tutorials gelesen hatte. :-( Wenn man dann Google bemüht hagelt es Begriffe wie "Pixelbitrate" und "Komprimierbarkeitstest", dabei will ich doch nur ein Video aufnehmen... verzweifelt guck Wer sich detailliert mit diesem Zeug beschäftigen will ist hier [2] vermutlich ganz gut aufgehoben. Die ganzen Bitratenrechner helfen mir nur bedingt, hätte nicht gedacht dass das dermaßen kompliziert ist! Für einen ersten Test Pi * Daumen 2000kBit/s gewählt und VirtualDub laufen lassen. Für 1,5h Video hat das Dingen sagenhafte 7 Stunden (!) gerechnet... Das Ergebnis ist gerade noch 1,9 GB groß und ich muss sagen "Respekt", die Qualität an sich ist erstaunlich! Bei bewegten Bildern sind allerdings Schlieren oder irgendwelche Artefakte zu sehen, besonders an harten Kanten (z.B. Zeichentrick). Auf den ersten Blick sind diese auch im mit huffyuv komprimiertem Material vorhanden, die Bitrate ist also anscheinend unschuldig. Ich hatte allerdings noch keine Zeit mir die Aufnahme komplett anzugucken und mit dem Original zu vergleichen, mal sehen. Was die Fehlermeldungen angeht, ganz zufrieden ist VLC nicht: Direkt nach dem Öffnen der Datei gibts folgende Meldungen:
1 | avi warning: unknown chunk (not loaded) |
2 | main warning: vlc_object_find_name(postproc) is not safe! |
3 | main warning: PTS is out of range (-10000), dropping buffer |
4 | main warning: PTS is out of range (-33219), dropping buffer |
5 | main warning: PTS is out of range (-34988), dropping buffer |
Was sagen die Experten? Ich würde ja sagen so ein paar Warnungen direkt am Anfang sind harmlos. Beim Hin- und Herspulen gibts weitere "PTS is out of range", ich vermute aber das ist normal. Ob das Ruckeln noch vorhanden ist weiß ich nicht, dazu müsste ich die Aufnahmen mal komplett angucken und das braucht eben 1,5h... Vom Ergebnis hängt mein weiteres Vorgehen ab. Ach ja, Memo an mich selber: Einstellungen usw. aufschreiben. Der Krempel ist unglaublich kompliziert, aber jetzt ziehe ich das durch und bastele mir (hoffentlich) ein für alle mal eine funktionierende "Toolchain". mhh schrieb: > Ich nehme in 720*576 auf Ich auch. Fynn B. schrieb: > Mit Avidemux gibt es auch gleich einen Video-Kalkulator, in dem du > grösse und Dateiformat einspeisen kannst. Dann berechnet er dir gleich, > mit welcher Bitrate er konvertieren wird. Genau das ist ja das Problem, die Dateigröße ist zweitrangig. Mir geht es primär darum die beste sinnvolle Qualität zu erreichen. (Sinnvoll heißt die Bitrate nicht unendlich zu erhöhen wenn die sichtbaren Verbesserungen irgendwann gegen Null gehen.) > Was VLC angeht: Bei mir macht er auch manchmal einige Fehler, indem er > das Bild nicht sauber wiedergibt und dann ca. 3 sekunden lang alles > verpixelt ist Das kenne ich, solche Probleme treten mit den huffyuv komprimierten Aufnahmen auf. [1] http://www.schokoladenes.de/2008/09/videos-professionell-und-einfach-mit-xvid-komprimieren/ [2] http://encodingwissen.de/
Hallo, ich muss noch mal um Hilfe bitten. Ich schrieb weiter oben von einem Problem mit Schlieren im Bild: > Bei bewegten Bildern sind allerdings Schlieren oder irgendwelche > Artefakte zu sehen, besonders an harten Kanten (z.B. Zeichentrick). Wie ich mittlerweile rausgefunden habe sind diese Schlieren/Wischeffekte schon in der verlustfrei komprimierten Aufnahme vorhanden, wenn ich allerdings das Bild der Signalquelle "live" betrachte ist nichts zu sehen (auch nicht in Zeitlupe). Es muss also irgendwie mit der Aufnahme zusammenhängen. Ein Beispiel habe ich angehängt (Standbild aus der Aufnahme, die gelbe Fläche bewegt sich schnell nach rechts). Die Qualität ist niedrig aber ausreichend und die Datei ist schön klein (Nicht wahr Falk? ;-)). Hat jemand einen Tipp? Ich vermute es gibt einen Zusammenhang mit dem Zeilensprungverfahren des Videobildes, vielleicht eine falsche Einstellung während der Aufnahme mit VirtualDub?
Ahnungsloser schrieb: > Ich vermute es gibt einen Zusammenhang mit dem > Zeilensprungverfahren Hört sich danach an... Bei der ganzen Kodiererei, schau mal nach "Deinterlacing", das dann Einschalten und Methode (Angleichen, Bob, Weaving, ..., halt ausprobieren) wählen, Testen.
PS: Der Effekt nennt sich Kammeffekt. Wunderschön hier http://de.wikipedia.org/wiki/Deinterlacing beschrieben und visualisiert.
Butoth schrieb: > PS: Der Effekt nennt sich Kammeffekt. Danke, dann werd ich mal Google anschmeißen...
VERDAMMTE SCHEISSE NOCHMAL!!! Es kann doch nicht so schwer sein ein stinknormales Video aufzunehmen!?! VirtualDub hat einen bzw. mehrere Deinterlacer (versteckt unter "Filter" bzw. "Filter Chain"), aber die enstehende Qualität ist schlecht und die Dateien sind deutlich größer, vermutlich weil wieder irgendwo irgendwelche Formate unkompatibel sind und konvertiert werden. Wisst ihr was das Schlimmste ist? Alle Sendungen die ich aufnehmen will liegen bereits in einwandfreier digitaler Qualität auf der Festplatte vom TV-Empfänger, aber irgendein *** Sesselfurzer hat beschlossen das diese verschlüsselt sein müssen obwohl die Kanäle per DVB-T frei empfangbar sind. Ich will doch nur Sicherungskopien in einem offenen Format, das kann doch nicht wahr sein! Sch*** geldgieriges Pack und deren Rechtebeschränkungen. Argh ich hab die Schnauze voll, wie viele Stunden hab ich jetzt schon mit diesem Mist verbracht ohne ein einziges brauchbares Video produziert zu haben?
Warum nimmst du nicht einfach ein TV-Karte mit Hardwareencoder, z.B. Hauppauge PVR-150? Qualität ist vor der Aufnahme einstellbar und die Filmchen landen in Echtzeit MPEG-komprimiert auf der Platte. Der Prozessor schaut dabei nur gelangweilt zu. Das Rohmaterial kannst du anschließend mit Avidemux zurechtschnippeln, ohne daß zeitaufwendig neu gerendert werden muß.
Icke ®. schrieb: > Warum nimmst du nicht einfach ein TV-Karte mit Hardwareencoder, z.B. > Hauppauge PVR-150? Tja... Ich möchte/muss eigentlich mit der vorhandenen Hardware auskommen (schon aus finanziellen Gründen), außerdem dürfte die Qualität leiden wenn man das aufgenommene (und bereits verlustbehaftet codierte) Material schneidet und neu codiert. Die Sache mit der Kompression hat sich ja eigentlich auch erledigt, Xvid funktioniert, ich hatte Tests gemacht um eine passende Bitrate zu ermitteln, das Kodieren geht über Nacht usw... Ich dachte eigentlich ich kann jetzt endlich mal mit der Überspielerei der Videos anfangen, hatte schon 100GB (nur mit huffyuv komprimiert) aufgenommen zusammen und dann kommt dieser Deinterlacing-Mist! Langsam ist mal gut!
Deine Vorgehensweise sollte so sein: - mit huffyuv aufnehmen (hast Du ja schon gemacht) - mit VirtualDub schneiden, Ergebnis mit Deinterlacing-Filter entweder ohne Komprimierung (für DVD-Umrechnung) oder mit XVid für Avis abspeichern. Ahnungsloser schrieb: > hatte schon 100GB (nur mit huffyuv komprimiert) > aufgenommen Keine verlorene Mühe, die bekommst Du noch nutzbar auf diese Art.
mhh schrieb: > Deine Vorgehensweise sollte so sein: > > - mit huffyuv aufnehmen (hast Du ja schon gemacht) Ja, das funktioniert mittlerweile ganz gut. > - mit VirtualDub schneiden, Das wäre der nächste Schritt, hab ich noch nicht ausprobiert aber sollte wohl möglich sein. > Ergebnis mit Deinterlacing-Filter entweder ohne Komprimierung (für > DVD-Umrechnung) oder mit XVid für Avis abspeichern. Genau da liegt das Problem. Ich hab nur kurz die bzw. den Filter von VirtualDub getestet, der entfernt zwar diesen Kammeffekt einigermaßen aber erzeugt wieder andere Artefakte und vergrößert die Dateien (wenn man huffyuv als Ziel"format" auswählt, kann sein das das bei Xvid keinen Unterschied macht). > Ahnungsloser schrieb: >> hatte schon 100GB (nur mit huffyuv komprimiert) >> aufgenommen > Keine verlorene Mühe, die bekommst Du noch nutzbar auf diese Art. Wenn ich einen vernünftigen Deinterlacingfilter finde vielleicht. Mal ne ganz blöde Frage: Ich spreche meine TV-Karte unter VirtualDub über "Microsoft WDM Image Capture (Win32) (VFW)" an, wenn ich die Karte direkt auswähle kann ich nicht auf Video-In umschalten (Signal kommt ja nicht vom internem Tuner sondern von außerhalb über Cinch- bzw. S-Video-Buchse). Durch diesen "Umweg" kann ich die ausgewählte Videonorm nicht ändern, ist eigentlich auch egal weil das Bild vorhanden und in Farbe ist, ich vermute mal das wird automatisch detektiert. Trotzdem: Kann das irgendwie das Interlacing-Problem beeinflussen wenn jetzt z.B. die Videoquelle SECAM liefert und im PC formal PAL eingestellt ist?
Ahnungsloser schrieb: > der entfernt zwar diesen Kammeffekt einigermaßen > aber erzeugt wieder andere Artefakte und vergrößert die Dateien (wenn > man huffyuv als Ziel"format" auswählt, huffyuv nicht als Komprimierung danach wählen, nur für die Aufnahme. Ich selber speichere unkomprimiert ab und wandle dann in DVD Format. Versuche auch mal ein Stück unkomprimiert mit Deinterlace abspeichern, das wieder mit VD laden und dann XVid als Endprodukt auswählen.
Hallo, ich hol die Sache noch mal hoch, mir stinkt es ganz gehörig aber ich will (nach 6 Monaten) endlich eine Lösung finden und die Videos sichern. Problem ist noch immer das Deinterlacen. Ich habe mal einen kurzen Test mit den ersten 4 Filtern von VirtualDub (s. Anhang) gemacht: -(Die Einstellungen auf der rechten Seite wurden nicht verändert.) -In Sachen Geschwindigkeit nimmt sich das alles nicht viel (18-21fps). -Die unterschiedliche Größe der Dateien (s.o.) beachte ich erstmal nicht, ich vermute/hoffe dass das Ergebnis nach dem Komprimieren mit XVID gleich ist. -Getestet wurde mit Zeichentrick. So wie ich das sehe scheint diese Art Video am kompliziertesten für die Filter zu sein, stimmt das? Ehrlich gesagt sind Reportagen/Spielfilme/... fast schon ohne Deinterlacing zu gebrauchen, so stark wie bei Zeichentrick sind die Artefakte lange nicht (aber trotzdem vorhanden). Mein Favorit ist aktuell der "Bob"-Algorithmus, gefolgt von "ELA" welcher mehr "örtliche Artefakte" (störende Punkte) erzeugt. "Yadif" überzeugt mich nicht, es bleiben einige Artefakte und der Algorithmus ist der langsamste. "Blend fields" hat praktisch überhaupt keinen Effekt. Bei allen Filtern tritt eine Art Ruckeleffekt ein, schnelle Bewegungen laufen nicht ganz flüssig. Sehr nervig, einen Grund habe ich aber noch nicht gefunden. Wie ist das, lässt sich das Ergebnis (the best=Bob) so einfach auf andere Videoarten (Spielfilme, Dokus, ...) übertragen? Und die ultimative Frage: Gibts noch bessere Deinterlacer die ohne (!!!) 42.000 ausgangsmaterial-spezifische Parameter gute Ergebnisse liefern? Genau da liegt nämlich das Problem, ich habe keine Ahnung davon und kann und will nicht für jede Sendung stundenlang testen und zig Parameter ermittlen! Ach so, noch was: Bei Yadif steht YV24, bei Bob und ELA RGB32. Was ist das genau und wo ist der Unterschied? Danke für eure Geduld & schöne erste Arbeitswoche nach den Ferien...
Als Aufnahme-Tool ist iuVCR nicht schlecht. Ich würde aber nicht direkt in divx/xvid/h264 oder sowas enkodieren, sondern mjpeg oder huffjuv nehmen, die erzeugen beide keine hohe CPU-Last und man hat keine Probleme mit dropped frames. Anschließend z.B. mit "handbrake" in xvid oder so konvertieren.
bluppdidupp schrieb: > Als Aufnahme-Tool ist iuVCR nicht schlecht. Danke für den Tipp, aber ich bleibe bei VirtualDub, zumindestens die Aufnahme funktioniert mittlerweile (puhh). > Ich würde aber nicht direkt in divx/xvid/h264 oder sowas enkodieren, > sondern mjpeg oder huffjuv nehmen, Ich nutze huffyuv für die Aufnahme, siehe oben. Als Zielformat ist Xvid vorgesehen, aber das Deinterlacen macht Probleme. > Anschließend z.B. mit "handbrake" in xvid oder so konvertieren. Ich nehme auch hier VirtualDub.
Ich wandle ebenfalls gerade angesammeltes Material, welches mir vorwiegend in MPEG (direkter DVB-T Stream) vorliegt nach xvid um. Inzwischen kann auch fast jeder Stand-Alone DVD-Player recht gut damit umgehen, wenn man nicht die gefühlten 782 möglichen Sonderfunktionen verwendet. Leider gibt es keine Einknopf-Lösung um Videomaterial auf dem einfachsten Weg zu konvertieren. Ich beschreibe mal meinen Weg, vielleicht nicht der beste aber mit den Ergebnissen bin ich recht zufrieden. Aufnehmen (Capturen) würde ich auf jeden Fall in Huffyuv und den Ton in WAV. Den Rechner dabei möglichst in Ruhe lassen, denn er muß ja die einzelnen Bilder "einfangen". Bei dem Schritt würde ich auch noch keine Filter einsetzen sondern das ganze einfach laufen lassen. Beim aufgenommenen Material muß man etwas unterscheiden, wie du schon festgestellt hast. Stichwort Deinterlacen: Dazu gibt es wohl die meisten Seiten im Netz und die unterschiedlichsten Philosophien. Ich verwende zum deinterlacen den smart-Deinterlace von Donald Graft. Ja, auch da kann man wieder viel einstellen, muß aber garnicht. Mit den von VirtualDub bin ich nie richtig klargekommen. Bei Material wie deutschen Spielfilmen, Ratgebern, Liveshows, vornehmlich deutsche Studioproduktion, hat man in der Regel schon Glück wenn man bei dem Deinterlacer beim Advanced-Processing "Field swap before phase shift" und "Phase shift" auswählt. Ich stelle das Ausgangsfenster dann auf 200% und scrolle dann über Stellen mit viel Bewegung um zu sehen ob die Kammeffekte weg sind. Klappt das nicht, wähle ich eine der anderen Optionen im Advanced-Processing aus. Meistens bekommt man es damit hin und dann sind auch ohne Flicken die Zeilen richtig zusammengesetzt. Klappt das damit nicht oder man hat Videomaterial wie US-Produktionen, Star-Trek Serien wäre z.B. solch ein Kandidat, lohnt sich das ausprobieren mit dem Advanced-Processing nicht. Sowas ist paarmal in den Formaten umgefummelt. Da lasse ich dann die Optionen aus und der Deinterlacer interpoliert dann je nach Bewegung selbst. Die Grundeinstellungen haben mir hier an sich immer gereicht. Soviel mal zum Deinterlace. Nützliche Filter gäbe es da noch genug zu nennen. Codieren in xvid: Im Grunde genommen ist es mir wurscht wie groß denn nun eine Datei wird. Meistens bleiben sie auf dem PC oder werden auf DVD gebrannt. Da ich damit nicht an eine Zielgröße der Datei gebunden bin, spare ich mir auch die direkte Eingabe der Bitrate und dann 2pass Codierung sondern ich nutze die Eingabe der Quantisierung. Das spart Zeit, der Encoder stellt sich auf die Situation im Video ein und die Dateigröße ergibt sich dann daraus. Ein guter Leitfaden zu dem ganzen und auch den xvid-Einstellungen findet sich bei http://encodingwissen.de/ Bei der Quantisierung differenziere ich so zwischen 2 und 8 (je kleiner die Zahl desto besser, größer das Ergebnis). Habe ich eine Ratgeber-Sendung, Dokumentation, die ich einfach nur mal noch aufheben möchte, bei der es nicht mehr so auf die Bildqualität ankommt, dann lasse ich sie auch mal auf 8 laufen. Darüber wird das nicht mehr wirklich gut. 5-6 sind da annehmbare Werte. Die Dateigröße entwickelt sich dann aus dem Bildinhalt. Man kann das gut an der "Projected File Size" beim codieren mit Virtual-Dub im Status-Fenster sehen. 5min laufen lassen, dann sieht man schon einen Trend was das wird. Habe ich Material das schon gut werden soll dann nehme ich so zwischen 3 und 4, auch mal 2. Das ist Geschmacksache, jeder hat da ein anderes Empfinden und wägt auch den Qualitäts/Platzbedarf ab. Für den Ton codiere ich mit dem Lame-Codec in den meisten Fällen 128kb/s, bei Sendungen mit Musik, Musikvideos etc. nach ermessen dann schon mal bis 192kb/s. Wichtig ist immer das deinterlacen, egal ob man es nun wahrnimmt oder es eher weniger auffällt. Die encodierten Dateien werden zum einen kleiner wenn die Kammeffekte rausgefiltert sind und zum andern kommt der Encoder auch besser damit klar - rechnet nicht so lange. Ich habe mir angewöhnt das Seitenverhältnis der Aufnahmen beizubehalten und nicht in der Größe umzufummeln. Das Ausgabefenster stelle ich dann je nachdem auf 4:3 oder 16:9 um. Wichtig ist: Im xvid-Einstellungsfenster bei Aspect-Ratio das Display-Format dann ebenfalls auf 4:3 oder 16:9 stellen. Steht das falsch, dann spielt vlc das fertige Video im falschen Anzeigeformat ab. Das läßt sich zwar dann in vlc korrigieren kann man aber vermeiden und was ein DVD-Player dann damit macht habe ich noch nicht probiert. Jetzt fällt mir nichts mehr weiter dazu ein. Mehr Einstellungen ändere ich garnicht. Vielleicht hilft das hier ein wenig weiter.
Probier doch mal avidemux. Das geht schon ziemlich Richtung Einknopflösung. http://avidemux.sourceforge.net/ http://www.avidemux.org/admWiki/doku.php
OK schrieb: > Inzwischen kann auch fast jeder Stand-Alone DVD-Player recht gut damit > umgehen, wenn man nicht die gefühlten 782 möglichen Sonderfunktionen > verwendet. Ich hab keinen DVD-Player, so mit stellt sich dieses Problem nicht. :-) > Aufnehmen (Capturen) würde ich auf jeden Fall in Huffyuv und den Ton in > WAV. Mache ich bereits so. > Den Rechner dabei möglichst in Ruhe lassen, denn er muß ja die > einzelnen Bilder "einfangen". Mache ich auch. > Bei dem Schritt würde ich auch noch keine > Filter einsetzen sondern das ganze einfach laufen lassen. Ja, das dürfte sinnvoll sein, auch weil man so das Rohmaterial hat und verschiedene Filter usw. probieren kann (was ich eigentlich NICHT für jede Aufnahme machen möchte!). > Stichwort Deinterlacen: Dazu gibt es wohl die meisten > Seiten im Netz und die unterschiedlichsten Philosophien. Man wird vor Möglichkeiten gerade zu erschlagen! > Ich verwende > zum deinterlacen den smart-Deinterlace von Donald Graft. Ja, auch da > kann man wieder viel einstellen, muß aber garnicht. Laut Google ein VirtualDub-Filter, werde ich mir angucken. > Bei Material wie deutschen > Spielfilmen, Ratgebern, Liveshows, vornehmlich deutsche > Studioproduktion, hat man in der Regel schon Glück wenn man bei dem > Deinterlacer beim Advanced-Processing "Field swap before phase shift" > und "Phase shift" auswählt. [...] > Klappt das damit nicht oder man hat Videomaterial wie US-Produktionen, > Star-Trek Serien wäre z.B. solch ein Kandidat, lohnt sich das > ausprobieren mit dem Advanced-Processing nicht. Sowas ist paarmal in den > Formaten umgefummelt. Das verstehe ich jetzt nicht. Werden per DVB-T verschiedene Formate ausgestrahlt? Naiv wie ich bin denke ich es gibt nur ein Format in welches das gesamte Material vor der Ausstrahlung konvertiert wird, stimmt das etwas nicht? > Soviel mal zum Deinterlace. Nützliche Filter gäbe es da noch genug zu > nennen. Gibt viel zu viele Deinterlacer, da blickt ja keiner durch. > Codieren in xvid: > [...] Hm. Mir ist die genaue Dateigröße auch nicht so wichtig. Soll ich jetzt beim Two-Pass-Verfahren bleiben oder doch wieder zurück? Egal, erstmal das Deinterlacingproblem lösen, eines nach dem anderen! > Für den Ton > codiere ich mit dem Lame-Codec in den meisten Fällen 128kb/s, bei > Sendungen mit Musik, Musikvideos etc. nach ermessen dann schon mal bis > 192kb/s. Klingt vernünftig, würde ich auch so machen. > Wichtig ist immer das deinterlacen, egal ob man es nun wahrnimmt oder es > eher weniger auffällt. Die encodierten Dateien werden zum einen kleiner > wenn die Kammeffekte rausgefiltert sind und zum andern kommt der Encoder > auch besser damit klar - rechnet nicht so lange. Das ist interessant! Ich habe eher das Gefühl das die UNkomprimierten Daten größer werden, wie es nach dem XVID-Durchlauf aussieht weiß ich nicht, so weit bin ich noch nicht gekommen. > Ich habe mir angewöhnt das Seitenverhältnis der Aufnahmen beizubehalten > und nicht in der Größe umzufummeln. Mache ich auch nicht. > Wichtig ist: Im > xvid-Einstellungsfenster bei Aspect-Ratio das Display-Format dann > ebenfalls auf 4:3 oder 16:9 stellen. Steht das falsch, dann spielt vlc > das fertige Video im falschen Anzeigeformat ab. Ist notiert. > Vielleicht hilft das hier ein wenig weiter. Auf jeden Fall! Was mich sehr interessiert: Gibt es irgendeine Sendungsart welche besonders schwierig zu deinterlacen ist, d.h. mit welcher man Deinterlacer testen und vergleichen kann? Ich habe gehört bei Zeichentrick gibt es meistens Probleme aufgrund der harten Kanten (starke abrupte Farbunterschiede), hast du da Erfahrungen? Der Hintergedanke ist der: Wenn man die Erfahrungen mit z.B. Zeichentrick auf andere Sendungsarten extrapolieren kann wird es DEUTLICH EINFACHER bzw. überhaupt erst möglich die Deinterlacer und ihre verschiedenen Einstellungen zu testen. Wenn ich für jede Zusammenstellung (Deinterlacer+Einstellungen) zig verschiedene Dateien bearbeiten lassen und anschließend vergleichen muss ist das kaum zu schaffen, sowohl von der Zeit für das eig. Deinterlacen her als auch vom Aufwand alles zu konfigurieren und anschließend zu vergleichen! Deswegen die obige Frage. Vielen Dank für deinen Beitrag! Mixer schrieb: > Probier doch mal avidemux. Das geht schon ziemlich Richtung > Einknopflösung. Ich muss zugeben ich bin misstrauisch, eine wirkliche Einknopflösung wird auch das nicht sein. Laut Wikipedia ist das Programm mit VirtualDub vergleichbar, ich denke mal man wird auch dort einiges einstellen müssen. Ich habe bereits zu viel Zeit in die Sache gesteckt um jetzt ein anderes Programm zu benutzen (vielleicht irre ich mich auch...), trotzdem Danke für den Hinweis!
Ahnungsloser schrieb: > Die Einstellungen auf der rechten Seite wurden nicht verändert Die besten Ergebnisse würdest du aber vermutlich mit einer doppelt so hohen Framerate erreichen (Also Option 3 oder 4) wenn das Ausgangsmaterial wirklich interlaced ist, vermutlich müsste man dann aber direkt während der Aufnahme das Filter anwenden. Ahnungsloser schrieb: > mit welcher man > Deinterlacer testen und vergleichen kann Schnelle Bewegungen sind auf jedenfall ein Problem, ggf. mal mit nem Actionfilm gegentesten?
Bei DVB-T, DVB-S etc. gibt es keine unterschiedlichen Formate. Unterschiedlich ist das Filmmaterial. Wie ich schon sagte ist eine Studioaufnahme anders als ein Actionfilm mit schnellen Bewegungen. Am verständlichsten wird das ganze wohl hier beschrieben: http://de.wikipedia.org/wiki/Deinterlacing Nach der Lektüre der Seite wird einem einiges klar und es stellt sich die Frage was denn nun tun? Im Grunde genommen kann man das treiben bis der Mond runterfällt. Für den Heimgebrauch ist es das beste etwas zu schauen welches Material man vorliegen hat um einen Kompromiss zu finden zwischen der Qualität und der Rechenzeit dafür. Wenn der Speicherplatz für die fertige Datei keine so große Rolle spielt würde ich auf jeden Fall zum 1-pass Encoding tendieren und den wie beschrieben mit der Quantisierung laufen lassen. Vorteil ist, dass sich Xvid dann bei Action-Scenen bei der Bitrate bedienen kann während in ruhigen nichts unnötig verballert wird. Mit der "Target-Quantizer" gibt man ihm eine gewünschte Qualität vor. 2-pass mit fixer Bitrate ist interessant, wenn eine bestimmte Zieldateigröße angepeilt wird die z.B. auf eine CD passen soll. Das stammt noch aus Zeiten wo DVD-Rohlinge teuer waren und es eine Freude war den letzten Indiana-Jones auf eine CD gequetscht zu haben. Dabei gibt man dem Encoder eine Bitrate mit. Der tüddelt das dann alles durch diese eine Wurst. In ruhigen Scenen reichts, wird es hecktisch löst sich das Bild in Würfel auf. Um dieses zu kompensieren kann man 2pass nutzen. Bei der Methode schaut sich der Encoder den ganzen Film an und entscheidet mehr oder weniger gut wie er die vorgegebene Bitrate günstig verteilen kann. Bei einem Action-Film kann es natürlich sein dass hier Ausschnitte zugunsten der vorgegebenen Dateigröße verhunzt werden. Ein Filmmaterial auf dass man sich quasi Einkalibrieren kann und diese Einstellungen dann immer nutzen kann, gibt es nicht so richtig. Ich habe gerade spaßhalber eine Folge "nano" von meiner DVB-T Box, eine auf Linux-VDR modifizierte Siemens Gigaset M740, gezogen. Da hat meine sonst übliche smart-deinterlace, zwei Kästchen anklicken und fertig-Methode nicht geklappt, obwohl es eine TV-Produktion ist. Auch die Alternativen haben nicht geklappt. So würde ich es dann, ebenfalls mit dem smart-deinterlace, auf der Bewegungserkennung laufen lassen. Ich möchte an dieser Stelle keine Werbung für Donald Grafts Deinterlacer machen, mit diesem bin ich halt bisher am besten hingekommen. Aber: Ich teste gerade mal mit dem VirtualDub internen und den Einstellmöglichkeiten. Mal sehen wie das so im Vergleich ist. Das alles kann schon frustrieren, ich wünsche trotzdem viel Spaß beim weiter dran tüfteln.
Läubi .. schrieb: > Ahnungsloser schrieb: >> mit welcher man >> Deinterlacer testen und vergleichen kann > Schnelle Bewegungen sind auf jedenfall ein Problem, ggf. mal mit nem > Actionfilm gegentesten? Puh, mal sehen ob ich da was passendes finde. Läubi .. schrieb: > Ahnungsloser schrieb: >> Die Einstellungen auf der rechten Seite wurden nicht verändert > Die besten Ergebnisse würdest du aber vermutlich mit einer doppelt so > hohen Framerate erreichen (Also Option 3 oder 4) wenn das > Ausgangsmaterial wirklich interlaced ist, Werde ich ausprobieren. > vermutlich müsste man dann > aber direkt während der Aufnahme das Filter anwenden. Macht das einen Unterschied ob man während der Aufnahme oder danach deinterlaced? Mein PC ist halt nicht der Schnellste, aufwändige Deinterlacingberechnungen während der Aufnahme packt der vermutlich nicht, auch das muss ich probieren. OK schrieb: > Unterschiedlich ist das Filmmaterial. Wie ich schon sagte ist eine > Studioaufnahme anders als ein Actionfilm mit schnellen Bewegungen. > > Am verständlichsten wird das ganze wohl hier beschrieben: > http://de.wikipedia.org/wiki/Deinterlacing Hab den Artikel gerade gelesen, so ganz klar ist mir das aber noch nicht, die ganzen Infos wollen erstmal verarbeitet (~verstanden/nachvollzogen) werden... > Im Grunde genommen kann man das treiben bis > der Mond runterfällt. Ja. :-( > Für den Heimgebrauch ist es das beste etwas zu > schauen welches Material man vorliegen hat um einen Kompromiss zu finden > zwischen der Qualität und der Rechenzeit dafür. Genau das versuche ich, aber so einfach ist auch das nicht. :-( > [XVid] Guck ich mir später an, eines nach dem anderen. > Ein Filmmaterial auf dass man sich quasi Einkalibrieren kann und diese > Einstellungen dann immer nutzen kann, gibt es nicht so richtig. Ich hatte es befürchtet. > Ich > möchte an dieser Stelle keine Werbung für Donald Grafts Deinterlacer > machen, mit diesem bin ich halt bisher am besten hingekommen. Guck ich mir an. > Das alles kann schon frustrieren, Oh ja! >ich wünsche trotzdem viel Spaß beim weiter dran tüfteln. Den werde ich bestimmt haben... (Ganz im Gegenteil). Fazit für mich: TESTEN TESTEN TESTEN Meine Signalquelle ist ein TV-Receiver der die Aufnahmen verschlüsselt (+*§@#&!) auf einer Festplatte ablegt. Am Besten wäre es wohl eine Art Testvideo (vielleicht 15 min lang oder so) mit verschiedenen Sendungsarten zu basteln und damit die einzelnden Deinterlacer zu vergleichen. Um auch Filter testen zu können die direkt während der Aufnahme laufen müsste ich dieses Testvideo allerdings auf der TV-Receiver-HDD haben, dass ist aber nicht vorgesehen. Ich hab das ganze zwar weit genug reverse-engineered um Aufnahmen zu einer Playlist zu kombinieren, aber eben nur komplette Aufnahmen. Fürs "Testvideo" brauche ich Sendungs_ausschnitte_ in der Playlist, nicht so einfach die ganze Sache. Software gibts dafür wohl auch nicht also heißt es mal wieder selber vieeeeeel Zeit aufbringen, forschen und falls nötig jede Menge C-Code produzieren. GRMPF!!! :-( (OT: Eigentlich will ich die Aufnahmen erstmal nur überspielen um Backups zu haben falls die HDD mal den Geist aufgibt oder der Dekoder durchdreht, aber das wird ja wohl so schnell nichts. Mal gucken ob irgendwo noch eine HDD rumliegt um die Rohdaten zu sichern, man weiß ja nie. Wäre sehr schade wenn die Daten verloren gehen.) Nochmal Danke für die Hilfe, ich melde mich sobald es was Neues gibt, kann etwas dauern...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.