Wann kriegt der ORF seine Radioprogramme in den Griff?

@DF-Newsteam

Danke für die Zusammenfassung meiner Analysen der vergangenen Monate (!) und für die eigene Meldung.

Stand aktuell sind immer noch die Datenfehler im AAC-Datenstrom bei allen ORF-Radioprogrammen, die 128 kBit/s LC-AAC haben. Gerade eben mal kurz in Radio Wien und Radio Niederösterreich reingehört - andauernd hat man die Störungen.

Manche Empfangsgeräte knacken oder klicken dabei nur kurz, andere haben eine kurze stumme Stelle - die Geräte des bayerischen Herstellers LaSAT/Bemondis machen aufgrund ihres Puffer- und Taktverhaltens an diesen Stellen ganz heftige, sehr deutlich hörbare Störungen und verlieren am S/PDIF kurzzeitig den Sync.

LaSAT hat u.a. viele OEM-Geräte auch Richtung Österreich verkauft über Marken wie WISI (die teils direkt von österreichischen Kabelnetzbetreibern empfohlen wurden, z.B. von kabelplus und Salzburg AG - siehe z.B. WISI OR 152 F oder in der höherwertigen Gerätefamilie mit Programmnamenanzeige eigentlich für Radio gut geeignet sind, siehe z.B. den Twin-Sat-Receiver WISI OR 294 oder die identisch aussehenden Single- oder Twin-Kabelreceiver OR 252 / OR 254), Silva Schneider (Triple-Tuner-Receiver mit 12-stelliger Programmnamenanzeige "Gran Prix" bei Hofer Austria), weiterhin HDTV-Receiver von Pollin, Schwaiger, SMART, MEGASAT, SKT und weitere - sowie über die Eigenmarke "Vistron" auch HDTV-Receiver und DVB-Kabelradios. Die Kabelradios zeigen natürlich die gleichen Störungen, wenn 1:1 die Datenströme von Satellit ins Kabelnetz umgesetzt werden. Auch die "Soundboxen" sind betroffen, diese Geräte gibt es für Sat und Kabel.

So klingt das bei diesen Geräten am Analogausgang (Aufnahme mit einem PCM-Recorder, für das Web hier ein MP3 draus gemacht). Das ist nicht aushaltbar, wenn das alle paar Minuten mehrfach hintereinander kommt. Das wäre für mich auch nicht brauchbar, wenn es einmal pro Stunde kommt. So etwas darf nicht auftreten.

OE1 war tatsächlich zwischen 9.10.2024 12:18 Uhr und 29.10.2024 13:07 Uhr auf 128 kBit/s LC-AAC runtergesetzt. Beide Übergänge liegen mir als Direktmitschnitt vor, bei LC-AAC kann man das auch dynamisch machen, das merkt man nichtmal an Umschaltgeräuschen etc., das läuft nahtlos weiter, wenn alles gut geht. Während der Zeit mit 128 kBit/s waren tatsächlich auch bei OE1 diese Fehler drin. Nach Rückstellung auf 192 kBit/s waren sie sofort wieder weg. Warum man überhaupt zwischenzeitlich die Kulturwelle runtergesetzt hatte, weiß ich nicht. Test? Versehen?

Natürlich liegt das nicht direkt an den 128 kBit/s, denn die ARD verwendet auch bei den meisten Programmen 128 kBit/s LC-AAC und das spielt seit Behebung bzw. Kaschierung bestimmter Fehler (die auch nichts mit der Bitrate zu tun hatten) problemlos. Bei der ORS gibt es offenbar im Encoder/Multiplexersystem einen Bug, der bei 128 kBit/s durch irgendwelche zu gering bemessenen Puffer, Bit-Reservoirs, zu gering bemessene "Luft" beim Multiplexen oder was auch immer sporadisch zu fehlenden Daten führt, bei 192 kBit/s aber zufällig nicht auftritt.

