Frage zu Re-Encoding eines h264-Streams

    Hallo,

    2 Probleme hätte ich...

    1. Frage:

    Ich habe hier ein paar h264-Streams (1080p), welche ich persönlich für etwas oversized halte (20 GB für 2 Stunden, durchschnittlicher Action-Anteil, durchschnittliches Grain).
    Deshalb wollte ich sie per CRF-Encoding recodieren.

    Nun meine Frage dazu:
    Ist der CRF-Wert ABSOLUT oder RELATIV zu sehen?
    Also der Stream IST ja bereits komprimiert.
    Liege ich mit einer Einstellung zwischen 18 und 19 nun trotzdem richtig, oder wird der bereits komprimierte Stream dann eventuell zu stark komprimiert, was die zu erwartende Qualität betrifft?

    Weiß jetzt nicht, ob ich mich richtig ausgedrückt habe. Jedenfalls hatte ich schon mal mit dem Re-Encoding begonnen (CRF 18.5) und nach 15% war die zu erwartende Größe deutlich kleiner als das Quell-Material.

    2. Frage:

    Ich habe hier außerdem noch einen TV-Mitschnitt (*.ts) in 1080i, welchen ich ebenfalls re-encoden wollte. In diesem Fall ist der Grund die Beseitigung des Senderlogos.
    Ich bekomme es aber ums Verrecken nicht hin, daß das Ergebnis fehlerfrei dargestellt wird.
    Egal, ob ich das sourcefile per DGAVCindex als 'avcsource' lade oder das TS-file per 'directshowsource'. Das Ergebnis ist total verblockt und es sind Sprünge im Bild.
    Dabei ist es egal, ob ich nun einen De-Interlacer im avisynth-script verwende, oder bei 'directshowsource' vom decoder de-interlacen lasse, oder ob ich GAR NICHT de-interlace.
    Die Option 'Encode Interlaced' half auch nicht.

    Bei 'avcsource' muß ich außerdem 'converttoyv12' setzen, sonst stürzt x264.exe ab.

    Hätte da jemand einen Lösungsvorschlag?

    Hier noch die 'Medien-Info' für den Stream, um den es in Frage 2 geht:

    General

    Video
    ID : 4113 (0x1011)
    Menu ID : 1 (0x1)
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : Main@L4.0
    Format settings, CABAC : Yes
    Format settings, ReFrames : 4 frames
    Codec ID : 27
    Duration : 1h 33mn
    Bit rate mode : Variable
    Bit rate : 9 351 Kbps
    Maximum bit rate : 40.0 Mbps
    Width : 1 920 pixels
    Height : 1 080 pixels
    Display aspect ratio : 16:9
    Frame rate : 25.000 fps
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Scan type : Interlaced
    Scan order : Top Field First
    Bits/(Pixel*Frame) : 0.180
    Stream size : 6.09 GiB (88%)
    Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
    Transfer characteristics : BT.709-5, BT.1361
    Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


    Ach so, ich nutze MeGUI 0.3.5 und bisher die x264-Version 0.98.1649
    (habe mir aber gerade noch das aktuelle build besorgt: 1766)

    EDIT:
    Habe eben noch MeGUI von 'Stable' auf 'development' um gestellt und updaten lassen:
    0.3.5.24, x264.exe: 1745-1 (Jeeb)

    Danke für die Aufmerksamkeit.

    2 Mal editiert, zuletzt von c4rD1g4n (13. November 2010 um 02:28)

    1.) CRF ist relativ. Aber bevor du recodierst: Das TS-Dateiformat enthält teilweise bis zur Hälfte nur Füllmaterial für konstante Übertragungsraten. Remultiplexe erst mal direkt zu MKV, wie viel kleiner wird es dadurch?

    2.) Noch eine Alternative: FFmpegSource2 { LoadPlugin("FFMS2.dll") | FFVideoSource("*.ts") # erstes Laden mit Indexierung dauert! }
    2.a) Vorher vielleicht die Aufnahme noch säubern? Eines der TS-AVC-Tools war wohl dafür relativ geeignet.

    3.) x264 1745-1 (Jeeb) ist etwas instabil mit den enthaltenen Audio-Codecs. Es ist sehr zu empfehlen, in der MeGUI das verwendete x264-Profil zu bearbeiten und im erweiterten Modus als zusätzlichen Kommandozeilen-Parameter "--acodec none" anzugeben.

    Auf gute Zusammenarbeit:

    REGELN befolgen | SUCHE benutzen | FAQ lesen | STICKIES beachten

    Einmal editiert, zuletzt von LigH (13. November 2010 um 12:33)

    Zitat von LigH

    1.) CRF ist relativ. Aber bevor du recodierst: Das TS-Dateiformat enthält teilweise bis zur Hälfte nur Füllmaterial für konstante Übertragungsraten. Remultiplexe erst mal direkt zu MKV, wie viel kleiner wird es dadurch?

    OK, nochmal anders gefragt.
    Bei den Files in denen es in Frage 1 geht, ist das Quellmaterial Blue Ray. Allerdings bin ich eben der Meinung, daß 0,51 Bits/Pixel wirklich unnötig sind.
    Ich denke, ab 0,25 liegt man bei AVC eigentlich immer auf der sicheren Seite, oder? CRF hin oder her. Vielleicht auch 0,30. Das wäre dann wirklich totsicher und immer noch fast um die Hälfte kleiner.

    Zitat von LigH


    2.) Noch eine Alternative: FFmpegSource2 { LoadPlugin("FFMS2.dll") | FFVideoSource("*.ts") # erstes Laden mit Indexierung dauert! }

    Gut, danke für den Tipp. Das werde ich mal ausprobieren.

    Zitat von LigH


    2.a) Vorher vielleicht die Aufnahme noch säubern? Eines der TS-AVC-Tools war wohl dafür relativ geeignet.

    Was sind das für Tools? Heißen die direkt so, oder gibt's da mehrere?

    Gut, genauer zu 1.: CRF arbeitet relativ zur (objektiven = technisch messbaren) Bildqualität. Nicht relativ zur Dateigröße.

    Wenn also die Decodierung eines schlechten Originals sehr viele Kompressionsartefakte hinterlässt, dann sind die schwer neu zu encodieren, also wird CRF mit kleinem Wert wahrscheinlich viel größere Kopien erzeugen. Ist das Material aber einfach bloß weich und detailarm (z.B. bloß ein hochskalierter ehemaliger SD-Film), dann reicht auch schon eine niedrige Bitrate (sowohl insgesamt = kbps als auch pro Fläche = bppf) völlig aus, um das bereits hinreichend exakt zu speichern. Man kann nicht sagen, ob 0,25 bppf "sicher" sind, ohne das Material zu kennen (Schärfe, Rauschen ... also der Detailgrad). Und bei Anime reicht vielleicht schon 0,15 bppf für Top-Qualität – wer weiß. Möglicherweise stammen die 0,51 bppf auch noch aus dem Überschuss an Fülldaten des TS-Kontainers.

    Die CRF-Methode bestimmt also nur den möglichen Qualitätsverlust zwischen dem Originalbild und dem Bild, das die Kopie bei der Darstellung zeigen würde. Das hat allerdings nichts mit dem subjektiven "Qualitätsempfinden" zu tun. x264 weiß nicht, ob diese Struktur da ein störendes Kompressionsartefakt oder Rauschen oder eine sinnvolle Struktur im Bildinhalt ist. Jedes Detail erschwert nur die Komprimierung und benötigt mehr Bitrate, egal ob es erwünscht oder unerwünscht ist.
    __

    Zu 2.a: Ich glaube, der "Cypheros TS-Doctor" war das empfehlenswerte Tool für HD-DVB mit AVC-Video. So wie ProjectX für SD-DVB mit MPEG2-Video.

    Das oben genannte Video hat ja auch bei 1920x1080 Pixel und 1:33 h gerade mal 6,09 GB. Wohlgemerkt das Video alleine.

    Dagegen sind die 20 GB für 2 h sicherlich primär auf Fülldaten im TS-Container zurückzuführen, die eben kein Bestandteil des Videoinhaltes sind.

    OK, wahrscheinlich ist das hier alles ein wenig mißverständlich.

    Bei File 1 ist die Quelle Blue Ray. Wie schon gesagt: meiner Meinung nach durchschnittlicher Action-Anteil, durchschnittliches Rauschen.
    DIESES File liegt als mkv vor, hat ca. 2 Stunden Laufzeit und ist 20 GB groß (0,51 bits/Pixel).
    Das ist meiner Meinung nach Overkill und deshalb will ich es nochmal per CRF ~18-19 neu encoden, um es kleiner zu bekommen bei möglichst wenig Qualitätsverlust.

    Bei File 2 ist die Quelle HDTV. Dieses File will ich NICHT verkleinern, sondern nur neu encoden um das Senderlogo zu entfernen.

    Zu Frage 1: Ist hier vielleicht etwas verwirrend von "absolut" und "relativ" zu sprechen. Man sollte sich klarmachen, daß x264 immer mit absolut unkomprimierten Rohdaten gefüttert wird. Der Encoder hat keinen Schimmer davon, wie groß Deine Ursprungsdatei ist.

    Frage 2: DGAVIndex hat Probleme mit Interlaced-Material. Wenn Die Tipps von Ligh (Cypheros TS-Doctor, FFmpegSource2) nicht funktionieren, könntest Du auch die neuen Tools von neuron2 ausprobien: DGDecNV für NVidia-Karten bzw. DGAVCDecDI, falls Du DiAVC besitzt. Eine für beide Werkzeuge gültige Lizenz kostet allerdings 15 US-Dollar.

    Das Problem mit PAFF-Interlacing hat eher das Decoder-Plugin (DGAVCDecode.dll), weniger der Indexer. Donald Graft musste bei DGAVCDec bei einem recht alten libavcodec-Decoder bleiben, weil bei neueren Versionen eine Zeit lang nicht sicher war, dass im zweiten Durchlauf immer exakt die selben Frames herauskamen wie im ersten. Die letzte Version, bei der das noch sicher war, konnte noch kein PAFF-Deinterlacing decodieren (was viele AVCHD-Kameras verwenden - gilt immer für das gesamte Frame), nur MBAFF (das, was x264 auch immer erzeugt - gilt abschnittsweise im Bild, ist also meist effizienter).

    Zitat von sneaker2

    Zu Frage 1: Ist hier vielleicht etwas verwirrend von "absolut" und "relativ" zu sprechen. Man sollte sich klarmachen, daß x264 immer mit absolut unkomprimierten Rohdaten gefüttert wird. Der Encoder hat keinen Schimmer davon, wie groß Deine Ursprungsdatei ist.

    Ja, ist ja logisch, wenn ich einfach erstmal zu Ende gedacht hätte :D
    Es wird ja (immer) erstmal DEcodiert.

    Was das Problem mit dem zweiten File betrifft, so bin ich immer noch nicht wirklich weiter.
    Mit FFVSource habe ich auf einmal 50 FPS und das Bild springt vor und zurück.
    Gibt's da irgendwelche Parameter, die man noch angeben könnte?
    Hatte dann auch noch
    telecide()
    decimate(2) bzw. selecteven() versucht.
    Damit kam ich dann zwar wieder auf 25 FPS, aber das Ergebnis war extrem holprig.

    Auf welchem Holzweg bin ich da schon wieder? :(

    Was directshowsource betrifft, bekomme ich, egal welchen decoder ich verwende, die corruptions nicht weg.
    Hatte es mit ffdshow, coreavc und divxh264 probiert. Das sind die einzigen, die erstmal ein fehlerfreies Bild liefern in virtual dub mod liefern, welches ich zum testen der scripte nutze (abgesehen von den corruptions nach dem recode).
    Alle anderen decoder (powerdvd, microsoft, arcsoft) bringen entweder eine Fehlermeldung oder ein Bild mit (vertikalen) Farbverschiebungen bzw. ich kann sie in win7dsfiltertweaker nicht auswählen, um sie zu aktivieren (mainconcept)

    TS-Doctor zeigte übrigens keinen Fehler.

    EDIT:
    Vielleicht habe ich es jetzt.
    Sieht jedenfalls seeehr gut aus. Genau wie das Original nur eben ohne Logo:

    FFVideoSource(clip)
    telecide()
    ChangeFPS(25)
    DeLogo(400, 192, "LO", "***", Cmix=0.0, Lmix=0.0)

    EDIT 2:

    Drecks....selecteven bzw. selectodd war gar nicht sooo verkehrt (wenn auch changefps die bessere Wahl ist)
    Das (meiste) Ruckeln kam nur dadurch zustande, weil ich meine Testclips mit virtual dub mod im MKV-Container gespeichert hatte. vdubmod "vergaß" nur leider die Framerate in den Container zu schreiben.
    Nach remux mit MKVmerge und Angabe der Framerate ruckelte es dann überhaupt nicht mehr (mit changefps).
    Ich kam drauf, weil ich testweise auch mal als xvid gespeichert hatte und dieses von Anfang an gar nicht ruckelte.

    Ich frage mich allerdings, warum selecteven bzw. selectodd nicht dasselbe Ergebnis bringt. Man sagt damit doch "Nimm jeden zweiten", was doch eigentlich richtig sein müsste, oder?

    Habe nun testweise auch noch mal yadif statt telecide ausprobiert, kann aber in diesem speziellen Fall auf den ersten Blick keinen Unterschied feststellen.

    3 Mal editiert, zuletzt von c4rD1g4n (16. November 2010 um 19:18)

    Kommt mir alles sehr sonderbar vor. Ich denke da an "Field-oriented Interlacing", da wären 50/Sekunde nicht verwunderlich. Aber ohne ausführliche MediaInfo-Analyse oder gar ein Schnipselchen zum Selber-Anschauen ist alles Spekulation.

    Eines kann ich dir aber sagen: Dass SelectEven() und SelectOdd() nicht das selbe Ergebnis liefern, kann nur bedeuten, dass du keine doppelten Inhalte hast, also wirklich jedes Bild verschieden ist (das stützt auch die Interlacing-Theorie). SelectEven wählt dann die geradzahligen "zweiten" (Halb-) Bilder aus, und SelectOdd genau die anderen - die ungeradzahligen "zweiten".

    Sorry, ich wollte das der Übersichtlichkeit halber spoilern, aber das geht hier irgendwie nicht :(

    Mir fällt auf, daß sich ScanOrder und ScanOrder/String unterscheiden.
    Deshalb kommen wohl auch meine Deinterlacer ab und zu durcheinander :hm:
    Bei yadif muß ich z.b. order=0 angeben, wenn ich von Anfang an recodiere.

    So weit, so gut. Ich bin ja nun schon ein Stückchen weiter.
    Eigentlich müsste ich nur noch sicher sein, welcher Deinterlacer nun der optimalste für diesen Fall ist.

    Einmal editiert, zuletzt von LigH (16. November 2010 um 20:48)

    SPOILER ist kein Standard-bbCode-Tag, das in jedem Board verfügbar wäre. Bei uns scheint CODE der einzige zu sein, der die Höhe zumindest überhaupt begrenzt.
    __

    Nun gut - sieht soweit nach "normalem" 1080i aus.

    Wenn der Source-Filter im Skript die Halbbildreihenfolge nicht richtig weitergibt, dann sollte "AssumeTFF()" direkt danach helfen (in deinem Fall ist zumindest TFF = "oberes Feld zuerst" vermerkt, wie MediaInfo berichtet).

    Wenn die Reihenfolge falsch ist (und es gibt Fälle, in denen AviSynth BFF als Standard annimmt), dann kann es zu eben solchen Vor-Zurück-Bewegungen kommen. Allerdings eigentlich nur bei Bobbern (bzw. "Deinterlacern im Bob-Modus") - z.B. TDeint(mode=1) oder Yadif(mode=1).

    Auf gute Zusammenarbeit:

    REGELN befolgen | SUCHE benutzen | FAQ lesen | STICKIES beachten

    Einmal editiert, zuletzt von LigH (16. November 2010 um 21:00)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden