b-frames in xvid deaktivieren sinnvoll?

Monk

Also ich habe jetzt schon einiges getestet, aber mir scheint die von mir angegebene Einstellung eigentlich ganz gut zu sein.

AQ aus = dürfte klar sein, da ich bei solchen Bitraten auch in dunklen Passagen nichts einsparen muß. Wäre sie an, würde man in dunklen Passagen zu viele Details verlieren.

Trellis = Meiner Meinung nach sind Trellis eher für Bitraten <=2000 kbit geeigent, da sie dunkle Kontraste zum tänzeln bringen. Was spricht denn dagegen Trellis abzuschalten?

Qpel = da bin ich mir noch nicht so sicher, ob es wirklich lohnt, diese einzusetzen, da die Encoding-Zeit um einiges verlängert wird. Außerdem habe ich schon des öfteren eher negative Erlebnisse mit qpel gemacht. Gut es könnte daran gelegen haben, daß ich bisher immer unter 1800 kbit encodiert habe.

b-frames abgeschaltet = hier bin ich mir mittlerweile ziemlich sicher, den richtigen Weg eingeschlagen zu haben. Ich habe einige Versuche mit und ohne b-frames unternommen. Stets präsentierte sich das Bild ohne b-frames als harmonischeres.

Matrix = Danke für den Tip. Diese Matrix wird auf jeden Fall mal getestet.

Bis später.

LigH

Mich würde dennoch interessieren, ob der Einsatz von B-Frames, die nicht wesentlich höhere Quantisierungsfaktoren bekommen als I/P-Frames, also nur von beidseitiger Bewegungsschätzung profitieren können, nicht doch gewisse Vorteile bringen.

Selur

Trellis sollte eigentlich ein 'only win' Feature sein was die Qualität angeht.
Persönlich würd ich wie Ligh B-Frames an lassen mit 2/1/0

Cu Selur

Monk

Hi Selur,

aber ich habe auch schon hier im Forum Beiträge aufgestöbert, in denen sich dieses Thema als äußerst strittig präsentierte. Es mag sein, daß es in den meisten Fällen von Vorteil ist (speziell auf niedrigere Bitraten bezogen) die Trelli-Funktion zu aktivieren, aber die "only win-Aussage" würde ich nach eigenen Erfahrungen nicht unterschreiben.

Das Bild wirkt ohne einfach harmonischer oder noch besser gesagt, statischer. Aber wie gesagt, beziehen sich meine Erfahrungen auf eine Bitrate von ca. 3600 kbit.

Ich werde aber nochmal den Tip b-frames 2/1/0 probieren.

Bis später.

billy

Ich nehme keine b-frames, aus dem einfachen Grund weil mein SA bei Nero u. vorher bei XviD rumspinnt. Ich bin mir aber auch nicht sicher ob das zwischenzeitlich alle neueren SA's richtig beherrschen.

Gruß, billy

Monk

Kann es denn zu irgendwelchen Komplikationen kommen, wenn die b-frames wegfallen? Normalerweise doch nicht, oder?

Mal kurz zwischendurch die Frage:

Was stelle ich bei Gordian Knot unter frameoverhead ein? Der Sound ist wahlweise AC3 oder mp3. Muß ich diesen frameoverhead überhaupt noch bei matroska beachten?

Kann es sein, daß es bei der Wiedergabe des fertigen Videos bei falschem frame-overhead zu Rucklern kommen kann? Normalerweise doch nicht, oder irre ich mich?

LigH

"Overhead" ist der Platz, den das Kontainerformat mehr braucht, um die Synchronität zwischen Video und Audio-Spuren zu gewährleisten. Denn die entsteht dadurch, dass immer abwechselnd ein paar Video-Frames und ein paar Audio-Blöcke gespeichert werden. Da muss dann zusätzlich irgendwo gespeichert sein: "Ab hier kommt Video, ab dort Audio, ..."

Je kleiner die Fragmente sind, umso leichter ist die Synchronität zu bewahren. Aber umso mehr Overhead entsteht - die endgültige Datei wird größer als die Summe ihrer Einzelteile.

