Eingaben, Datenströme und Ausgaben
[Das dieser Seite zugeordnete Feature Windows Media Format 11 SDK ist ein Legacyfeature. Es wurde von Source Reader und Sink Writer abgelöst. Source Reader und Sink Writer wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code nach Möglichkeit quellleser und Senkenschreiber anstelle des Windows Media Format 11 SDK verwendet. Microsoft schlägt vor, dass vorhandener Code, der die Legacy-APIs verwendet, so umgeschrieben wird, dass nach Möglichkeit die neuen APIs verwendet werden.]
Eine "Eingabe" in dieser Dokumentation ist jeder digitale Mediendatenstrom (z. B. Audio oder Video), den Ihre Anwendung mithilfe entsprechender APIs aus einer Quelle an das Writer-Objekt übermittelt. Eingaben müssen in einem unterstützten Format bereitgestellt werden. Als Eingabe werden mehrere RGB- und YUV-Standardformate unterstützt, und die Audiocodecs unterstützen PCM. Wenn ein angegebenes Eingabeformat vom Codec nicht nativ unterstützt wird, instanziiert das Writer-Objekt entweder ein Audio- oder Videohilfsobjekt, das eine Vielzahl von Formaten in Formate konvertieren kann, die der Codec akzeptieren kann. Bei Audioeingaben passt das Hilfsobjekt die Bittiefe, die Abtastrate und die Anzahl der Kanäle nach Bedarf an. Für Videoeingaben führt das Videohilfsobjekt Farbraumkonvertierungen und Rechteckgrößenanpassungen durch. In einigen Fällen können komprimierte Audio- und Videodaten in einem Eingabedatenstrom übergeben werden. Eine Eingabe kann von einem anderen Medientyp als Audio und Video sein, z. B. Text, Skriptbefehle, Standbilder oder beliebige Dateidaten.
Eine "Ausgabe" in dieser Dokumentation bezieht sich auf Daten, die das Readerobjekt zum Rendern an eine Anwendung übergibt. Eine Ausgabe entspricht einem einzelnen Stream zum Zeitpunkt der Wiedergabe. Wenn Sie den gegenseitigen Ausschluss verwenden, teilen sich alle sich gegenseitig ausschließenden Streams eine einzelne Ausgabe. In der Regel werden Ausgabedaten in Form von unkomprimierten Audio- oder Videodaten verwendet, obwohl sie beliebige Datentypen enthalten können. Unterstützte Videoausgabeformate sind an anderer Stelle in dieser Dokumentation aufgeführt.
Der Begriff "Stream" in dieser Dokumentation bezieht sich auf Daten in einer ASF-Datei, im Gegensatz zu (1) den Eingabequelldaten, bevor sie vom Writer-Objekt verarbeitet werden, und (2) die Ausgabedaten, nachdem sie vom Reader-Objekt dekomprimiert wurden. Ein ASF-Stream enthält Daten, die aus einer einzelnen Eingabe für das Writer-Objekt stammen, obwohl mehrere Datenströme aus derselben Eingabe erstellt werden können. Ein Stream weist von Anfang bis Ende die gleichen Format- und Komprimierungseinstellungen auf. Eine einfache ASF-Datei enthält zwei Streams, einen für Audio und einen für Video. Eine komplexere Datei kann zwei Audio- und mehrere Videostreams enthalten. Die Audiodatenströme haben möglicherweise die gleichen Komprimierungseinstellungen, enthalten jedoch unterschiedliche Inhalte, z. B. einen Kommentar in verschiedenen Sprachen. Die Videostreams enthalten möglicherweise den gleichen Inhalt, weisen jedoch unterschiedliche Komprimierungseinstellungen auf. Das Medienformat und die Komprimierungseinstellungen, die vom Writer-Objekt auf jeden Stream angewendet werden, werden im Profil angegeben.
Die Beziehung zwischen Eingaben, Datenströmen und Ausgaben kann von drei grundlegenden Typen sein. Die folgenden drei Diagramme veranschaulichen die Beziehungen.
In der grundlegendsten Beziehung, bei der es sich um ein Profil ohne gegenseitigen Ausschluss handelt, wird jede Eingabe vom Writer verarbeitet und als einzelner Stream in die ASF-Datei eingefügt. Bei der Wiedergabe liest der Reader den Stream und übermittelt unkomprimierte Beispiele als einzelne Ausgabe, wie im folgenden Diagramm dargestellt.
Eine komplexere Beziehung tritt auf, wenn der gegenseitige Ausschluss mehrerer Bitraten verwendet wird. In diesem Fall wird eine einzelne Eingabe vom Writer verarbeitet und mit mehreren Bitraten codiert. Jede Codierung der Daten wird in die ASF-Datei als separater Stream eingefügt. Bei der Wiedergabe bestimmt der Reader basierend auf der verfügbaren Bandbreite, welcher Stream dekomprimiert werden soll. Der Reader liest dann den ausgewählten Stream und übermittelt unkomprimierte Beispiele als einzelne Ausgabe, wie im folgenden Diagramm dargestellt.
Der dritte Beziehungstyp kann auftreten, wenn ein sprachbasierter oder benutzerdefinierter gegenseitiger Ausschluss verwendet wird. In dieser Beziehung werden mehrere Eingaben vom Reader verarbeitet, und jede wird als einzelner Stream in die ASF-Datei eingefügt. Bei der Wiedergabe wählt Ihre Anwendung basierend auf der von Ihnen bereitgestellten Logik manuell aus, welcher Stream dekomprimiert werden soll. Der Reader liest dann den ausgewählten Stream und übermittelt unkomprimierte Beispiele als einzelne Ausgabe. Dieser Prozess kann zum Einschließen von Soundtracks in mehreren Sprachen verwendet werden. Dieser Prozess wird anhand des folgenden Diagramms veranschaulicht.
Es gibt einige Unterschiede in den zuvor beschriebenen Beziehungen. Beispielsweise kann eine Datei alle drei Beziehungen oder eine oder zwei davon enthalten. Es ist auch möglich, dass einige Eingaben komprimiert werden, in diesem Fall führt der Writer keine zusätzliche Komprimierung durch. Der Reader kann auch komprimierte Beispiele liefern. Wenn dies der Fall ist, müssen Sie jedoch nach Datenstromnummer und nicht nach Ausgabenummer darauf zugreifen.
Hinweis
Ein-, Dampf- und Ausgaben werden von den Objekten des Windows Media Format SDK alle Nummern zugewiesen. Streams weisen eine Streamnummer auf, die 1-basiert, die Sie im Profil definieren. Jedem Stream wird auch ein Datenstromindex zur Verwendung beim Aufzählen von Streams in einem Profil zugewiesen. Keine dieser Zahlen ist garantiert konsistent. Das heißt, die Eingabenummer 1 entspricht möglicherweise nicht der Datenstromnummer 1, Die Datenstromnummer 1 entspricht möglicherweise nicht dem Datenstromindex 1 usw.
Zugehörige Themen