Video-encoder

Re: Video-encoder

hackenbush — Mon, 26 Oct 2009 08:24:16 GMT

Nachdem ich lange mit divx rumgesch***en habe, auch x264 probiert habe etc. bin ich bei xvid und AutoGK hängengeblieben; liefert für mich gute Ergebnisse, und funktioniert auch zuverlässig.

Die ganzen Dinge wie demuxen und commandlinekodieren waren mir dann doch zu hardcore, ausserdem hatte ich eine oder zwei Inputs, wo ffmpeg mit Fehlermeldung ausgestiegen ist, und ich trotz Studium der ganzen Optionen auf keinen grünen Zweig gekommen bin.

Re(6): Video-encoder

Jacques Lemans — Sun, 25 Oct 2009 09:34:37 GMT

kranke software

Re(5): Video-encoder

morph1 — Sun, 25 Oct 2009 09:34:05 GMT

nein, top zeigt das so an wenn mehr als ein kern drin is

Re(4): Video-encoder

Jacques Lemans — Sun, 25 Oct 2009 08:55:52 GMT

eine auslastung von 368%

fehlt da ein komma?

Re: Video-encoder

Fitz — Sat, 24 Oct 2009 16:39:36 GMT

Beim rippen von DVDs merke ich zwischen ffmpeg

Welches Format wird damit generiert, also Container und Videocodec?

Als Video-Bitrate verwende ich immer 1800 kbps und bei x264 noch das High-Quality-Preset.

Entspricht welchem Quantizer?

Ich bin mittlerweile dazu übergegangen, archivierbare DVB-Aufnahmen als x264 in einem MKV-Container zu kodieren, allerdings etwas umständlich, da ich auf Gordian Knot zum Zurechtschnippseln nicht verzichten möchte. Das Avisynth-Script importiere ich dann in MeGUI, wo dann das Encoding stattfindet, aber nach wie vor Avisynth-Filter verwenden kann.

Grundsätzlich bevorzuge ich einen qualitätsbasierten Durchgang, denn bei einer fixen Bitrate hast du das Problem, dass sie manchmal zu hoch und dann wieder zu niedrig ist, je nach Anspruchsgrad des Materials.

Warum der Umstieg von xvid auf x264? Etwas geringerer Platzbedarf, bei höherer Qualität, wobei ich keinen Direktvergleich gemacht habe und ich noch mit dem Quantizer herumexperimentiere (bei xvid = 2). Der WD Media Player ist auch ein Grund, denn mein alter DVD-Player hatte noch keine MKV-Unterstützung.

Re(3): Video-encoder

morph1 — Sat, 24 Oct 2009 09:37:25 GMT

es hat sich durch einen merkwürdigen zufall ergeben, dass der server im keller ein core2quad wurde, interessanterweise nun die schnellste kiste im haus

ghb erzeugt eine auslastung von 368% laut top

von daher ists halt nicht ganz fair wenn der codec multiprozessor support hat :D

den rest der zeit langweilt sich die kiste eh zu tode, der freut sich über das bissi beschäftigung :D

Re(2): Video-encoder

Hawelka — Sat, 24 Oct 2009 07:45:52 GMT

also ich encodiere mittlerweile alles mit handbrake bzw ghb

ebenfalls

macht im two-pass ~ 75fps netto, im single pass >140fps

Du musst einen deutlich anderen Rechner haben, als meinereiner!

da machts filme schrumpfen richtig spass

Deine CPU sieht das bestimmt einen Zacken anders

Re: Video-encoder

morph1 — Sat, 24 Oct 2009 00:08:38 GMT

also ich encodiere mittlerweile alles mit handbrake bzw ghb

einstellungen die sich als gut herausgestellt haben:

x264 mit 1200-1300kbit

je nach quelle (dvd, dvb) mit ac3 oder als aac tonspur

macht im two-pass ~ 75fps netto, im single pass >140fps

da machts filme schrumpfen richtig spass

Re(3): Video-encoder

user86060 — Fri, 23 Oct 2009 15:19:58 GMT

vermutet

tststs ... war keine Vermutung, sondern Wissen - immerhin beschäftige ich mich seit 3 Jahren mit dem Zeugs

