Beiträge von Fourty2

    Hmm,


    MPEG2 oder MPEG4?

    Schnellvorlauf nutze ich selten, per 1/3 und grün/gelb funktioniert ja alles.

    Das dürfte derselbe (vermutlich) fehlende Re-Init des Decoders sein - irgendwie ist da der Wurm drin... ;)


    Edit:

    Habe mal ein MPEG4, VDR 2.4, 576i (vom Himmel) getestet... funktioniert.
    Also vermutlich eher ein MPEG2 Problem.


    Eventuell habe ich das aber schon gestern behoben (das A/V-Diff steigt und steigt...):


    Stefan

    Leider behebt der Patch (noch) nicht alle Probleme, die seit der "Code-Bereinigung" aufgetreten sind.


    Falls Du noch pre VDR-2.x Aufnahmen hast... besser nicht abspielen.


    Startwert waren ca. 500 ms Diff...

    Jun 29 23:49:48 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=1996,68 ms, vClk 10:37:17.827 - aClk 10:37:15.831)

    Jun 29 23:51:26 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=2316,97 ms, vClk 10:38:56.387 - aClk 10:38:54.070)

    Jun 29 23:55:01 roadrunner vdr: [5234] VAAPI: video: slow down video, duping frame (/\=2716,92 ms, vClk 10:42:31.507 - aClk 10:42:28.790)


    Das RpiHDDevice spielt diese Aufnahme problemfrei und AV-synchron ab.

    Auch auf z.B. EuroNews hab ich noch seltsame Klötzchen-Störungen.

    :-(

    Grüße,

    Stefan

    Habe mir das Verhalten nochmal angesehen:

    Offenbar scheitert das Abspielen, sobald, etwa nach Umschalten, das


    "VAAPI: video/vaapi: synced after <xx> frames"


    vorbei ist. Startet man die Aufnahme per Back/Ok und erwischt die Sync-Phase des TV-Bilds darunter, wird abgespielt.


    Teste mal dies:



    Oder als Komplett-Patch anbei.


    Stefan

    Also...

    Schärfen geht bei mir auch nicht (stehendbleibendes Geisterbild). Hatte ich mal als Bug gemeldet...


    Farbkalibrierung hat mein Spyder gemacht - kümmert sich der XServer per Argyll (o.s.ä.) drum. Kann ich also nichts zu sagen - ist alles aus hier.


    Zum Abspielproblem:
    Hab' mal 'ne Mutex verschoben - dann läuft meine Testaufnahme zuverlässig mit Ton an.


    Audio-Fix


    Oder hier nochmal komplett mit:
    - Audio Mutex-Fix

    - 33 Bit PTS Rollover Fix (26:30:00.000 -> 0:00:00.000 macht keine Bildfehler)

    - Anderer Sync-Mittelwertbildung (die alte Methode tut's eigentlich auch... ;) )

    speedupdown.patch.gz


    Wenn die Zeiten im Log stören:

    +// err = VaapiMessage(1, "video: speed up video, droping frame(s)");

    + Info("video: speed up video, droping frame (/\\=%.2f ms, vClk %s - aClk %s)",diff*1000/(double)90000, Timestamp2String(video_clock), Timestamp2String(audio_clock));


    durch

    + err = VaapiMessage(1, "video: speed up video, droping frame(s)");

    +// Info("video: speed up video, droping frame (/\\=%.2f ms, vClk %s - aClk %s)",diff*1000/(double)90000, Timestamp2String(video_clock), Timestamp2String(audio_clock));


    bei den Infos() ersetzen. Nur Debug-Output...


    Stefan

    Jo, fein..


    Man kann das Verhalten auch bei Live-TV (einfach x-mal umschalten) provozieren. Dann hat man tonloses Live-TV mit "1 TS packet(s) not accepted in Transfer Mode" und Bild, nach 8s ein kurzes Einfrieren, danach geht es dann allerdings mit normalem Softstart-Sync und Ton weiter (hier auch bei ARD HD -> ZDF HD möglich).


    Also ein eher "allgemeines" Problem, so in etwa, als ob der berechnete Ton-PTS-Sync Zeitpunkt schon "Geschichte" ist.


    Stefan

    Und nachdem's nun funktioniert, fällt mir auf, dass meistens beim Start einer Aufnahme der Ton stumm bleibt. Erst nach dem Umschalten auf eine andere Tonspur spricht der VDR. Hat jemand Erfahrung? Was muss ich machen?



    Das war einer von den drei Punkten, weshalb ich mich an den Patch gemacht habe. Leider ist die Ursache eine (noch unbekannte) Andere.

    Workaround ist Abspielen, falls ohne Ton (und Auto-Stop nach ca. 8 sec) dann -> Back/Exit -> Ok.. (wieder abspielen)

    Ab und an erwischt das Vaapidevice dann die falsche Halbbildfolge (=Zittern), dann halt nochmal Back -> Ok...


    Mit Audio-Debug sieht das "Tonlos" so aus:


    Also, falls jemand eine Idee hat, her damit...

    Den Filmschnipsel kann ich gerne zur Verfügung stellen - zuverlässig tonlos ab Startpunkt "0"


    Grüße,

    Stefan

    Nur zur Info:

    Das Dauer-Frame-Duping kann ich bei mir auch aktivieren, wenn Softstart aus ist...


    Code
    1. Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=102,18 ms, vClk 19:02:30.469 - aClk 19:02:30.358)
    2. Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=98,94 ms, vClk 19:02:30.469 - aClk 19:02:30.380)
    3. Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=102,03 ms, vClk 19:02:30.509 - aClk 19:02:30.398)
    4. Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=98,81 ms, vClk 19:02:30.509 - aClk 19:02:30.420)
    5. Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=101,97 ms, vClk 19:02:30.549 - aClk 19:02:30.438)
    6. [..]


    Da ist also was im Sync-Code falsch. Bzw., es erfolgt nie eine vollständige Synchronisation.


    Habe dann auch "+89", wie im Ursprungsposting
    VAAPI: video: 19:02:28.829 +89 438 0/\ms 19+5 v-buf


    statt z.B.,

    VAAPI: video: 19:17:17.909 +6 331 0/\ms 20+3 v-buf
    (mit Softstart und Patch)


    Stefan

    Hmm, läuft hier (mit einem ähnlichen Patch, andere Mittelwertbildung, bringt aber nix).



    Sieht mir irgendwie so aus, als wenn die Zeitdifferenz zwischen Audio und Video schneller auseinanderläuft , als er Frames wegwerfen kann.

    Nur warum?


    Stefan

    Hi,


    da ist im Syncdecoder (und vermutlich noch an anderen Stellen) was kaputtgespielt.


    Bei mir (aktueller GIT-Stand) zeigte sich das Problem aber eher beim Abspielen von Aufnahmen, Live-TV war ok. Bei Aufnahmen hatte ich was a la 25i, wenn er mit etwas Glück beim richtigen Halbbild loslief und der Audio-Sync einrastet.


    Vielleicht hilft dies:

    https://github.com/pesintta/vd…8359/speedupdown.patch.gz


    Grüß

    Stefan

    Tja, eben. ;-)

    Meist wird nicht bedacht, das ein "Überspannungsereignis" das lokale Erdpotential "ein wenig" anhebt, während der Hausanschluß (Strom (nur die 3 Phasen... ) / Tel. o. xDSL / ..) auf Fernpotential bleibt. Und hin ist die schöne Technik.

    Ganz besonders, wenn in der Nähe z.B. eine WKA Blitzableiter spielt. Nachdem unser Hausanschluß und TK eingehend geschützt waren (irgendwas um EUR 600,- Anno 2004), hatten dann halt nur noch die Nachbarn E-Schrott - und wir bisweilen ein heftiges "Klong" im Anschlußraum..

    Daher:
    Die 20 m oben machen trotz "nasser Erde" ausreichend mehr Potentialdifferenz für die arme Netztechnik als per Kupfer erheblich niederohmiger verbunden - daher der dicke PE-Leiter.


    Stefan

    Nur der Vollständigkeit halber:
    Man kann dies durchaus per Kupfer realisieren. Dann muß man natürlich auf den Potentialausgleich achten (sowie die Strecken und ggf. gleich zusätzlich den Hausanschluß mit Ableitern schützen).


    Die knapp 80m Strecke, die seit ca. 2006 bei einem Kunden zwischen Büro- und Privathaus (unterirdisch) liegt, führt daher eine 16 mm² Erde mit, die die Potentialausgleichsschienen der Gebäude niederohmig verbindet. Bisher immer problemfrei - sowohl bei LAN wie ISDN.


    Stefan

    Hallo,


    mußte sowas in den epg2vdr (und entsprechendes in scraper2vdr) patchen

    Code
    1. cUpdate::cUpdate(cPluginEPG2VDR* aPlugin)
    2. : cThread("epg2vdr-update")
    3. @@ -264,6 +264,8 @@
    4. {
    5. int status = success;
    6. + sleep(30);
    7. +
    8. if (!connection)
    9. connection = new cDbConnection();

    damit der VDR mit laufenden Aufnahmen (falls mal keine Daten vom CAM kommen) in keiner Restart-Schleife hängen bleibt.

    Denke, die Aufnahmenliste im scraper bleibt zu lange gelockt. Immer wenn das gute Stück nicht auf die Fernbedienung reagiert, ist epg2vdr/scraper2vdr beschäftigt. Leider hab ich so adhoc keinen Weg gefunden, die Aufnahmen-Liste nur Scrap-für-Scrap zu locken. Insbesondere bei vielen Aufnahmen und / oder langsamen SQL-Servern geht das dann schief.


    Stefan

    Hallo zusammen,


    wo wir gerade dabei sind:

    Wäre es mit Vaapidevice / ALSA möglich, den AC3/PCM Ton auf HDMI und gleichzeitig ein 2-Kanal Downmix (oder halt auch 2xPCM bei Stereo-Quelle) auf S/PDIF zu schaufeln?

    Das wäre die Ideallösung für die Hörgeschädigte im Haushalt - dann wäre der Rest des Bluetooth-LL-Delays zum Haupton auch noch verschwunden. :-)


    Grüße,

    Stefan

    Bitrate kostet Geld. CD-nahe Quali ist mit AAC LC machbar, das hängt von der Sendestation ab

    Das ist natürlich insbesondere bei unserer Zwangs-Pensionskasse mit angehängtem Sendebetrieb bei 8 Mrd € / Jahr Etat Argument Nr. 1.


    Dürfen schon, brauchen nur nicht.

    Digitale Modulationen wie DVB-T/T2 oder DAB(+) nutzen mehrere Sender im Gleichwellennetz. UKW kann das nicht und muss mit mehr Pegel störende Nachbarsender wegdrücken. Und ebenso brauchen DAB - Empfänger weniger Signal als eine UKW Ausstrahlung.

    Nun, wir sehen ja, wie aus der ehemaligen 99% Abdeckung mit UKW und analogem VHF/UHF TV schon mit DVB-T1 ein Flickenteppich entstand, der bei DAB([.+]) ebenso vorhanden ist.


    Offenbar reicht die Leistung eben *nicht*.


    Und - vielleicht liegts am Alter - ich sehe auch nicht ein, warum ich einen Radio-Stream für Hintergrundberieselung durch die IP-Leitung prügeln soll (nein, keine Sorge 100 MBit Downstream), den ich erst mühsam aus dem unüberschaubaren Angebot fischen soll. Irgendwas nervt da doch immer.


    Daher läuft hier stationär "der eigene Sender", direkt per Bitstream an die Verstärker, in FLAC Qualtität. Und der ist auch, wie UKW ganz ohne externe Anbindung verfügbar. Nur Strom braucht er.


    Bis 1993(?) ging es hier vor Ort zwar auch mit etwa einer Dachrinne (1593 kHz, 800 kW EIRP), aber da war die Senderwahl irgendwie blöd - da war UKW schon besser. ;)


    Stefan