Beiträge von siski

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

    Hallo HelmutB,


    Zitat von 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

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

    Hallo miteinander,

    Zitat von HelmutB

    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

  • [EA5] Radio Kanäle: Einträge/Namen haben sich verändert.

    Hallo miteinander,


    ich möchte an dieser Stelle auf mich selber antworten:


    Ich habe noch ein Problem in meiner ffmpeg Implementierung korrigiert, wovon insbesondere MDR, RBB und der BR betroffen waren: Diese Radioprogramme verteilen die meisten "UECP-RDS" Nachrichten auf mehrere AAC Frames wodurch diese "verteilten" RDS Nachrichten verlorengingen. Der NDR war von dem Thema nicht betroffen, hier ist immer genau eine vollständige UECP RDS Nachricht in ein AAC Frame eingebettet. Die Anpassung in ffmpeg erfordert auch ein angepasstes ts2shout.


    Die korrigierte Version ist für die Experimentierfreudige zum Ausprobieren in meinem Github Bereich https://github.com/carsten-gross/ abgelegt. Die aktuelle ts2shout Version hat die commit id 52c20a (current master) bzw. FFmpeg 37f926d. Das Zusammenzubringen ist aktuell noch kein Selbstläufer, ich habe das Makefile so vorbereitet, dass man das selbstgebaute ffmpeg nicht installieren muss. Dadurch vermeidet man das eigene System zu zerbasteln ;-). Linux-Erfahrene sollten das eigentlich gut hinbekommen können.


    Die AAC Anpassungen wurden mittlerweile von KODI übernommen, ich denke aber KODI ist kein typischer Client für VDR.


    Grüße,


    Carsten

  • DD Octopus Net, Paketverluste, femon

    Hiho,


    Bei mir ist die Fehlerquote gering, 19/160851616. Von 160 Millionen empfangenen Paketen waren 19 kaputt. Ich vermute der TE hat eher größere Probleme. Bei mir tritt der Packetloss im RTP auf (ich vermute beim TE auch, RTSP ist ja das Signalisierungsprotokoll über den der SAT>IP Satempfänger gesteuert wird).


    Grüße,


    Carsten

  • DD Octopus Net, Paketverluste, femon

    Hallo miteinander,

    In meinem Aufbau mit einer Selfsat SAT>IP 21 habe ich auch Probleme mit gelegentlichem Packetloss. Das Problem bei mir ist ein "flaches RJ-45" Kabel das durch die Terassentür geklemmt ist. Hin und wiederkommt es zu einem CRC-32 Fehler im Ethernetframe, das RTP Paket wird dann konsequent verworfen, dadurch gehen exakt 7 MPEG frames verloren. ts2shout bzw. tvheadend loggen dann einen continuity error und der Ethernet-Switch an dem die Antenne hängt zählt den "FCS"-Zähler (Frame-check-sequence) jeweils um eines hoch. Gelegentlich ists auch ein "Internal-MAC-Receive-Error". Ggf. setzt zuckt ton- und/oder Bild kurz.


    Es kann also auch abseits der SAT Technik auch in der Netzwerkverkabelung liegen. Kannst Du an Deinem Switch FCS Fehler einsehen? Heißt oft auch "CRC-Fehler".


    Große Probleme hat man auch wenn aus irgendeinem Grund die andere Seite der Ethernetverbindung auf Halbduplex und die andere auf Vollduplex steht. Dann gibts regelmässig Packetloss, immer dann wenn die RTSP Session aktiv wird.


    Grüße,


    Carsten

  • [EA5] Radio Kanäle: Einträge/Namen haben sich verändert.

    Hallo miteinander,

    Zitat von HelmutB

    Ich sehe gerade, dass es"AV_FRAME_DATA_DATA_STREAM_ELEMENT0" nur in der FFmpeg Version, von Carsten Gross als Erweiterung vonenum AVFrameSideDataTypegibt oder gab:


    Ich habe mir gerade mal einen Account angelegt, nachdem sich hier eine Diskussion um "mein" ts2shout und meine Anpassungen an ffmpeg "entwickelt". Ich habe eine Änderung an FFmpeg implementiert, die die RDS Daten im AAC Strom des neuen ARD Transponders als sog. "FrameSideData" in ffmpeg bereitstellt.


    In ts2shout habe ich entsprechende Anpassungen vorgenommen (aktuelle Version v0.99) und bei mir auf einem x86-PC läuft das mit den Anpassungen in FFMpeg (über die hier diskutiert wird) ordentlich.

    Ich habe etwas hin- und herüberlegt und im commit fba0cf556b41573b9b5dbb88270b5f97dfd872af "meiner" ffmpeg Version ist in libavutil/frame.h das Makro "AV_FRAME_DATA_RDS_DATA_PACKET" definiert. So plane ich das auch upstream vorzuschlagen, d.h. damit das Teil von ffmpeg werden kann.


    AV_FRAME_DATA_DATA_STREAM_ELEMENT0 war ein erster Aufschlag, mit AV_FRAME_DATA_RDS_DATA_PACKET gefällt mir das aber besser und es fügt sich IMHO besser in das Konzept von ffmpg ein (und kann dann auch für MPEG 1/2 implementiert werden).


    Mit ts2shout spielt es bei mir zuhause gut zusammen und ich habe wieder RDS auf dem neuen ARD Transponder auf (fast) allen ARD Programmen. Das Übersetzen von ffmpeg und ts2shout ist aktuell aber kein "Selbstläufer", da ich in meiner Installation das systemweite ffmpeg nicht "kaputt" machen will.


    Von einem User habe ich schon feedback das es mit Raspian (= ARM = Big-Endian) ein Thema zumindest mit der Demo in doc/examples gibt. Das will ich noch auf einem PI nachvollziehen, meine PIs sind aber tatsächlich alle "belegt" ;) - als selbstgebaute Raspberry PI Media Player


    Vor längerer Zeit schon habe ich Anpassungen an ts2shout vorgenommen, daß sowohl VDR als auch tvheadend den MPEG-TS Strom zuliefern können.

    Grüße,


    Carsten