>>Erstens, dass sie so schnell reagiert und nicht einige zig bis hunderte frames mittelt und zweitens, dass sie überhaupt die bitrate regelt.
1. Wenn die Reaktion über 100 Frames gezogen wird, hast Du das schwanken über einen größen Zeitraum. Mit den Frames mitteln ist so ne Sache wenn die Vorgabe Xkbit/s lautet und das erste Frame DEUTLICH drüber liegt und das zweite DEUTLICH drunter würde im Mittel zwar tatsächlich Xkbit/s eingehalten. Aber es ändert nichts an der Tatsache, daß das erste Bild nicht der Vorgabe entspricht.
2. Auch bei vbr muß der encoder "wissen" in welchen Grenzen er sich aufhalten soll (Bsp. SVCD). Aber richtig, man kann dem Einschwingvorgang damit erheblich entgegenwirken. Es kommt also jetzt in erheblichem Maße auf das Speichermedium an (Extremfall für cbr ist Band).
>>Und selbst wenn man cbr oder wenigstens abr verwenden will ist das problem nicht der harte schnitt, sondern die komplexität der bilder, den was vor dem aktuellen frame oder danach kommt ist bedeutungslos (ausser indirekt für die bitratenregelung).
Ja, sehe ich ein. Ich kenne jdf. keine "Version" von MJPG bei dem Prädiktion angewandt wird. Apropos "Version" genau das ist ja das Problem mit MJPEG. Wenn Du z.B. an einem Fast Schnittplatz ein MJPEG File erstellst kannst Du den aus lauter inkompatibilität nicht an einem Anderen Schnittplatz verwenden. Deswegen hat man sich ja auch hingesetzt und eine neue EPG (Expert Group) gebildet. Die Motion Picture Expert Group (die Mitmischenden Firmen sind im Prinzip die Gleichen wie auch bei JPEG). Die Gruppe hatte sich zum Ziel gesetzt endlich einen gemeinsamen Nenner für die Speicherung datenreduzierter digitaler Signale zu entwerfen: MPEG.
Für die Transformation der Macroblöcke in den Frequenzbereich spielt die vorgegebene Datenrate übrigens keine Rolle. Einzig und allein die Quantisierung entscheidet über den Reduktionsgrad. Das ist die Schraube an der "gedreht" werden kann.
>>Ein mjpg encoder wird sicherlich darauf getrimmt, seine 25-30 voll- respektive 50-60 halbbilder pro sekunde auch tatsächlich kodiert zu bekommen, als auf optimale qualität.
Ich will mal schwer hoffen, daß er es auf die Reihe bekommt den vorgegebenen an Bildern/sek zu erzeugen. Das sollte er auch mit einem 386er - gib him genügend Zeit. Aber auch MPEG schafft alle gängigen Vertikalfrequenzen ebenfalls auf einer langsamen Kiste - mit genügend Zeit. Ich nehme mal stark an Dir geht es um Echtzeitcodierung. Da darf es natürlich auch nicht zu dropped Frames bei der Codierung kommen. Und wen wunderts: MPEG, daß gegenüber MJPEG auch eine Prädiktion/Differenzbildübertragung der Bilder zulässt (und damit einen höheren Datenreduktionsgrad)wird in der Regel höhere Rechneranforderungen für Echtzeitcodierung mit sich bringen. - In der Regel. Deswegen die Variante mit dem "nur I-Frames". Außerdem haben doch fast alle die richtigen "Kisten" zum echtzeit MPEGII codieren.
>>Das ist doch (vom genauen format/standard abgesehen) vbr-mjpg.
Bis auf das es überall (Weltweit) von allen Geräten, die sich MPEGII decoder schimpfen abgespielt werden kann. Ich sehe das als signifikanten Vorteil.
>>Da kann man auch keyframe-only-quality_based-divx nehmen, welcher besser ist, hängt wohl vom jeweiligen encoder ab .
Naja, die MPEG hat sich inzwischen noch öfters getroffen und MPEG4 entwickelt. Zusammengefasst: Der Grad der Datenreduktion ist gestiegen und es gibt nicht allzu viele MPEG4 Standalone Geräte. DIVX ist nur der gehackte MPEG4 von Microsoft. Die übrigens auch in der MPEG sitzen und weil die anderen nicht auf M$ hören wollten hat M$ einen eigenen MPEG4 encoder rausgebracht. Der Rest der Gruppe kloppt sich gerne um Lizenzen...zurück zum Thema DivX hat braucht auch mehr Resourcen als MPEG2 für eine Echtzeitcodierung. Also keine wirkliche Altanative, wenn Dir MPEGII zu Resourcen fressend ist.
Neugierig wie ich bin würde ich jetzt nur noch gerne Wissen welchen Hardware MPEG Encoder Du verwendest. Zum Probieren mit den MPEG encodern empfehle ich TMPGEnc.
Gruß
Minesweeper XL
Minesweeper XL
