'Ne Szene mit Kameraschwenk wäre vielleicht besser zur Analyse - denn die Schwenks werden ja üblicherweise mit der vollen Framerate von 23,976fps (respektive 24fps) realisiert, während die Animationen eben nur mit 12fps produziert werden. Die Analyse der 12fps macht aber nach meinem Verständnis das Auffinden von derartigen "Rückwärtssprüngen" wie im obigen Beispiel schwieriger, da z.B. gar nicht auffallen würde, wenn Frame c3 und c4 vertauscht sind, da die ja identisch sind.
Beiträge von Tom Keller
-
-
Das ist mir ja auch klar - ich wollte nur Gründe nennen, warum an einem Encoder noch jahrelang (aus guten Gründen) gefeilt werden kann und warum ein Encoder-Update deshalb durchaus Sinn macht
. -
Warum sollte ich jetzt einen Codec aus 2016 benutzen, wenn der von 1999 eigentlich völlig ausreicht?
Weil neuere Versionen Bugfixes mitbringen, die Crashes oder Qualitätseinbrüche unter bestimmten Voraussetzungen beseitigen? Weil neuere Versionen MT-Optimierungen und Unterstützung für Befehlssatzerweiterungen aktueller Prozessoren mitbringen, die für massiv höhere Encoding-Geschwindigkeit sorgen? Weil z.B. bei LAME immer weiter am psychoakkustischen Modell gefeilt wurde, um die Klangqualität für jede Bitrate und Einstellung so weit wie möglich zu optimieren? -
Ist da überhaupt eine definitive/endgültige "was ist erlaubt" Angabe möglich? Ist ja erstmal nur ein Datenstrom - was da rein gepackt wird, kann sich doch theoretisch im Laufe der Zeit ändern (siehe: Einführung von H.265/HEVC). Und die maximale Bitrate bestimmt der Transponder... bzw. die Anzahl der darüber ausgestrahlten Kanäle (wobei es natürlich eine durch die Technik bestimmte Obergrenze gibt).
Effektiv lassen sich so höchstens Angaben dazu machen, was aktuell (mehr oder weniger) gängig ist - in der Art von:
- gängige Video-Codecs: MPEG2, H.264/MPEG-4 AVC, H.265/HEVC
- gängige Audio-Codecs: MPEG-1 Audio Layer 2, Dolby Digital/AC3, AAC
- usw.
-
Und hier nun der Schlüssel zum Erfolg des Gesamten Beitrages!
"Use Direct 3D 9/11 (EXPERIMENTAL)"
1x angehakt und mehr hätte ich in den ganzen Optionen nicht verstellen brauchen,
das das oben genannte Video dadurch nun flüssig läuft
Ähm... ich hatte dich auf der vorherigen Seite aber schonmal darauf hingewiesen, dass du mal mit den Display-Einstellungen dort "rumspielen" sollst - du hattest aber geantwortet, dass das nichts gebracht hat :hm: ... -
Hab ja kein VfW Blackmagic MJPG Codec auf diesem System Installiert und bekomme bei der Nativen Zuspielung
von L-SMASH-Works über AviSynth folgenden Decompressor unter VirtualDub angezeigt:
Internal DIB decoder (YUY2)
Jetzt nach dem ich die LAV Filters Installiert habe, bekomme ich nun einen anderen Decompressor angezeigt,
wenn ich das Video ohne AviSynth direkt in VirtualDub als AVI Datei öffne:[Blockierte Grafik: http://img.xrmb2.net/images/728335.png]
Der Internal DIB decoder (YUY2) ist für die Verarbeitung und Anzeige von unkomprimiertem(!) Video im YUY2-Farbraum da - also das, was (wie schon erwähnt) ein AviSynth-Script IMMER ausspuckt: unkomprimiertes Video. Die Videodecodierung übernimmt dabei L-SMASH.Wenn du die MJPG-AVI direkt öffnest, kommt der Internal Motion JPEG decoder (MJPG) zum Einsatz - das ist der von von 'LigH' erwähnte MJPG-Decoder, der in VirtualDub eingebaut ist. Die Videodecodierung übernimmt dabei VirtualDub selbst.
Mit der Installation der LAV-Filters hat aber nichts davon zu tun
.Letztendlich glaube ich nicht, dass hier die Ursache für das Ruckeln am Decoder liegt, sondern eher irgendwo zwischen Decoder und Ausgabe. Du könntest z.B. mal mit den Einstellungen in VirtualDub unter "Options" -> "Preferences" -> "Display" rumspielen (erstmal alle Anzeigebeschleunigungen abschalten und schauen, ob es was bringt... falls ja: nach und nach anschalten) bzw. unter "Options" -> "Allow Video Overlays" abschalten.
-
Ich bin verwirrt: was sollen die LAV-Filters da jetzt ändern? Das sind DirectShow-Filter/Decoder. Und weder VirtualDub noch VLC können nativ DirectShow-Decoder verwenden.
Abgesehen davon: für die Decodierung in AviSynth ist doch grundsätzlich der Quellfilter (also in diesem Fall: FFMS2/L-SMASH) verantwortlich - VirtualDub, VLC, MPC-HC bekommen dann immer nur das unkomprimierte Video geliefert und müssen "schlimmstenfalls" noch eine Farbraumkonvertierung vornehmen... aber eben nichts anderes machen.
Die Ursache könnte aber eventuell darin liegen, dass der MPC-HC (meines Wissens) als einziger das AviSynth-Script nativ über die eingebauten LAV-Filters öffnen kann und nicht auf den Umweg über das uralte VfW-Interface angewiesen ist. VirtualDub ist allerdings darauf angewiesen (es sei denn du erzwingst die Verwendung vom Ffmpeg-Input-Plugin für das Script)... beim VLC bin ich mir nicht ganz sicher. Die Installation der Standalone-LAV-Filters ändert daran allerdings (wie gesagt) nichts.
-
Vier Beiträge über deinem
:Sonstige Normwandlungs-"Verbrechen" hat scharfis_brain in seiner Übersicht "exotisches Interlacing" erklärt.
-
Herausgefunden habe ich, daß wohl die Komponente BePipe benötigt wird, dennoch habe ich es nicht hinbekommen.
Da hast du aber etwas falsches herausgefunden - BePipe wird nicht von BeHappy benötigt... im Grunde genommen IST BeHappy eine mit 'nem GUI aufgebohrte Weiterentwicklung von BePipe. -
Gibt es auch ein schönes kommandozeilenorientiertes Tool, welches opusenc.exe nutzt, und das vorher noch normalisieren kann? Ähnlich BeSweet?
Wie wär's mit BeHappy? Ich hatte zumindest mal eine Extension für die Einbindung der opusenc.exe geschrieben, die meines Wissens auch in überarbeiteter Form in die letzte BeHappy-Version eingeflossen ist. -
Wenn ich die "libgcc_s_sjlj-1.dll" aus der 2.6.11 nehme kommt die Fehlermeldung, dass die Datei "libwinpthread-1.dll" fehlt.
Und was passiert, wenn du die libwinpthread-1.dll dazu kopierst :hm: ? -
Nur die SUP sind defekt
Puhhh... dann kann es ja Gottseidank nicht an MaestroSBT gelegen haben - das kann nämlich keine SUP-Dateien erstellen :[Blockierte Grafik: http://abload.de/img/unbenannt-1dwbnn.png]
Ich persönlich hab für Muxman immer SST-Dateien mit 4-Bit-Bitmaps erstellt und hatte (wie gesagt) noch nie Probleme. Ich hab also mit MaestroSBT meine Software der Wahl gefunden - eben auch, weil mir andere Tools nicht so viele Gestaltungsmöglichkeiten bieten. Oder kennst du eine andere Software zum Rendern von Textuntertiteln, die mir erlaubt, für bestimmte Untertiteltafeln eine andere Schriftart oder -position als für den Rest anzugeben?
-
Das Authoring ändert die U/T nicht.
Hab ich auch nicht behauptet .Von MaestroSBT (sowohl als von SubtitleCreator) hätte ich grosse Erwartungen, die Realität war aber enttäuschend.
Ich hatte zuerst auch SubtitleCreator verwendet... bin dann aber zu MaestroSBT gewechselt, da SubtitleCreator (selbst wenn man in den Rendering-Optionen Anti-Aliasing abschaltete) scheinbar immernoch versuchte, eine gewisse Kantenglättung anzuwenden, die das Ergebnis aber eher "ausgefranst" aussehen lies (das ist aber schon eine Weile her - vielleicht kriegen das aktuelle Versionen besser hin).Auf jeden Fall bin ich deshalb auf MaestroSBT umgestiegen... und war damit bislang ausgesprochen zufrieden. OK - die Bedienung ist wirklich umständlich und man kann auch nur *.ssa Untertitel damit laden (*.srt Untertitel müssen daher vorher umgewandelt werden)... das ermöglicht allerdings auch (per vordefinierten Styles in der SSA-Datei) deutlich komplexere Gestaltungsmöglichkeiten als bei ähnlichen Tools (z.B. zweifarbige Untertitel... oder einzelne Untertitelzeilen, die woanders im Bild positioniert sind als der Rest).
So werden die U/T (fast alle von SC, teilweise von MS)
Das Photo zeigt wie ein Bild von Maestro SBT aussieht, nach deinterlacing.
So ein Fehlerbild hab ich noch nie zu Gesicht bekommen :hm: . Ich würde bei sowas aber immer erst einen anderen Player und (falls das nichts ändert) eine andere Authoring-Software zum Gegenprüfen heranziehen, bevor ich der Untertitelsoftware die Schuld gebe. Letzten Endes erzeugt MaestroSBT ja nur Bilder und eine Datei mit Timecode-Angaben (und enthaltenen oder separaten Angaben zur Farbzuordnungstabelle). Das sind alles Dateien, die man manuell auf Fehler überprüfen kann - und wenn man da keinen sieht, ist es nicht unwahrscheinlich, dass z.B. die Authoring-Software die Ursache ist (weil sie vielleicht aufgrund eines Bugs was fehlinterpretiert oder sonstwie verbockt hat)... oder eben der Software-Player (VLC ist z.B. meines Wissens immernoch teilweise ein wenig buggy, was die Video-DVD-Wiedergabe angeht). -
- Was für einen Fehler? Ohne Infos Fehlermeldungen sind wir Hellseher auf unsere Glaskugel angewiesen - und die ist mehr als unzuverlässig .
- Treiberprobleme? Mit Sicherheit... HALT... ganz bestimmt nicht... oder doch? Nee... mal im Ernst: wenn, dann fehlen höchsten passende Decoder - aber ohne Fehlermeldung lässt sich halt rein gar nichts dazu sagen.
- Wichtiger als 1. und 2.: DirectShowSource() sollte IMMER nur als eine Art "Notnagel" dienen, wenn native Source-Plugins versagen, bzw. nicht existieren. Sprich: LSMASHVideoSource() wäre hier zu bevorzugen, weil halt: "speziell für MP4-Dateien ausgelegt" und "nicht von System-Decodern (DirectShow/MediaFoundation) abhängig". Alternativ könnte man auch FFVideoSource() ausprobieren.
Erst wenn die versagen lohnt sich eventuell(!!!) ein Blick auf DirectShowSource(). Da sollte man aber lieber per GraphStudio (Next) einen Filtergraphen (*.grf) basteln und den laden, anstelle die eigentliche Media-Datei. Denn nur so kann man wirklich gezielt Einfluss auf die verwendeten DirectShow-Filter nehmen. Lädt man hingegen direkt die Datei, hängt es von den Merits der jeweiligen Filter ab, welcher bevorzugt verwendet wird - und die Vorgaben dazu sind meist alles andere als optimal.
EDIT: 'LigH' war schneller
! - Was für einen Fehler? Ohne Infos Fehlermeldungen sind wir Hellseher auf unsere Glaskugel angewiesen - und die ist mehr als unzuverlässig
-
Von der umständlichen Handhabung abgesehen ist MaestroSBT aber von der Qualität der gerenderten 4 Bit Bitmaps sehr gut – eben so gut wie es mit 4 Bit geht.
Die Bitmaps sind eher gut, die U/T sind leider nicht 100% kompatibel. Eine Regel habe ich noch nicht gefunden, mal geht 100%, mal hat es einige defekte U/T.
Ich muss da 'Skiller' zustimmen - von der optischen Qualität her produziert MaestroSBT extrem gute Untertitel. Kompatibilitätsprobleme hatte ich damit auch noch nie... und ich hab es bestimmt schon für 20-30 DVDs verwendet (meist mit Muxman authored). Vielleicht liegt die Inkompatibilität ja eher bei der Authoring-Software... oder betrifft nur ein ganz bestimmtes Untertitel-Ausgabeformat :hm: !? -
sorry ich habe halt eine andere Profession.
Warum 'sorry'? Die habe ich auch ...So wie ich das glaube verstanden zu haben, gibt es auch bei einem analogen Medium eine maximale Datenmenge
Jain. Die maximale Datenmenge hängt davon ab, wie genau du das analoge Signal erfassen willst und eine wie präzise Erfassung überhaupt machbar ist bzw. in der Praxis Sinn macht. Beim Digitalisieren von VHS-Bändern ist das z.B. nicht gerade unwesentlich davon abhängig, was der verwendete D/A-Wandler leisten kann.Beim Komprimieren des unkomprimierten Videos kommt zudem bei der Frage nach der Datenmenge die Gegenfrage nach dem Bildinhalt hinzu. Viel Bildrauschen interpretieren nämlich üblicherweise alle Kompressionsalgorithmen als zu bewahrende Bilddetails (= mehr Bitrate nötig) - das gleiche gilt für viel Bewegung im Bild und (verständlicherweise) für komplexe und kontrastreiche Bildinhalte. Je (inhaltlich) gleichförmiger und (zeitlich) unveränderter die Bildinformationen sind, desto besser/effektiver lassen sie sich ohne Verluste (bei verlustlosen Kompressionsverfahren) bzw. ohne sichtbare Verluste (bei verlustbehafteten Kompressionsverfahren) komprimieren = desto weniger Bitrate ist nötig = desto niedriger die Datenmenge.
Die Frage nach der Datenmenge ist daher nicht wirklich zu beantworten - zumindest nicht pauschal.
-
reicht es gar, den H.264 12,5Mbit/s Stream zu wählen, da dieser die gesamte Datenrate eines VHS-Signals abbildet?
Das sind so Fragen, bei denen sich mir ein wenig die Nackenhaare kräuseln . Grundsätzlich ist da nämlich schon einmal der Denkfehler drin, dass der Inhalt eines analogen Mediums (wie eben der einer VHS) einer präzisen Datenmenge entsprechen muss :hm: ... ganz zu schweigen von dem Fehler, die Durchschnittsbitrate eines hocheffizienten Kompressionsformats wie H.264 (ohne Rücksichtnahme auf den Bildinhalt) als Qualitätsindex zu nehmen :eek: ... -
u.a. ein lied "googtime" welches in avi & mpg vorlag...
Das Video lag der Windows95-CD nur als AVI-Datei in zwei Varianten bei - beide mit einer Auflösung von 320x240 Pixeln @ 15fps, komprimiert mit Cinepak. Eine Version besaß allerdings 2-Kanal-PCM-Ton mit 11kHz @ 8bit, die andere (High-Performance-Variante ) kam mit 22kHz PCM-Ton @ 16bit daher.Auf der Windows98-CD gab es auch Videos - aber das waren alles nur Werbeclips für Microsoft-Produkte (z.B. für den "Microsoft Flight Simulator 98" oder für die "Microsoft IntelliMouse"). Einige dieser Clips waren zwar MPEG Program Streams - enthielten allerdings nur MPEG-1-Video mit MP2-Ton. Denn worauf ich oben hinaus wollte und wie 'LigH' ja auch schon schrieb: MPEG-2 beherrschte Windows9x von Haus aus nicht.
-
Damit sollte wohl selbst Win98 noch zurecht kommen - LOL :ani_lol:
Aber nicht von Haus aus :zunge: . -
Mit Build 2050 soll sich das aber geändert haben - ich zitiere mal von hier:
ZitatI slipstreamed into 2050 a licensing fix. It now properly uses only the motherboard serial number. You will need to make a new license when you grab this, theoretically the last you'll ever need for your specific motherboard.
There are some other changes to licensing. The license generator now detects duplicate machine IDs and won't increment the count if you re-enter a machine ID you already licensed. You can use that to query the license keys you already made. If you put a new machine ID, however, you will get incremented. Next, the maximum number of licenses was increased to 16. Finally, VBVChecker licensing was made the same as the other DG tools. Now all the tools should generate the same machine ID (except DGAVCDecDI, which I plan to kill very soon).
These changes make the licensing much more user-friendly. With these changes, going forward, I am less receptive to license count reset requests, as 16 unique machine IDs per donation is fair. Eliminating the reset also simplifies maintenance.
Sprich: ab dieser Version wird nur noch die Motherboard-Nummer zur Generierung der Machine-ID herangezogen. Solange man also nicht das Motherboard wechselt, sollte somit die bestehende Lizenz Gültigkeit behalten. Das war meiner Meinung nach schon lange überfällig, da ich (ebenfalls dank mehreren Software-Netzwerkadaptern) bislang schon 6 Mal eine neue Lizenz generieren durfte
.