Bei MP3 ist es relativ unkritisch; bei AC3 dagegen ist es wichtig, dass an den Grenzen der Audio-Blöcke getrennt wird. Und die dauern nicht genau so lange wie die Video-Frames. So kann es sein, dass z.B. mal 2, mal 3 Frames zwischen Audio-Stücken liegen müssen.

Monk

Hallo Ligh,

wie ich das jetzt verstanden habe, muß ich das jedesmal austesten. Also einmal wähle ich 2 und einmal 3 frames unter GK. Es gibt aber einige, die behaupten, der Frameoverhead spiele unter Matroska keine Rolle mehr, ist das also falsch? Oder waren Deine Äußerungen auf das avi-Format bezogen?

Kann denn durch die falsche Wahl der frames das Video ruckeln?

LigH

Zitat von Monk

Also einmal wähle ich 2 und einmal 3 frames unter GK.

Nein. Bei AC3 gibt man das Interleaving (das Maß, wie groß die Stückchen gewählt werden) in Millisekunden an. VirtualDubMod rechnet dann schon aus, wie oft wie viele Frames verwendet werden müssen. Und ich rede hier eher von Mustern wie

3 Videoframes - n Audioblöcke - 2 Videoframes - m Audioblöcke - 3 Videoframes - ...

Durch eine falsche Wahl der Interleaving-Faktoren kann es bei AC3-Tonspuren zu Rucklern kommen, je nach Decoderfilter und Player; laut AlexNoe liegt das eher an den Decoderfiltern, die da zu wählerisch sind.

Aber VirtualDubMod und AviMux_GUI machen das mittlerweile zuverlässig: Stelle ein, wie viele Audio-Spuren du verwendest, und welchen Typ - und vertraue ruhig.
__

Jedes Kontainerformat hat einen Overhead, besonders wenn Video und Audio gemultiplext vorliegen. Das eine Format hat einen größeren Overhead, das andere einen kleineren.

Ein paar Details dazu kannst du auf der Webseite von Alexander Noe finden, wo er die "Mythen über AVI" aufklärt:

http://forum.gleitz.info/showthread.php?t=12764

Monk

Wie stehts denn mit der Zuverlässigkeit von mkvmerge in dieser Hinsicht? Das benutze ich nämlich meistens zum muxen.

LigH

Matroska wurde entwickelt, als diese Problematik längst bekannt war. Und viele Player, die Matroska verarbeiten können, verlassen sich auch nicht mehr auf andere AC3-Decoder, sondern decodieren es selber.

Monk

Ich hoffe, daß Ihr mich nicht langsam für eine Nervensäge haltet. Aber ich muß es die Vorgehensweise genau wissen, um nicht am Schluß irgendwelchen Bockmist zu produzieren.

Also:

Gordian Knot ist doch im Prinzip nur ein Frontend. Demnach ist es doch sowieso Wurscht, was ich dort wo eingebe. Die Eingaben sind doch lediglich interessant, wenn ich direkt in GK encodiere. Richtig?

Ich encodiere aber direkt mit Virtual Dub in mkv. Muxen in Virtual Dub ist also Essig, da kommt bei mir immer eine Error-Meldung, deshalb benutze ich mkvmerge.

Nun daher nochmal die abschließende Frage (um ganz sicher zu gehen).

Erkennt mkvmerge automatisch, wenn ich ihm eine AC3 vor die Füße schmeiße, welcher frameoverhead angewendet werden soll?

Oder versteckt GK im avs-script irgendeinen Hinweis in Bezug auf den frame-overhead? Ich weiß, das hört sich blöd an, aber ich suche nach einer Begründung, warum sich das Video meiner Meinung nach verändert, sobald ich am frameoverhead herumspiele, obwohl ich ja nicht in GK encodiere.

kurt

du machst doch in GK nur ein avs-skript für das video, oder? das kannst du ja beliebig bearbeiten. dann sollten eigentlich keine infos über tonspuren da auftauchen...
was den overhead angeht: im XviD_bulid_in-Calculator kannst du ja alle Werte eingeben (AC3, Filesize, matroska usw.) - das kommt bei mir eigentlich immer ganz gut hin mit der angestrebten Zielgröße (nach Muxen in mkvmerge) ...
hatte mit mkvtoolnix nie probleme beim Muxen mit AC3, manchmal muss ein Delaywert eingegeben/angepasst werden - steht aber ja auch nach dem Rippen im Tonspurnamen...