einige Tools (Handbrake, die QT-Plugins, sonstige ffmpeg/x264-Frontends) bieten
nochmals gut 20 Optionen zum Feintuning an.

netterweise ist h.264 in seinen Algorithmen darauf optimiert worden,
daß es gut in Hardware abgebildet werden kann (diskrete Berechnungen
= kleine Fließkommaeinheit), sowohl beim Decodieren, als auch für
das Encoding. Es steht uns also eine Welle von Graphikkarten bevor,
die das beschleunigen können sollten.
Das war zuletzt vor 10 Jahren bei den MJPEG-Karten der Fall.

Re(2): Video-encoder

Hawelka — Fri, 23 Oct 2009 14:38:45 GMT

1800kbps sind für h.264 noch keine Herausforderung - dreh auf 1000-1200 runter

Es ist, wie du vermutet hast. Hab soeben mal mit 600 kpbs einen Vergleich gemacht.
Jetzt erklärt sich der enorme Unterschied im Rechenaufwand. Die Videos sind wie Tag und Nacht

Re(7): Video-encoder

user86060 — Fri, 23 Oct 2009 14:23:55 GMT

"I break together" würde jetzt Helge Schneider sagen!

ich kontere mit "I think I spider" (OTTO)

ich hab nach wie vor unterschiedlichste Plattformen im Einsatz,
teils in VMs, teils in Hardware, aber der iMac ist halt die ultimative
Multimedia-Maschine in einem = TV (DVB-T / Terratec), VCR, Player und bald (*händereib*) SAT (elgato rulz), und eben VM-Host.
Dekadenz? vielleicht. aber höchst funktional.

der turbo.264 Stick war vor 2 Jahren einfach die beste Lösung am kleinen Powerbook.
(ok - DAS Teil ist dekadent )
für kleinere Auflösungen ist der Treiber sogar echtzeitfähig (eben streaming),
für PAL bricht er eben auf 16-20fps ein. Der HD-Stick ist natürlich schneller
und kann mehr MPEG4 Features. Vielleicht, wenn ich dereinst punkto Videocam
aufrüste.

Re(6): Video-encoder

Hawelka — Fri, 23 Oct 2009 13:46:23 GMT

anfangs hab ich den Vorgänger von dem hier (max 800x600) benutzt:
http://www.elgato.com/elgato/int/mainmenu/products/Accessories/Turbo264HD/product1.de.html

"I break together" würde jetzt Helge Schneider sagen!
Ich hatte ja in meinem Leben noch nie einen Mac (und seit 7 Jahren nicht mal ein Win-PC).
Aber einmal, möchte ich diese Dekadenz am eigenen Leib spüren
Im ernst - faszinierend! was es alles gibt.

Ich archiviere je nach Material zw. 1200 und 1600kpbs (Simpsons ... 16:9
Serien), wobei ich den Rechner da gerne als Heizung mißbrauche, wenn er dann tagsüber
5-8 Stunden rechnet.

Meine Simpsons "Staffel 1-10" hab ich auch archiviert. Und weil meinem Rechner diese Last nicht zuzumuten war, hab ich mein DVD-LW via NFS bei einem Kundenrechner der Breitband hatte, gemountet und über die Fernwartung dort gerippt. Fühlte sich gut an

Re(7): Video-encoder

hellbringer — Fri, 23 Oct 2009 13:02:33 GMT

Ich hatte, wie gesagt, nie Probleme damit. Hab einfach die Priorität auf "niedrig" gestellt und man überhaupt nicht mehr gemerkt, dass der im Hintergrund codiert. Hab sogar schon paarmal aus versehen rebootet, weil ich vollkommen vergessen hab, dass noch die Komprimierung im Hintergrund läuft

Systeme waren Windows 2000 und Windows XP. CPU war eine Single-Core. Geht wirklich voll geschmeidig.

Re(5): Video-encoder

user86060 — Fri, 23 Oct 2009 13:01:02 GMT

So hab ich es auch immer bisher gemacht - zuerst als ISO kopieren, und erst
später komprimieren. Und das kopieren dauert nun mal die Zeit die es eben
braucht.

hängt auch teils vom Laufwerk ab. *smack*Pioneer*

