Beiträge von FatFaster

  • AviDemux und .mp4

    Was mir aufgefallen ist, AVIdemux zeigt die I-Frames nicht an der richtigen stelle bei mir an (bei meinem h264 video).
    Deshalb wurde das wohl das mit avidemux zusammengefügte Video nicht abgespielt...

    Zitat

    Bei mir lag es eventuell daran, dass ich B-Frames verwende.


    Aber was denn falsch daran sein b-frames zu verwenden?

  • Frage zu Behappy

    Glaube diese Meldung kommt, wenn der entsprechende Encoder nicht im Verzeichnis von BeHappy ist.

    Zitat

    Kann mir jemand helfen, oder gibts noch andere Möglichkeiten, um das Script in ein Audioprogramm einzubinden?


    In welches Audioprogramm denn? Man kann es ja noch ins Wave-Format speichern und dann mit deinem lieblings Audioprogramm bearbeiten :D

  • LC - HE - HEv2 - AAC(plus)

    Vielen Dank für die schnellen Antworten.
    Jetzt frage ich mich nur, ob AAC+ v2 oder AAC HE auch später von den Hardware-Playern unterstützt wird?
    Im Grunde ja schon, nur will ich dann später nicht meinen Sound nur in Mono hören :zunge:

    Zitat

    Auch AAC+ v2 ist abwärtskompatibel. Dekoder ohne spezielle Unterstützung für PS können AAC+ v2 Streams allerdings nur als Mono dekodieren.
    http://de.wikipedia.org/wiki/MPEG-4_Hi…ed_Audio_Coding

  • LC - HE - HEv2 - AAC(plus)

    Hallo,

    ich kenne eigentlich immer noch nicht den wirklichen Unterschied zwischen den ganzen verschiedenen AAC-kodierungen.
    Nehmen wir mal als Beispiel den Nero CLI Enc,
    der hat 3 verschiedene Optionen (glaube mehr gibts ja auch nicht :)) :

    AAC LC
    AAC HE
    AAC HEv2 (ist das = aacplus??)

    Was Unterscheidet diese 3 Arten der AAC kodierung von einander?

    Ist das einfach nur so, dass LC hat die "schlechteste" Qualität und HEv2 die "beste" von den dreien hat? Oder benutzt man diese je nachdem, ob man hohe oder niedrige Bitraten verwendet?

  • Mit Variablen Framerate (VFR) Encoden....

    Hab jetzt mal ein paar Encodes, mit und ohne dedup gemacht.
    Als codec hab ich den x264 mit "Constant Qantizer @ 21" benutzt.
    Zusätlich hab ich deen zum entrauschen genommen + LanczosResize.

    Beim ersten Encode war der Unterschied von ca. 3.8 MB zwischen der Variante mit und ohne Dedup. Nicht sehr groß....

    Danach hab ich mal statt deen, sharpen(1.00) genommen. Ich weiß, ist nicht sehr schlau, bei verrauschtem Material zu schärfen ohne vorher zu entrauschen. Aber ich wollte mal gucken, wie sich Dedup auf weniger gut komprimierbares Material auswirkt.
    Ergebniss war:

    Mit dedup: 330 MB
    Ohne dedup: 353
    ---
    23MB Unterschied.


    Zitat

    Interessant, ich hatte mich schon gefragt, wie Du ein .avs-Skript "einfach so" abspielst. Gäbe es auch andere Möglichkeiten, z.B. ohne Wiedergabe? (Wer weiß was?)

    Also, einmal kann man das Script in Vdub öffnen und auf Play drücken :D
    Der Media Player Classic kann auch AVS-Scripts öffnen und abspielen. Man kann mit dem Player auch mit einer schnelleren Geschwindigkeit abspielen. Jedoch hab ich festgestellt, wenn diese zu hoch ist, dann werden Frames verschluckt, was den Log unbrauchbar macht :(


    Außerdem hab ich hier http://www.avisynth.org/mediawiki/wiki…o_vfr_.28mkv.29
    beim Punkt 3.3.2 TIVTC gelesen, dass Megui und Vdub einen "analysis pass" für sowas haben. Hab gesucht, aber konnte keinen in Vdub finden :hm:

    Code
    Open this and play through it. (MeGUI and VirtualDub have an "analysis pass" for this.) Then close it, comment those lines out (or start a second script) and add:

  • Mit Variablen Framerate (VFR) Encoden....

    Zitat

    Bringt das viel? Holt man den zusätzlichen Zeitaufwand, der sich durch die Erstellung der "log.dup.txt" ergibt, wieder rein?


    Also ich spare da ca. ne Stunde Encoding Zeit, bei "Constant Quality" mit x264.
    Und das ist ja grade mal ein Durchgang. Wenn einer 2 oder 3 durchgänge macht sparrt er dementsprächend nochmehr ;)

    Die erstellung der Log Datei dauert auch nicht lange. Man kann z.B. mit dem MPC einfach mit 2x oder 4x Geschwindigkeit abspielen. Dauert dann so ung. 10min bei ner 22min Folge (hab da jetzt nicht allzu genau drauf geachtet) :D


    Zitat

    Auch hier frage ich mich, wie viel das bringt. Die entfernten Frames sind ja doppelte Frames. Diese hätte der Encoder aber sowieso äußerst platzsparend komprimieren können.


    Interessiert mich auch sehr!
    Deshalb hab ich mal ein encode ohne dedup gemacht

    Hab jeweils das gleiche AVS Script (deinterlancen + entrauschen +schärfen), außer das einmal dedup nicht verwendet wurde.

    Dauer ohne dedup 32400 Frames (21:36.000)
    Dauer mit dedup 22712 Frames (15:08.480)

    Encodet hab ich mit x264 CLI - Constant Quality @ 21

    Code
    --crf 21 --keyint 220 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter 2,3 --subme 6 --analyse p8x8,b8x8,i4x4,p4x4 --qpstep 6 --me umh --threads 2 --thread-input --progress --no-psnr

    Größe mit dedup @ 88,2 MB
    Größe ohne dedup @ 97,2 MB
    -> 9 MB unterschied (ohne das Entrauschen wäre die Differenz größer, denke ich)
    Naja kein sooo großer unterschied aber immerhin und es spart einiges an Encodingzeit ;)

  • Mit Variablen Framerate (VFR) Encoden....

    Hab jetzt mal nach alternativen zu den oben genannten Beispiel gesucht und bin dabei auf Dedup gestoßen. Damit lassen sich Doppelte Frames löschen und so ebenfalls eine VFR Datei erstellen. Habs mal testweise an der Serie Futurama ausprobiert.

    Nötige Tools:
    Avisynth
    Dedup.dll
    Vdub oder Megui
    den gewünschten codec (z.B xvid, x264)
    MKVtoolnix


    Als erstes muss Dedup ein log erstellen (1st pass sozusagen).
    Dies sieht dann so aus:

    PHP
    Loadplugin("dedup.dll")mpeg2source("futurama")#deen("a2d",3,4,5,4) <- optional; kein rauschen mehr, bessere "freeze Frame" #Erkennung für dedupDupmc(log="log.dup.txt")#crop(0,0,16,16) <- so kann man den ersten schritt schnell hintersich #bringen, schnell encoden oder mit einem Player schnell abspielen lassen. Nur #der log ist wichtig ;-)

    Der nächste Schritt sieht bei mir so aus: (nun zum richtigem Encode :D )

    PHP
    Loadplugin("dedup.dll")