btw: mit VDM sollte man auf keinen Fall mkvs muxen, da dies nicht vollständig unterstützt wird (VDM ist veraltet) - also gut daß es bei dir eh nich funzt

Monk

Hallo Kurt,

danke für die Info. Dann fällt mir aber jetzt ein großer Stein vom Herzen. Ich habe nämlich vor einiger Zeit schon einmal mit Matroska herumgespielt und auch einige Videos erstellt. Ich hatte schon die Befürchtung, die wären alle versaut (also von der Technik, nicht vom Inhalt her ).

Also muß im Prinzip lediglich der delay-Wert angepasst werden und den frame-overhead in GK kann ich getrost links liegen lassen. Ok, dann mache ich das so.

kurt

hehe, hatte mal ähnliche Befürchtungen gehabt:
http://forum.doom9.org/showthread.php?s=&threadid=88156

fps

Zitat von Monk

Also muß im Prinzip lediglich der delay-Wert angepasst werden...

Wobei du beim Delay aufpassen musst den richtigen zu nehmen.
DVDDec***ter solltest du im Nornalfall nicht vertrauen, DGIndex dagegen schon.

Monk

Hallo Kurt,

mich machte stutzig, daß ich bemerkte, daß sich eine Änderung des frameoverheads in GK auf das gemuxte Video auswirkte, obwohl ich nicht direkt in GK gemuxt hatte. Aber das kann nur Einbildung gewesen sein, weil GK - wie Du auch schon sagtest - nur ein avs-script erstellt, mehr nicht, wovon ich eigentlich bisher auch immer ausging . Aber ich bin froh, daß dieses Thema durch die endgültige Gewissheit endlich aus der Welt geschafft wurde.

Aber prinzipiell ist es doch möglich, vorausgesetzt man hat Video und Audio falsch gemuxt, diesen Fehler zu korrigieren, durch einen demux und anschließenden "Neu"-mux.

Ist halt nur ärgerlich wegen der verbratenen CDs oder DVDs.

Mir ist aber gestern nacht noch etwas neues aufgefallen.

Kann es sein, daß das aspect ratio je nach Container minimal verändert wird?

Mplayer zeigt mir bei Matroska-Files (anamorph) 720x576 entzerrt auf 1024x576 an.

Das gleiche Video in mpeg4 oder avi gemuxt weist ein aspect ration von 1048x576 auf.

Viperzahn

Zitat von fps

Wobei du beim Delay aufpassen musst den richtigen zu nehmen.
DVDDec***ter solltest du im Nornalfall nicht vertrauen, DGIndex dagegen schon.

Das ist unsinn.

kurt

@ Monk: sorry mit Gk kenn ich mich kaum aus: ich croppe da nur und stell falls nötig noch die UT-Spur ein um letztlich nur das avs-script zu erzeugen... frameoverhead hab ich da nirgends beachtet/gesehen...
wenn du mal ein falsch gemuxte DVD gebrannt hast (Audio-Delay), ist das eigentlich kein Problem, weil du auch während der Wiedergabe im AC3Filter oder auch in ffdshow diesen Delay wieder ausgleichen kannst... man muß halt nur ein bischen mit den Werten rumspielen

zur AR: hui, keine Ahnung, warum das außerhalb von mkv aus der Reihe fällt... zum Ändern der mp4-DAR gibts ja den ARchanger (s.anderer Thread)

allgemein: wenn du sicher gehen willst welche AR die richtige ist, einfach eine entprechende *.vob decodieren --> screenshot machen und mit der eingestellten AR deines videos vergleichen.... (aber das wirst du wohl auch selbst wissen :D)

fps

Zitat von Viperzahn

Das ist unsinn.

Glaube ich nicht.
Schau mal in diesen Thread, dort wurde über das Thema schon mal diskutiert.
Bei meinen DVDs lag der DvdDecrypter(bis Version 3.5.2.0) sehr oft daneben:
Er lieferte bei manchen Serien DVDs immer -80ms, DGIndex dagegen 0ms.
Durch Vergleichen hat sich eindeutig herausgestellt dass die 0ms stimmen, was sehr leicht an einer öfters vorkommenden tickenden Uhr festzustellen war .

Jetzt mitmachen!