Bevor hier noch irgendwelche missverständnisse oder irritationen entstehen, muss ich noch klar stellen, dass meine argumentation vor dem hintergrund des threadkopfes zu betrachten ist, d.h. ausschliesslich das encoden beim capturen und die besonderheiten dabei (keine dropped frames und ressourcenschonung).
Dass als finales archivformat natürlich am besten eine multipass cinemacraft mpg2 dvd steht ist unbestritten (am besten von einer hochwertigen digitalen quelle, z.b. 3ccd profi dv cam, vom profi bedient, vom profi ausgeleuchtet etc.). Für reine pc anwendungen evtl. auch eine mpg4 variante mit allen schikanen (full res, ibp, qpel, gmc, keyframe detection, multipass vbr).
Beim capturen ist eine (ausreichend) niedrige cpu auslastung, hohe komprimierung, geringer qualitätsverlust und (als zwischenformat) eine leichte nachbearbeitung erforderlich. Die rollenverteilung zwischen cpu auslastung, komprimierung und qualität ist vom encoder und den vorhandenen ressourcen abhängig (cpu nicht zu weit unter 100%, man will ja nix verschenken), das fehlen von deltaframes aber fast schon zwingend für angenehmes schneiden erforderlich. Nur deshalb sollte ein (auch ohne weltweiten segen irgend welcher standardisierungsgremien) keyframe_only-quality_based-vbr format eingesetzt werden, wie z.b. huffyuv, mjpg, mpg(2) und mpg4-derivate mit entsprechenden parametern etc. Bei nicht zu extremen inhalten sollte auch die dateigrösse nicht zu grossen überraschungen führen, cbr ist aber in der regel nur nachteilig. Sobald das rohmaterial ausgetausch werden muss, sollte aber ein nicht zu exotisches format eingesetzt werden.
Als mpg2 hardware encoder benutze ich eine wintv-pvr-pci, die, sofern sie funktioniert, per s-video oder kabertuner ordentliche ergebnisse liefert. Die motivation für den einsatz war die aussicht auf minimale systembelastung bei absolut synchronem bild/ton (bei erträglichen 6mbit/s mpg2, 224kbit/s mp2, 704x576 kommen einige prozent cpu und 0.75MB/s festplatte zusammen und die hätte sich erwähnter 386 auch noch locker aus den rippen geleiert). Leider scheinen sich der via chipsatz (der berüchtigte kt133), eine sb-live und die pvr bezüglich der isochoren pci-bus verwendung nicht immer einig zu sein und da die pvr wohl viel zu wenig pufferspeicher hat verliert sie hin und wieder etwas von den kodierten mpg2 daten. Das ergibt dann schöne blockartefakte im bild und gezwitscher im ton. Ein zugesifftes win2k, extra usb2 karte (die auch nicht den ausschlag gibt, aber die sachlage noch verschärft) etc. machen die situation auch nicht besser. Das ausblenden des tv-fensters (wegen yuv/rgb pci-busmaster vom booktree in die graka) und die realtime priorität der tv-software erlauben aber meistens einwandfreie ergebnisse.
Wenn die in kürze anstehen migration auf nforce2 (bessere pci implementierung, keine extra netzwerkkarte, keine s-blive (verwende spdif), keine extra usb2 karte) die situation nicht bahnbrechend ändert, ist wohl der tausch gegen eine andere (vidac?) tv-mpg-karte fällig.
mr.escape
mr.escape
