Beiträge von mb1

    Zitat

    Tmpg

    Im Moment habe ich keinen anderen Codec auf dem System, das dieses Video öffnen kann. Das ist wenigstens vorbildlich.
    Ich habe das ganze erst mit OpenDMLSource AviSynth geöffnet und an VirtualDubMod weiter gegeben zum Snapshot. Dann noch mal an Tmpg verfüttert.


    OK, dann waren es wohl nur falsche Einstellungen.

    Optimalerweise ist aber ein entsprechender DV-Codec installiert.
    Dann kann VirtualDubMod auch direkt öffnen.
    Einige Encoder bringen ihre eigenen DV-Decoder mit, z.B. Procoder und Mainconcept.

    Gerade mit Avisynth muss man sehr aufpassen bei DV.

    Tja, das hatte ich befürchtet :(
    Dein Himmel ist leider "nur" grau.

    Links mein Original, rechts dein Bild zum Vergleich:

    [Blockierte Grafik: http://people.freenet.de/mb1svcd/Gol_compare.jpg]


    NACHTRAG:

    Zitat

    mb1: Wieso hat denn Wesi das Video ohne Logo nicht freigegeben ? Spricht da was Existenzielles dagegen, das zu nehmen, will heissen ihn zu fragen und eine Erlaubnis dazu zu bekommen ?


    Ich glaube, das war mehr aus Vorsicht. Durch meine Tests wurde es zu einem gewissen Standard-Testvideo - und da wollte er sich wohl das Video nicht komplett ungeschützt aus der Hand nehmen lassen.
    Weiß aber seine Beweggründe auch nicht wirklich.

    Zitat

    Hallo mb1,

    das Video habe ich vor x Monaten mal von Wesi bekommen. Es hat das Logo.
    Ist aber nicht mit dem MS Codec gerendert worden. Canopus Software DV Codec (dvsd).


    Hmm, hoffentlich hat er es "richtig" gerendert.
    Der MS DV spreizt ja den Farbraum beim dekodieren (und staucht beim enkodieren), der Canopus DV lässt diesen immer unangetastet.

    Im Zweifel hat das Video dann zu intensive Farben.

    So muss der erste Frame (zumindest in meiner Achterbahnversion) korrekt aussehen:

    [Blockierte Grafik: http://people.freenet.de/mb1svcd/Goliath_Farbumfang.jpg]

    und so sieht es aus, wenn es falsch ist:

    [Blockierte Grafik: http://people.freenet.de/mb1svcd/Goliath_Falschfarbe.jpg]

    Was für eine Version des Achterbahnvideos ist das denn mit 440 MB?
    Ist das die Version, in der hin und wieder ein Logo eingeblendet wird?

    Das ist dann kein Originalcapture, sondern bereits eine zusätzlich gerenderte Version (auch noch mit dem MS DV und allen entsprechenden Qualitätsabstrichen).
    Zum dekodieren sollte dabei dann auch unbedingt der MS DV benutzt werden!

    Die Version, mit der ich meine "DV zu Mpeg2" Tests mache, hat 514 MB, ist Typ2 und hat 2:24 min (3616 Frames PAL), kein Logo und ist der Original-Firewire-Capture.

    Allerdings wurde diese Version von Wesi (TW) wohl nicht für die Allgemeinheit freigegeben :(

    NACHTRAG:
    Mit 7zip kann man das Achterbahnvideo um über 10% packen (deutlich mehr als mit rar und zip, dauert aber auch recht lang), was bei vielen Downloads vielleicht doch der Mühe wert ist

    Die Demo-Version von InstantCopy hat für SVCD eine 5min-Tonbeschränkung für das dekodieren von ac3 (Dolby Digital). Siehe Pinnacle-Produktseite bzw. Demoeinschränkungen.

    InstantCopy macht aber sehr schlechte SVCDs (etwa TMPG Low Quality/Fast Niveau) und ist dabei ziemlich langsam. Ist einfach nicht empfehlenswert.

    Zitat

    Bei SVCDs kenn ich mich nicht so genau aus. Ich glaube jedoch, dass der Buffer hier nur 917 kbit/s groß ist.


    Huch, wie kommt das. Ist ja praktisch "nur" die Hälfte.

    Die Größe des Videostream VBV-Buffers ist für die SVCD in der IEC 62107 mit 1.835.008 (Bits) / 8 (Bits/Byte) / 1024 (Bits/KBit) = 224 KByte definiert.

    Zitat

    Wenn man bedenkt, welcher Anteil der Bitrate einer GOP in die I-Frames geht, dann beträgt die Bitrate dieser Frames wohl mitunter ein Vielfaches der zulässigen max. Bitrate.


    Ein einzelnes I-Frame hat keine Bitrate, nur eine bestimmte Größe.

    OK, gebe ich mal einen Hinweis:
    Die Dekoding-Reihenfolge eines Mpeg-Streams ist anders als die Enkoding-Reihenfolge.
    Zum Beispiel muss für das erste P-Frame einer GOP das vorangegangene I-Frame im "Puffer" gehalten werden, zusätzlich die dazwischenliegenden B-Frames.
    Der VBV-Puffer muss also immer mindestens einige Bilder im Speicher behalten, die er dann "schlagartig" an den Dekoder weiterleitet.

    Nun ist der VBV nicht etwa 1835 kbps groß, sondern er ist 1835 kb gross bzw. 224 KB.

    Schauen wir uns mal das typische Bild einer GOP und seiner Größenverteilung an (enkodiert wurde mit 6000 kbps CBR):

    [Blockierte Grafik: http://members.fortunecity.de/teneriffa/_3gop.jpg]

    Der erste I-Frame hat ca. 53 KB
    Danach ein P-Frame mit rund 36 KB.
    Ein B-Frame benötigt ca. 23 KB
    Der Puffer ist so schonmal mit 135 KB belegt.
    Bei höheren Bitraten, etwa 9500 kbps CBR darf man nochmal mehr als 50% dazurechnen, also sind wir dann schon bei über 200 KB.

    Was sagt uns das über die Luft, die nach oben noch bleibt ;D

    Oooch Leute, ihr seid doch keine Anfänger mehr :nein:

    Zitat

    Bei DVDs ist der 1835 kbit/s (224*8.192) groß. Die Bitrate kann also eine sekunde lang 1835 kbit/s über dem eigentlichen Maximum liegen (die 1835 kbit/s können sich aber auch anders verteilen).


    Bei SVCD ist der VBV identisch gross. Wenn also die Aussage stimmen würde, dürfte kein Player kurze Peaks bis ca. 4500 kbps übelnehmen.
    Und wenn sie deutlich unter einer Sekunde liegen, sogar noch weit höher (vorausgesetzt danach entspricht die Bitrate wieder 2x-CD-Speed).

    Nun, das ist natürlich nicht so!

    Zitat

    maximale Bitratensumme aller Streams mit 9800 kbit/s anzunehmen, in den restlichen 280 kbit/s sollte der Overhead und einige Untertitel auf jeden Fall reinpassen

    Zitat

    Video und Audiostream - bzw. Streams bei mehreren Tonspuren und/oder Angles - 9,8 Mbit/s nicht überschreiten darf/dürfen, und die 10,08 dann noch plus Overhead und Untertitel(n) seien...


    Alles falsch.
    Schaut doch einfach in die Spezifikation
    http://www.mpeg.org/MPEG/DVD/General/Breakdown.html

    9,8 Mbps gilt für die Summe aller einzelner Videostreams, aller einzelner Audiostreams und aller einzelner Untertitelstreams zusammen.
    Dabei gibt es dann noch einige zusätzliche Einschränkungen, v.a. für die Video- und Audiostreams hinsichtlich der Bitrate.

    Man kann nur Dateien mit nahezu identische Größe fair qualitativ vergleichen (dann geht es aber auch je nach Methode encoderübergreifend).

    Das Problem ist, wie macht man einen qualitativen Vergleich. Die messtechnischen Verfahren, die dir am Ende einen Zahlenwert ausspucken, basieren auf simulierten visuellen Wahrnehmungsverfahren in Bezug gesetzt auf das Originalbild. Die c't macht das mittlerweile so (leider). Wäre natürlich eine bequeme Lösung, nur funktioniert sie nicht.

    Jeder hat eine andere visuelle Wahrnehmung, z.B. bevorzugt der eine lieber ein weicheres Bild und will niemals eine Verblockung sehen und der andere nimmt für ein knackscharfes Bild auch mal die ein oder andere Verblockung in Kauf. Was ist da nun qualitativ besser - und v.a. was machen die Messmethoden dann daraus; welcher Zahlenwert wird ausgespuckt?

    Theoretisch bedeutet CQ ja nicht "gleiche Qualität", sondern nur konstante Qualität. Denn sonst hätten sämtliche 6 Ergebnisdateien identische Bild-für-Bild-Qualität. Tatsächlich aber hat die größte Datei sogar tendenziell die schlechteste Qualität, weil die Enkodierung nicht genügend sorgfältig erfolgte.

    Im Umkehrschluß heisst das aber auch, dass die kleinste Datei (hier HQ) nicht automatisch die beste Qualität hat.
    Oftmals (vor allem bei TMPG) ist es so, dass HQ besser ist als HstQ, da bei HstQ Rauschen u.ä. als Bewegung erkannt wird und ungünstigerweise in Motionvektoren umgesetzt wird (die im Bild und selbstverständlich auch in den Nachfolgebildern entsprechend Platz "verschwenden").
    Bei TMPG kann man wohl behaupten, dass die Bewegungssuche bei HstQ zu empfindlich eingestellt ist.
    Das ist nur dann von Vorteil, wenn man nahezu rauschlose Videos hat, die besonders viel Bewegung beinhalten (z.B. mein DV-Testvideo einer Achterbahnfahrt).

    Zum Schluss sei noch angemerkt, dass der CQ-Tester das Ergebnis durchaus auch selbst verfälschen kann (je nachdem, welche Frames ausgewählt werden) und man ein echtes Ergebnis nur durch komplette Enkodierung des Filmes bekommen kann.

    Was soll uns der Test also sagen?
    Nimm zum enkodieren lieber HQ statt HstQ, denn es geht schneller und wird sogar noch besser (bzw. komprimiert besser)?

    Ist wohl einleuchtend, dass diese Aussage nicht stimmt.
    Sie ist schlicht einzelfallbezogen ...

    z.B. Ravisent Cinemaster 2000 vom April 2000
    Version: 1.0.00.0069 (dvdplay2.exe)
    oder aber der Sigma Designs Hardware Decoder
    (File - Preferences - Decoder)

    Gibt es das denn überhaupt noch zu kaufen?
    Ob es sich lohnt, musst du für dich selbst entscheiden. Vernünftig arbeiten kann man nur mit Realtime-Preview. Das braucht man, um im Film Kapitelmarken zu setzen (und zu sehen, wo man das macht), um die Auswirkungen von Untertiteleinstellungen direkt im Film ansehen zu können (z.B. Einblenden/Ausblenden); außerdem, ob Audio synchron ist usw.

    Du hast doch Maestro, dann müsstest du doch alles haben, was für ein ordnungsgemäßes Funktionieren des Programmes benötigt wird. Anders lieferte Spruce ja auch nicht aus ...

    Auf der Maestro-CD im Unterverzeichnis Manual\subtitle scripts befindet sich eine "Subtitle Animation Example.stl"-Datei (21,1 KB) in der sich ein exemplarischer Aufbau zeigt.

    Ansonsten findest du noch im Handbuch im Kapitel 12-70 "Adding Animation to .STL Subtitles Files" eine über mehrere Seiten gehende ausführliche Beschreibung. Genauer kann das hier auch keiner aufschreiben.
    Sogar Wipe-Commands sind möglich!

    0 für P ist ok aber für B sollte man unbedingt auf ca. -5 (meine Einstellung) oder wenigstens 0 gehen, weil Tmpeg generell den B-Frames zu wenig Bitrate spendiert und diese dann unnötigerweise sehr schlecht werden.

    Tmpeg DVD Author kann selber von 44,1 auf 48 kHz wandeln, das alleine macht den Stream also nicht "illegal".

    Der Fehler liegt eindeutig darin:

    Zitat

    [00:00:00:000] +-------- LAME -------
    [00:00:00:000] | Bitrate method : CBR
    [00:00:00:000] | MP3 bitrate : 128
    [00:00:00:000] | Channels Mode : Joint Stereo
    [00:00:00:000] | Error Protection: No
    [00:00:00:000] +---------------------

    Abgesehen davon, sollte man auf eine DVD keinen Stereoton mit 128 kbps bannen. Mindestens 192 kbps sollten schon sein.

    An deinen Bildern sieht man klar, dass tooLAME, was für mp2-Ton zuständig ist, nicht verwendet wird.

    Hallo Kawa72,

    Ulead MediaStudio arbeitet ausschließlich mit DV Typ1.

    Systemsteuerung --> Sounds und Multimedia --> Geräte --> Videokomprimierungs-Codecs, unter Eigenschaften kannst du den Codec wieder weghauen

    Das einfachste ist nachwievor den Panasonic-DV zu installieren.
    Huffyuv benötigt schließlich eine Menge Platz.

    Einfach diese inf-Datei per Rechtsklick speichern in das Verzeichnis, in dem bereits die Panasonic dll liegt.
    Anschließend per Rechtsklick auf die inf-Datei "Installieren" auswählen. Fertig.

    Schon kann man die DV.avis alle bequem laden (sowohl in Tmpeg, VirtualDub oder sonst einem Programm, das mit avi umgehen kann).

    Neue ausführliche Anleitungen wird es nicht geben !

    Eigentlich wollte ich eine neue Seite erstellen, die sich extrem ausführlich mit Encoder-Tests beschäftigt.
    Sowas gibt es nirgends im Netz (tecoltd.com ist sehr rudimentär und veraltet).

    Dazu hätte es dann Empfehlungen gegeben, was man bei Encoder X mit DV-Material (auch DVD, etc.) am sinnvollsten einstellt ...

    Vermutlich werde ich es aber jetzt doch nicht so machen - und alternativ irgendwann mal eine web.exe-Datei zum Download anbieten.
    Wann steht in den Sternen, obwohl ich es eigentlich noch dieses Jahr hinkriegen wollte ...

    Zusätzlich wollte ich eine State-Of-The-Art-Kurzanleitung (für Profis) herausgeben, wie man momentan einfach, kurz und knackig optimale Qualität erzielt (beim Rippen von DVD, bei DV, TV-Capture etc.)
    Das geht nämlich sehr sehr schnell und einfach (gebe die Methode aber derzeit nicht preis).

    Zitat

    Mensch mb1, Michael macht sich die Mühe schlecht hin, da sollte er doch erstmal hier auf der Site eine Anleitung suchen, oder ??


    Das ist schon richtig, davon gehe ich normalerweise auch aus, dass der User das so macht (und nicht nur im Forum postet), wenn er eine Anleitung sucht.

    Ich habe sie jedoch bisher noch nicht gelesen und deswegen (noch) nicht empfohlen.
    Ich bitte mir das nachzusehen. Auf DVD2SVCD-Anleitungen stürze ich mich wohl erst, wenn mir der Lesestoff ausgeht (was er nie tun wird :D ).

    Musste mich gerade erst wieder über das Nyquist-Theorem im Zusammenhang mit interlaced resizing einlesen :D