mpeg2source("futurama")
#Dupmc(log="log.dup.txt") <- brauchen wir jetzt nicht
dedup(threshold=1.3, range2=5, log="log.dup.txt", maxcopies=20, maxdrops=20, times="mkv.times.txt", decwhich=3)

    Wichtig sind beim "zweiten pass" die vorher erstellte log.txt Datei und die nach dem encode erstellte mkv.times.txt Datei, sonst hat man am ende keine Datei mit VFR.
    Denn threshold sollte man auch nicht zu hoch eingestellen, sonst hat man später im Video kurze hänger im Bild. Näheres zu den Parametern steht in der Dedup.txt

    Wenn man nun fertig encodet hat, startet man MKVtoolnix und öffnet dort seine Video-Datei. Wichtig jetzt ist noch, dass man bei timecodes (etwas weiter unten) die von dedup erstellte mkv.times.txt ebenfalls öffnet, sonst gibts keine VFR.

    Danch fügt man noch den Ton hinzu (hier braucht man die timecodes nicht zu laden), klickt auf Start und Fertig ist das Video mit Variabler Framerate und ohne doppelte Frames :)
    ---
    Der Vorteil ist:
    Man braucht weniger Zeit zu encoden, weil man nun weniger Frames zum encoden hat. Die Futurama Folge hat eigentlich 32374 Frames ( 21min 34sek). Mit dedup bin ich auf 23745 Frames ( 15min 49 sek). Das heißt eine Ersparnis von 8629 Frames (über 5min).
    Dadurch hat man bessere Qualität bei gleicher Dateigröße

    Ein Nachteil wurde weiter oben von Eastermeyer genannt.

    ---
    Ich glaube die erstellten timecodes lassen sich auch für MP4 verwenden, habs jedoch noch nicht ausprobiert (habs im engl. Doom9 Forum gelesen)