Hypersensible eHD

  • Bei minimalen Fehlern in Aufnahmen produziert meine eHD Bild- und Ton-Aussetzer für gefühlt eine halbe Sekunde.


    Dieselbe Aufnahme über VLC, XBMC oder Air Video Server abgespielt, funktioniert ohne Probleme.


    Ich meine, das Problem hat sich seit Umstieg auf VDR mit TS Aufzeichnung deutlich verschärft.



    Weiß jemand, ob sich da was machen lässt oder heißt es Warten auf Verbesserungen im hdplayer seitens von Reel?


    Ich überlege sogar, ob ich auf einen VDR 1.7.0 downgraden soll, der noch in PES aufzeichnet.


    Pete

  • Da ein kaputter TS den h264-Decoder gern langfristig (bis zum Re-Zap) verwirrt, ist im hdplayer was drin, das bei TS-Continuity-Fehlern einen Decoder-Reset auslöst. Wenn der Empfang halbwegs vernünftig ist, sollte das aber eigentlich nur selten auftauchen.

  • Ah, da isser ja wieder, unser lieber Himmelskörper. Hab ihn schon vermisst. Wie liebevoll er sich doch um alles kümmert, was mit RMM zu tun hat... Und selbst wenn das Thema gar nichts mit RMM zu tun hat, sorgt er oft für kostenlose Werbung, soviel könnte ich hier gar nicht posten. Und damit man ihn besser versteht, baut er auch noch immer so hypsche Smilies in seine kompetenten Posts ein.


    @Mods:
    Er sollte dringend im Forum einen besonderen Status geniessen, gebt ihm doch bitte ein eigenes Subtopic, wo es nur um RMM geht.

  • Zitat

    Original von real_schorsch
    @Mods:
    Er sollte dringend im Forum einen besonderen Status geniessen, gebt ihm doch bitte ein eigenes Subtopic, wo es nur um RMM geht.


    Und das dann bitte für alle anderen unsichtbar machen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Original von real_schorsch
    Ah, da isser ja wieder, unser lieber Himmelskörper. Hab ihn schon vermisst. Wie liebevoll er sich doch um alles kümmert, was mit RMM zu tun hat... Und selbst wenn das Thema gar nichts mit RMM zu tun hat, sorgt er oft für kostenlose Werbung, soviel könnte ich hier gar nicht posten. Und damit man ihn besser versteht, baut er auch noch immer so hypsche Smilies in seine kompetenten Posts ein.


    @Mods:
    Er sollte dringend im Forum einen besonderen Status geniessen, gebt ihm doch bitte ein eigenes Subtopic, wo es nur um RMM geht.


    Dennoch gibt es diese Aussetzer sehr häufig, besonders bei HD kommt der Decoder schnell aus dem Tritt.

  • Dem muss ich leider zustimmen und das gilt auch für die Reelbox Avantgarde II welche die eHD in sich stecken hat.

    Gruß
    Frodo

  • Zitat

    Original von ALT255
    Dennoch gibt es diese Aussetzer sehr häufig, besonders bei HD kommt der Decoder schnell aus dem Tritt.


    Was für Aussetzer hast Du denn bei HD?
    Ich habe seit fast 1 1/2 Jahren eine Reel-eHD in meinem VDR stecken und bei mir macht die Reel-Karte praktisch keine Probleme. Keine Aussetzter oder Tonprobleme bei SD und HD!
    Das einzige was bei mir immer Probleme gemacht hat, sind die DVB-S2-Karten, die dann immer mal "TS continiuty errors" usw. bringen, aber dafür kann ja die Reel-eHD nichts.


    Momentan, solange es die viel gepriesene TT-Full-HD-Karte noch nicht gibt, hat man zur Reel-eHD kaum eine vernünftige Alternative!
    Hier bekommt man ohne größeren Aufwand und ohne große Softwareeinstellerei-Gefrickel a'la VDPAU ein sehr gutes HD-Bild.


    Paulaner

  • Zitat

    Originally posted by Paulaner
    Das einzige was bei mir immer Probleme gemacht hat, sind die DVB-S2-Karten, die dann immer mal "TS continiuty errors" usw. bringen, aber dafür kann ja die Reel-eHD nichts.


    Naja, ist schon schön wenn Decoder etwas toleranter sind. Und es gibt ja auch noch Kabelnutzer ;)


    Zitat

    Originally posted by Paulaner
    Momentan, solange es die viel gepriesene TT-Full-HD-Karte noch nicht gibt, hat man zur Reel-eHD kaum eine vernünftige Alternative!


    Wobei die den Beweis noch bringen müssen das die einen besseren Decoder on Board haben ;) Viel gepriesen und hohe Erwartungen hin oder her, am Ende wird die Praxis zeigen was sie halten. Und die SD FF waren ja auch nie wirklich frei von Problemen.


    cu

  • Zitat

    Original von real_schorsch
    Da ein kaputter TS den h264-Decoder gern langfristig (bis zum Re-Zap) verwirrt, ist im hdplayer was drin, das bei TS-Continuity-Fehlern einen Decoder-Reset auslöst. Wenn der Empfang halbwegs vernünftig ist, sollte das aber eigentlich nur selten auftauchen.


    Ich habe das Problem bei SD und HD sowohl bei Aufnahmen, als auch beim Livestreaming über Streamdev. Im Log des VDR Server findet sich allerdings keine Fehlermeldung, die zeitlich zu den Aussetzern passt.


    Die Aufnahmen lassen sich mit anderen Playern abspielen (VLC, Air Video, XBMC, Plex) und produzieren dort überhaupt keine sichtbaren Störungen bzw. allenfalls nur minimalste Fehler, die kaum stören.


    Ich habe eine SD Aufnahme mit ProjectX nach PES gewandelt. Dabei hat ProjectX 2 oder 3 Fehler gemeldet (und wohl auch repariert). Die PES Aufnahme lies sich dann mit der eHD abspielen. An der Stelle, an der vorher der Aussetzer war, hatte ich jetzt nur kurz ein Paar Klötzchen-Artefakte aber keinen Aussetzer.


    Wie bereits erwähnt habe ich den Eindruck, dass es früher mit dem VDR 1.7.0 keine derartigen Aussetzer gab. Gut, nat. schon ab und an Bildstörungen mit Klötzchenbildung, aber die störten deutlich weniger, als diese kompletten Aussetzer.


    Da ich zeitgleich mit dem Wechsel auf VDR 1.7.15/16 die Hardware des Servers und den Aufstellungsort geändert habe (jetzt weiter entfernt vom Haus-Kabelanschluss), kann ich nicht sagen, ob die TS-Streams jetzt von schlechterer Qualität sind, als früher die PES-Streams, oder ob die eHD nur mit TS schlechter zurecht kommt als mit PES.


    real_schorsch: Ich kann gerne eine kurze Aufzeichnung in SD oder HD zu Verfügung stellen, die reproduzierbar an einer Stelle den eHD-Reset erzwingt. Ich habe zwischenzeitlich genügend davon. ;-/



    Am Besten wäre es nat., wenn Real den Decoder der eHD stabiler hinbekäme.


    Gibt es ansonsten Programme, die einen TS-Stream soweit reparieren, dass die eHD damit sicher klarkommt? Evt. ließe sich das sogar als Helper-App in Streamdev einbinden. ProjectX kann IMHO nicht mit HD umgehen, ist dafür also keine universelle Lösung. Gibt es eine HD-fähige Alternative?



    Grüße


    Pete

  • "Früher" war der Decoder-Reset nicht drin. Meistens waren die Fehler dann nur kurz sichtbar, vereinzelt hat es aber in einer Dauerschmiererei geendet. Offensichtlich geht da was in der Frameverwaltung daneben, sodass es nie mehr ein Gesamutupdate des Bildes gibt. Den Effekt habe ich aber auch schon bei anderen (und neueren) HW-h264-Decodern gesehen, lustigerweise mit wirklich identisch aussehenden Fehlern... Das Hautproblem ist dabei, dass der Effekt nicht automatisch erkennbar ist, sonst könnte man den Decoder-Reset wirklich nur dann machen, wenn er nötig ist...


    Die grundlegende Ursache zu ändern, ist IMO nicht möglich. Micronas gibts nicht mehr, der Decoder selbst läuft zu grossen Teilen in der HW, ein kleiner Teil ist zwar FW für den zweiten MIPS, aber die war nie öffentlich. RMM hat zwar noch ein paar non-public-Infos zu diversen Registern (damit waren noch Sachen wie Gamma-Einstellungen oder SPDIF-Statusbits-Bugs zu fixen), zu den Interna des Decoders gibts gar nichts.


    Ein Vergleich mit SW-Playern ist zwar schön, ist aber Äpfel und Birnen. Ein SW-Decoder kann im Fehlerfall soviel Sachen machen und probieren, das ist in der Komplexität in HW nicht sinnvoll unterzubringen. Man schaue sich zB. mal die Load vom mplayer an, wenn er SD-Material mit Fehlern mit "error-concealment" behandelt. Die verzehnfacht sich fast...


    Was bei mir schon länger auf der Liste steht (aber wg. familiärer Probleme nicht ging), war, den Reset bei Continuity-Fehlern zumindest konfigurierbar zu machen. Das ist die einzige Stelle, die vermeintliche Fehler erkennen kann.

  • Kann ich den Decoder-Reset im Source des hdplayer mal testweise deaktivieren?


    Dann könnte ich testen, ob das insgesamt ein befriedigenderes Ergebnis bringt.


    Wenn, sagen wir mal, nur jeder 20. Continuity-Fehler den Decoder außer Tritt bringt, und bei 19 dafür der Decoder sich sofort wieder fängt ohne Reset, dann könnte ich evt. den hdplayer via Remote command manuell Neustarten, wenn es zu Dauerschmiererei kommt.


    Klar, besser wäre nat. ein Signal ohne Continuity-Fehler.


    Mir ist nicht ganz klar, wo die her kommen. Störungen in der Antennenleitung, Probleme in den DVB Karten oder irgendein Mobo Voodoo, wie IRQ Sharing etc.


    Wüsste ich es, könnte ich versuchen, die Ursache des Problems zu bekämpfen, anstatt an den Symptomen rumzudoktern.


    Für Tips wäre ich dankbar.


    Pete

  • > Kann ich den Decoder-Reset im Source des hdplayer mal testweise deaktivieren?


    Wenn du das MIPS-Zeug kompilieren kannst, ja. Der Reset ist in hdplayer3/demux.c, Funktion vdec_write_tsp(), ca. Zeile 787. Da ist ein Vergleich auf den Continuity-Counter und bei fehlendem Frame gibts ein decoder_reset().


    > Remote command manuell Neustarten


    Der hdplayer muss nicht neu gestartet werden, es reicht ein Rezap (OK-OK, Prog+- etc.) bzw. bei der Wiedergabe mal ein kurzes Vor/Rückspulen. Netterweise verursachen die TS-Fehler im h264-Decoder die Schmiererei nicht reproduzierbar, d.h. selbst beim Rückspulen und nochmaligem Abspielen der Fehlerstelle kann es nur zu einer temporären Störung kommen.


    > Wüsste ich es, könnte ich versuchen, die Ursache des Problems zu bekämpfen, anstatt an den
    > Symptomen rumzudoktern.


    Der Test beim Empfang ist relativ einfach, wenn der Treiber die BER/UNC-Werte rausrückt. Wenn schon die BERs ab und zu ungleich 0 sind, kann über längere Zeit auch mal ein unkorrigierbarer Fehler durchkommen.


    BTW: Die "untere" Definition von Quasi-Error-Free ist eine TS Paketfehlerrate (FER) von 1e-7. 10MBit/s sind ~7000 Pakete/s. Bei einer FER von 1e-7 ist also nach knapp 30min schon ein defektes Paket dabei. Wenn der Fehler tatsächlich noch vom BCH-Dekoder (BCH bei DVB-S2 ist der Reed-Solomon von DVB-S) erkannt, aber nicht mehr korrigiert werden kann, bekommt das Paket vom Tunerchip das Error-Bit und es fliegt schon im vdr raus (remux.c, Check auf TsError()). Damit entsteht dann auch die Lücke im Paketzähler. Du kannst ja in den TsError-Fall mal eine Log-Meldung reinsetzen.

  • Zitat

    Original von real_schorsch
    >
    > Wüsste ich es, könnte ich versuchen, die Ursache des Problems zu bekämpfen, anstatt an den
    > Symptomen rumzudoktern.


    Der Test beim Empfang ist relativ einfach, wenn der Treiber die BER/UNC-Werte rausrückt. Wenn schon die BERs ab und zu ungleich 0 sind, kann über längere Zeit auch mal ein unkorrigierbarer Fehler durchkommen.



    Hallo Schorsch.


    Eine Umgebung um für MIPS zu kompilieren müsste ich mir erst einrichten, das geht nicht so auf die Schnelle.



    BER/UNC-Werte bekomme ich über Femon schon.


    Ich habe als DVB Karten eine TT C-1500 und eine TT C-1501. Die TT C-1500 hat aber bekanntermaßen etwas Probleme mit Femon und zeigt relativ bescheidene Signalstärke an (in etwa STR: 55%, SNR: 7% ). Ditto. auch ständig BER Werte im 2-stelligen Bereich. UNC aber dauerhaft Null.


    Die TT C-1501 liegt dagegen ständig bei ca. STR: 92%, SNR: 96% und 0 bei BER/UNC.


    Beide liefern aber normalerweise ein anständiges Bild ohne Störungen (bis auf die eHD Dekoder-Resets), so dass ich auf die schlechten Femon-Werte der TT C-1500 nicht so viel gebe.


    Gestern beim Livestreaming mal längere Zeit auf die Femon Anzeige gestarrt und hatte 3 Mal einen Dekoder-Reset beim Betrieb über die TT C-1501 (ich hätte das ja eher bei der TT C-1500 erwartet). Bei den ersten Beiden war BER/UNC auf Null. Beim 3. Reset meine ich, dass UNC ganz kurz gewechselt hat, war aber zu schnell um das mit Sicherheit zu sagen. Vielleicht ist die Femon-Anzeige aber auch nicht zeitnah genug, um einzelne UNCs anzuzeigen.


    Habe dann längere Zeit mal über die eine, dann über die andere Karte geschaut und es kam zu keinen weiteren Dekoder-Resets. Irgendwann hat sich der VDR-Server dann an der TT C-1500 festgebissen, d.h. beim Transponderwechsel wurde die TT C-1501 gar nicht mehr genommen, keine Ahnung warum. Habe die Tests dann abgebrochen.


    Verdammt schwer, die Ursache für die Fehler zu tracken.


    Das Einzige, was mir jetzt noch einfällt, wäre, eine Zeitlang nur mit einer DVB-Karte im Server zu arbeiten, um festzustellen, ob evt. eine der Karten das Problem darstellt.


    Hast Du noch eine Idee, was ich ansonsten noch verändern oder loggen könnte, um das Problem einzugrenzen?


    Pete

  • > Ditto. auch ständig BER Werte im 2-stelligen Bereich. UNC aber dauerhaft Null.


    Sagt wenig. Die UNCs sind je nach Treiber nur Augenblickswerte und werden nicht bis zum nächsten Auslesen gesammelt. Es kann gut sein, dass man einen Wert !=0 verpasst. Aber mit vorhandenen BERs (deren Skalierung auch nicht klar ist) ist auf jeden Fall die Wahrscheinlichkeit für einen nicht korrigierbaren Fehler deutlich grösser.


    Weil aber effektiv ein als fehlerhaft markiertes Paket im vdr rausgeworden wird, könnte man den TsError-Teil in remux.c einfach mal auskommentieren, bzw. nur Loggen aber weiter nicht beachten. Damit dürften zumindest von da aus keine Continuity-Fehler her kommen.

  • hi,


    ich habe auch die aktuele beta (10.04) mit testing auf einer partition und grundlegende probleme bei hd sehe ich da nicht, aussetzer mit bildproblemen oder decoder reset sind mir da nicht aufgefallen - aber das dürfte wie real_schorsch schon sagte von der empfangsqualität abhängen (habe nur eine eHD, keinen ntceiver oder eine avg)


    gravierende probleme habe ich nur gelegentlich bei 576i (nutze wegen der bildqualität source resolution) aber das scheint ein spezielles problem meiner eHD oder zwischen eHD und dem sony tv zu sein, 720p und 1080i laufen immer anstandslos und das 576i problem verschwindet meist nach 1/2 h ganz

  • Zitat

    Original von HTPC-Schrauber
    Hmm, Fehler solls bei Beta-Software ja manchmal geben :lol2


    Absolut Richtig, wäre nicht.


    Zitat

    Die grundlegende Ursache zu ändern, ist IMO nicht möglich. Micronas gibts nicht mehr, der Decoder selbst läuft zu grossen Teilen in der HW, ein kleiner Teil ist zwar FW für den zweiten MIPS, aber die war nie öffentlich. RMM hat zwar noch ein paar non-public-Infos zu diversen Registern (damit waren noch Sachen wie Gamma-Einstellungen oder SPDIF-Statusbits-Bugs zu fixen), zu den Interna des Decoders gibts gar nichts.


    Das schreit ja geradezu nach neuer Hardware, die Spatzen zwitschern das RMM in nächster Zeit zu diesem Thema etwas konkreter wird.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!