Das nachfolgende komprimieren war dann immer recht nervig, weil es im
Stundenbereich lag, und der Rechner für andere Sachen kaum zu gebrauchen war.

anfangs hab ich den Vorgänger von dem hier (max 800x600) benutzt:
http://www.elgato.com/elgato/int/mainmenu/products/Accessories/Turbo264HD/product1.de.html
Mac only Lösung - aber auch auf einem G4 20 fps bei kaum Last / im Hintergrund, bzw. CPU nur zum Skalieren / DeInterlacen.
Seit 1 - 1.5 Jahren ist der x264 / ffmpeg an und für sich die qualitativ bessere Lösung, aber eben nur mit starkem Rechner.

Wenn ich nun mit ffmpeg 1-pass kodiere, brauche ich kaum länger als zum reinen kopieren. Und weil mit das recht komisch vorkam, hab ich mit den Vergleichstests angefangen.

recht so

Ich archiviere je nach Material zw. 1200 und 1600kpbs (Simpsons ... 16:9 Serien),
wobei ich den Rechner da gerne als Heizung mißbrauche, wenn er dann tagsüber
5-8 Stunden rechnet.

Re(6): Video-encoder

Hawelka — Fri, 23 Oct 2009 12:49:31 GMT

Wieso? Einfach die Prozesspriorität auf Niedrig stellen.

Das "Teil" läuft ohnehin mit "nice -19", aber wennst auf einem Single-Core parallel noch arbeiten möchtest, wirds einfach "zäh". Sauerbraten bräuchtest daneben nicht mehr starten
Bei Mehr-Core-Rechnern schaut die Welt dann schon ganz anders aus.

Re(5): Video-encoder

hellbringer — Fri, 23 Oct 2009 12:25:49 GMT

Das nachfolgende komprimieren war dann immer recht nervig, weil es im
Stundenbereich lag, und der Rechner für andere Sachen kaum zu gebrauchen war.

Wieso? Einfach die Prozesspriorität auf Niedrig stellen. Hat selbst auf meinen alten Single-Core nie Probleme gemacht. Und bei einem modernen Dual- oder Quad-Core sollte es fast gar nicht ins Gewicht fallen. Sogar spielen kann man nebenbei.

Re(5): Video-encoder

hellbringer — Fri, 23 Oct 2009 12:25:49 GMT

Das nachfolgende komprimieren war dann immer recht nervig, weil es im
Stundenbereich lag, und der Rechner für andere Sachen kaum zu gebrauchen war.

Wieso? Einfach die Prozesspriorität auf Niedrig stellen. Hat selbst auf meinen alten Single-Core PCs nie Probleme gemacht. Und bei einem modernen Dual- oder Quad-Core sollte es fast gar nicht ins Gewicht fallen. Sogar spielen kann man nebenbei.

Re(4): Video-encoder

Hawelka — Fri, 23 Oct 2009 12:18:25 GMT

Kopieren != Komprimieren

So hab ich es auch immer bisher gemacht - zuerst als ISO kopieren, und erst später komprimieren. Und das kopieren dauert nun mal die Zeit die es eben braucht.
Das nachfolgende komprimieren war dann immer recht nervig, weil es im Stundenbereich lag, und der Rechner für andere Sachen kaum zu gebrauchen war.
Wenn ich nun mit ffmpeg 1-pass kodiere, brauche ich kaum länger als zum reinen kopieren.
Und weil mit das recht komisch vorkam, hab ich mit den Vergleichstests angefangen.

Re(2): Video-encoder

Hawelka — Fri, 23 Oct 2009 12:09:39 GMT

den AVIVO video converter mit GPU-computing könnte man auch verwenden

Unter Windows wäre das etwas - stimmt

Re(3): Video-encoder

hellbringer — Fri, 23 Oct 2009 12:09:06 GMT

Mir gehts vor allem um die Performance. Denn Videofilme die man am selben Tag
zurückbringt, kosten nur die Hälfte

Fürs Kopieren wirst doch nicht länger als einen halben Tag brauchen, oder?

Kopieren != Komprimieren

Re(3): Video-encoder

hellbringer — Fri, 23 Oct 2009 12:09:06 GMT

Mir gehts vor allem um die Performance. Denn Videofilme die man am selben Tag
zurückbringt, kosten nur die Hälfte

