Meldung, dass die Kompression leiden würde,
weil die Höhe nicht durch 16 teilbar ist... Was bedeutet das ??
Das die effektive Größe bei gleicher Qualität nicht so gut sein wird wie wenn das Material durch 16 teilbar wäre.
Das Bild ist astrein... oder ist das nur eine optische Täuschung ?
Wenn Du Deinen eigenen Augen nicht vertraust, was sollen wir da sagen?
Wie wäre es mit: "Du täuscht Dich, das Bild sieht mies aus und Du solltest die Dorgen wechseln."
Sollte man sich bei solchen Meldungen Sorgen machen ?
Nicht mehr als man sich um die Verwendung von x264vfw sorgen machen sollte,...
Cu Selur
Hi Selur, alles fit ? 
Das die effektive Größe bei gleicher Qualität nicht so gut sein wird wie wenn das Material durch 16 teilbar wäre.
äh... umgekehrt vielleicht ?
nicht so gute effektive Qualität bei gleicher Grösse würde ich eher verstehen... 
Wenn Du Deinen eigenen Augen nicht vertraust, was sollen wir da sagen?
Wie wäre es mit: "Du täuscht Dich, das Bild sieht mies aus und Du solltest die Dorgen wechseln."
Valium wechseln...? sowasvonegaal... wozu ?? :ani_lol:
Nicht mehr als man sich um die Verwendung von x264vfw sorgen machen sollte,...
Hier in dem Fall gehts nicht anders, da ich (für heute...) auf diese vergleichsweise umständliche Scriptschreiberei keine Lust habe.
Sämtliche Filter in Vdub sind auf diese Weise viel bequemer zu handhaben.
und x264vfW ist bei "üblichen" Bitraten besser als sein Ruf... Oder sollte ich dich jetzt missverstanden haben ?
Hinterher pack ich es sowieso wieder in mkv, falls dich das beruhigt 
Wer passende GUIs verwendet, die x264.exe als Kommandozeilenencoder verwenden (MeGUI, StaxRip, sx264/Hybrid), der muss überhaupt keine Zeile Skript selber schreiben, und erzeugt gleich von Anfang an Videodateien mit einem Kontainer, der die Komplexität von MPEG4-AVC (H.264) überhaupt korrekt verwalten kann. Außerdem bietet x264vfw überhaupt nicht das volle Potenzial aller Optionen, die x264 unterstützen würde.
Und dass die VirtualDub-Filter durch das Konvertieren von YUV zu RGB zum Filtern und nachträglicher Konvertierung von RGB zu YUV zum Komprimieren sowohl Zeit als auch Qualität verschwenden, haben wir nun wahrlich oft genug erwähnt.
Die Komprimierbarkeit bzw. Effizienz ist ohne Teilbarkeit durch 16 vielleicht geringfügig schlechter, aber nicht das größte Problem (es sei denn, man betrachtet den unteren und rechten Rand mit der Lupe). Statt dessen aber funktionieren viele Beschleunigungsfunktionen beim Abspielen nicht ohne.
geschrieben, warum die teilbarkeit/16 gegeben sein sollte hat aber noch niemand. Also...
Bei der Kompression wird das Bild in 16x16 große Pixelblöcke unterteilt. Wenn eine glatte Teilbarkeit/16 in beide Richtungen gegeben ist, schön. Wenn nicht, muss der Encoder am Rand zusätzliche Pixel hinzuerfinden, um den Letzten Block auch noch auf 16 aufzufüllen. Diese Pixel tragen natürlcih keine Bildinformation, aber müssen halt verarbeitet und gespeichert werden. Dieser Overhead ohne Nutzen ist die gesunkene Encodereffizienz: Mehr Daten bei gleicher Quali, oder aber schlechtere Quali bei gleicher Datenmenge. Den Qualitätsverlust kann ich mit bloßem Auge nicht erkennen, aber die zusätzliche Datenmenge ist durchaus relevant. Der Effekt ist bei niedrigen Auflösungen prozentual größer, als bei Hohen. Allerdings wirst du durch verwendung der veralteten vfw-Version von x264 ähnliche Nachteile erleiden, die dir Offensichtlich nix ausmachen (sonst würde man das nicht verwenden, denn LigH hat dir einfachste Alternativen aufgezeigt.)
tach auch !
Sind das wirklich 16*16 Blöcke?
Gab es da nicht auch (Sub-) Blöcke 8*8 ?
Zumindest bei MPEG reichet eine Teilbarkeit durch 8 meistens aus, um das Maximum an Kompression zu erreichen.
Wenn du nicht mehr als MPEG sagst, wirds schwer dazu was zu sagen, denn es ist näherungsweise alles MPEG was in diesem Forum läuft.
Die Encoder, die ich bisher benutzt hab, fragten nach 16er-Blöcken. Es gibt auch bei x264 dynamisch verwendete Subblöcke (bis 4x4), allerdings vermute ich, das sich 16x16 als bewährter Standard etabliert hat. Immerhin vervierfacht man mit einem generellen Wechsel auf 8x8 den Aufwand für Bewegungssuche, Frequenztransformationen und wahrscheinlich noch einiges mehr. Und der Rechenaufwand ist ohnehin schon unhandlich.
Eine 8x8-Sample-Unterteilung (wie bei MPEG1/2 per DCT üblich) verwendet MPEG4-AVC / H.264 eigentlich nur - wenn erlaubt - im High Profile.
Und da bei Chroma-Subsampling 4:2:0 die U- und V-Komponente horizontal und vertikal je halbe Auflösung haben, decken 8x8 U-/V-Samples insgesamt 16x16 Samples in der Y-Komponente ab.
Bei MPEG1/2 nannte man diese Kombination aus U-Block, V-Block und 2x2 Y-Blöcken einen "Makroblock".
Der Nachteil des unnötigen RGB Zwischenschrittes ist vor allem darin zu sehen, dass ohne ihn das Encoden ca. 10% flotter geht.
Nicht nur allein durch die Konvertierung, sondern auch dadurch, dass RGB24 doppelt so viele Bytes benötigt wie YV12, und dass viele Bearbeitungsfunktionen im YUV-Farbraum einfach effizienter durchführbar sind (z.B. Änderungen der Helligkeiten müssen auf R, G und B angewendet werden, im Gegensatz zu nur Y).
Ist schon schade, dass so viele Jahre Entwicklung in AviSynth geflossen sind, um optimale Videobearbeitung zu ermöglichen, was sich dank AvsP mittlerweile auch relativ einfach austesten lässt - aber nur die Faulheit hält die technisch veraltete VirtualDub-Filterung am Leben...
Wenn du nicht mehr als MPEG sagst, wirds schwer dazu was zu sagen, denn
Bei mir altem Sack bedeutet MPEG immer 1/2.
Diese neumodische Schweinkram, der eigentlich MP3 heißen sollte und jetzt MP4 heißt, oder h264 oder wasauchimmer kann doch in den Blöcken haben was er will. ;):ani_lol:
Dank LigH heben sich auch wieder die Nebel der Vergangenheit als ich noch wußte das DCT Discrete Cosinus Transformation heißt.
Nicht nur allein durch die Konvertierung, sondern auch dadurch, dass RGB24 doppelt so viele Bytes benötigt wie YV12, und dass viele Bearbeitungsfunktionen im YUV-Farbraum einfach effizienter durchführbar sind (z.B. Änderungen der Helligkeiten müssen auf R, G und B angewendet werden, im Gegensatz zu nur Y).
ist doch alles richtig Leute... aber was letztendlich zählt, sind nicht messwerttechnisch interessante Details sondern nur das sichtbare Ergebnis, oder ?
und 10% mehr Zeit... lol, das sind bei den üblichen 6 h Encodierzeit gerade mal 30 Minuten. Der PC rödelt sowieso die Nacht durch...
Für den Komfort bei gleicher visueller Leistung ist das für mich ein akzeptabler Tausch.
Ist schon schade, dass so viele Jahre Entwicklung in AviSynth geflossen sind, um optimale Videobearbeitung zu ermöglichen,
Nein, es ist nicht schade, denn es kommt grösstenteils denjenigen zugute, die speziell darauf zugeschnitten sind...
- aber nur die Faulheit hält die technisch veraltete VirtualDub-Filterung am Leben...
Ich gebs zu, ich war(bin, lol...) in diesem Fall nur ein kleiner bequemer Sünder gewesen. Wie die überwiegende Mehrheit bin ich nicht mit einem Spock Gehirn gesegnet das in Programmiersprachen badet. Aber ich würde Bequemlichkeit den Menschen nicht vorhalten, denn das ist eine unumstössliche Tatsache alles Lebendigen schlechthin. Spock hat sich daran gewöhnt dass das auch immer so bleiben wird.
Ich nehme ja auch brav weiterhin Avisynth filter wenn es denn wirklich sein muss
Hinterher pack ich es sowieso wieder in mkv, falls dich das beruhigt
Geht das jetzt? Früher kamen vom Muxer heftige Warnungen, wenn man einen Stream im vfw-compatiblity-mode in mkv muxen wollte:
Error: 'bandits_movie.mkv' track 1: You are trying to put AVC/h.264 video from an AVI or a similar VfW (Video for Windows) compatible source into a Matroska file in the so-called 'VfW compatibility mode'. Please note that this is not the official way to store AVC/h.264 video in Matroska. Therefore proper playback of such files cannot be guaranteed, and we strongly urge you to use the native Matroska-mode.
At the moment mkvmerge does not support converting from VfW-mode AVC/h.264 tracks to native Matroska-mode AVC/h.264 tracks. You can, however, first import the video track into a MP4 file with e.g. 'MP4Box' (use Google). Then you can use mkvmerge and put the video into a Matroska file.
If you really know what you are doing then you can force mkvmerge to put this AVC/h.264 track into a Matroska file even in VfW mode if you add '--engage allow_avc_in_vfw_mode' to the command line. You can do that in mmg with the 'Add command line options' menu entry in the 'Muxing' menu.
Man kann aber aus den vfw-compatibility-streams richtige native-streams machen:
1. Mit VD ein avi machen
2. x264-raw-Daten aus avi extrahieren: mp4box.exe -aviraw video video.avi
3. x264-raw-Daten in mp4 muxen: mp4box.exe -add video_video.h264 video.mp4
4. mp4-Video zusammen mit dem Ton in mkv muxen
Gruß
akapuma
In einer AVI-Datei werkeln überhaupt keine Codecs. Wenn überhaupt, dann im Windows-System, das die AVI-Datei abspielt. Falls eine AVI-Datei ausführbaren Code enthalten sollte, dann würde ich mir aber ernsthaft Sorgen um die Sicherheit meines PCs machen.
Ja, natürlich weiß ich, dass du damit eigentlich ausdrücken wolltest: "egal mit welchen Codecs der Inhalt des AVIs encodiert wurde"; aber ich kann da akapuma's Signatur nur zustimmen.
@Lil barney
5000er Bitrate bei 720p
Soll anscheinend ne DVD-R werden. Aber in 5Mbit kann man schon fast bequem nen FullHD-Videostream bei guter Qualität parken. Das die vfw-version dabei konkurrenzfähig ist, wundert jetzt nicht... Da kannste auch xvid nehmen, und du bist ein vielfaches schneller aus der Sache raus. Selbst mpeg2 würden die meisten Menschen nicht unterscheiden können, und das codierste mal eben in ner kaffeepause.
... und du bist ein vielfaches schneller aus der Sache raus
kommt aber sehr auf die Einstellungen an bei gleicher Datenrate gehe ich stark davon aus, dass man mit x264 schneller Encoden kann und dabei qualitativ besseres Material erhält als bei Xvid (wenn man sich etwas mit den Einstellungen beschäftigt).
Nochmal "zu-durch-16-teibar", welche Möglichkeiten hat man überhaupt?
Filme werden (soweit mir bekannt) immer in durch 16 teilbaren Auflösungen gesendet. Filme haben aber oft einen "Schmutzrand", den man entfernen kann, z.B. 0 - 20 Pixel je Seite. Schneidet man die Ränder weg, dann ist es unwahrscheinlich, daß die Auflösung nachher noch durch 16 teilbar ist.
Möglichkeit 1: Auflösung ignorieren und einfach croppen (nicht durch 16 teilbar)
Was macht der Codec? Meines Wissens nach füllt er intern die Bereiche auf, so daß es wieder durch 16 teilbar ist. Es wird aber so aufgefüllt, so daß so wenig Verluste wie möglich entstehen (Wie war das nochmal? Wurde gespiegelt oder wiederholt?)
Möglichkeit 2: Alles so lassen, wie es ist
Hier muß der Codec den "Schmutzrand" mit codieren. Das macht aber meines Erachtens folgende Probleme:
- Den Rand zu komprimieren ist wesentlich weniger effizient als dem Codec den Rand selbst intern auffüllen zu lassen, insbesondere, wenn der Rand eine scharfe Kante bildet.
- Der Rand ist auch schonmal recht häßlich. Und wenn man z.B. einen 4:3-Film auf einem 16:9-TV sieht, dann sieht man den Rand rechts und links, weil er nicht durch den Overscan verschwindet.
Möglichkeit 3: So schneiden, so daß es duch 16 teilbar ist
Zwangsläufig muß man mehr schneiden als notwendig. Und bei bestimmten DVB-Sendungen hat man z.B. nur etwa 350 sichtbare Zeilen. Wenn man dann noch z.B. 15 Zeilen mehr davon wegschneiden muß, um auf MOD16 zu kommen - na, ich weiß nicht.
Möglichkeit 4: Croppen und anschließend auf MOD16 resizen
Beispiel: der letzte von mir umgewandelte Film hatte eine Auflösung von 720 x 576 Pixeln. Nach dem Croppen waren es noch 714 x 572 Pixel. Und, um auf MOD16 zu kommen, habe ich auf 704 x 560 Pixel resized.
Nun - welcher Weg wirklich der beste ist weiß ich nicht.
Gruß
akapuma
Edit: hab noch was gefunden: Link
Wurde gespiegelt oder wiederholt?
Wiederholt.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