Decodiert man mit FFmpeg, kommen detailliertere Fehlermeldungen. Die sehen immer so oder so ähnlich aus:

[aac @ 000000000043f000] decode_band_types: Input buffer exhausted before END element found
[aist#0:0/aac @ 00000000004346c0] [dec:aac @ 000000000042a380] Error submitting packet to decoder: Invalid data found when processing input
[aac @ 000000000043f000] decode_band_types: Input buffer exhausted before END element found
[aist#0:0/aac @ 00000000004346c0] [dec:aac @ 000000000042a380] Error submitting packet to decoder: Invalid data found when processing input
[aac @ 000000000043f000] Number of bands (43) exceeds limit (40).
[aist#0:0/aac @ 00000000004346c0] [dec:aac @ 000000000042a380] Error submitting packet to decoder: Invalid data found when processing input
[aac @ 000000000043f000] decode_band_types: Input buffer exhausted before END element found
[aist#0:0/aac @ 00000000004346c0] [dec:aac @ 000000000042a380] Error submitting packet to decoder: Invalid data found when processing input


"Input buffer exhausted before END element found" deutet für mich auf abruptes Ende eines Frames, bevor es eigentlich zuende ist, hin. Genaueres kann ich mangels Programmierkenntnissen und mangels Kenntnis des Encoder/Multiplexersystem bei der ORS freilich nicht sagen.

Bei OE1 mit 192 kBit/s LC-AAC kann man auch 12 Stunden Audio am Stück durch FFmpeg schieben und es kommt keine einzige solche Fehlermeldung. Bei ARD-Programmen mit 128 kBit/s LC-AAC gilt das gleiche: fehlerfreies Decodieren, egal wie lange man das macht.

Der technische Dientleister des ORF, die ORS, wird da selbst nicht viel machen können - außer die Bitrate der 128er Programme hochzusetzen. Vielleicht reichten dafür auch 136 oder 144 kBit/s oder spätestens 160 kBit/s - das ist reine Glückssache. Der einzige, der da grundlegens was ändern kann, dürfte der Muxer/Encoderhersteller sein, das System braucht einen Bugfix in der Software. Man müsste es einfach ausprobieren, den Vorschlag habe ich in Richtung ORF schon gemacht.

Ich stehe mit der verantwortlichen Person beim ORF in Kontakt seit September 2024. Damals wies ich auf weitere Fehler hin, so spielten z.B. bestimmte moderne Linux-Receiver nicht, vermutlich weil man keine PCR-Timestamps in den Datenströmen hatte

Neu ORF-Radios kein Ton - Vu+ Support Forum

Foren-Übersicht

und die LaSAT/Bemondis-Geräte und auch auf LC-AAC aufgerüstete UKW-Kopfstellenumsetzer konnten mit dem anfangs (bei 128 kBit/s unsinniger- und unnötigerweise) verwendetem HE-AACv1 nichts anfangen und spielten völlig kaputt, da HE-AAC deutlich höhere Anforderungen an Hard- und Software stellt als LC-AAC. LC-AAC reicht bei 128 kBit/s dicke, ohne die bekannten Störungen wäre das, was aus den Encodern kommt, auf wirklich hohem Niveau. Beides wurde binnen weniger Tage behoben - es lag halt im Rahmen des der ORS Möglichen, da reine Konfigurationssache. Die Datenfehler im AAC sind fieser. Die klickt man nicht einfach so in der Konfigurationssoftware weg - höchstens über die Lösung mit höherer Bitrate.

Neben der AAC-Datenfehler-Thematik sind auch die DVB-Servicelabel sehr unglücklich gewählt. Auf Geräten mit kürzeren Displays (DVB-Kabelradios und HDTV-Receiver von LaSAT/Bemondis beispielsweise) sind die Programme nicht zu unterscheiden:



Da ging das Priorisieren der Coroprate-Labels über die Benutzbarkeit. Auch das sollte geändert werden - das Wort "RADIO" und ein Leerzeichen weg, dann passt es.

Ein nice-to-have wären freilich auch RDS-Informationen, also mindestens Radiotext, gerne auch PS, CT, PI (für die Weiterverwendung in UKW-Kopfstellenumsetzern). Aber das ist angesichts der Tatsache, dass nichtmal die Basics funktionieren, Jammern auf hohem Niveau. Also besser kein RDS einbetten, nicht dass noch mehr kaputtgeht. RDS nach UECP in die Ancillary Data des AAC zu packen ist heikel, da nicht in den DVB-Spezifikationen vorgesehen, die ARD ist da auch erst derbe auf die Nase gefallen und macht es jetzt über einen Trick, von dem ich nicht weiß, ober definitiv immer "safe" ist.

 

Habe heute Vormittag ca. 3 Stunden über Satellit Hitradio Ö3 via Sony-TV und angeschlossener Stereoanlage gehört. Mir ist kein Aussetzer aufgefallen.

 

Ich komme komischerweise da, wo ich gerade bin, nicht an OE3 in AAC ran. Der Receiver hängt am Kleinkabelnetz mit 1:1-Einspeisung, ich habe aber keinen Fernseher / Monitor zur Hand und kann nur über das Gerätedisplay konfigurieren. Alle ORF-Programme sind da, auch ORE3 Visual (der Videostream). Nur OE3 als AAC will das Gerät offenbar nicht finden, warum auch immer. Selbst neuer Suchlauf auf diesem Kanal brachte nicht. Jetzt hier massiv umzubauen (Gerät abkabeln, in Mutters Wohnzimmer schaffen, an den TV hängen, dort einrichten) schaffe ich nicht. Vielleicht schaffe ich es morgen abend direkt an meiner Satanlage. Aber alle anderen ORF-Radios in 128 LC-AAC haben diese Störungen.

Falls Du OE3 Visual (TV) genutzt hast, das läuft in 160 AC-3 und ist vermutlich nicht betroffen (habe es nicht getestet).

Falls Du tatsächlich OE3 in AAC gehört hast: Glück gehabt, manche Geräte knacken an den Fehlerstellen nur leise oder machen winzigen Aussetzer, das fällt u.U. dann nicht weiter auf.

 

@conrad2

Ich habe jetzt doch mal diesen Aufwand gemacht (und mir den erwarteten Ärger meiner pflegebedürftigen Mutter eingefangen, die für solche Spielereien kein Verständnis hat). Komplettes Plattmachen des Receiverspeichers und Neueinlesen brachte auch OE3 AAC.

In 15 Minuten OE3 (die 128er AAC-Variante) hatte ich eine (!) Störung gehört, da wären bei anderen ORF-Programmen mindestens 5 Störungen drin gewesen, sage ich mal.

Dann habe ich mir vom Logging-Server eines Freundes 12 Stunden OE3 gezogen, von heute Nacht 0 Uhr bis heute Mittag um 12. Das dann durch FFmpeg decodiert und das Logfile angeschaut. Das gleiche mit den gleichen 12 Stunden Radio Wien.

Ergebnis: das OE3-Logfile ist 69,4 kByte groß, das Logfile von Radio Wien ist 125 kByte groß. Nun steht da oben dran noch viel Prosa von FFmpeg, also zählen wir mal die Zeilen mit Fehlern.

Bei OE3 habe ich 437 Zeilen mit Fehlermeldungen von FFmpeg. Bei Radio Wien habe ich 851 Zeilen mit Fehlermeldungen. Dabei sind aber auch Zeilen eines Typs, die es beoi OE3 gar nicht gibt: FFmpeg erkennt dann aufgrund der kaputten Daten fälschlicherweise Features von AAC, die nicht in FFmpeg unterstützt werden und bittet dann um Mitarbeit:

[aac @ 000000000043c0c0] If you heard an audible artifact, there may be a bug in the decoder. Clipped noise gain (-116 -> -100) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[aac @ 000000000043c0c0] If you want to help, upload a sample of this file to VideoLAN File Uploader and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)

Das kommt dann mehrfach hintereinander und bezieht sich möglicherweise auf insgesamt einen Fehler. Wenn ich diese Zeilen auch rausnehme, bleiben 705 Zeilen übrig bei Radio Wien. Das ist auch noch deutlich mehr als bei OE3 (437 Zeilen).

Das ist hochinteressant, da gibt es auch noch Unterschiede in der Häufigkeit je nach Service. Aber damit können wohl nur die Entwickler des Encoder/Muxerservers der ORS was anfangen. Ich weiß nichtmal, welche Technik dort läuft. Formal encodiert diese Software vermutlich bestmöglich (das 128er LC-AAC ist ansonsten sehr in Ordnung, keinesfalls schlechter als bei der ARD, die auf Qbit bzw. Ferncast setzt), aber da sind halt diese Fehler.

Ich kann ja von außen nichtmal erahnen, ob das im Encoder oder im Muxer passiert. Vielleicht ist auch nur zu wenig Headroom im Muxer reserviert und die Datenrate aus dem Encoder geht in Bursts etwas zu hoch.

 

Hast Du mal mit Neutrino probiert ob es da diese Fehler auch gibt?
Ich habe leider nur Kabel und kann es daher nicht testen.

 

Ich habe keine Linux-Receiver. Die Info, dass bestimmte Linux-basierte Geräte nicht spielen, habe ich nur aus den o.g. Foren - in einem war auch knallhart ein komplettes Posting von mir aus den Radioszene-Foren zitiert worden. Das Thema betraf offenbar alle AAC-Programme, auch OE1, das damals LC-AAC und 192 kBit/s hatte und bei mir fehlerfrei spielte. Mit Einbauen der PCR-Timestamps spielte das dann ja auch alles auf den Linux-Geräten prinzipiell (abgesehen von den Datenfehlern), dieses Thema hat sich also erledigt.

Allgemein ist das Verhalten von Endgeräten bei Problemen mit PCR / PTS offenbar völlig unvorhersagbar. Der NDR hatte auf NDR 1 NDS (Hannover) vergangenen Herbst mal den Effekt, dass bestimmte Geräte stumm blieben, andere aber spielten. Es gab wohl zahlreiche Beschwerden deswegen, aber sie fanden erstmal keine Ursache. Ich bin dann von einem in der ARD arbeitenden Freund gebeten worden, da mal drauf zu schauen. In den Signalisierungen war alles unauffällig, meine LaSAT-Geräte spielten auch NDR 1 NDS als wäre nichts gewesen. Aber dann fand ich dort die PTS für bestimmte Datenpakete zeitiger als die PCR - und das ist ein Kausalitätsverstoß. Datenpakete, die zum Zeitpunkt t ausgespielt werden sollen, können nicht laut PCR zum Zeitpunkt t + delta t mit delta t > 0 im Gerät eintreffen. Die LaSAT-Geräte haben das ignoriert, andere nicht. Nach Reset von Encoder oder Muxer (weiß nicht, wo das passiert ist, können beide Stellen sein) spielte es auf den anderen Geräten wieder.

 

Soweit stecke ich nicht in der Materie.
Ich weiß nur das es mal ein Problem gab als jemand Radiosender aufnehmen wollte das dies nicht gelang weil Die Audio/Videosync aktiv war und ohne Videosignal funktionierte das ganze dann nicht. Wenn man A/V Sync abgeschaltet hatte klappte die Aufnahme. Mittlerweile wird geprüft ob es sich um einen reinen Audiostream handelt.

 

Geräte reagieren in der Tat völlig unterschiedlich auf Fehler im Datenstrom. Siehe hier: NDR1 Niedersachsen Hannover via Astra 1, 11053 MHz

 

Das war genau dieser Fehler. Betroffen war Niedersachsen und nicht Welle Nord, habs oben korrigiert. Ich werde bei unwichtigen Dingen vergesslich.