Fürs Kopieren wirst doch nicht länger als einen halben Tag brauche, oder?

Kopieren != Komprimieren

Re(2): Video-encoder

Hawelka — Fri, 23 Oct 2009 12:07:49 GMT

1800kbps sind für h.264 noch keine Herausforderung - dreh auf 1000-1200 runter
(für PAL-Auflösung), da trennt sich die Spreu vom Weizen.

siehst - diesen Aspekt hab ich überhaupt nicht berücksichtigt!
Da ich die Videos nicht archiviere, bin ich recht locker mit der Bitrate.

2-pass ist nur bei stark schwankendem Material (Standbilder <-> Aktionszenen, "MTV-Schnitt") + Streaming interessant.

D.h. bei einer klassischen Film-DVD bringt das gar nicht viel. Das entspricht auch meinen bisherigen Erfahrungen. Weder in der Größe noch in der Qualität tut sich da wirklich etwas.

wenn man mit ffmpeg auskommt + die Leistung ein Problem ist, spricht nichts dagegen.

Mir gehts vor allem um die Performance. Denn Videofilme die man am selben Tag zurückbringt, kosten nur die Hälfte

Re: Video-encoder

HITCHER — Fri, 23 Oct 2009 11:52:33 GMT

den AVIVO video converter mit GPU-computing könnte man auch verwenden,
wenn man eine flotte ATI Grafikkarte hat. Der soll auch recht schnell sein.
Habe ich aber noch nicht gebraucht bis jetzt.

http://game.amd.com/us-en/drivers_catalyst.aspx?p=win7/windows-7-64bit

Re: Video-encoder

user86060 — Fri, 23 Oct 2009 11:47:26 GMT

1800kbps sind für h.264 noch keine Herausforderung - dreh auf 1000-1200 runter (für PAL-Auflösung), da trennt sich die Spreu vom Weizen.

ffmpeg macht mpeg4 Simple/Standard Encoding (andere Class) - h.264 ist MPEG4 Advanced Video Coding (AVC), spätestens bei der Option CABAC geht jede Encoding-SW in die Knie bei den fps. 2-pass ist nur bei stark schwankendem Material (Standbilder <-> Aktionszenen, "MTV-Schnitt") + Streaming interessant.

wenn man mit ffmpeg auskommt + die Leistung ein Problem ist, spricht nichts dagegen.

der Container ist Geschmacksache, und fällt vom Overhead her 0 ins Gewicht.
ich bevorzuge MP4 (.mp4 / .m4v ... Unterschied ist nur, daß zweiteres meist direkt iTunes zugeordnet wird und .mp4 zB QuickTime), Consumergeräte bevorzugen eher DivX = AVI (mit dem simple coding-kompatiblen DivX3/4/5 Codec)

Video-encoder

Hawelka — Fri, 23 Oct 2009 11:07:08 GMT

Welche Video-encoder verwendet ihr für gewöhnlich?

Beim rippen von DVDs merke ich zwischen ffmpeg, xvid und x264 keinen Unterschied in der Qualität. Sehr wohl aber in der Geschwindigkeit. Über ffmpeg codiert, schaffe ich über 140 Frames pro Sekunde. Bei x264 gerade mal 20 fps. Auch zwischen ein- und zwei-pass-Kodierung kann ich keinen Unterschied erkennen.
Als Video-Bitrate verwende ich immer 1800 kbps und bei x264 noch das High-Quality-Preset.
Ich hab von den einzelnen Videos jeweils 20 Frames als bmp-Images abgespeichert und diese mit gimp auf 400% vergrößert. Unterschiede sind so gut wie nicht vorhanden. Und wenn, dann sind die Bilder der ffmpeg-codierung sogar besser als die x264 codierten.
Auch die Filegrößen der einzelnen Videos unterscheiden sich nur sehr gering. Egal welchen Container ich bei den jeweiligen codecs verwende (avi, mp4, mkv).

Wenn ich also nun gegenüberstelle - ffmpeg-1pass und x264-2pass, bin ich mit der ersten Variante 18 mal so schnell und hab dennoch qualitativ ein gleichwertiges Ergebnis.
Ich bin verwirrt