Beiträge von Peter Pan

    Zitat von Selur

    (Nur mal so am Rand: Wozu brauchste so nen Filter eigentlich?)

    Für ein von uns entwickeltes DSP basiertes Mpeg4 Compressionsboard.

    Wir haben zwar einen Encoder/Decoder für Raw Mpeg4 lizensiert, aber für den Export wäre eine entsprechende mp4/avi-Hülle praktischer.

    Die könnte ich natürlich selber erstellen, aber ich dachte vielleicht gäbe es einen Filter, so daß ich mal schnell einige Sachen in Graphedit ausprobieren kann.

    Evtl. arbeiten andere Mpeg4 Dekoder schneller als der von uns lizensierte.

    Vielleicht sollten wir mal die Sendeanstalten zu einer Stellungnahme bewegen!

    Ich weiß zwar nicht welche (Hardware)-Encoder zum Einsatz kommen, aber wäre es nicht technisch machbar einen 'Quasi 2pass'-Durchlauf zu realisieren, indem der Stream zweimal encoded wird. Und zwar zeitlich versetzt, sagen wir mal um 30 Sekunden. Der vorlaufende Stream dient dann zur Bitraten Bedarfsregelung für die nächsten 30 Sekunden des nachlaufenden Streams.

    Der einzige Nachteil wäre ein zusätztliches Delay von 30 Sekunden. Aber bei Sendungen, die nicht live sind, ist es ja egal.

    Mich ärgert, das man sich bei DVB-T nicht für MPEG4 entschieden hat. Zumal ohnehin alle Hardware neu angeschaft werden mußte. :nein:

    Wir haben hier in Kiel seit 8 November ebenfalls DVB-T
    Die Bildqualität empfinde ich als sehr 'durchwachsen'.

    Hier nun ein krasses Beispiel aus der neuen Enterprise Serie
    (Folge 63, 'Carpenter Street')

    DVB-T vs. Kabel analog

    Schaut euch das obige Beispiel mal an, und schreibt eure Erfahrungen mit der
    Bildqualität von DVB-T.

    Zitat


    Selur:
    ehmm,.. man kann Overflow treatment nicht deaktivieren,... (ging noch nie)

    Im Tooltip von Overflow control strength (%) steht, das ein Wert von 0 dem XviD-Core die Kontrolle überlassen wird.
    Daher bin ich davon ausgegangen, daß die Werte für Max overflow improvement/degradation in diesem Falle ignoriert würden :hm:

    Ich werde heute Abend mal einen entsprechenden Test mit den Standardwerten machen.

    Erstmal vielen Dank für die Bemühung Selur

    Selur
    Sorry, habe die fehlenden Angaben in der Textdatei ergänzt.
    http://home.arcor.de/apostrophe/XvidParam.txt
    Intraframe tuning, Overflow treatment und curve compression waren deaktiviert.
    (Habe ich bislang immer so gemacht.)

    Das I-Frame Intervall habe ich mit absicht auf 100 frames gesetzt, damit FF und RW mit dem ZoomPlayer etwas flüssiger funktionieren.

    Ich hatte schon mal testweise alle MinQuantizier von 1 auf 2 geändert. Dann wird das File im 2nd pass allerdings zu klein. Das liegt wohl daran, das der mittlere Quantizierer irgendwo zwischen 1 und 2 liegt, um die gewünschte Dateigröße zu erziehlen.

    Was mir noch auffälllt es sind im 2. Durchgang nur noch Quantizier von 1 und 2 vorhanden. Früher waren bei in etwa gleichen Randbedingungen durchaus Quantizierer bis 10 vorhanden.

    nexustheoriginal
    Ich habe die Versionen XviD Versionen 1.00 und 1.02 getestet. Beide zeigen bei mir das gleiche Fehlverhalten.
    Ich verwende ein AviSynth-Script, daher ist es auf jeden Fall bei beiden Durchgängen das gleiche File.


    Ist es eigendlich normal, das der XviD-Codec unter VirtualDub zwei mal bei den vfw-Codecs auftaucht. Einmal mit dem FOURCC code yv12 und das anderemal mit dem FOURCC code xvid?

    Hallo,

    ich habe seit einiger Zeit ein Problem mit XviD. Es liefert im 2pass Verfahren viel zu große Ergebnisse.
    Ein wenig Erfahrung habe ich schon (ca. 500 Startrek Episoden mit unterschiedlichen Codecs habe ich schon gerendert.) Bislang meist ohne Probleme.
    Aber nun passiert etwas seltsames.
    Der erste pass liefert eine Datei die 545MByte groß ist.
    Der zweite pass liefert eine Datei die aber 1198MByte groß ist !!

    Wie kann der 2pass größer als der erste werden. Ich habe keinerlei Einstellungen zwischen den beiden Durchgängen verändert.
    Hier sind meine Einstellungen:
    http://home.arcor.de/apostrophe/XvidParam.txt

    Interessanter weise wird beim ersten Durchgang ein konstanter Quantizierer von q=2 verwendet, obwohl alle min Quantizer auf 1 stehen. Beim zweiten Durchgang werden dann ausschließlich q=1 und q=2 verwendet. Das kann doch aber nicht sein?

    Hat jemand hier im forum eine Idee woran das liegen kann?

    Hmmm,
    ich finde das Urteil absolut lächerlich, wem schadet der WMP?
    Keiner regt sich über mitgelieferte Software bei Linux oder Apple auf. Zu den gängigen Linux Distributionen gehören sogar ganze Office-Pakete.
    Soweit ich weiß gehört zu Mac OS X Quicktime, DVD-Player, iMovi und sicherlich einiges mehr.
    Warum sollte Microsoft nicht auch entsprechende Tools mit ausliefern dürfen?

    Ich bin der Meinung, man sollte Herstellern nicht vorschreiben, wie sie ihre Produkte gestalten sollen.

    Ich habe den Eindruck hier sollen leere Haushaltskassen gefüllt werden.

    Hmmm...

    Es erstaunt mich aber sehr, das das Abspeichern der Bewegungsvektoren keinen Geschwindigkeitszuwachs bringt.
    Die 'Motion Estimation' ist doch einer der zeitaufwendigeren Berechnungen bei der codierung.
    Sie könnte bei 2. pass dann komplett übersprungen werden.
    Einen Qualitätsverlust kann es eigentlich nur geben, wenn die Genauigkeit mit der die Vektoren gespeichert werden nicht ausreicht.