Das Rauschen bei H.264 Umwandlung erhalten ?

    Hi.
    Ich habe eine 1080i Videokamera die tolle MPEG2 Streams mit einem sehr feinen
    Rauschen liefert. Das Rauschen erinnert mich an den Grain von Filmaufnahmen.

    Mir persönlich gefällt das Rauschen und ich möchte es beim Verkleinern in H.264
    möglichst ehalten. Mir ist klar, dass Rauschen die Dateigrösse nicht verkleinert aber
    eine möglichst kleine Dateigrösse ist hier zweitrangig.
    Es geht darum hauptsächlich den Originalcharakter der Aufnahmen zu erhalten.

    Ich habe schon verschiedene Einstellungen probiert, jedoch komprimiert der
    von mir benutzte Encoder so stark, dass das Bild zwar danach erstklassig
    scharf ist, jedoch das Rauschen ist futsch.
    Es wäre klasse, wenn mir jemand einen Tipp zu den Parametern geben könnte
    um das zu erreichen.

    [Blockierte Grafik: http://img368.imageshack.us/img368/3887/image2kopieac1.jpg]

    Wenn sich dieser Thread auf x264 bezieht, dann muss das eine sehr sehr alte Version sein. Denn "Slices" werden bei x264 schon lange nicht mehr benutzt und "Film Grain Optimization" hat es nie in die offizielle Version geschafft (auch wenn letzteres hier durchaus helfen könnte). In diesem Fall sollte man unbedingt auf eine aktuelle Version updaten! Falls hier nicht x264 zum Einsatz kommt, dann würde ich dringend anraten mal x264 anzutesten. Mit VAQ + Psy RDO (+ Psy Trellis) sollte x264 in der Lage sein, das Bildrauschen zu erhalten...

    Wobei man, meiner Erfahrung nach, je nach Quelle auch noch die Deadzones etwas herunterschrauben muss um gute Rauscherhaltung zu bekommen.
    LoRd_MuldeR: Weißt Du in welchen x264 Versionen man den Slice Count ändern konnte? (erinnere mich da gar nicht dran und ging deshalb erst gar nicht von x264 aus :))

    Cu Selur

    oh sorry ich habs vergessen dazuzuschreiben: Das ist nich der x264 sondern der H.264 von Elecard. In meiner Unwissenheit dachte ich dass bei dem Codec grösstenteils die gleichen Parameter zum Encoden verwendet werden...
    "Film Grain Optimization" habe ich narürlich schon getestet, jedoch keine nennenswerte Verbesserung feststellen können. Eine Verringerung der Bitrate bewirkt nur zunehmende Blockbildung bei schnellen Bildfolgen und das Bild wirkt nicht etwa körniger, sondern noch etwas detailärmer, flächiger, ist jedoch trotzdem immer noch sehr scharf.
    Ich werde mal mit dem Adaptive Q Mode herumspielen, danke für den Tipp.

    Zitat

    Eine Verringerung der Bitrate bewirkt nur zunehmende Blockbildung bei schnellen Bildfolgen und das Bild wirkt nicht etwa körniger, sondern noch etwas detailärmer, flächiger, ist jedoch trotzdem immer noch sehr scharf.


    Ich hätte eher an eine Erhöhung der Datenrate gedacht. :)

    Achso. Jep, habe ich natürlich auch schon probiert, jedoch so ab 5000-5500 aufwärts ist keinerlei Verbesserung in keiner Hinsicht mehr wahrzunehmen, nur die Dateigrösse steigt linear an.

    Soweit ich mich erinnere, hatte der Ateme H.264 Beta Encoder eine Rausch-Modellierung. Das war mehr oder weniger der Vorgänger des Nero Digital AVC Encoders ... zumindest falls Nero den heutzutage tatsächlich einsetzt. Nach Beta 3 war ja nichts mehr zu hören von den Entwicklern.

    Ich vermute mal, die Idee ist, das Rauschen in der Stärke beim Decodieren wieder einzublenden, wie es beim Encodieren gefiltert wurde; dann müsste allerdings ein entsprechender Wert im Datenstrom hinterlegt werden, und ein Decoder diesen später auch auswerten...

    Unabhängig von Encoder und Decoder kann man natürlich auch z.B. den Rauschgenerator in ffdshow zuschalten. Ist nicht das Original-Rauschen des Filmes, aber zumindest recht umfangreich steuerbar.

    In dem Screenshot oben heißt es ja "Film Grain Optimization" (FGO). Das scheint also eine Optimierung des Encoders zu sein, die das Bildrauschen besser erhalten soll. Genauso wie das FGO Patch, das es mal für x264 gab. Dafür benötigt man auch keinen speziellen Dekoder. Die Funktion, bei der das Bildrauschen vom Encoder herausgefiltert und vom Decoder wieder hinzugefügt wird, ist "Film Grain Modelling" (FGM). Soweit ich weiß ist das zwar im H.264 Standard vorgesehen, wird bisher aber von keinem Encoder tatsächlich eingesetzt. Und dafür bräuchte man auch einen Decoder, der diese Funktion unterstützt...


    Zum Thema Nero Digital:

    Zitat von Dark Shikari

    You should use a newer version of Ateme's encoder... using the Nero encoder really is rather unfair, given it hasn't been updated in over 4 years. The newer Ateme encoder is quite good and reliably beats Mainconcept in every test I've done.

    Zitat von LessThanJake

    Weißt du zufällig woran man genrerell erkennen kann, ob slices oder full frames enthalten sind?

    greets
    LTJ

    Slices sind auch vollständige Frames, das hat ja nichts mit "interlacing" zu tun.
    Es geht lediglich darum, dass bestimmte Teile des Frames unabhängig voneinander und somit parallel decodiert werden können.
    Und wenn man sagt "ohne" Slices zu arbeiten, dann heißt das, dass man genau 1 Slice verwendet.

    Die Anzahl der Slices kann man sich zum Beispiel mit h264visa anzeigen lassen:

    [Blockierte Grafik: http://img79.imageshack.us/img79/5790/slicesqv2.th.png]

    (Das Programm ist kostenpflichtig, kann aber beliebig oft für 30 Tage kostenlos getestet werden)

    Zitat von LoRd_MuldeR

    Slices sind auch vollständige Frames, das hat ja nichts mit "interlacing" zu tun.
    Es geht lediglich darum, dass bestimmte Teile des Frames unabhängig voneinander und somit parallel decodiert werden können.
    Und wenn man sagt "ohne" Slices zu arbeiten, dann heißt das, dass man genau 1 Slice verwendet.

    Dass das nichts mit Interlacing zu tun hat, ist mir klar. Falls aber mehrere Slices vorhanden sind, was der H264 Standard ja erlaubt, brauche ich trotzdem alle um ein vollständiges Bild dekodieren zu können, egal ob die Slices unabhängig voneinader dekodierbar sind oder nicht. H264-Visa zeigt das x264 und der Mainconcept-Encoder nur Fullframesslices erzeugen. Mich interessiert, ob das die Regel ist und überhaupt, wo man das im Bitstream auslesen kann. Aber das gehört ja eigentlich alles ganicht hier in den Thread. Sorry lieber Threadersteller, ich möchte hier nicht vom Thema ablenken. :redface:.

    greets
    LTJ

    Zitat von LessThanJake

    Falls aber mehrere Slices vorhanden sind, was der H264 Standard ja erlaubt, brauche ich trotzdem alle um ein vollständiges Bild dekodieren zu können, egal ob die Slices unabhängig voneinader dekodierbar sind oder nicht.

    Naja, falls man nicht alle Slices eines Frames (korrekt) dekodieren kann, dann kann man zumindest die Slices anzeigen, die dekodiert werden konnten. Man kann dann also zumindest einen unvollständigen Frame anzeigen, anstatt gar nichts. Das ist vor allem beim Broadcasting interessant, wo öfter mal Datenpakete verloren gehen...

    Zitat von LessThanJake

    H264-Visa zeigt das x264 und der Mainconcept-Encoder nur Fullframesslices erzeugen. Mich interessiert, ob das die Regel ist...

    Zumindest für BluRay ist das nicht die Regel, da die BluRay Specs vorsehen, dass mindestens vier Slices pro Frame verwendet werden. Es gab einige Diskussion im englischen Forum, ob das eine "Empfehlung" oder verpflichtend ist und ob x264 dann überhaupt BluRay-kompatible Streams erzeugen kann. Einige BluRay-Authoring Programme nehmen Streams ohne Slices jedenfalls nicht an. Dennoch sollte man möglichst auf Slices verzichten, da sie die Kompression negativ beeinflussen. Die Bewegungsvektoren können nicht über Slice-Grenzen hinweg gehen. Je mehr Slices man verwendet, desto stärker leidet die Kompression...

    Zitat von LessThanJake

    und überhaupt, wo man das im Bitstream auslesen kann

    Wie man die Anzahl der Slices auslesen kann, weiß ich nicht genau. Sollte man aber in den H.264 Specs nachlesen können, wenn man es genau wissen will...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden