[radio-1.1.0] RDS/Radiotext und AAC-Audio

Die die alten ARD Radioprogramme mit RDS im MPEG1 Audiostream bald abgeschalten werden, habe ich nach einer Lösung gesucht, diese Informationen auf einfache Weise aus dem neuem Audio-Sendeformat AAC-LATM herauszuholen. Einen vollständigen AAC-Bitstream Parser wollte ich mir dazu nicht antun, ich gehe die Sache umgekehrt an und suche dazu in den letzten 128 Byte jedes AAC-Frames nach einem Data_Stream_Element <DSE> mit RDS Daten.

Da es sich bei AAC sich um einen Bitstream handelt, werden die Daten zuerst an eine Bytegrenze geschoben und dann versucht beim Rückwärtslesen den Beginn des <DSE> zu erkennen.

Soweit ich es beurteilen kann, werden damit bei allen neuen ARD Radioprogrammen die RDS Daten gefunden und angezeigt - nur bei "Bremen 1..4" sehe ich im Gegensatz zu den "alt_*" Prgrammen nocht nichts.

Die Programme "hr1" bis "hr4" haben dei RDS Daten nun auch direkt im Audiostream, das war glaube ich im September noch nicht der Fall.

Im Anhang der radio-1.1.0-00-AAC_RDS.patch für das radio-plugin-1.1.0.

Für die Sender mit eigener RDS-Pid gibt es noch den passenden Erweiterungspatch radio-1.1.0-01-AAC_RDS-RdsPid.patch, damit muß aber auch der VDR gepatcht werden. Der VDR RDSPid Patch ist noch unverändert zu hier, der Link https://www.vdr-portal.de/inde…2-vdr-2-5-6-rdspid-patch/.

Helmut

Quote from TomJoad

Du solltest in Zeile 180 des patches noch "==" in "=" abändern?

Ja, unbedingt, es soll ja eine Zuweisung sein. Sonst gibt es Fehler beim Umschlaten zw. MPEG und AAC.

Ich werde es korrigieren.

Danke

Helmut

Hier die Version 2 des AAC_RDS Patch.

Darin ist der von TomJoad oben festgestellte Fehler behoben. Zusätzlich wird jetzt bei MPEG die Framegröße für jeden Frame dezidiert ermittelt, da sich z.B.. bei "JAM FM" über das Padding-Bit die Größe jedes Frames um +/- 1 Byte zum Vorgänger ändert.

Das Frame- und Bufferhandling von AAC unD MPEG ist jetzt vereinheitlicht, und durch das Argument "-x" kann das Anzeigen eines Hintergrundbilds komplett abgeschaltet werden - das benötige ich derzeit für xineliboutput das mit Standbild keinen Ton ausgibt.

Edit:

Eine klein Ergänzung: Das AAC-RDS Parsing ist unverändert. Ich habe gestern noch eine kurze Aufnahme vom "Bremen Eins" durch ts2shout mit gepatchtem ffmep laufen lassen. Da auch hier keine RDS Daten angezeigt wurden, gehe ich davon aus, dass derzeit auf diesen Sendern (noch) kein RDS übertragen wird.

Hier die Version 3 des radio-1.10 AAC_RDS Patch mit einer kleinen Änderung durch die die Option "kein Standbild" im Setup-Menü eingestellt werden kann. Der Plugin-Parameter "-x" darf nicht mehr verwendet werden.

Im neuen vdr-2.5.6-RDSPid-v2.patch wird die RDS-Pid und Type nun als Erweiterung der tpid in die channels.conf geschrieben: :0+123@17;...:.

Der Zugriff erfolgt über cChannnels::Upid() und cChannnels::Utype().

Im dazu passenden radio-1.1.0-01-AAC_RDS-RdsPid-v2.patch wird die Upid nun verwendet um festzustellen, ob die RDS-Daten direkt im Audiostream oder einem separaten Stream übertragen werden. Programme ohne RDS-Pid werden nicht mehr auf RDS-Daten geprüft.

Das erweiterte channels Format sollte rückwärtskompatibel sein und auch von einem ungepatchten VDR wieder eingelesen werden können.

Läuft bei mir bisher fehlerfrei, ich habe es allerdings noch nicht sehr intensiv geprüft.

Hallo Carsten!

Durch das rückwärts lesen und dem Versuch ein <DSE> nur durch '0x80' und einem passenden Längen-Byte zu erkennen, lassen sich falsche Treffer leider nicht ganz vermeiden. Es ist also schon möglich, dass einige RDS-Daten dadurch nicht richtig erkannt werden, es sollten aber wirklich nur ganz wenige sein.

Beim Text fällt mir auf, dass das letzte Byte direkt nach "Nea" 0x0D ist, ein <newline>, Also ist die Textzeile komplett.

Und Some say - Nea gibt es offensichtlich wirklich :).

Ich bin mir nicht sicher, ob der Index wirklich immer fortlaufend gesendet wird. Ich habe auch immer wieder gleichmässige Sprünge in gesehen, oder einfach ohne Index - nur 0.

Siehst du RDS-Pakete mit Index 0x89 bis 0x9B wenn du diese Aufnahme durch ts2shout mit deinem ffmpeg schickst?

LG Helmut

Hallo Carsten,

