da ich mich mit der Materie Videobearbeitung/Videoschnitt erst seit kurzem beschäftige, stoße ich naturgemäß auf das eine oder andere Problem. Zur Zeit versuche ich "altes" Video Material über eine Hauppauge WinTV PCI Karte zu capturen. Als Capturing-Software nutze ich Virtualdub bzw AV_IO. Mein Ziel ist es, ein möglichst geeignetes Ausgangsmaterial für den Schnitt und für das anschließende Digitalisieren und Brennen im SVCD Format zu bekommen. Auf verschiedenen Internetseiten wird dieser Vorgang beschrieben und es wird empfohlen im Format 480 x 576 (SVCD) zu capturen. Leider führt die Auswahl dieses Formats bei Virtualdub zu einem Fehler "unsupported video format" und AV_IO schüttelt ebenfalls den Kopf (beide scheinen nur 352 x 288 zu akzeptieren). Warum geht dies nicht? Liegt es an der Hauppauge TV-Karte? Gibt es evtl. ein Workaround um doch noch zu meinem Ziel zu kommen?
hallo,
das liegt an dem original-hauppauge-capture-driver.
im netz (z.b. auf google.de suchen) gibt es div.
gepatchte driver, die können dann auch vollbild.
aber! solltest du auf die idee kommen, in vollbild und
online-audiokompression (mp3 oder so) zu fahren,
würde ich dir nen 1,7er AMD (oder höher!) empfehlen.
dann klappt auch mit den frames ....
B.
(User Above) hat geschrieben:
:
: Hallo zusammen,
:
: da ich mich mit der Materie Videobearbeitung/Videoschnitt erst seit kurzem beschäftige,
: stoße ich naturgemäß auf das eine oder andere Problem. Zur Zeit versuche ich
: "altes" Video Material über eine Hauppauge WinTV PCI Karte zu capturen.
: Als Capturing-Software nutze ich Virtualdub bzw AV_IO. Mein Ziel ist es, ein
: möglichst geeignetes Ausgangsmaterial für den Schnitt und für das anschließende
: Digitalisieren und Brennen im SVCD Format zu bekommen. Auf verschiedenen
: Internetseiten wird dieser Vorgang beschrieben und es wird empfohlen im Format 480 x
: 576 (SVCD) zu capturen. Leider führt die Auswahl dieses Formats bei Virtualdub zu
: einem Fehler "unsupported video format" und AV_IO schüttelt ebenfalls den
: Kopf (beide scheinen nur 352 x 288 zu akzeptieren). Warum geht dies nicht? Liegt es
: an der Hauppauge TV-Karte? Gibt es evtl. ein Workaround um doch noch zu meinem Ziel
: zu kommen?
(User Above) hat geschrieben:
: hallo,
: das liegt an dem original-hauppauge-capture-driver.
: im netz (z.b. auf google.de suchen) gibt es div.
: gepatchte driver, die können dann auch vollbild.
:
: aber! solltest du auf die idee kommen, in vollbild und
: online-audiokompression (mp3 oder so) zu fahren,
: würde ich dir nen 1,7er AMD (oder höher!) empfehlen.
:
: dann klappt auch mit den frames ....
:
:
: B.
Merci B.(ritta) für den Tip. Werd mich gleich mal auf die Suche machen und heute abend testen. Zu deiner Randbemerkung...zum Glück hab ich nen 1,8er Athlon mit dem DDRam Board und ner schnellen UDMA-100 Platte. Hoffe, dass der nicht so schnell aus den Pantoffeln kippt.
Aaaaaaber...und dies wäre eigentlich ein weiteres Topic von mir gewesen...zumindest mit Virtualdub war ich nach den ersten Versuchen etwas enttäuscht bzw. verwundert. Jede Menge 'dropped Frames'. Als Encoder hab ich den Pegasus Picvideo Codec installiert, der ja anscheinend ganz flott sein soll, doch selbst bei halber PAL Auflösung dennoch diese frame drops. Interessanterweise scheint hier AV_IO besser zu funzen, denn die frame drops halten sich dort in Grenzen (bei jeweils 25 fps). Gibt es denn außer der FPS und dem Capture Video Format noch besonders 'kritische' Parameter, welche das Ergebnis merklich beeinflussen? Wenn ich Erfahrungsberichte von Benutzern mit deutlich schwächerer HW-Ausstattung so lese, dann sollte ich mit meiner Kiste eigentlich keine Probleme und sogar genügend Reserven nach oben haben. Ach ja, ich habe zum Zeitpunkt des Capturens alle evtl. störende Hintergrundprozesse gestoppt (Virenscanner, Firewall etc). Any Ideas?
bei deiner Ausstattung machte es fast mehr Sinn, gleich verlustfrei zu capturen - am besten mit dem HuffYuv-Codec (http://www.math.berkeley.edu/~benrg/huffyuv.html). Du hast es so gleich in bester Qualität auf der Platte und wirst weniger Performanceprobleme haben als wenn du einen M-JPEG Codec benutzt (das Umrechnen des Datenstroms kann je nach Einstellung und Codec auch schnelle Rechner überfordern). Mit einem schnellen Rechner wie deinem sollte unkomprimiertes Capturen problemlos möglich sein.
Caputuren sollte man immer möglichst in Full-PAL - unabhängig davon, daß "krumme" Auflösungen dabei meist nicht unterstützt werden - übernimmt das Umrechnen in normgerechtes SVCD-Format später eh der Encoder.
-BEI- Steffen->
Danke für den Tip mit <A HREF="http://www.iulab.com">www.iulab.com> (nicht iulabs.com ). Ich werde sowohl Treiber als auch Capture Tool heut abend mal testen. Benutze WinXP und wenn ich mir die Website und die WDM Problematik die dort geschildert ist so durchlese, bin ich wirklich auf das Ergebnis gespannt. Klingt vielversprechend.
-BEI- Sandra->
Auch dir besten Dank für deine Antwort. Es scheint, ich lerne jeden Tag ne Menge hinzu . Zu deinem Beitrag hab ich jedoch noch zwei Verständnisfragen...
Unter "verlustfrei" würde ich eigentlich spontan "unkomprimiert" verstehen. Das wird es jedoch nicht sein, denn sonst wäre es ja kein Codec, gelle? Was ist dann eigentlich das 'Ergebnis' des Encodierens mit HuffYuv, wenn kein M-JPEG? Zumindest gehe ich davon aus, dass es ein Format ist welches u.a. von gängiger Schnittsoftware verarbeitet werden kann.
Meine zweite Frage...versteht man unter 'Full-Pal' das 768 x 576 Video-Format (im Capturing Sinne)?
(User Above) hat geschrieben:
:
: Unter "verlustfrei" würde ich eigentlich spontan "unkomprimiert"
Ja, exakt.
:
: verstehen. Das wird es jedoch nicht sein, denn sonst wäre es ja kein Codec, gelle?
Streng genommen hast du Recht! Der Fachbegriff Codec kommt von Compression/Dekompression - was in diesem Falle nicht stattfindet (obwohl es da auch Ausnahmen gibt bei HuffYuv, das sprengt aber hier den Rahmen...). Es hat sich aber eingebürgert, für die Art und Weise, wie Videodatenströme in einem Format (z.B. AVI, MPEG, etc.) "verpackt" sind, den Begriff Codec zu benutzten. Man könnte aber in diesem Falle naheliegender von "noconodec" sprechen - aber das hört sich doch etwas drollig an )
:
: Was ist dann eigentlich das 'Ergebnis' des Encodierens mit HuffYuv, wenn kein
: M-JPEG? Zumindest gehe ich davon aus, dass es ein Format ist welches u.a. von
: gängiger Schnittsoftware verarbeitet werden kann.
Mit HuffYuv (RGB-Profil) wird der Videodatenstrom mit voller 24bit RGB Farbtiefe abgespeichert (RGB=Rot, Grün, Blau mit jeweils 8bit Farbtiefe). Das hat natürlich zur Folge, daß eine enorme Datenmenge entsteht, ca. 27 MB pro Sekunde, dies solltest du bei deinen Projekten bedenken.
Wenn dein AVI dann als 24bit RGB vorliegt, sollte es auch in jedem Schnittprogramm weiterverarbeitet werden.
Mit M-JPEG wird das Video während des Capturens nach dem JPEG-Kompressionsverfahren komprimiert. Grob gesagt werden bei diesem Verfahren Farben innerhalb von Pixelblöcken im Bild zusammengefasst - was mit einem Verlust an Bildinformation u. somit Qualität einhergeht. Die Datenmenge verkleinert sich dadurch, doch bei an das Ausgangsmaterial angepasstem Kompressionsverhältnis (z.B. 10:1 für VHS, 8:1 für SVHS) sind kaum Qualitätsverschlechterungen feststellbar.
Es ist aber in jedem Falle - um optimale Ergebnisse zu erzielen - für das spätere Umrechnen in MPEG-Formate besser, unkomprimiert zu capturen, da MPEG-Encoder weit empfindlicher auf komprimiertes Material reagieren als das menschliche Auge - grob gesagt. M-JPEG ist eigentlich nicht für weiteres Konvertieren geeignet, sondern für´s Capturen, Schneiden und Zurückspielen auf analoge Bandformate.
:
: Meine zweite Frage...versteht man unter 'Full-Pal' das 768 x 576 Video-Format (im
: Capturing Sinne)?
Ah ja! Danke für deine ausführliche Antwort. War sogar mir verständlich und deckt sich dann auch mit dem was ich bisher über das Thema gelesen hab. Im Unterschied zu M-JPEG ist der Huffyuv Codec also quasi ein reiner 'Farbkomprimierer', könnte man das so formulieren? Auf der Website ist ja auch von Komprimierungsfaktoren von ca 2.x die Rede (im Unterschied zum Faktor 7.x bei PICVideo MJPEG Qualität 19 und YUY2).
(User Above) hat geschrieben:
: Streng genommen hast du Recht! Der Fachbegriff Codec kommt von
: Compression/Dekompression - was in diesem Falle nicht stattfindet
Ups, Sandra. Ersten kann man zwischen verlustbehafteter und verlustfreier Kompression unterscheiden (oder sind gezippte Dateien entweder nicht komprimiert, oder vielleicht verlustbehaftet?), zweitens kommt Codec von Coding/Decoding, was man an den Begriff (Mpeg)-Encoder sehen kann.
(User Above) hat geschrieben:
:
:Mit HuffYuv (RGB-Profil) wird der Videodatenstrom mit voller 24bit RGB Farbtiefe abgespeichert RGB=Rot, Grün, Blau mit jeweils 8bit Farbtiefe). Das hat natürlich zur Folge, daß eine enorme atenmenge entsteht, ca. 27 MB pro Sekunde, dies solltest du bei deinen Projekten bedenken.
:Wenn dein AVI dann als 24bit RGB vorliegt, sollte es auch in jedem Schnittprogramm :weiterverarbeitet werden.
Ist nicht ganz richtig, weil HuffYuv, wie der Name schon sagt, auch YUV-Farbräume komprimiert und das sogar besser als RGB. --> http://www.math.berkeley.edu/~benrg/huf ... ffyuv.html
:
:Mit M-JPEG wird das Video während des Capturens nach dem JPEG-Kompressionsverfahren komprimiert. :Grob gesagt werden bei diesem Verfahren Farben innerhalb von Pixelblöcken im Bild zusammengefasst :was mit einem Verlust an Bildinformation u. somit Qualität einhergeht. Die Datenmenge verkleinert :sich dadurch, doch bei an das Ausgangsmaterial angepasstem Kompressionsverhältnis (z.B. 10:1 für :VHS, 8:1 für SVHS) sind kaum Qualitätsverschlechterungen feststellbar.
M-JPEG komprimiert jede Farbe getrennt im YUV-Farbschema (Luma und zwei Chroma-Anteile). Am Ende der Bearbeitung (Kodierung) wirkt das Bild unschärfer, weil jedem Bild visuell unwichtige Stützstellen entfernt werden und der Rest dann verlustfrei komprimiert wird. Die Stützstellen sind Zahlenwerte, die nach der DCT (discret cosinus transformation) das jeweilige Pixelraster (üblich 8x8) beschreiben.
Ups, mfranz. Worauf willst du eigentlich hinaus? Ich habe sehr deutlich von diesem Unterschied geschrieben.
Und Zippen ist verlustloses Komprimieren/Verdichten von Daten. Das gibt es zwar auch bei bestimmten Kompressionsverfahren, davon war aber in diesem Zusammenhang nicht die Rede.
, zweitens kommt Codec von Coding/Decoding, was man an
(User Above) hat geschrieben:
: den Begriff (Mpeg)-Encoder sehen kann.
Falsch. Der Begriff leitet sich ursprünglich ab aus Compression/Decompression. Man kann aber sicher auch Codieren/Encodieren sagen - aussagen tut es das gleiche.
So what.
Lass es uns locker sehen - mit derartigen Spitzfindigkeiten könnten wir jetzt Diskussionen lostreten, bis kein Mensch mehr weiß, worum es eigentlich ging
(User Above) hat geschrieben:
: Lass es uns locker sehen - mit derartigen Spitzfindigkeiten könnten wir jetzt
: Diskussionen lostreten, bis kein Mensch mehr weiß, worum es eigentlich ging
:
: Schönen Tag noch.
:
: Gruß
: Sandra
Hallo Sandra,
ups, auf die Füße wollte ich Dir nicht treten. Tut mir leid. Allerdings, spitzfindig finde ich meine Erläuterungen nicht. Ich fand Deine Erklärungen zu oberflächlich, um jemanden die Funktionsweisen zu erklären. Einfacher ist es in diesem Fall auf erklärende WEB-Seiten zu verweisen. Es ist nicht immer alles leicht zu erklären.
dein Beitrag - vor allem auch bez. YUV - ist eine sinnvolle Ergänzung zu meinem. Ich bin aber bewußt nicht in die Tiefe gegangen (auch etwas Zeitmangel i.M.) und habe auf einfache Wortwahl geachtet, da Andi sich ja als noch unbedarft "geoutet" hat. In der Praxis verwirrt es Neulinge nur, wenn man zuviel Fachchinesisch gebraucht. Daß es dir "oberflächlich" vorkommt ist klar - für dich sind diese Dinge selbstverständlich, für andere, die nicht so tief in der Materie stecken, nicht.
Und falls dann Unklarheiten bestehen, kann man´s immer noch näher erläutern - dafür ist das Forum ja auch da.
Bin jetzt tatsächlich schlauer und Sandras Erläuterungen bzw. Empfehlungen bringen mich, glaub ich, schon weiter. Mir ist klar, dass die Materie noch viel an Fachwissen und Technik verbirgt, doch fürs erste hab ich mir nen brauchbaren Einstieg verschafft. Hab mir ja bereits diverse Seiten zum Thema angeschaut, doch in der Flut der Information geht manchmal der Überblick verloren und die Probleme entstehen dann bei der praktischen Umsetzung.
Hab mich eben mal erlaubt euren Thread durchzulesen. Wirklich sehr schön, ABER:
Wenn ich euch richtig verstanden hab, redet ihr hier von einem Codec, das 27Mb pro SEKUNDE groß sein soll!
Bei Windows wäre dann ja schon nach geschlagenen 160 Sekunden Schluß mit capturen, weil das File dann die magische 4GB und Windows-macht-nicht-weiter-Grenze überschreitet...
Hab ich das richtig verstanden, oder sollte ich mich mit euerm "Codec" vielleicht auch mal auseinandersetzen? An sich klingt verlustfreies capturen ja sehr verlockend
P.S.: Ich hoffentlich liest diesen Thread auch noch jemand, ausser mir...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
. Zu deinem Beitrag hab ich jedoch noch zwei Verständnisfragen...RGB=Rot, Grün, Blau mit jeweils 8bit Farbtiefe). Das hat natürlich zur Folge, daß eine enorme
atenmenge entsteht, ca. 27 MB pro Sekunde, dies solltest du bei deinen Projekten bedenken.
