Beiträge von Fourty2

    Würde für die Entwicklung ja erst mal reichen. Https im Proxy aufbrechen (Dummy-Zertifikat usw.) ist auch nicht so einfach.


    Ach, so kompliziert ist das nicht. Und man kann dann per elsquid Werbung filtern.

    Code
    1. ==> /var/log/squid/access.log <==Oct 3 08:43:03 40192 192.168.1.3 TCP_MISS/200 438 GET https://256-trouter-neu-b.drip.trouter.skype.com/socket.io/1/xhr-polling/225bb2dd461afe1b-42874fa8c1561374? - HIER_DIRECT/168.63.43.207 text/plainOct 3 08:43:09 146 192.168.1.3 NONE/200 0 CONNECT www.vdr-portal.de:443 - HIER_DIRECT/85.93.89.140 -Oct 3 08:43:10 141 192.168.1.3 NONE/200 0 CONNECT www.vdr-portal.de:443 - HIER_DIRECT/85.93.89.140 -Oct 3 08:43:10 303 192.168.1.3 TCP_MISS/200 1454 POST https://www.vdr-portal.de/index.php? - HIER_DIRECT/85.93.89.140 application/jsonOct 3 08:43:10 500 192.168.1.3 TCP_MISS/200 21766 GET https://www.vdr-portal.de/forum/index.php? - HIER_DIRECT/85.93.89.140 text/htmlOct 3 08:43:10 240 192.168.1.3 TCP_INM_HIT/304 290 GET https://www.vdr-portal.de/images/styleLogo-296c03f7c3faa38016f25bc8475f2bb67fc15e55.gif - HIER_NONE/- image/gif



    Stichworte: "Squid SSL-Bump", z.B.
    https://wiki.squid-cache.org/C…Intercept/SslBumpExplicit

    Man muß den Squid nur mit

    --enable-ssl \

    --enable-ssl-crtd \

    --with-openssl \


    übersetzen, sowie ein CA-Cert erzeugen, das man dann den Intranet Browsern als gültige CA mitteilt.

    Dann braucht die squid.conf noch sowas in der Art:



    In nobumpSites.txt dann Seiten, die früher per https gesichert worden wären: Banken, Elster und Co.
    In BrokenTrustedSites.txt kaputte Seiten (Zertifikat abgelaufen / Ketten defekt..), wie das Portal hier - sonst verbietet der Proxy den Zugriff.


    Ganz "Kaputtes", aka gepinnte Certs kann man per z.B. proxy.pac über den extra "nobump" Port routen, falls man ohne proxy keinen Netzzugriff erlauben will.


    Grüße,

    42

    Und der patch dazu:

    Diff
    1. --- a/lib/curl.c
    2. +++ b/lib/curl.c
    3. @@ -120,7 +120,7 @@
    4. curl_easy_setopt(handle, CURLOPT_TIMEOUT, 30); // Set timeout
    5. curl_easy_setopt(handle, CURLOPT_NOBODY, 0); //
    6. curl_easy_setopt(handle, CURLOPT_USERAGENT, CURL_USERAGENT); // Some servers don't like requests
    7. -
    8. + curl_easy_setopt(handle, CURLOPT_ACCEPT_ENCODING, "");
    9. return success;
    10. }


    Stefan

    Ja.

    Ist kein SSL sondern ein "GZIP Problem"...



    Wenn man mirrors.xml ungzipped, sieht sie gut aus.
    Problem: Wie sag ich es curl...

    Stefan

    Hallo zusammen,


    hab da gerade ein neues Problem beim Start des epgd. Und zwar kann er sich nicht mit dem TVDB Scraper verbinden. Laut zwischen geschaltenem Squid ruft er die mirrors.xml ab. Mag diese aber nicht parsen:

    Code
    1. noname.xml:1: parser error : Start tag expected, '<' not found▒^


    Hab die Datei mal per wget abgerufen. mc kann sie parsen und zeigt den Inhalt korrekt an, aber die Datei hat ein eigenwilliges Format (siehe Anhang).


    Im mc betrachtet:

    XML
    1. <?xml version="1.0" encoding="UTF-8" ?>
    2.    <Mirrors>
    3.       <Mirror>
    4.          <id>1</id>
    5.          <mirrorpath>http://thetvdb.com</mirrorpath>
    6.          <typemask>7</typemask>
    7.       </Mirror>
    8.    </Mirrors>



    Jemand eine Idee?


    Grüße,

    Stefan

    Dateien

    • mirrors.zip

      (267 Byte, 13 Mal heruntergeladen, zuletzt: )

    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