Beiträge von sneaker2

  • Blu Ray compliant ?

    Zu 1.)
    Wenn man z.B. "--preset veryslow --tune film --level 4.1" verwendet, dann werden nicht 16 Ref-frames genutzt. x264 verringert automatisch die Anzahl der ref-frames auf die im H.264-Standard für das Level und die Auflösung maximal erlaubte Anzahl. Wenn man allerdings manuell "--ref 16" vorgibt, dann benutzt x264 auch 16 Frames, selbst dann, wenn es die Grenzen des vorgegebenen Levels sprengt.

    Zu 5.)
    Maxrate: Auf keinen Fall --vbv-maxrate benutzen, um die Dateigröße zu begrenzen. Dadurch können keine Bits für komplexe Szenen genutzt werden, so daß das Ergebnis - wie Du bereits festgestellt hast - miserabel wird. Wenn Du eine bestimmte Größe erreichen mußt, dann mache eine 2-Pass-Enkodierung oder notfalls 1-Pass ABR.

  • Einige Fragen

    Zu 2.:

    Es gibt zwei Möglichkeiten Videos mit variabler Framerate mit AviSynth zu verarbeiten:

    a) Umwandeln in konstante Framerate

    z.B.:
    FFVideoSource("video.mp4",fpsnum=24000,fpsden=1001)

    b) Erstellen von Timecodes, mit denen dann der Encoder bzw. Muxer gefütter wird

    z.B.:
    FFVideoSource("video.mp4",timecodes="timecodes.txt")
    danach z.B. mit x264 Encoden:
    x264 --tcfile-in timecodes.txt -o neues_video.mkv eingangsvideo.avs

  • Untertitel bei MKV nicht automatisch starten, Frage zu sub-Untertitel

    Welchen Player verwendest Du denn?
    Im Media Player Classic kannst Du das Laden von externen Untertiteln ausschalten, indem Du unter "Playback" "Auto-load subtitles" ausschaltest. Mehrere externe Untertitel sind möglich, wenn Du sie z.B. so benennst:
    1.) untertitel.ger.srt
    2.) untertitel.eng.srt
    etc.

    Um Untertitel in Matroska standardmäßig abzuwählen, kannst Du im Haali Media Splitter folgende Einstellung unter "Languages">"Audio and Subtitle languages" setzen: "*,off" (ohne die Anführungszeichen)

  • x264, --min-keyint = auto?

    Soweit ich weiß sind "I" weiterhin IDR-Frames und "K" recovery-point-I-Frames (vorausgesetzt "--open-gop" ist aktiviert). Zumindest schluckt der aktuelle Patch das ohne zu meckern, habe den Stream allerdings nicht daraufhin untersucht, ob es tatsächlich die richtigen Frametypen gesetzt hat.

  • x264, --min-keyint = auto?

    Zitat von Selur

    Ging an sich ohne Probleme, wurde nur durch den OpenGop-Patch gekillt. (siehe openGop Thread im englischen Forum)

    Sehe da im Moment nur jpsdr, der sich in der aktuellen Version noch über Abstürze beschwert. Habe es mal mit dem aktuellen Build von kierank getestet und hatte keine Probleme. Welche Probleme gibt es denn noch damit?

    Zitat

    Um möglichst schnell dahin springen zu können (anders als I- sind IDR-Frames wirklich ohne andere Frames decodierbar), die Möglichkeit zu haben z.B. die Frames an den Kapitelstarts direkt zu dekodieren (wenn man z.B. ein Menü erstellt) und ohne Reencoden an Kapitelmarken schneiden zu können.

    Ein I-Frame ist immer ohne andere Frames dekodierbar, das ist doch gerade die Definition eines I-Frames. Das gilt auch für Nicht-IDR-I-Frames. Deshalb ist es meiner Meinung nach auch bei Kapiteln nicht vonnöten, einen IDR-Frame zu setzen, sondern es reicht ein recovery-point-I-Frame.
    Beim Schneiden (zum Beispiel eine Staffel einer Serie in einem Stück enkodieren und erst danach in einzelne Folgen schneiden) braucht man aber tatsächlich IDR-Frames, da stimme ich Dir zu.

    Zitat

    I-Frames referenzieren soweit ich mich entsinne immer nur in die Vergangenheit und nie in die Zukunft. (orientiere mich dabei an der 'decoding order')

    s.o.: I-Frames referenzieren gar nichts.

    Zitat

    IDR Frames erzwingen über ein qpFile geht leider aktuell noch nicht. (wollte eigentlich eine Hybrid Version herausbringen die openGop unterstützt, werde dies aber erst mal sein lassen bis das qpfile Problem gefixed ist)

    Hatte keine Probleme, als ich es kurz getestet habe. Was geht denn nicht? Dann würde ich erstmal den Patch nicht mehr nutzen.

    :huh:

    /edit:
    Anscheinend definieren wir beide "referenzieren" entgegengesetzt?

  • x264, --min-keyint = auto?

    Zitat von Selur

    Wenn DS meint der Wert könnte wegfallen, wäre das sicher interessant, wobei ich hoffe, dass der Open GOP Patch vorher noch in den Git MainBranch wandert. Vorher sollte er aber noch so angepasst werden, dass man immer noch über das qpFile IDR-Frames erzwingen kann (damit man z.B. an Kapitelmarken IDR-Frames erzwingen kann).



    Das mit dem Erzwingen über qpfile ( "K" vs "I") ist definitiv geplant bzw. schon implementiert, aber wozu sollte man an einer Kapitelmarke IDR-Frames erzwingen? Das ist doch eigentlich nur nötig, wenn die erste GOP eines neuen Kapitels die vorhergehende (also letzte GOP des alten Kapitels) referenziert. Der OpenGOP-Patch verursacht aber nur, daß die vorhergehende GOP die neue referenziert, also nur in eine Richtung. Oder irre ich mich? (Bin selber etwas verwirrt durch das alles)

    P.S.: Neuer OpenGOP-Patch und Binary sind im englischen Doom9 verfügbar.

  • H264 Broadcast settings in QT-Pro

    Zitat von LigH

    Der Encodiermodus "Constant Rate Factor" (CRF) des x264 arbeitet derart, dass die Bitrate sich daraus ergibt, wie fein die Quantisierung automatisch gewählt werden musste, um ein gewisses Qualitätsmaß zu gewährleisten, also Abweichungen zum Original gering zu halten. Leider ist er für Übertragungen mit begrenzter Bandbreite eher ungeeignet, weil er sich eventuell nicht an maximale Bitraten hält.

    Seit vorgestern hat x264 einen neuen VBV-Modus, welcher die bisherigen Probleme im CRF-Modus beheben soll.

  • Muxxen von 23.976fps-Video mit 25fps-Audio funktioniert nicht

    Zitat von klaro8872

    Habe zuerst die beiden Tipps von sneaker2 versucht, hat beides nicht geholfen.

    Warum? HQ-LQ lag richtig.

    Ich kann Dir nur Empfehlen, die Zeitstempel der Ursprungsdatei zu übernehmen, weil ich weiterhin zu meiner obigen Rechnung stehe.
    (Einzige Ausnahme: Sollte die variable Bildrate nur aus einer Verzögerung/eines Vorziehens des Beginns der Videospur herrühren, so läßt sich das Setzen einer konstanten Framerate durch einfaches Verzögern/Vorziehen der Tonspur ausgleichen.)

  • Muxxen von 23.976fps-Video mit 25fps-Audio funktioniert nicht

    Zitat von HQ-LQ

    ich glaube nicht das der film eine variable bildrate hat,
    denn dann würde mediainfo den kleinsten gemeinsamen nenner von ~24fps & ~30fps anzeigen, nehmlich ~120fps
    (prüf das erst einmal)

    Woher willst Du wissen, ob er MediaInfo nutzt?
    Zudem habe ich doch oben die durchschnittliche Bildrate genau errechnet. Und die liegt weder bei 24/1,001 noch bei 30/1,001. Es stimmt zwar, daß nicht 100% sicher ist, daß es VFR-Material ist, aber der Verdacht liegt schon nahe.

    Nebenbei würde es mich interessieren, wo MediaInfo das anzeigen soll? Habe es gerade mal bei einer VFR-Datei getestet und es zeigt bei mir nicht das kleinste gemeinsame Vielfache an, sondern nur "23.976", obwohl es Hybridmaterial ist. Oder geht es nicht bei allen Dateien? Habe eine Matroska-Datei mit DivX im VFW-Modus getestet.

  • Muxxen von 23.976fps-Video mit 25fps-Audio funktioniert nicht

    Wenn man bei MKVMerge keine FPS angibt, wählt er automatisch 25 FPS.
    Dabei kommst Du auf eine Länge von 26:51. Daraus läßt sich die durchschnittliche FPS der Ursprungsdatei berechnen:
    ((26*60+51)*25)/(22*60+50) =~ 29,39781 FPS

    Da diese Bildrate keinem Standard entspricht, liegt der Verdacht nahe, daß die Ursprungsdatei eine variable Framerate hat. Möglicherweise 24/1,001 und 30/1,001 FPS. Durch Dein manuelles Eingeben einer konstanten Framerate zerstörst Du damit jegliche Synchronisation. Du mußt die Zeitstempel aus Ursprungsdatei in die neue Datei übernehmen. Dazu gibt es zwei Möglichkeiten:
    1.) Öffne die Ursprungsdatei in MKVMerge, lasse das FPS-Feld leer und füge nun die MP3-Spur dazu und wähle nicht mehr benötigte Spuren ab oder
    2.) Extrahiere die Zeitstempel über mkvextract: "mkvextract timecodes_v2 film.mkv 1:timescodes.txt" - Wähle diese txt-Datei nun in den Eigenschaften der Videospur in mkvmerge als Quelle für die Zeitstempel

    Es liegen eventuell noch mehr Probleme vor, die ein synchrones Muxen verhindern könnten, aber die Zeitstempel müssen mit ziemlicher Sicherheit übernommen werden.

  • Xvid(avi) nach .mp4(mit yamb) hat danach fps 23.455(avi 25fps)

    Habe die nochmal heruntergeladen und erhalte dann auch nur die 230 KB große mp4box.exe, bei der "keep nvops" ebenfalls nicht geht. Komisch - dachte, daß das die Version sein müßte, die ich auch installiert habe. Naja, hauptsache es läuft jetzt so, wie Du es möchtest.
    Werde das mit YAMB mal dem Entwickler melden - scheint definitiv ein Fehler zu sein, den Du da gefunden hast.

  • Xvid(avi) nach .mp4(mit yamb) hat danach fps 23.455(avi 25fps)

    Zitat von gnarf

    1.) Also wenn ich das richtig verstanden habe:

    Wenn man 10 fast gleiche frames hat, dann wird davon nur 1 frame angezeigt allerdings nur 10 mal so lang(darum sinkt auch die frameanzahl wenn ich die mp4 mittels direkt show in vdub öffne); ist das so?

    Ja. XviD setzt dann einfach 1 "richtigen" Frame und 9 NVOPs im AVI-Container. Beim Umwandeln nach MP4 wird der erste Frame einfach länger angezeigt. (Ob ich den ersten 10 mal so lange anzeige oder ihn 9 mal wiederhole macht keinen Unterschied)

    Zitat

    2.) Was macht das mp4 mit den nicht dargestellten frames(gelöscht werden sie ja wohl nicht)?

    Doch, sie werden gelöscht. Allerdings ist dies kein Problem, weil das nicht bei "fast" gleichen Bildern gemacht wird, sondern nur bei NVOPs - welche 100% identisch zu den vorhergehenden sind.

    Zitat

    4.) Warum gibt es diese Framerate-Anpassung eigentlich nicht bei der Datei mit den Bframes? Ich hab jetzt auch schon andere Sources getestet und es ist immer das gleiche, die datei mit xvid/bframes hat immer 25fps und die ohne bframes hat immer eine niedrigere.
    Gibts diese NVOBs bei files mit bframes nicht?
    Ich mein ich würde ja gern die xvid-datei mit bframes nehmen aber das schafft mein handy nicht bei schnellen schwenkbewegungen(da ruckts)

    Die gibt es auch bei Dateien mit B-Frames, allerdings scheint XviD sie dort sehr viel seltener - häufig gar nicht - zu setzen.

    Zitat

    5.) Kann man diese fps anpassung irgendwo in mp4box(oder bei einem anderen mp4- erstellungstool) deaktivieren, sodass er die Videodatei 1:1 in den mp4 container packt ohne diese Framerate-Anpassung?

    Nein, da im MP4-Container keine NVOPs vorgesehen sind. (Falsch, siehe unten)

    Zitat

    6.) Worin liegt der Sinn dieser Framerate- Anpassung(Variablen Framerate)

    Gute Frage ;) . Die MP4-Ersteller sehen das Ganze wohl eher umgekehrt: die NVOPs sind ein für den AVI-Container notwendiger Trick, der bei MP4 nicht gebraucht wird.

    Zitat

    7.) Falls meine oberen Folgerungen stimmen;

    Wenn ich allerdings die datei ohne bframes in vdub öffne (mittels avs-scripts und ffdshow), dann finde ich keine frames die länger angezeigt werden. jeder frame wird gleich lang angezeigt nämlich ca. 0,043 Sekunden.
    wenn mans hochrechnet(mit 0,0426 sekunden) kommt man genau auf 9106 frames bei 6:28.237 Minuten Abspieldauer.

    Warum macht das dann vdub so; soweit ich das verstanden hab sollten ja nur frames die den fast selben inhalt nur einmal dafür doppelt solange angezeigt werden und die mit unterschiedlichem inhalt halt die üblichen 40 ms?
    Denn 43 ms ist ja keine korrekte anzeigedauer(kein Monitor hat diese Aktualisierungsrate)

    AviSynth arbeitet immer mit konstanter Framerate - deshalb diese Anzeige in VirtualDub. Wenn Du die Datei nun über VirtualDub einfach nur umwandeln würdest, würde Deine Datei unsynchron werden.


    Zum Schluß noch ein Wort, da ich glaube, daß Du den neuen Framerate-Wert falsch deutest:

    Die Framerate wird nicht wirklich geändert. Deine MP4-Datei läuft exakt solange wie die AVI-Datei und wird genau gleich ausgegeben. Man sollte sich nicht von den krummen FPS-Werten nach der Umwandlung verwirren lassen.

  • TCPMP spielt keine MKV mehr ab

    Ich kenne es leider auch nicht. Habe nur im Changelog vom mkvmerge geschaut und der Wechsel auf simple blocks schien mir die wahrscheinlichste Ursache für Dein Problem zu sein.
    Wird TCPMP überhaupt noch weiterentwickelt? Wurde glaube ich durch den kostenpflichtigen CorePlayer abgelöst. Evtl. müßtest Du etwas Geld investieren und schauen, ob der auch aktuelle Dateien unterstützt.