[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

  • Danke, scheint wunderbar zu funktionieren.

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

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • 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 miteinander,

    können.

    Hier die Version 3 des radio-1.10 AAC_RDS Patch mit einer kleinen Änderung durch die die Option "kein Standbild" im Setup-Menü

    [...]

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

    Das ist äußerst spannend. Von mir ist ja das ts2shout und ich habe Anpassungen an ffmpeg gemacht (die leider nicht upstream übernommen wurden, zumindest bist jetzt nicht), um die AAC Daten auszulesen. Allerdings stört mich der ffmpeg-"Overhead" doch etwas und ich habe Deine Anpassungen mal als "Test" in meinem ts2shout probiert.


    Ich nehme immer ein paar aufgezeichnete .ts Dateien an denen ich dann den Code erprobe. Meine Referenz für inline-AAC "einfach" ist hier NDR 2, weil das immer komplette RDS Nachrichten in einem AAC Frame enthält. Ich kann einige, aber leider nicht alle, RDS Frames meiner aufgezeichneten Dateien mit Deinem Code dekodieren. Hattest Du mal Deinen Code geprüft ob Du eine komplett aufsteigende Sequenz von RDS Nachrichten empfängst?


    Hier mal als Beispiel was ich mit Deinem angepassten GetLatmRdsDSE() aus einer meiner Dateien u.a. herausholen kann:


    Sieht kryptisch aus, sind aber alles gültige UECP RDS Nachrichten (in umgekehrter Reihenfolge)


    Das sind direkt die extrahierten "rdsChunks". 3 Byte vor dem "FE" (umgekehrt) ist ja immer eine laufende Nummer, hier fängt es mit "0x77" an, dann kommt 0x7e, weiter gehts mit der 0x81, 0x82 (da sind also direkt zwei aufeinanderfolgende richtig extrahiert worden), dann 0x84 usw. Gelegentlich kommt auch ein ganzer RT (hier: "Some say - Nea"). Das sieht schonmal gar nicht schlecht aus, ist aber leider nicht komplett.


    Ist das bei Dir ähnlich, habe ich da evtl. was falsch oder ist das mit der Methode "die beste Möglichkeit" (weil ja auch "von hinten her" gelesen wird)?

    Grüße,


    Carsten

  • 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

  • Bei meinen Tests mit GetLatmRdsDSE() waren die Transaktionsnummern im 3.Byte immer durchlaufend. "False Positives" kann man vermindern, wenn man abfragt, ob am Anfang ein "0xFE" oder ein "0xFE" unmittelbar nach einem "0xFF" kommt, aber ich habe schon ein Pseudopaket mit lauter "0xFE" gesehen.


    Den Ffmpeg-Code konnte ich nicht nutzen, weil der vdr jedes empfangene TS-Paket an mehrere Receiver verteilen kann, in dem Fall an die Audio-Ausgabe im Output-Plugin und an das Radioplugin, das RDS und früher RASS extrahiert. Das Radioplugin bekam dann manchmal nur einen Teil der Seitenbanddaten, der andere verpuffte im Audio-Ausgabeplugin, wenn ein frame gleichzeitig verarbeitet wurde.

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Hallo HelmutB,


    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?


    Mit dem ffmpeg/ts2shout Code passt es. Mein in meinem RDS Dekoder-Teil integrierter Debug-Output lässt das "0xfe/0xff" weg und schreibt in "Vorwärtsrichtung" auf die Konsole, deshalb sieht es ein bißchen anders aus. Ich werte nur Radiotext aus, die ganzen PI Code, TMC und sonst was für Sachen laufen einfach so vorbei ....

    usw. usf.


    Ich habe auch mal rein interessehalber die Daten im Speicher hin- und herrotiert, evtl. suche ich mir mal die Frames raus die "nicht" gefunden werden wo es da jeweils genau hakt.


    Danke auf jeden Fall für Deinen Ansatz, Das bringt so den mp2 Ansatz zurück und ich sehe das potential den Zugriff auf die DSE Daten zu haben ohne AAC komplett dekodieren oder verstehen zu müssen.


    Grüße,


    Carsten

  • 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

  • Hallo Helmut, es scheinen auf jeden Fall ein Problem mit dem Erkennen von FIL Elementen zu geben. Folgt in der realen Reihenfolge nach dem DSE-Element ein FIL-Element als letztes vor dem TERM, wird das DSE-RDS nicht erkannt.

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • 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..

    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