-
QUERVERWEIS ZU VERWANDTEN ANMELDUNGEN
-
Die vorliegende Anmeldung beansprucht Priorität zu der vorläufigen US Patentanmeldung Nr. 61/836,865, eingereicht am 19. Juni 2013 mit dem Titel „Audio Encoder and Decoder with Program Information or Substream Structure Metadata” von Jeffrey Riedmiller und Michael Ward.
-
TECHNISCHES GEBIET
-
Die vorliegende Anmeldung betrifft Audiosignalverarbeitungseinheiten und insbesondere Decodierer von Audiodaten-Bitströmen mit Metadaten, die für eine Programminformation hinsichtlich Audioinhalt indikativ sind, der durch die Bitströme angegeben wird. Einige Ausführungsbeispiele der Erfindung erzeugen oder decodieren Audiodaten in einem der Formate, die als Dolby Digital (AC-3), Dolby Digital Plus (Enhanced AC-3 oder E-AC-3), oder Dolby E bekannt sind.
-
HINTERGRUND
-
Dolby, Dolby Digital, Dolby Digital Plus und Dolby E sind Warenzeichen der Dolby Laboratories Licensing Corporation. Dolby Laboratories bietet proprietäre Implementierungen von AC-3 und E-AC-3, bekannt als Dolby Digital beziehungsweise Dolby Digital Plus.
-
Audiodatenverarbeitungseinheiten arbeiten typischerweise in einer blinden Art und Weise und achten nicht auf die Verarbeitungshistorie von Audiodaten, die stattfindet, bevor die Daten empfangen werden. Dies kann in einem Verarbeitungssystem funktionieren, in dem eine einzelne Entität die gesamte Audiodatenverarbeitung und -codierung für eine Vielzahl von Ziel-Mediawiedergabevorrichtungen durchführt, während eine Ziel-Mediawiedergabevorrichtung die gesamte Decodierung und Wiedergabe der codierten Audiodaten durchführt. Allerdings funktioniert diese blinde Verarbeitung nicht gut (oder überhaupt nicht) in Situationen, in denen eine Vielzahl von Audioverarbeitungseinheiten über ein diverses Netzwerk verteilt sind oder in einem Tandem (d. h. eine Kette) platziert sind und von denen erwartet wird, ihre jeweiligen Typen von Audioverarbeitung optimal durchzuführen. Zum Beispiel können einige Audiodaten für Hochleistungs-Mediasysteme codiert sein und müssen eventuell in eine reduzierte Form, die für eine mobile Vorrichtung geeignet ist, entlang einer Medienverarbeitungskette umgewandelt werden. Demgemäß kann eine Audioverarbeitungseinheit unnötigerweise einen Typ einer Verarbeitung auf den Audiodaten durchführen, der bereits durchgeführt wurde. Zum Beispiel kann eine Lautstärkeabgleichungseinheit eine Verarbeitung auf einem Eingangs-Audio-Clip durchführen, unabhängig davon, ob die gleiche oder eine ähnliche Lautstärkeabgleichung früher auf dem Eingangs-Audio-Clips bereits durchgeführt wurde oder nicht. Als ein Ergebnis kann die Lautstärkeabgleichungseinheit eine Abgleichung durchführen, auch wenn dies nicht notwendig ist. Diese unnötige Verarbeitung kann auch eine Verschlechterung und/oder das Entfernen von spezifischen Merkmalen verursachen, während der Inhalt der Audiodaten wiedergegeben wird.
-
Kurze Beschreibung
-
Eine elektrische Vorrichtung wird offenbart, die eine Schnittstelle zum Empfangen eines Rahmens von codiertem Audio umfasst, wobei der Rahmen Programminformations-Metadaten umfasst, die sich in einem Auslassen- bzw. Überspringen(Skip)-Feld des Rahmens befinden, und codierte Audiodaten, die sich außerhalb des Auslassen-Felds befinden. Ein Puffer ist mit der Schnittstelle gekoppelt zum temporären Speichern des Rahmens und ein Parser bzw. Analysierer ist mit dem Puffer gekoppelt zum Extrahieren der codierten Audiodaten aus dem Rahmen. Ein AC-3-Audio-Decodierer ist mit dem Parser gekoppelt oder mit diesem integriert zum Erzeugen von decodiertem Audio aus den codierten Audiodaten.
-
Kurze Beschreibung der Zeichnungen
-
1 ist ein Blockdiagramm eines Ausführungsbeispiels eines Systems.
-
2 ist ein Blockdiagramm eines Codierers, der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist.
-
3 ist ein Blockdiagramm eines Decodierers, der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist, und eines damit gekoppelten Postprozessors, der ein anderes Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist.
-
4 ist ein Diagramm eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
-
5 ist ein Diagramm des Synchronisationsinformation(SI – Synchronization Information)-Segments eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
-
6 ist ein Diagramm eines Bitstrom-Information(BSI – Bitstream Information)-Segments eines AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
-
7 ist ein Diagramm eines E-AC-3-Rahmens, einschließlich der Segmente, in die er unterteilt ist.
-
8 ist ein Diagramm eines Metadaten-Segments eines codierten Bitstroms, der in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung erzeugt wird, einschließlich eines Metadaten-Segment-Headers, der ein Container-Sync-Wort (als „Container-Sync” in 8 identifiziert) und Versions- und Schlüssel-ID-Werte aufweist, gefolgt von mehreren Metadaten-Nutzlasten und Schutzbits.
-
Bezeichnung und Nomenklatur
-
In dieser Offenbarung, einschließlich der Ansprüche, bezieht sich der Ausdruck „Metadaten” (eines codierten Audio-Bitstroms) auf getrennte und verschiedene Daten von entsprechenden Audiodaten des Bitstroms.
-
In dieser Offenbarung, einschließlich der Ansprüche, bezeichnet der Ausdruck „Programminformations-Metadaten” (oder „PIM (program information metadata)”) Metadaten eines codierten Audiobitstroms, die für zumindest ein Audioprogramm indikativ sind, wobei die Metadaten für zumindest eine Eigenschaft oder Charakteristik von Audioinhalt von zumindest einem Programm Indikativ sind (zum Beispiel Metadaten, die einen Typ oder Parameter einer Verarbeitung angeben, die auf Audiodaten des Programms durchgeführt wird, oder Metadaten, die angeben, welche Kanäle des Programms aktive Kanäle sind).
-
In dieser Offenbarung, einschließlich der Ansprüche, bezeichnet der Ausdruck „Audioprogramm” einen Satz von einem oder mehreren Audiokanälen und optional auch assoziierte Metadaten (zum Beispiel Metadaten, die eine gewünschte räumliche Audiopräsentation beschreiben, und/oder PIM).
-
In dieser Offenbarung, einschließlich der Ansprüche, wird der Ausdruck „koppeln” oder „gekoppelt” verwendet, um entweder eine direkte oder eine indirekte Verbindung zu bezeichnen. Wenn somit eine erste Vorrichtung mit einer zweiten Vorrichtung gekoppelt wird, kann diese Verbindung über eine direkte Verbindung oder über eine indirekte Verbindung über andere Vorrichtungen und Verbindungen sein.
-
Detaillierte Beschreibung von Ausführungsbeispielen der Erfindung
-
Ein typischer Strom von Audiodaten umfasst sowohl Audioinhalt (zum Beispiel einen oder mehrere Kanäle von Audioinhalt) und Metadaten, die zumindest eine Charakteristik des Audioinhalts angeben. Zum Beispiel gibt es in einem AC-3-Bitstrom mehrere Audio-Metadaten-Parameter, die insbesondere vorgesehen sind zur Verwendung bei einem Ändern des Klangs des Programms, das an eine Hörumgebung geliefert wird. Einer der Metadaten-Parameter ist der DIALNORM-Parameter, der vorgesehen ist, um den mittleren Pegel eines Dialogs in einem Audioprogramm anzugeben, und verwendet wird, um einen Audio-Abspielsignalpegel zu bestimmen.
-
Obwohl die vorliegende Erfindung nicht auf eine Verwendung mit einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom beschränkt ist, wird sie zur Einfachheit in Ausführungsbeispielen beschrieben, in denen sie einen derartigen Bitstrom erzeugt, decodiert oder anderweitig verarbeitet.
-
Ein codierter AC-3-Bitstrom weist Metadaten auf und einen bis sechs Kanäle von Audioinhalt. Bei dem Audioinhalt handelt es sich um Audiodaten, die unter Verwendung einer Wahrnehmungsaudiocodierung komprimiert wurden. Die Metadaten umfassen mehrere Audio-Metadaten-Parameter, die zur Verwendung bei einem Verändern des Klangs eines Programms vorgesehen sind, das an eine Hörumgebung geliefert wird.
-
Jeder Rahmen eines AC-3-codierten Audiobitstroms enthält Audioinhalt und Metadaten für 1536 Abtastwerte von digitalem Audio. Für eine Abtastrate von 48 kHz entspricht dies 32 Millisekunden von digitalem Audio oder einer Rate von 31,25 Rahmen pro Sekunde Audio.
-
Jeder Rahmen eines E-AC-3-codierten Audiobitstroms enthält Audioinhalt und Metadaten für 256, 512, 768 oder 1536 Abtastwerte von digitalem Audio, abhängig davon, ob der Rahmen einen, zwei, drei beziehungsweise sechs Blöcke von Audiodaten enthält. Für eine Abtastrate von 48 kHz entspricht dies 5,333, 10,667, 16 oder 32 Millisekunden von digitalem Audio oder einer Rate von 189,9, 93,75, 62,5 beziehungsweise 31,25 Rahmen pro Sekunde von Audio.
-
Wie in 4 gezeigt, ist jeder AC-3-Rahmen in Abschnitte (Segmente) unterteilt, einschließlich: ein Abschnitt Synchronisationsinformation (SI – Synchronization Information), der (wie in 5 gezeigt) ein Synchronisationswort (SW – Synchronization Word) und das erste von zwei Fehlerkorrekturwörtern (CRC1) enthält; einen Abschnitt Bitstrom-Information (BSI – Bitstream Information), der die meisten der Metadaten enthält; sechs Audio-Blöcke (AB0 bis AB5), die Daten-komprimierten Audioinhalt enthalten (und auch Metadaten umfassen können); Ausschuss-Bit-Segmente (W – Waste) (auch als „Auslassen- bzw. skip-Felder” bekannt), die alle nicht-verwendeten Bits enthalten, die übrig bleiben, nachdem der Audioinhalt komprimiert ist; einen Abschnitt Hilfs(AUX – Auxiliary)-Information, der mehr Metadaten enthalten kann; und das zweite von zwei Fehlerkorrekturwörtern (CRC2).
-
Wie in 7 gezeigt, ist jeder E-AC-3-Rahmen in Abschnitte (Segmente) unterteilt, einschließlich: ein Abschnitt Synchronisationsinformation (SI – Synchronization Information), der (wie in 5 gezeigt) ein Synchronisationswort (SW – Synchronization Word) enthält; einen Abschnitt Bitstrom-Information (BSI – Bitstream Information), der die meisten der Metadaten enthält; zwischen einem und sechs Audio-Blöcken (AB0 bis AB5), die Daten-komprimierten Audioinhalt enthalten (und auch Metadaten umfassen können); Ausschuss-Bit-Segmente (W – Waste) (auch als „Auslassen-Felder” bekannt), die alle nicht-verwendeten Bits enthalten, die übrig bleiben, nachdem der Audioinhalt komprimiert ist (obwohl nur ein Ausschuss-Bit-Segment gezeigt wird, folgt typischerweise ein anderes Ausschuss-Bit- oder Auslassen-Feld-Segment jedem Audioblock); einen Abschnitt Hilfs(AUX – Auxiliary)-Information, der mehr Metadaten enthalten kann; und ein Fehlerkorrekturwort (CRC).
-
In einem AC-3(oder E-AC-3)-Bitstrom gibt es mehrere Audio-Metadaten-Parameter, die spezifisch zur Verwendung bei einem Ändern des Klangs des Programms vorgesehen sind, das an eine Hörumgebung geliefert wird. Einer der Metadaten-Parameter ist der DIALNORM-Parameter, der in dem BSI-Segment enthalten ist.
-
Wie in 6 gezeigt, umfasst das BSI-Segment eines AC-3-Rahmens einen Fünf-Bit-Parameter („DIALNORM”), der den DIALNORM-Wert für das Programm angibt. Ein Fünf-Bit-Parameter („DIALNORM2”), der den DIALNORM-Wert für ein zweites Audioprogramm angibt, das in demselben AC-3-Rahmen getragen wird, ist enthalten, wenn der Audiocodiermodus („acmod”) des AC-3-Rahmens „0” ist, was anzeigt, dass eine Dual-Mono- oder „1 + 1”-Kanal-Konfiguration verwendet wird.
-
Das BSI-Segment umfasst auch ein Flag („addbsie”), das das Vorhandensein (oder Fehlen) von zusätzlicher Bitstrom-Information nach dem „addbsie”-Bit angibt, einen Parameter („addbsil”), der die Länge einer zusätzlichen Bitstrom-Information nach dem „addbsil”-Wert angibt, und bis zu 64 Bits von zusätzlicher Bitstrom-Information („addbsi”) nach dem „addbsil”-Wert.
-
Das BSI-Segment umfasst andere Metadaten-Werte, die nicht ausdrücklich in 6 gezeigt werden.
-
Gemäß typischen Ausführungsbeispielen der Erfindung sind PIM (und optional auch andere Metadaten) in einem oder mehreren reservierten Feldern (oder Schlitzen) von Metadaten-Segmenten eines Audiobitstroms eingebettet (zum Beispiel dem Auslassen-Feld), der auch Audiodaten in anderen Segmenten (Audiodaten-Segmente) umfasst. Typischerweise umfasst zumindest ein Segment jedes Rahmens des Bitstroms (zum Beispiel das Auslassen-Feld) PIM und zumindest ein anderes Segment des Rahmens umfasst entsprechende Audiodaten (d. h. Audiodaten mit zumindest einer Charakteristik oder Eigenschaft, die von den PIM angegeben wird).
-
In einer Klasse von Ausführungsbeispielen ist jedes Metadaten-Segment eine Datenstruktur (manchmal hier als ein Container bezeichnet), die eine oder mehrere Metadaten-Nutzlast(en) enthalten kann. Jede Nutzlast umfasst einen Header mit einem spezifischen Nutzlast-Identifizierer (und Nutzlast-Konfigurationsdaten), um eine eindeutige Angabe des Typs von Metadaten zu liefern, die in der Nutzlast vorhanden sind. Die Reihenfolge von Nutzlasten in dem Container ist nicht definiert, so dass Nutzlasten in jeder Reihenfolge gespeichert werden können, und ein Parser bzw. Analysierer muss in der Lage sein, den gesamten Container zu analysieren, um relevante Nutzlasten zu extrahieren und Nutzlasten zu ignorieren, die entweder nicht relevant sind oder nicht unterstützt werden. 8 (die unten beschrieben wird) zeigt die Struktur eines derartigen Containers und von Nutzlasten in dem Container.
-
Ein Kommunizieren von Metadaten (zum Beispiel PIM) in einer Audiodatenverarbeitungskette ist besonders nützlich, wenn zwei oder mehr Audioverarbeitungseinheiten in der Verarbeitungskette (oder einen Inhalt-Lebenszyklus) miteinander im Tandem arbeiten müssen. Ohne Aufnahme von Metadaten in einen Audiobitstrom können schwerwiegende Mediaverarbeitungsprobleme auftreten, wie Qualitäts-, Pegel- und räumliche Verschlechterungen beispielsweise, wenn zwei oder mehr Audio-Codecs in der Kette verwendet werden und eine single-ended-Lautstärkeanpassung während eines Bitstrom-Pfads zu einer Media-verbrauchenden Vorrichtung (oder einem Wiedergabepunkt des Audioinhalts des Bitstroms) mehr als einmal angewendet wird.
-
1 ist ein Blockdiagramm einer beispielhaften Audioverarbeitungskette (ein Audiodatenverarbeitungssystem), bei der eines oder mehrere der Elemente des Systems in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung konfiguriert werden kann/können. Das System umfasst die folgenden Elemente, miteinander gekoppelt, wie gezeigt: eine Vorverarbeitungseinheit, einen Codierer, eine Signalanalyse- und Metadaten-Korrektureinheit, einen Transcodierer, einen Decodierer und eine Vorverarbeitungseinheit. In Variationen des gezeigten Systems sind ein oder mehrere der Elemente weggelassen oder zusätzlichen Audiodatenverarbeitungseinheiten sind enthalten.
-
In einigen Implementierungen ist die Vorverarbeitungseinheit von 1 konfiguriert, PCM(Zeitdomäne)-Abtastwerte, die Audioinhalt aufweisen, als Eingabe anzunehmen und verarbeitete PCM-Abtastwerte auszugeben. Der Codierer kann konfiguriert sein, die PCM-Abtastwerte als Eingabe anzunehmen und einen codierten (zum Beispiel komprimierten) Audiobitstrom auszugeben, der indikativ ist für den Audioinhalt. Die Daten des Bitstroms, die indikativ sind für den Audioinhalt, werden hier manchmal als „Audiodaten” bezeichnet. Wenn der Codierer gemäß einem typischen Ausführungsbeispiel der vorliegenden Erfindung konfiguriert ist, umfasst der Audiobitstrom, der von dem Codierer ausgegeben wird, PIM sowie Audiodaten.
-
Die Signalanalyse- und Metadaten-Korrektureinheit von 1 kann einen oder mehrere codierte Audio-Bitströme als Eingabe annehmen und bestimmen (zum Beispiel validieren), ob Metadaten in jedem codierten Audiobitstrom korrekt sind, durch Durchführen einer Signalanalyse. Wenn die Signalanalyse- und Metadaten-Korrektureinheit feststellt, dass enthalte Metadaten ungültig sind, ersetzt sie typischerweise den/die falschen Wert(e) mit dem/den richtigen Wert(en), der/die von der Signalanalyse erlangt wird/werden. Somit kann jeder codierte Audiobitstrom, der von der Signalanalyse- und Metadaten-Korrektureinheit ausgegeben wird, korrigierte (oder nicht-korrigierte) Verarbeitungszustands-Metadaten sowie codierte Audiodaten umfassen.
-
Der Decodierer von 1 kann codierte (zum Beispiel komprimierte) Audio-Bitströme als Eingabe annehmen und (in Reaktion) Ströme von decodierten PCM-Audio-Abtastwerten ausgeben. Wenn der Decodierer gemäß einem typischen Ausführungsbeispiel der vorliegenden Erfindung konfiguriert ist, ist die Ausgabe des Decodierers in einem typischen Betrieb eines der folgenden oder umfasst eines der folgenden:
ein Strom von Audio-Abtastwerten und zumindest ein entsprechender Strom von PIM (und typischerweise auch andere Metadaten), die aus einem eingegebenen codierten Bitstrom extrahiert sind; oder
ein Strom von Audio-Abtastwerten und ein entsprechender Strom von Steuerungsbits, die aus PIM (und typischerweise auch anderen Metadaten) bestimmt werden, die aus einem eingegebenen codierten Bitstrom extrahiert sind; oder
ein Strom von Audio-Abtastwerten, ohne einen entsprechenden Strom von Metadaten oder Steuerungsbits, die aus Metadaten bestimmt werden. In diesem letzten Fall kann der Decodierer Metadaten aus dem eingegebenen codierten Bitstrom extrahieren und zumindest eine Operation auf den extrahierten Metadaten durchführen (zum Beispiel eine Validierung), obwohl er die daraus bestimmten extrahierten Metadaten oder Steuerungsbits nicht ausgibt.
-
Durch Konfigurieren der Nachverarbeitungseinheit von 1 in Übereinstimmung mit einem typischen Ausführungsbeispiel der vorliegenden Erfindung ist die Nachverarbeitungseinheit konfiguriert, einen Strom von decodierten PCM-Audioabtastwerten anzunehmen und darauf eine Nachverarbeitung durchzuführen (zum Beispiel eine Lautstärkeabgleichung des Audioinhalts) unter Verwendung von PIM (und typischerweise auch anderen Metadaten), die mit den Abtastwerten empfangen werden, oder Steuerungsbits, bestimmt durch den Decodierer aus Metadaten, die mit den Abtastwerten empfangen werden. Die Nachverarbeitungseinheit ist typischerweise auch konfiguriert, den nachverarbeiteten Audioinhalt zum Abspielen durch einen oder mehrere Lautsprecher wiederzugeben.
-
Typische Ausführungsbeispiele der vorliegenden Erfindung sehen eine verbesserte Audioverarbeitungskette vor, in der Audioverarbeitungseinheiten (zum Beispiel Codierer, Decodierer, Transcodierer, und Vor- und Nachverarbeitungseinheiten) ihre jeweilige Verarbeitung anpassen, die auf Audiodaten anzuwenden ist, gemäß einem zeitgleichen Zustand der Media-Daten, wie durch Metadaten angegeben wird, die jeweils durch die Audioverarbeitungseinheiten empfangen werden.
-
Die Audiodaten-Eingabe an eine Audioverarbeitungseinheit des Systems von 1 (zum Beispiel der Codierer oder Transcodierer von 1) kann PIM (und optional auch andere Metadaten) sowie Audiodaten (zum Beispiel codierte Audiodaten) umfassen. Diese Metadaten können in dem Eingangs-Audio durch ein anderes Element des Systems von 1 (oder einer anderen Quelle, die in 1 nicht gezeigt wird) in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung aufgenommen worden sein. Die Verarbeitungseinheit, die das Eingangs-Audio (mit Metadaten) empfängt, kann konfiguriert sein, zumindest eine Operation auf den Metadaten (zum Beispiel Validierung) oder in Reaktion auf die Metadaten (zum Beispiel adaptive Verarbeitung des Eingangs-Audios) durchzuführen, und typischerweise die Metadaten, eine verarbeitete Version der Metadaten oder Steuerungsbits, die aus den Metadaten bestimmt werden, auch in ihrem Ausgangs-Audio aufzunehmen.
-
2 ist ein Blockdiagramm eines Codierers (100), der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist. Eine/Jede der Komponenten oder Elemente des Codierers 100 kann/können als ein oder mehrere Prozess(e) und/oder eine oder mehrere Schaltung(en) (zum Beispiel ASICs, FPGAs oder andere integrierte Schaltungen), in Hardware, Software oder eine Kombination aus Hardware und Software implementiert werden. Der Codierer 100 weist einen Rahmenpuffer 110, einen Parser 111, einen Decodierer 101, einen Audiozustandsvalidierer 102, eine Lautheits-Verarbeitungsstufe 103, eine Audiostrom-Auswahlstufe 104, einen Codierer 105, eine Füller/Formatierer-Stufe 107, eine Metadaten-Erzeugungsstufe 106, ein Dialog-Lautheitsmessungs-Teilsystem 108 und einen Rahmenpuffer 109 auf, verbunden wie gezeigt. Auch umfasst der Codierer 100 typischerweise andere Verarbeitungselemente (nicht gezeigt).
-
Der Codierer 100 (der ein Transcodierer ist) ist konfiguriert, einen Eingangs-Audiobitstrom (der zum Beispiel einer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein kann) in einen codierten Ausgangs-Audiobitstrom (der zum Beispiel ein anderer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein kann) umzuwandeln, einschließlich durch Durchführen einer adaptiven und automatischen Lautheits-Verarbeitung unter Verwendung von Lautheits-Verarbeitungszustands-Metadaten, die in dem Eingangsbitstrom enthalten sind. Zum Beispiel kann der Codierer 100 konfiguriert sein, einen Eingangs-Dolby-E-Bitstrom (ein Format, das typischerweise in Produktions- und Broadcast-Einrichtungen verwendet wird, aber nicht in Verbrauchergeräten, die Audioprogramme empfangen, die an diese ausgestrahlt wurden) in einen codierten Ausgangs-Audiobitstrom (geeignet zum Aussenden an Verbrauchergeräte) in einem AC-3- oder E-AC-3-Format umzuwandeln.
-
Das System von 2 umfasst auch ein codiertes Audio-Liefer-Teilsystem 150 (das die codierten Bitströme speichert und/oder liefert, die von dem Codierer 100 ausgegeben werden) und einen Decodierer 152. Ein codierter Audiobitstrom, der von dem Codierer 100 ausgegeben wird, kann durch das Teilsystem 150 gespeichert werden (zum Beispiel in der Form einer DVD oder Blu Ray Disc) oder durch das Teilsystem 150 übertragen werden (das eine Übertragungsverbindung oder -Netzwerk implementieren kann), oder kann durch das Teilsystem 150 sowohl gespeichert als auch übertragen werden. Der Decodierer 152 ist konfiguriert, einen codierten Audiobitstrom (der durch den Codierer 100 erzeugt wird) zu decodieren, den er über das Teilsystem 150 empfängt, einschließlich durch Extrahieren von Metadaten (PIM und optional auch Lautheits-Verarbeitungszustands-Metadaten und/oder andere Metadaten) aus jedem Rahmen des Bitstroms und Erzeugen decodierter Audiodaten. Typischerweise ist der Decodierer 152 konfiguriert, eine adaptive Verarbeitung auf den decodierten Audiodaten unter Verwendung von PIM durchzuführen, und/oder die decodierten Audiodaten und Metadaten an einen Postprozessor weiterzuleiten, der konfiguriert ist, eine adaptive Verarbeitung auf den decodierten Audiodaten unter Verwendung der Metadaten durchzuführen. Typischerweise umfasst der Decodierer 152 einen Puffer, der den codierten Audiobitstrom speichert (zum Beispiel auf eine nicht-transitorische Weise), der von dem Teilsystem 150 empfangen wird.
-
Verschiedene Implementierungen des Codierers 100 und des Decodierers 152 sind konfiguriert, um verschiedene Ausführungsbeispiele des erfindungsgemäßen Vorgehens durchzuführen.
-
Ein Rahmenpuffer 110 ist ein Pufferspeicher, der gekoppelt ist, um einen codierten Eingangs-Audiobitstrom zu empfangen. In Betrieb speichert der Puffer 110 (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des codierten Audiobitstroms, und eine Sequenz der Rahmen des codierten Audiobitstroms wird von dem Puffer 110 dem Parser 111 zugeführt.
-
Der Parser 111 ist gekoppelt und konfiguriert, PIM aus jedem Rahmen des codierten Eingangsaudios zu extrahieren, in dem solche Metadaten enthalten sind, um Audiodaten aus dem codierten Eingangsaudio zu extrahieren, und um die Audiodaten dem Decodierer 101 zuzuführen. Der Decodierer 101 des Codierers 100 ist konfiguriert, die Audiodaten zu decodieren, um decodierte Audiodaten zu erzeugen, und um die decodierten Audiodaten der Lautheits-Verarbeitungsstufe 103, der Audiostrom-Auswahlstufe 104, dem Teilsystem 108 und typischerweise auch dem Zustandsvalidierer 102 zuzuführen.
-
Der Zustandsvalidierer 102 ist konfiguriert, die ihm zugeführten Metadaten zu authentifizieren und zu validieren. In einigen Ausführungsbeispielen sind die Metadaten ein Datenblock (oder sind darin enthalten), der in dem Eingangsbitstrom aufgenommen wurde (zum Beispiel in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung). Der Block kann einen kryptographischen Hash (einen Hash-basierten Nachrichtenauthentifizierungscode (HMAC – Hash-Based Message Authentication Code)) zum Verarbeiten der Metadaten und/oder der zugrundeliegenden Audiodaten (vorgesehen von dem Decodierer 101 an den Validierer 102) aufweisen. Der Datenblock kann in diesen Ausführungsbeispielen digital signiert sein, so dass eine stromabwärtige Audioverarbeitungseinheit relativ einfach die Verarbeitungszustands-Metadaten authentifizieren und validieren kann.
-
Der Zustandsvalidierer 102 führt Steuerungsdaten an die Audiostrom-Auswahlstufe 104, den Metadaten-Generator 106 und das Dialoglautheitsmessungs-Teilsystem 108 zu, um die Ergebnisse der Validierungsoperation anzuzeigen. In Reaktion auf die Steuerungsdaten kann die Stufe 104 entweder die adaptiv verarbeitete Ausgabe der Lautheits-Verarbeitungsstufe 103 oder die Audiodaten, die von dem Decodierer 101 ausgegeben werden, auswählen (und weiter an den Codierer 105 leiten).
-
Die Stufe 103 des Codierers 100 ist konfiguriert, eine adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten durchzuführen, die von dem Decodierer 101 ausgegeben werden, basierend auf einer oder mehreren Audiodaten-Charakteristik(en), die durch die Metadaten angegeben werden, extrahiert durch den Decodierer 101. Die Stufe 103 kann ein adaptiver Transformations-Domäne-Echtzeit-Lautheits- und Dynamikregelungs-Prozessor sein. Die Stufe 103 kann eine Benutzereingabe (zum Beispiel Benutzer-Ziel-Lautheit/Dynamikregelungswerte oder „dialnorm”-Werte) oder eine andere Metadaten-Eingabe (zum Beispiel ein oder mehrere Typ(en) von Daten Dritter, Verfolgungsinformation, Identifizierern, proprietäre oder Standard-Information, Benutzeranmerkungsdaten, Benutzerpräferenzdaten etc.) und/oder eine andere Eingabe (zum Beispiel von einem Fingerabdruck-Verfahren) empfangen und eine derartige Eingabe verwenden, um die decodierten Audiodaten zu verarbeiten, die von dem Decodierer 101 ausgegeben werden. Die Stufe 103 kann eine adaptive Lautheits-Verarbeitung auf decodierten Audiodaten (von dem Decodierer 101 ausgegeben) durchführen, die für ein einzelnes Audioprogramm indikativ sind, und kann die Lautheits-Verarbeitung zurücksetzen in Reaktion auf ein Empfangen von decodierten Audiodaten (von dem Decodierer 101 ausgegeben), die für ein anderes Audioprogramm indikativ sind.
-
Das Dialoglautheitsmessungs-Teilsystem 108 kann arbeiten, um eine Lautheit von Segmenten des decodierten Audios (von dem Decodierer 101) zu bestimmen, die für einen Dialog (oder andere Sprache) indikativ sind, zum Beispiel unter Verwendung von Metadaten, die durch den Decodierer 101 extrahiert werden, wenn die Steuerungsbits von dem Validierer 102 anzeigen, dass die Metadaten ungültig sind. Ein Betrieb des Dialoglautheitsmessung-Teilsystems 108 kann deaktiviert werden, wenn die Metadaten eine zuvor bestimmte Lautheit von Dialog(oder andere Sprach)-Segmenten des decodierten Audios (von dem Decodierer 101) anzeigen, wenn die Steuerungsbits von dem Validierer 102 anzeigen, dass die Metadaten gültig sind. Das Teilsystem 108 kann eine Lautheitsmessung auf decodierten Audiodaten durchführen, die für ein einzelnes Audioprogramm indikativ sind, und kann die Messung in Reaktion auf ein Empfangen von decodierten Audiodaten zurücksetzen, die für ein anderes Audioprogramm indikativ sind.
-
Nützliche Werkzeuge (zum Beispiel der „Dolby LM100”-Lautheitsmesser) zum bequemen und einfachen Messen des Pegels eines Dialogs in einem Audioinhalt sind vorhanden. Einige Ausführungsbeispiele der erfindungsgemäßen APU (zum Beispiel die Stufe 108 des Codierers 100) sind implementiert, um ein derartiges Werkzeug zu umfassen (oder dessen Funktionen durchzuführen), um die mittlere Dialoglautheit von Audioinhalt eines Audiobitstroms (zum Beispiel eines decodierten AC-3-Bitstroms, der an die Stufe 108 von dem Decodierer 101 des Codierers 100 zugeführt wird) zu messen.
-
Wenn die Stufe 108 implementiert wird, um die wahre mittlere Dialoglautheit von Audiodaten zu messen, kann die Messung einen Schritt eines Isolierens von Segmenten des Audioinhalts umfassen, die vorwiegend Sprache enthalten. Die Audio-Segmente, die überwiegend Sprache sind, werden dann in Übereinstimmung mit einem Lautheitsmessungsalgorithmus verarbeitet. Für Audiodaten, die aus einem AC-3-Bitstrom decodiert werden, kann dieser Algorithmus ein standardmäßiges K-gewichtetes Lautheitsmaß sein (in Übereinstimmung mit dem internationalen Standard ITU-R BS.1770). Alternativ können andere Lautheitsmaße verwendet werden (zum Beispiel solche, die auf psychoakustischen Modellen von Lautheit basieren).
-
Der Metadaten-Generator 106 erzeugt Metadaten (und/oder leitet an die Stufe 107), die durch die Stufe 107 in den codierten Bitstrom aufzunehmen sind, der von dem Codierer 100 auszugeben ist. Der Metadaten-Generator 106 kann an die Stufe 107 die Metadaten (und optional auch PIM) leiten, die durch den Codierer 101 und/oder den Parser 11 extrahiert werden (zum Beispiel, wenn Steuerungsbits von dem Validierer 102 anzeigen, dass die Metadaten gültig sind), oder neue PIM und/oder andere Metadaten erzeugen und die neuen Metadaten an die Stufe 107 zuführen (zum Beispiel, wenn Steuerungsbits von dem Validierer 102 anzeigen, dass die Metadaten, die durch den Decodierer 101 extrahiert werden, ungültig sind), oder er kann an die Stufe 107 eine Kombination von Metadaten, die von dem Decodierer 101 und/oder dem Parser 111 extrahiert werden, und neu erzeugten Metadaten zuführen. Der Metadaten-Generator 106 kann Lautheit-Daten, die von dem Teilsystem 108 erzeugt werden, und zumindest einen Wert aufnehmen, der den Typ einer Lautheits-Verarbeitung anzeigt, die durch das Teilsystem 108 durchgeführt wird.
-
Der Metadaten-Generator 106 kann Schutzbits erzeugen (die aus einem Hash-basierten Nachrichtenauthentifizierungscode (HMAC – Hash-Based Message Authentication Code) bestehen können oder diesen umfassen können), die nützlich sind für zumindest eines aus einer Entschlüsselung, Authentifizierung oder Validierung der Metadaten, die in den codierten Bitstrom und/oder die zugrundeliegenden Audiodaten, die in den codierten Bitstrom aufzunehmen sind, aufzunehmen sind. Der Metadaten-Generator 106 kann derartige Schutzbits an die Stufe 107 liefern zur Aufnahme in den codierten Bitstrom.
-
In einem typischen Betrieb verarbeitet das Dialoglautheitsmessung-Teilsystem 108 die Audiodaten, die von dem Decodierer 101 ausgegeben werden, um in Reaktion darauf Lautheitswerte (zum Beispiel Gate-gesteuerte und nicht-Gate-gesteuerte Dialoglautheitswerte) und Dynamikregelungswerte zu erzeugen. In Reaktion auf diese Werte kann der Metadaten-Generator 106 Lautheits-Verarbeitungszustands-Metadaten zur Aufnahme (durch den Füller/Formatierer 107) in den codierten Bitstrom zur Ausgabe von dem Codierer 100 erzeugen.
-
Der Codierer 105 codiert (zum Beispiel durch Durchführen einer Komprimierung) die Audiodaten, die von der Auswahlstufe 104 ausgegeben werden, und führt das codierte Audio der Stufe 107 zu für eine Aufnahme in den codierten Bitstrom zur Ausgabe von der Stufe 107.
-
Die Stufe 107 multiplext das codierte Audio von dem Codierer 105 und die Metadaten (einschließlich PIM) von dem Generator 106, um den codierten Bitstrom zur Ausgabe von der Stufe 107 zu erzeugen, vorzugsweise derart, dass der codierte Bitstrom ein Format hat, das durch ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung spezifiziert wird.
-
Der Rahmenpuffer 109 ist ein Pufferspeicher, der zumindest einen Rahmen des codierten Audiobitstroms speichert (zum Beispiel auf eine nicht-transitorische Weise), der von der Stufe 107 ausgegeben wird, und eine Sequenz der Rahmen des codierten Audiobitstroms wird dann von dem Puffer 109 als Ausgabe von dem Codierer 100 an das Liefersystem 150 zugeführt.
-
In einigen Implementierungen des Codierers 100 ist der codierte Bitstrom, der in dem Speicher 109 zwischengespeichert ist (und an das Liefersystem 150 ausgegeben wird), ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und weist Audiodaten-Segmente (zum Beispiel die AB0–AB5-Segmente des Rahmens, der in 4 gezeigt wird) und Metadaten-Segmenten auf, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente PIM (und optional auch andere Metadaten) umfasst. Die Stufe 107 fügt Metadaten-Segmente (einschließlich Metadaten) in den Bitstrom in dem folgenden Format ein. Jedes der Metadaten-Segmente, das PIM umfasst, ist in einem Ausschuss-Bit-Segment des Bitstroms (auch als „Auslassen-Feld” bezeichnet) (zum Beispiel ein Ausschuss-Bit-Segment „W” wie in 4 oder 7 gezeigt), oder ein „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld (zum Beispiel das AUX-Segment, das in 4 oder 7 gezeigt wird) an dem Ende eines Rahmens des Bitstroms enthalten. Ein Rahmen des Bitstroms kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes Metadaten umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, kann eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden sein.
-
In einigen Ausführungsbeispielen hat jedes Metadaten-Segment (hier manchmal als ein „Container” bezeichnet), das von der Stufe 107 eingefügt wird, ein Format, das einen Metadaten-Segment-Header (und optional auch andere obligatorische oder „Kern”-Elemente) und eine oder mehrere Metadaten-Nutzlast(en) nachfolgend auf den Metadaten-Segment-Header umfasst. PIM, wenn vorhanden, sind in einer ersten der Metadaten-Nutzlasten enthalten (durch einen Nutzlast-Header identifiziert und typischerweise mit einem Format eines ersten Typs). Ähnlich ist jeder andere Typ von Metadaten (wenn vorhanden) in einer anderen der Metadaten-Nutzlasten enthalten (durch einen Nutzlast-Header identifiziert und typischerweise mit einem Format, das spezifisch ist für den Typ von Metadaten). Das beispielhafte Format ermöglicht einen bequemen Zugriff auf die PIM und andere Metadaten zu anderen Zeitpunkten als während einer Decodierung (zum Beispiel durch einen Postprozessor nach einer Decodierung oder durch einen Prozessor, der konfiguriert ist zum Erkennen der Metadaten, ohne eine vollständige Decodierung des codierten Bitstroms durchzuführen), und ermöglicht eine bequeme und effiziente Fehlererfassung und -korrektur (zum Beispiel eine Teilstromidentifikation) während einer Decodierung des Bitstroms. Eine Metadaten-Nutzlast in einem Metadaten-Segment kann PIM umfassen, eine andere Metadaten-Nutzlast in dem Metadaten-Segment kann einen zweiten Typ von Metadaten umfassen, und optional auch zumindest eine andere Metadaten-Nutzlast in dem Metadaten-Segment kann andere Metadaten umfassen (zum Beispiel Lautheits-Verarbeitungszustands-Metadaten oder „LPSM (loudness processing state metadata)”).
-
In einigen Ausführungsbeispielen hat eine Programminformations-Metadaten(PIM – program information metadaten)-Nutzlast, die in einem Rahmen eines codierten Bitstroms (zum Beispiel ein AC-3-Bitstrom, der für zumindest ein Audioprogramm indikativ ist) aufgenommen ist (durch Stufe 107), das folgende Format:
einen Nutzlast-Header, der typischerweise zumindest einen Identifikationswert (zum Beispiel einen Wert, der indikativ ist für eine PIM-Format-Version und optional auch Länge-, Zeitdauer-, Anzahl- und Teilstrom-Assoziations-Werte); und
nach dem Header, PIM in dem folgenden Format:
Aktivkanal-Metadaten, die indikativ sind für jeden stillen Kanal und jeden nicht-stillen Kanal eines Audioprogramms (d. h. welche(r) Kanal/Kanäle des Programms Audioinformation enthält/enthalten, und welche(r) (wenn überhaupt) nur Stille enthält/enthalten (typischerweise für die Dauer des Rahmens)). In Ausführungsbeispielen, in denen der codierte Bitstrom ein AC-3- oder E-AC-3-Bitstrom ist, können die Aktivkanal-Metadaten in einem Rahmen des Bitstroms in Verbindung mit zusätzlichen Metadaten des Bitstroms verwendet werden (zum Beispiel das Audiocodier-Modus(„acmod”)-Feld des Rahmens, und, wenn vorhanden, das chanmap-Feld in dem Rahmen oder assoziierten abhängigen Teilstrom-Rahmen), um zu bestimmen, welche(r) Kanal/Kanäle des Programms Audioinformation enthält/enthalten und welche(r) Stille enthält/enthalten. Das „acmod”-Feld eines AC-3- oder E-AC-3-Rahmens gibt die Anzahl von Vollbereichs-Kanälen eines Audioprogramms an, angegeben durch Audioinhalt des Rahmens (zum Beispiel, ob das Programm ein 1.0-Kanal monophones Programm, ein 2.0-Kanal-Stereo-Programm oder ein Programm ist, das L, R, C, Ls, Rs Vollbereichs-Kanäle aufweist), oder dass der Rahmen für zwei unabhängige 1.0-Kanal monophone Programme indikativ ist. Ein „chanmap”-Feld eines E-AC-3-Bitstroms gibt eine Kanal-Zuordnung für einen abhängigen Teilstrom an, angegeben von dem Bitstrom. Aktivkanal-Metadaten können nützlich sein zum Implementieren eines Aufwärtsmischens (upmixing) (in einem Postprozessor) stromabwärts eines Decodierers, um zum Beispiel Audio zu Kanälen, die Stille enthalten, an dem Ausgang des Decodierers hinzuzufügen;
Abwärtsmischen- bzw. Downmix-Verarbeitungszustands-Metadaten, die angegeben, ob das Programm abwärtsgemischt wurde (vor oder während einer Codierung), und wenn ja, den Typ eines Abwärtsmischen, der angewendet wurde. Abwärtsmischen-Verarbeitungszustands-Metadaten können nützlich sein zum Implementieren eines Aufwärtsmischens (in einem Postprozessor) stromabwärts eines Decodierers, um zum Beispiel den Audioinhalt des Programms unter Verwendung von Parametern aufwärts zu mischen, die am ehesten einem Typ eines Abwärtsmischens entsprechen, der angewendet wurde. In Ausführungsbeispielen, in denen der codierte Bitstrom ein AC-3- oder E-AC-3-Bitstrom ist, können die Abwärtsmischen-Verarbeitungszustands-Metadaten in Verbindung mit dem Audiocodiermodus(„acmod”)-Feld des Rahmens verwendet werden, um den Typ des Abwärtsmischens zu bestimmen (wenn vorhanden), der auf den Kanal/die Kanäle des Programms angewendet wird;
Aufwärtsmischen- bzw. Upmix-Verarbeitungszustands-Metadaten, die angeben, ob das Programm aufwärtsgemischt wurde (zum Beispiel aus einer kleineren Anzahl von Kanälen) vor oder während einer Codierung, und wenn ja, den Typ des Aufwärtsmischens, der angewendet wurde. Aufwärtsmischen-Verarbeitungszustands-Metadaten können nützlich sein zum Implementieren eines Abwärtsmischens (in einem Postprozessor) stromabwärts eines Decodierers, um zum Beispiel den Audioinhalt des Programms auf eine Weise abwärtszumischen, die mit einem Typ eines Aufwärtsmischens kompatibel ist (zum Beispiel Dolby Pro Logic, oder Dolby Pro Logic II Movie Modus oder Dolby Pro Logic II Music Modus oder Dolby Professionelle Upmixer), der auf das Programm angewendet wurde. In Ausführungsbeispielen, in denen der codierte Bitstrom ein E-AC-3-Bitstrom ist, können die Aufwärtsmischen-Verarbeitungszustands-Metadaten in Verbindung mit anderen Metadaten verwendet werden (zum Beispiel der Wert einer „strmtyp”-Feld des Rahmens), um den Typ eines Aufwärtsmischens zu bestimmen (wenn vorhanden), der auf den Kanal/die Kanäle des Programms angewendet wird. Der Wert des „strmtyp”-Felds (in dem BSI-Segment eines Rahmens eines E-AC-3-Bitstroms) gibt an, ob ein Audioinhalt des Rahmens zu einem unabhängigen Strom (der ein Programm bestimmt) oder einem unabhängigen Teilstrom (eines Programms, das mehrere Teilströme enthält oder mit diesen assoziiert ist) gehört, und kann somit unabhängig von jedem anderen Teilstrom decodiert werden, der durch den E-AC-3-Bitstrom angegeben wird, oder ob Audioinhalt des Rahmens zu einem abhängigen Teilstrom (eines Programms, das mehrere Teilströme enthält oder mit diesen assoziiert ist) gehört und somit in Verbindung mit einem unabhängigen Teilstrom decodiert werden muss, mit dem er assoziiert ist; und
Vorverarbeitungszustands-Metadaten, die angeben, ob eine Vorverarbeitung auf Audioinhalt des Rahmens durchgeführt wurde (vor einem Codieren des Audioinhalts, um den codierten Bitstrom zu erzeugen), und wenn ja, den Typ der Vorverarbeitung, die durchgeführt wurde.
-
In einigen Implementierungen sind die Vorverarbeitungszustands-Metadaten indikativ für:
ob eine Surround-Dämpfung angewendet wurde (zum Beispiel, ob Surround-Kanäle des Audioprogramms um 3 dB vor einem Codieren gedämpft wurden),
ob eine 90°-Phasenverschiebung angewendet wurde (zum Beispiel auf die Surround-Kanäle Ls- und Rs-Kanäle des Audioprogramms vor einem Codieren),
ob ein Tiefpaßfilter auf einen LFE-Kanal des Audioprogramms vor einem Codieren angewendet wurde,
ob ein Pegel eines LFE-Kanals des Programms während der Produktion überwacht wurde und wenn ja, der überwachte Pegel des LFE-Kanals relativ zu einem Pegel der Vollbereichs-Audiokanäle des Programms,
ob eine Dynamikbereichskomprimierung durchgeführt werden soll (zum Beispiel in dem Decodierer) auf jedem Block des decodierten Audioinhalts des Programms, und wenn ja, der Typ (und/oder Parameter) einer durchzuführenden Dynamikbereichskomprimierung (zum Beispiel kann dieser Typ von Vorverarbeitungszustands-Metadaten angeben, welcher der folgenden Komprimierungsprofiltypen durch den Codierer angenommen wurde, um Dynamikbereichskomprimierungs-Steuerwerte zu erzeugen, die in dem codierten Bitstrom enthalten sind: Film Standard, Film schwach, Musik Standard, Musik schwach, oder Sprache. Alternativ kann dieser Typ von Vorverarbeitungszustands-Metadaten angeben, dass eine starke Dynamikbereichskomprimierung („compr” Komprimierung) auf jedem Rahmen von decodiertem Audioinhalt des Programms auf eine Weise durchgeführt werden soll, die durch Dynamikbereichskomprimierungs-Steuerwerte bestimmt wird, die in dem codierten Bitstrom enthalten sind),
ob eine Spektralerweiterungsverarbeitung und/oder Kanalkopplungscodierung verwendet wurde, um spezifische Frequenzbereiche von Inhalt des Programms zu codieren und wenn ja, die minimalen und maximalen Frequenzen der Frequenzkomponenten des Inhalts, auf dem eine Spektralerweiterungscodierung durchgeführt wurde, und die minimalen und maximalen Frequenzen von Frequenzkomponenten des Inhalts, auf dem eine Kanalkopplungscodierung durchgeführt wurde. Dieser Typ einer Vorverarbeitungszustands-Metadaten-Information kann nützlich sein, um eine Entzerrung (in einem Postprozessor) stromabwärts eines Decodierers durchzuführen. Sowohl Kanalkopplung- als auch Spektralerweiterungs-Information sind ebenfalls nützlich zur Optimierung einer Qualität während Transcodier-Operationen und -Anwendungen. Zum Beispiel kann ein Codierer sein Verhalten optimieren (einschließlich der Anpassung von Vorverarbeitungsschritten, wie Kopfhörer-Virtualisierung, Aufwärtsmischen, usw.) basierend auf dem Zustand von Parametern, wie Spektralerweiterungs- und Kanalkopplungs-Information. Darüber hinaus kann der Codierer seine Kopplungs- und Spektralerweiterungs-Parameter dynamisch anpassen, um Werte anzupassen und/oder zu optimieren, basierend auf dem Zustand der eingehenden (und authentifizierten) Metadaten, und
ob Dialog-Verbesserungs-Anpassungsbereichs-Daten in dem codierten Bitstrom enthalten sind, und wenn ja, der Anpassungsbereich, der verfügbar ist während einer Durchführung einer Dialog-Verbesserungs-Verarbeitung (zum Beispiel in einem Postprozessor stromabwärts eines Decodierers), um den Pegel eines Dialog-Inhalts relativ zu dem Pegel eines Nicht-Dialog-Inhalts in dem Audioprogramm anzupassen.
-
In einigen Implementierungen sind zusätzliche Vorverarbeitungszustands-Metadaten (zum Beispiel Metadaten, die Kopfhörer-bezogene Parameter angeben) in einer PIM-Nutzlast eines codierten Bitstroms (durch Stufe 107) enthalten zur Ausgabe von dem Codierer 100.
-
Jeder Metadaten-Nutzlast folgt die entsprechende Nutzlast-ID und Nutzlastkonfigurationswerte.
-
In einigen Ausführungsbeispielen hat jedes der Metadaten-Segmente in dem Ausschuss-Bit-/Auslassen-Feld-Segment (oder auxdata-Feld oder „addbsi”-Feld) eines Rahmens drei Strukturebenen:
eine Struktur auf hoher Ebene (zum Beispiel ein Metadaten-Segment-Header), einschließlich eines Flags, das anzeigt, ob das Ausschuss-Bit(oder auxdata oder addbsi)-Feld Metadaten umfasst, zumindest einen ID-Wert, der anzeigt, welche(r) Typ(en) von Metadaten vorhanden ist/sind, und typischerweise auch einen Wert, der angibt, wie viele Bits von Metadaten (zum Beispiel von jedem Typ) vorhanden sind (wenn Metadaten vorhanden sind). Ein Typ von Metadaten, der vorhanden sein kann, ist PIM, und ein anderer Typ von Metadaten, der vorhanden sein kann, ist LSPM;
eine Struktur einer mittleren Ebene, die Daten aufweist, die mit jedem identifizierten Typ von Metadaten assoziiert sind (zum Beispiel Metadaten-Nutzlast-Header, Schutzwerte und Nutzlast-ID und Nutzlastkonfigurationswerte für jeden identifizierten Typ von Metadaten); und
eine Struktur einer unteren Ebene, die eine Metadaten-Nutzlast für jeden identifizierten Typ von Metadaten aufweist (zum Beispiel eine Sequenz von PIM-Werten, wenn PIM als vorhanden identifiziert wird, und/oder Metadaten-Werte eines anderen Typs (zum Beispiel LSPM), wenn dieser andere Typ von Metadaten als vorhanden identifiziert wird).
-
Die Datenwerte in einer derartigen Struktur mit drei Ebenen können verschachtelt sein. Zum Beispiel kann/können der/die Schutzwert(e) für jede Nutzlast (zum Beispiel jede PIM oder andere Metadaten-Nutzlast), identifiziert durch die Strukturen einer hohen und mittleren Ebene, nach der Nutzlast enthalten sein (und somit nach dem Metadaten-Nutzlast-Header der Nutzlast), oder der/die Schutzwert(e) für alle Metadaten-Nutzlasten, identifiziert durch die Strukturen einer hohen und mittleren Ebene, kann/können nach der letzten Metadaten-Nutzlast in dem Metadaten-Segment enthalten sein (und somit nach den Metadaten-Nutzlast-Headern aller Nutzlasten des Metadaten-Segments).
-
In einem Beispiel (das unter Bezugnahme auf das Metadaten-Segment oder „Container” von 8 beschrieben wird) identifiziert ein Metadaten-Segment-Header vier Metadaten-Nutzlasten. Wie in 8 gezeigt, weist der Metadaten-Segment-Header ein Container-Sync-Wort (als „Container sync” identifiziert) und Versions- und Schlüssel-ID-Werte auf. Auf den Metadaten-Segment-Header folgen die vier Metadaten-Nutzlasten und Schutzbits. Nutzlast-ID und Nutzlast-Konfigurations(zum Beispiel Nutzlastgröße)-Werte für die erste Nutzlast (zum Beispiel eine PIM-Nutzlast) folgen dem Metadaten-Segment Header, die erste Nutzlast selbst folgt auf die ID und Konfigurationswerte, Nutzlast-ID und Nutzlast-Konfigurations(zum Beispiel Nutzlastgröße)-Werte für die zweite Nutzlast (zum Beispiel eine PIM-Nutzlast) folgen auf die erste Nutzlast, die zweite Nutzlast selbst folgt auf diese ID und Konfigurationswerte, Nutzlast-ID und Nutzlast-Konfigurations(zum Beispiel Nutzlastgröße)-Werte für die dritte Nutzlast (zum Beispiel eine Lautheitsverarbeitungszustands-Metadaten-Nutzlast) folgen auf die zweite Nutzlast, die dritte Nutzlast selbst folgt auf diese ID und Konfigurationswerte, Nutzlast-ID und Nutzlast-Konfigurations(zum Beispiel Nutzlastgröße)-Werte für die vierte Nutzlast folgen auf die dritte Nutzlast, die vierte Nutzlast selbst folgt auf diese ID und Konfigurationswerte, und Schutzwert(e) (identifiziert als „Schutzdaten” in 8) für alle oder einen Teil der Nutzlasten (oder für die Struktur der hohen und mittleren Ebene und alle oder einige der Nutzlasten) folgen der letzten Nutzlast.
-
3 ist ein Blockdiagramm eines Decodierers (200), der ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit ist, und eines Postprozessors (300), der damit gekoppelt ist. Der Postprozessor (300) ist auch ein Ausführungsbeispiel der erfindungsgemäßen Audioverarbeitungseinheit. Die Komponenten oder Elemente des Decodierers 200 und des Postprozessors 300 können als ein oder mehrere Prozess(e) und/oder eine oder mehrere Schaltung(en) (zum Beispiel ASICs, FPGAs oder andere integrierte Schaltungen), in Hardware, Software oder einer Kombination aus Hardware und Software implementiert werden. Der Decodierer 200 weist einen Rahmenpuffer 201, einen Parser 205, einen Audio-Decodierer 202, eine Audiozustands-Validierungsstufe (Validierer) 203 und eine Steuerungsbit-Erzeugungsstufe 204 auf, verbunden wie gezeigt. Typischerweise umfasst der Decodierer 200 auch andere Verarbeitungselemente (nicht gezeigt).
-
Der Rahmenpuffer 201 (ein Pufferspeicher) speichert (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des codierten Audiobitstroms, der durch den Decodierer 200 empfangen wird. Eine Sequenz der Rahmen des codierten Audiobitstroms wird von dem Puffer 201 an den Parser 205 zugeführt.
-
Der Parser 205 ist gekoppelt und konfiguriert, um PIM (und optional auch andere Metadaten) aus jedem Rahmen des codierten Eingangsaudios zu extrahieren, um zumindest einige der Metadaten (zum Beispiel PIM) an den Audio-Zustandsvalidierer 203 und die Stufe 204 zuzuführen, die extrahierten Metadaten als Ausgabe (zum Beispiel an den Postprozessor 300) zuzuführen, um Audiodaten aus dem codierten Eingangsaudio zu extrahieren und um die extrahierten Audiodaten an den Decodierer 202 zuzuführen.
-
Der codierte Audiobitstrom, der in den Decodierer 200 eingegeben wird, kann einer aus einem AC-3-Bitstrom, einem E-AC-3-Bitstrom oder einem Dolby-E-Bitstrom sein.
-
Das System von 3 umfasst auch einen Postprozessor 300. Der Postprozessor 300 weist einen Rahmenpuffer 301 und andere Verarbeitungselemente (nicht gezeigt) auf, einschließlich zumindest eines Verarbeitungselements, das mit dem Puffer 301 gekoppelt ist. Der Rahmenpuffer 301 speichert (zum Beispiel auf eine nicht-transitorische Weise) zumindest einen Rahmen des decodierten Audiobitstroms, der durch den Postprozessor 300 von dem Decodierer 200 empfangen wird. Verarbeitungselemente des Postprozessors 300 sind gekoppelt und konfiguriert zum Empfangen und adaptiven Verarbeiten einer Sequenz der Rahmen des decodierten Audiobitstroms, der von dem Puffer 301 ausgegeben wird, unter Verwendung von Metadaten, die von dem Decodierer 200 ausgegeben werden, und/oder Steuerungsbits, die von der Stufe 204 des Decodierers 200 ausgegeben werden. Typischerweise ist der Postprozessor 300 konfiguriert, eine adaptive Verarbeitung auf den decodierten Audiodaten unter Verwendung von Metadaten von dem Decodierer 200 durchzuführen (zum Beispiel adaptive Lautheits-Verarbeitung auf den decodierten Audiodaten unter Verwendung von Metadaten-Werten, wobei die adaptive Verarbeitung basieren kann auf einem Lautheitsverarbeitungszustand und/oder einer oder mehreren Audiodaten-Charakteristik(en), angegeben durch Metadaten für Audiodaten, die indikativ sind für ein einzelnes Audioprogramm).
-
Verschiedene Implementierungen des Decodierers 200 und des Postprozessors 300 sind konfiguriert, um verschiedene Ausführungsbeispiele des erfindungsgemäßen Vorgehens durchzuführen.
-
In einigen Implementierungen des Decodierers 200 ist der empfangene (und in dem Speicher 201 gepufferte) codierte Bitstrom ein AC-3-Bitstrom oder ein E-AC-3-Bitstrom und weist Audiodaten-Segmente (zum Beispiel die AB0–AB5-Segmente des Rahmens, der in 4 gezeigt wird) und Metadaten-Segmente auf, wobei die Audiodaten-Segmente indikativ sind für Audiodaten, und jedes von zumindest einigen der Metadaten-Segmente PIM (oder andere Metadaten) umfasst. Die Decodierer-Stufe 202 (und/oder der Parser 205) ist konfiguriert, die Metadaten aus dem Bitstrom zu extrahieren. Jedes der Metadaten-Segmente, das PIM (und optional auch andere Metadaten) umfasst, ist in einem Ausschuss-Bit-Segment eines Rahmens des Bitstroms oder in einem „addbsi”-Feld des Bitstrom-Information(„BSI”)-Segments eines Rahmens des Bitstroms oder in einem auxdata-Feld (zum Beispiel das AUX-Segment, das in 4 gezeigt wird) an dem Ende eines Rahmens des Bitstroms enthalten. Ein Rahmen des Bitstroms kann ein oder zwei Metadaten-Segment(e) umfassen, von denen jedes Metadaten umfasst, und wenn der Rahmen zwei Metadaten-Segmente umfasst, kann eines in dem addbsi-Feld des Rahmens und das andere in dem AUX-Feld des Rahmens vorhanden sein.
-
Ausführungsbeispiele der vorliegenden Erfindung können in Hardware, Firmware oder Software oder einer Kombination aus beiden (zum Beispiel als ein programmierbares Logik-Array) implementiert sein. Zusätzlich können die hier beschriebenen Audioverarbeitungseinheiten Teil verschiedener Kommunikationsvorrichtungen, wie Fernseher, Mobiltelefone, Personalcomputer, Tablet-Computer, Laptops, Set-top-Boxen und/oder Video-Empfänger, sein und/oder mit diesen integriert sein. Sofern nicht anders angegeben, sind die Algorithmen oder Prozesse, die als Teil der Erfindung enthalten sind, nicht inhärent auf einen bestimmten Computer oder eine andere Vorrichtung bezogen. Insbesondere können verschiedene Universalmaschinen mit Programmen verwendet werden, die gemäß den Lehren hier geschrieben werden, oder es kann einfacher sein, eine stärker spezialisierte Vorrichtung (zum Beispiel integrierte Schaltungen) zu konstruieren, um die erforderlichen Vorgänge durchzuführen. Somit kann die Erfindung in einem oder mehreren Computerprogramm(en) implementiert werden, das/die auf einem oder mehreren programmierbaren Computersystem(en) ausgeführt wird/werden (zum Beispiel eine Implementierung eines der Elemente von 1 oder der Codierer 100 von 2 (oder ein Element davon), oder der Decodierer 200 von 3 (oder ein Element davon), oder der Postprozessor 300 von 3 (oder ein Element davon)), die jeweils zumindest einen Prozessor, zumindest ein Datenspeichersystem (einschließlich flüchtiger und nicht-flüchtiger Speicher und/oder Speicherelemente), zumindest eine Eingabevorrichtung oder -anschluss, und zumindest eine Ausgabevorrichtung oder -anschluss aufweisen. Der Programmcode wird auf Eingangsdaten angewendet, um die hier beschriebenen Funktionen durchzuführen und eine Ausgabeinformation zu erzeugen. Die Ausgabeinformation wird auf eine oder mehrere Ausgabevorrichtung(en) auf bekannte Weise angewendet.
-
Jedes derartige Programm kann in jeder gewünschten Computersprache (einschließlich Maschinen-, Assembler- oder höhere prozedurale, logische oder objektorientierte Programmiersprachen) implementiert werden, um mit einem Computersystem zu kommunizieren. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
-
Zum Beispiel, wenn durch Computersoftware-Anweisungssequenzen implementiert, können verschiedene Funktionen und Schritte von Ausführungsbeispielen der Erfindung durch Multithread-Software-Anweisungssequenzen implementiert werden, die in geeigneter digitaler Signalverarbeitungs-Hardware laufen, in diesem Fall können die verschiedenen Vorrichtungen, Schritte und Funktionen der Ausführungsbeispiele Teilen der Software-Anweisungen entsprechen.
-
Jedes derartige Computerprogramm ist vorzugsweise auf einem Speichermedium oder einer Speichervorrichtung (zum Beispiel Festspeicher oder -Media oder magnetische oder optische Media) gespeichert oder auf diese heruntergeladen, die durch einen allgemeinen oder programmierbaren Spezial-Computer lesbar sind, zum Konfigurieren und Betreiben des Computers, wenn das Speichermedium oder die Speichervorrichtung durch das Computersystem gelesen wird, um die hier beschriebenen Vorgehensweisen durchzuführen. Das erfindungsgemäße System kann auch als ein computerlesbares Speichermedium implementiert sein, das mit einem Computerprogramm konfiguriert ist (d. h. Speichern), wobei das derart konfigurierte Speichermedium ein Computersystem veranlasst, auf eine spezifische und vordefinierte Weise zu arbeiten, um die hier beschriebenen Funktionen durchzuführen.
-
Eine Anzahl von Ausführungsbeispielen der Erfindung wurden beschrieben. Dennoch ist offensichtlich, dass verschiedene Modifikationen durchgeführt werden können, ohne von dem Gedanken und dem Umfang der Erfindung abzuweichen. Zahlreiche Modifikationen und Variationen der vorliegenden Erfindung sind angesichts der obigen Lehren möglich. Es ist offensichtlich, dass in dem Umfang der beigefügten Ansprüche die Erfindung anders praktiziert werden kann, als spezifisch hier beschrieben wurde.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- internationalen Standard ITU-R BS.1770 [0050]
