[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.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,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

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

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

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,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

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

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

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,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

  • Hallo Helmut

    Danke für den Patch

    Wolfgang (wolfi.m) hat den Patch am vdr-plugin-radio für EasyVDR5 angepasst

    Vorher: Version 1.0.0-4easyVDR6~focal

    Nun: Version 1.1.0-0easyVDR5~focal

    Und es läuft jetzt ohne segfault

    Danke und Gruß von Helmut alias Emma53

    Test_VDR: Lintec Senior - MSI G41M P25 MS7592 Board - Intel P4 E8500 / 775 CPU - MSI GT710 PCI-e passiv - DVBSky S2 952 Dual SAT - 120GB Intenso SSD + Big HDD - 2x2GB DDR3 RAM - LG GH24NSD1 S-ATA DVD - SMK RC6 MCE 50GB FB. an STM32 USB-Arduino - EasyVDR 5 - Softhddevice mit Pulseaudio - Kodi 20.5 m. Confluence Skin
    Clients:Div. Raspberry PI

    Fernbedienungsempfänger: Siehe hier:RP 2040 Zero I.R. Empfänger kompl.

    Edited once, last by Emma53 ().

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

  • Wäre es möglich den Patch gegen den aktuellen Git-Stand des Radio-Plugin statt gegen die letzte getaggte Version zu erstellen, damit das nicht zu weit auseinander läuft?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Oder besser in ein Git einfliessen lassen?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!