Posts by kls

    ttxtsubslivereceiver.h:35:22: error: by 'virtual void cTtxtSubsLiveReceiver::Receive(uchar*, int)' [-Werror=overloaded-virtual]
    35 | virtual void Receive(uchar *Data, int Length);
    | ^~~~~~~

    Mach mal ein 'const' vor 'uchar', also


    virtual void Receive(const uchar *Data, int Length);

    Statt 'Channels.' muss es jetzt so aussehen:

    Code
    1. LOCK_CHANNELS_READ;
    2. ...
    3. ...Channels->...

    Wurde beides in VDR 2.3.1. geändert.

    Eigentlich sollte VDR die CAMs der Reihe nach probieren, bis eines entschlüsselt, und sich das dann selber in der cam.data merken.

    Was passiert denn, wenn du deine vorhande cam.data mal löscht, beide CAMs einsteckst und auf ORF schaltest und dann einige Minuten wartest?

    MarkusE : beim zweiten hunk deines Patchs fehlen die Klammern.


    Im Fehlerfall 'last = -1' zu setzen ist sicher sinnvoll. Zusätzlich würde ich noch 'size = 0' setzen, damit alles zusammenpasst.


    Anbei ein Patch, der auch noch in cIndexFile::GetClosestIFrame() 'index' abfragt.

    Inzwischen habe ich herausgefunden, dass das Ergebnis wesentlich besser wird, wenn man hdrgen eine *.hdr-Datei (und nicht direkt *.tif) erzeugen lässt, und diese dann mit 'convert' in TIFF konvertiert. Ich werde noch ein wenig mit den stonits experimentieren und dann ggf. weitere Erkenntnisse hier posten.

    Ich habe jetzt mal neue Fotos (bei Sonnenschein) gemacht, den Rand weggeschnitten und mit


    ./hdrgen -F -a -r picam.rsp -o hdr.tif -s 3 cldr--6.jpg -s 2 cldr-0.jpg -s 1 cldr-6.jpg


    ohne existierende rsp-Datei folgende "picam.rsp" erhalten:

    Code
    1. 3 1.35139 -1.73392 1.30848 0.0740541
    2. 3 1.41096 -1.79354 1.35062 0.0319624
    3. 3 1.52995 -1.90005 1.34595 0.0241512

    Als stonit-Werte habe ich 3, 2 und 1 genommen, da ja jeweils ein f-Stop Unterschied zwischen den Fotos ist (wenn ich das richtig sehe).

    Das Resultat sieht gar nicht mal so übel aus, ist aber leider ziemlich "blass".

    Haben die jpeg-Dateien wirklich keine Exif-Info integriert?

    Doch, haben sie. Aber anscheinend reicht das nicht:

    Würdest du diese .gitignore Datei in dein Repository aufnehmen?

    Ich glaube, das Thema hatten wir schon mal (ich finde aber leider das Posting nicht mehr - vielleicht war es auch auf der VDR-ML).

    Erstens mag ich keine Dot-Files verwalten, und zweitens hat da dann sicher jeder einen Vorschlag, was da noch alles rein soll ;-).

    Soweit die manpage verständlich ist, wäre der Weg zur korrekten rsp Datei, eine nicht existierende anzugeben, welche das Programm dann dort selbst ablegt (d.h. wenn alle anderen Optionen stimmen).

    Drei Fotos haben anscheinend nicht gereicht. Ich habe es jetzt mal mit 5 Fotos (ev -12, -6, 0, +6, +12) probiert und da hat er eine rsp-Datei erzeugt:

    Code
    1. 1 0.906286 0.0937142
    2. 1 0.921759 0.0782411
    3. 1 0.916837 0.0831626

    Der Aufruf


    ./hdrgen -a -r picam.rsp -o hdr.tif -s 8 hdr--12.jpg -s 6 hdr--6.jpg -s 4 hdr-0.jpg -s 2 hdr-6.jpg -s 1 hdr-12.jpg


    erzeugte dann auch ein Bild, das aber nicht wirklich nach HDR aussieht. Ich hänge mal einen Screenshot der Quell-Fotos und des Resultats an. Vielleicht erkennt ja jemand, was da noch im Argen liegen kann.

    Nach längerer Zeit komme ich endlich mal wieder dazu, mich mit diesem Thema zu beschäftigen.

    Mit den rsp-Daten aus #8 (danke wirbel ) als "picam.rsp" abgespeichert bekomme ich mit drei Jpeg-Dateien, aufgenommen mit ev -6, 0, +6 bei


    ./hdrgen -a -r picam.rsp -o hdr.tif hdr--6.jpg hdr-0.jpg hdr-6.jpg


    die Meldung "hdr--6.jpg: needs exposure calibration [...] Failure generating HDR image"

    Ich muss vor den Dateinamen der Jpegs jeweils eine Option "-s stonits" angeben, etwa


    ./hdrgen -a -r picam.rsp -o hdr.tif -s 0.8 hdr--6.jpg -s 0.4 hdr-0.jpg -s 0.2 hdr-6.jpg


    Damit wird eine Ausgabedatei erzeugt, die aber weit davon entfernt ist "HDR" zu sein.

    Das liegt wohl daran, dass (offensichtlich) die rsp-Daten ja nicht zur Kamera des RasPi passen (ich verwende die 12.3MP Kamera mit IMX477 Sensor) und ich keine Ahnung habe, welche Werte für die "stonits" zu verwenden sind. Die Doku (siehe Link in #8) sagt dazu nur "simply pick a value for the brightest image, and increase it subsequently for each exposure in the sequence. One f-stop requires doubling this conversion factor, and two f-stops requires quadrupling".

    Im Web habe ich leider keine rsp-Daten für die verwendete Kamera gefunden, und auch keine weiteren Hinweise, welche Werte für die "stonits" passen.


    Weiß hier vielleicht jemand näheres dazu?

    'childTid' ist zu diesem Zeitpunkt u.U. noch nicht gesetzt, daher wird der Thread wohl keine Resourcen freigeben.

    Ausserdem ist StartThread() 'static' und hat daher keinen Zugriff auf ein 'childTid'. Wenn, dann müsste es wohl 'Thread->childTid' heissen, aber das ist, wie gesagt, zu diesem Zeitpunkt womöglich noch nicht gesetzt.


    Ich muss gestehen, dass mir der Unterschied zwischen 'childTid' und 'childThreadId' jetzt auch nicht so ganz klar ist.

    Das mit der Übergabe an die RecordingInfo mach ich dann schon.


    Nachdem es ein cH264Parser::ParseSequenceParameterSet() gibt spricht natürlich nichts dagegen, das entsprechend auch für cH265Parser einzubauen.

    Außerdem gibt's in cFrameParser zwei Funktionen zur Abfrage. Die könnte man in cFrameDetector nutzen wenn framesPerSecond gesetzt wird, da offenbar die Auflösung immer vor der Framerate bestimmt wird.

    Das verstehe ich nicht. Was hat die Auflösung mit der Framerate zu tun?

    Da für H.265 ein zusätzlicher SPS Parser notwendig ist würde ich gerne wissen, ob das aufgenommen wird bevor ich das umsonst programmiere.

    Na ja, wenn wir das Speichern der Auflösung einbauen, dann für alle unterstützten Formate. Ich hoffe mal, dass das nicht zu viel zusätzlicher Code wird. Einen cH265Parser gibt es ja bereits - ist die Auflösung bei H265 wirklich so gut "versteckt"?

    Fürs Protokoll: falls ich das einbaue, wird es nur für Aufnahmen geschehen, nicht für Live-TV. Bei Live-TV wird der Datenstrom vom Empfangsdevice zum Wiedergabedevice einfach "durchgereicht", ohne groß in die Daten reinzuschauen. Ausgabedevices werden also auf jeden Fall diese Info selber extrahieren können müssen, falls sie sie benötigen.