dein Test mit ts2shout ist sehr hilfreich - jetzt sehe ich, dass der Transaktions / Sequence Counter fortlaufend ist und mein Code doch viele DSE's nicht oder falsch erkennt.

Ich werde es mir auf "NDR 2" genauer ansehen. Da hier immer ganze RDS-Meldungen im Stück übertragen werden, sollte ich den Fehler doch leichter finden können.

TomJoad hat mich auch auf einen Fehler bei kurzen Frames die innerhalb eines einzigen TS-Pakets liegen aufmerksam gemacht, das sollte ich mir auch gleich ansehen.

LG Helmut

TomJoad - du hast recht. Die Ursache ist, dass die <FIL> Erkennung nicht bem ersten Treffer bleibt.

Ich habe bisher nur gültige <FIL> Elemente mit 0-Byte Länge gesehen, immer unmitttelbar vor dem <TERM>.
Hier vorab ein Einzeiler zur Korrektur..

--- vdr-plugin-radio-1.1.0.aac_rds_v3/radioaudio.c    2021-12-23 19:07:11.018272547 +0100
+++ vdr-plugin-radio-1.1.0.aac_rds_v3a/radioaudio.c    2021-12-23 19:09:32.648277531 +0100
@@ -751,7 +751,7 @@ int cRadioAudio::GetLatmRdsDSE(const uch
                 uchar eCh = (tmp >> rs) & 0xFF;
                 rdsChunk[i] = eCh;
 
-                if (i < 0xF && (eCh & 0xF) == i && (eCh & 0x70) == 0x60 && eCnt == 0) { // potential short <FIL>, 7-bit header
+                if (eCnt == 0 && i < 0xF && !fill && (eCh & 0xF) == i && (eCh & 0x70) == 0x60) { // potential short <FIL>, 7-bit header
                     fill = p;
                     //dsyslog("%s: <FIL> (ID-byte %02X)", __func__, eCh & 0x7F); hexdump(rdsChunk, i + 1);
                     }

LG Helmut

Ich bin inzwischen bei Version 6 des AAC_RDS Patch angelangt. v4 und v5 haben TomJoad ich intern bei testen"verbraucht". Die <DSE> Erkennung ist inzwischen ziemlich gut und es gehen fast keine RDS-Messages mehr verloren.

Ich habe festgestellt, das das radio-plugin mit asprintf() arbeitet um den Radiotext zu speichern. Leider wird aber fast überall auf ein free() der nicht mehr benötigten Daten vergessen.

Ich habe daher noch einen "extension" Patch der nun char-Arrays mit fixer Länge verwendet, viele unnötige Zeilenumbrüche entfernt die den Code zum Teil schwer lesbar gemacht machen und der auch einige kleinere Korrekturen enthält.

Zusätzlich zeigt das Plugin nun bis zu 6 RT+ Tags an - zu Titel und Interpret jetzt auch Album, Orchester, Komponist und Dirigent die z.B. bei BR Klassik sehr zuverlässig mitübertragen werden.

Dieser Erweiterunsgspatch ist etwas grösser, die grundsätzliche Funktiosweise des Plugins bleibt aber gleich.

Für den des AAC_RDSv6 Patch habe ich auch eine Version für den aktuellen Stand auf https://projects.vdr-developer.org/git/vdr-plugin-radio.git/ vom 15.7.2018 von Ulrich Eckhardt.

Hier zwei Screenshots.

Helmut

TomJoad hat mich schon vor einer Woche drauf hingewiesen, dass im radio-1.1.0.00-AAC_RDSv6.patch ein Bug enthalten ist, durch den es beim Umschalten zwischen AAC und MPEG1 Radiprogrammen bei der Erstellung des "bitrate" String zu einem double free() mit nachfolgendem segfault kommen kann.

Ich habe erst heute gesehen, dass Emma53 dieser Fehler auch schon aufgefallen ist: ARD stellt Astra-Hörfunk von MP2 auf AAC um und neuer Kanal

Als erste Hilfe im Anhang ein diff zur Version6, das diesen Fehler behebt.
Helmut

Hier die Version 7. Ich habe nun einen Pat/Pmt Parser eingebaut, damit kann das Plugin externe RDS-Pids selbst erkennen und der VDR muß nicht mehr gepatched werden. Das "bitrate" diff von oben ist natürlich enthalten, und das Default für die verbosity ist von "1" auf "0" geändert - Radiotext Debuging müss nun mit "-v 1" aktiviert werden.

Sonst ist kein weiterer Patch notwendig, der v6-Extension-Patch von Post #13 kann (oder sollte?) zusätzlich auch noch angewendet werden.

Helmut

PS: Ich habe mit vdr-2.5.6 und 2.4.7 getestet, vdr-2.2.0 sollte aber auch passen.

Hier der (ungetestete) V7-Patch gegen den aktuellen Stand im git.

Das git hat sich nur durch das Dateisplitting von der Version 1.1.0 leider schon so weit entfernt, dass fast jeder Patch doppelte Arbeit bedeutet. Und soweit ich die Code-Änderungen im git nachverfolgen konnte, gibt es gar keine funktionellen Änderungen zur Version 1.1.0.

Ich weiß nicht genau, wie man das einfach lösen kann. Vielleicht mit einer offiziellen Version 1.1.1, auf der man dann weiter aufbaut.

Helmut