6.3. Datenbankstruktur
Die Datenbankstruktur ist weitgehend übersichtlich. Es wurden drei Tabellen für die Datenverarbeitung angelegt.
- Token – Zugriffskontrolle auf die Methoden der REST API
- Media – Eine Tabelle zum Verlinken der physischen Media-Assets (HLS-Streams auf dem Dateisystem) mit den Token zur Modifizierung, Entfernung und zum Playout im Fall von verschlüsselten Inhalten
- Profiles – Definition von Qualitätsstufen separat für Video- und für Audioassets
6.3.1. Token
Die Tabelle erstellt, verifiziert und annulliert Tokens, die notwendig sind, um auf jede REST-Methode zuzugreifen, bis auf die Publish-Methode, die benötigt wird, um in den Workflow einzusteigen. Diese Methode bedarf eines zusätzlichen Authorisierungsmechanismus90. Das Feld expired ist entweder null, kann auf „jetzt“ (ergo die Vergangenheit im nächsten Moment) oder auf ein fixen Zeitpunkt in der Zukunft eingestellt werden. Auf diese Weise kann ein Token bei der Erstellung mit einem Ablaufdatum versehen werden. Die Konditionen, zu denen die Token erworben werden können, sowie ihr Ablaufdatum und/oder die Bedingung, die erfüllt werden muss, damit ein Token ungültig wird, werden von der Logik im Token-Objekt bestimmt. Die Tabelle dient lediglich zur endgültigen Verifizierung, ob ein jeweiliger Zugriff auf eine REST-Methode gültig ist.
| Name | Token |
|---|---|
| id | Primärer Key |
| media | Primärer Key der Media -Tabelle |
| value | Token (256 Hexadezimalstellen) |
| type | Tokenkategorie (UPLOAD.TOKEN, MEDIA.TOKEN oder WATCH.TOKEN) |
| expired | Zeitpunkt, in dem die Gültigkeit abläuft (in der Zukunft oder Vergangenheit) |
| created | Datensatz wurde angelegt |
| modified | Datensatz wurde modifiziert |
Die Token Tabelle verwaltet den Zugriff zu allen REST-Methoden. Diese sind:
- Upload-Methode (UPLOAD.TOKEN → MEDIA.TOKEN)
- Delete-Methode (MEDIA.TOKEN → UNLINK MEDIA)
- In Planung: Renew-Methode (MEDIA.TOKEN → MEDIA.TOKEN)
- In Planung: Download-Methode (MEDIA.TOKEN → URL zum Streamarchiv)
- In Planung: Decrypt-Methode (MEDIA.TOKEN → WATCH.TOKEN)
- In Planung: Playout-Methode (WATCH.TOKEN → index.m3u8 mit Keyinfos)
Tokens sind für das Funktionieren der REST API unentbehrlich. In ihnen liegt die Tür zur Verwertung der Streamingdienstleistungen. Ihr Entwurf und ihre Entwicklung sollten Bestandteile eines jeden Streamingunterfangens sein. Sie müssen mit besonderer Sorgfalt implementiert werden, da sie die Sicherheit des gesamten Systems tragen.
6.3.2. Media
Diese Tabelle wird momentan zur Lagerwirtschaft des Medienbestands benutzt. Sie erlangt jedoch ihre Wichtigkeit bei der Implementierung von verschlüsselten Medien-Assets, denn die Keyinfo zum Abspielen wird hier gespeichert.
| Name | Media |
|---|---|
| id | Primärer Key |
| subdir | Unterverzeichnis im Webroot |
| sourcefile | Originaldateiname |
| streamInfo | JSON-Output von ffprobe |
| keyinfo | AES-Schlüssel |
| created | Datensatz wurde angelegt |
| modified | Datensatz wurde modifiziert |
Die Media Tabelle verwaltet:
- eine Liste des physischen Medienbestands (subdir) auf dem Webstorage
- (Meta-)Informationen über die Quelldatei eines Medien-Assets (sourcefile, streamInfo)
- die Keyinfo zum Entschlüsseln eines Medien-Assets
- jedes Assets ist über seinen Primary Key mit einem MEDIA.TOKEN verbunden und kann mit mehreren WATCH.TOKEN‘s verbunden sein
Die beiden Felder „sourcefile“ und „streamInfo“ werden nicht aktiv benutzt. In Zukunft können sie dazu dienen, die Metainformationen (auch OpenGraph) der einzelnen Assets mit den Metainformationen aus der Quelldatei zu ergänzen (optional zur manuellen Eingabe). Die Media-Tabelle kann also trotz des Encoder-Charakters des Projekts bestimmte Metainformationen zum Asset enthalten. Vor Allem können dadurch menschlich lesbare Informationen aus den Metadaten der Quelldatei extrahieren und zeitweise zwischenspeichern, bis der Medienadministrator dem Asset eine eigene Beschreibung hinzugefügt hat. Eine Screenshot Galerie kann diverse Vorschaubilder zur Wahl bereithalten, die ebenfalls in dieser Tabelle indexiert werden können. Abschließend können Tags für Suchmaschinen und Web Analytics einem Medien-Asset beigefügt werden, was die Indexierung und damit die Distribution erheblich optimalisieren könnte.
6.3.3. Profiles
In diesem Teil wird die Struktur der Profiles-Tabelle veranschaulicht sowie die Kriterien besprochen, mit denen diese Tabelle und das dazugehörige Xcdr-Objekt Entscheidungen bzgl. der Enkodierung in stufenweise abgemagerte Profile treffen. Die Felder sind weitestgehend FFmpeg-Kommandozeilenparameter, die bei einem Aufruf von FFmpeg zur Definierung der Profile dienen. Es werden zahlreiche FFmpeg-Parameter voreingestellt. Es fehlt der -hls_time Parameter, der die Länge einer ts-Datei in Sekunden festlegt. Er ist aber notwendig, um die Keyframes, also die Vollbilder in einem kontinuierlichen Livestream, an den Anfang einer ts-Datei zu setzen. Dies ist für den korrekten Wechsel der Bitraten durch den Player notwendig. Die weiteren Gegebenheiten zum Enkodieren der Keyframes am Anfang eines Chunks sowie die Arithmetik dazu werden im Teil 7.3. Playout-Test erklärt.
| Nr. | Name | Profiles |
|---|---|---|
| 1 | id | Primärer Key |
| 2 | audioVideo | audio, video |
| 3 | videoCodec | libx264, qsv_h264 (Intel QuickSync Video), libx265 |
| 4 | videoProfile | baseline, main, high |
| 5 | videoLevel | Siehe Tabelle 4 |
| 6 | videoLines | Die vertikale Auflösung des Profils. |
| 7 | videoFramerate | Bilder pro Sekunde |
| 8 | videoGop | GOP – Group of Pictures (Keyframeinterval) |
| 9 | videoCrf | CRF – Constant Rate Factor (visueller Qualitätsfaktor) |
| 10 | audioCodec | aac oder libmp3lame |
| 11 | audioSamplerate | Samplerate des Audiostreams |
| 12 | audioBitrate | Audiobitrate |
| 13 | audioChannels | 1, 2, 5.1 |
- Der FFmpeg-Transcoder kann sowohl den libx264-, den libx265- wie den Intel QuickSync Video Encoder benutzen. Alle drei Codecs lassen sich mit dem HLS-Protokoll enkapsulieren und als VoD-Asset zum Abruf bereitgestellt werden. Jedoch müssen die jeweiligen adaptiven Bitraten eines HLS-Streams mit demselben Encoder erstellt werden, damit ein HLS-Player sie korrekt erkennen, abrufen und dekodieren kann.
- Die Level der H.264-Enkodierung wurden in Tabelle 7 zusammengefasst. In der Praxis werden im Webstreaming viel kleinere Bitraten für HD-Video benutzt, als es die Tabelle erscheinen lässt. Die Auflösungen und die zugeordneten Level-Nummern gehen aus der Norm hervor. Der Level bestimmt die Kompatibilität des Streams zu einem Endgerät. Er wird durch die maximalen Bildparameter definiert, die er enkodieren kann, d.h. Bildschirmauflösung, Zahl der Bilder pro Sekunde sowie die resultierende Bandbreite. Ein Endgerät kann je nach definiertem Level das Abspielen des Streams verweigern, da er nicht mit der Herstellerspezifikation für die maximale Auflösung etc. übereinstimmt. Deswegen muss er sorgfältig gewählt werden oder die Wahl dem Transcoder überlassen werden.
- Bei der Auswahl der Videoprofile wurde die vertikale Auflösung (Zahl der Linien – videoLines) als ausschlaggebende Metric genommen. „Es gibt eine alte Daumenregel, die besagt, daß der Faktor einer Auflösungsänderung hoch 0.75 den Faktor ergibt, mit dem die Ursprungsbandbreite multipliziert werden muss, um die Zielbandbreite zu erhalten und die Ursprungsqualität beizubehalten“92. Erfahrungswerte sind, da sich dies in einem relativ experimentellen Bereich abspielt, keine Ungunst. Die Videoauflösung steht also in einem mathematischen Verhältnis zur benötigten Bandbreite. Deswegen wurde sie als Hauptkriterium für die Bestimmung der Ergebnisprofile mit abgestuften Bitraten verwendet.
- Die Zahl der Bilder pro Sekunde (5fps – 60fps)
- Der Group of Pictures (GOP)- Wert bestimmt das Intervall zwischen den Bildern, in denen im Stream ein Vollbild verschickt wird. Er sollte bei Livestreams lediglich wenige Sekunden betragen.
- Der Constant Rate Factor (CRF) ist ein FFmpeg-spezifischer Wert, der die Stärke der Kompression definiert. Wenn der Wert kleiner als 21 ist, geht man von einer durchschnittlichen Qualität aus. Bei kleiner werdenden Werten ist eine reelle Qualitätsverbesserung nur noch mit überproportional größer werdenden Bandbreiteneinbußen zu erreichen.
- HLS-Streams können sowohl den AAC- wie auch den MP3-Audiocodec übertragen. Oft ist die Konversion einer ganzen MP3-Sammlung zum AAC-Codec nicht vertretbar, da jede Konversion mit Qualitätseinbußen einhergeht. Der MP3-Codec kann unverändert ins HLS-Format importiert werden.
- Die Abtastrate der Audiospur. Man geht davon aus, daß 44100Hz (44.1kHz) die ursprüngliche Abtastrate der hochqualitativen Audio-CD und damit sogar für hohe Ansprüche ausreichend ist. Eine Abtastrate von 48000Hz befindet sich ebenfalls im Studioqualitätsbereich.
- Ähnlich wie die vertikale Auflösung im Fall von Video-Assets, so ist bei Audio-Assets die Bitrate die Orientierungsgröße, nach der eine Abstufung in Profile mit einer kleineren Audioauflösung erfolgt. Prinzipiell bedeutet eine höhrere Bitrate bei Audiokompression eine bessere Kopie der Originalaufnahme.
- Es kann eine Konversion zu Mono oder Stereo stattfinden. Falls die Originalaudiospur das 5.1 Dolby Surround -Format besitzt, kann dieses ebenfalls durch den 5.1 -Parameter beibehalten werden.