Posts by kls

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.

Mit

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

entsteht

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:

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".

SHF wrote:

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

Doch, haben sie. Aber anscheinend reicht das nicht:

mini73 wrote:

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 ;-).

wirbel wrote:

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:

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.

FireFly wrote:

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?

FireFly wrote:

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.

HelmutB wrote:

Da durch DetachAllReceivers() alle Receiver auf "NULL" gesetzt werden, ist hier ein Lock auf die Receiverliste vermutlich auch nicht so wichtig.

Der mutexReceiver schützt die Liste der Receiver des Devices, sollte also bei jedem Zugriff gelockt werden. Den Lock in DetachAllReceivers() wegzulassen fühlt sich irgendwie nicht richtig an. Was wäre z.B. wenn die Schleife receiver[i] "nimmt" und bevor sie Detach() damit aufrufen kann von anderer Stelle ein explizites Detach() mit diesem Receiver gemacht (und der Receiver gelöscht) wird? Ich weiß nicht, wie wahrscheinlich dieses und andere Szenarien sind, aber den Lock hier wegzulassen würde mir Bauchschmerzen machen...

jojo61 wrote:

Leider werden dadurch die Umschaltzeiten eher länger.

Also bei mir (DVB-S mit softhddevice) geht das Umschalten absolut flott.

zillerbaer wrote:

Es kommen bei Wiedergabe regelmässig unvollständige Packete:

Das Längenfeld im PES-Header ist 16 Bit groß, ein PES-Paket kann also maximal 65535 Byte lang sein. Wenn längere Pakete (ohne Läagenangabe) kommen, dann teilt VDR sie in Pakete mit maximal dieser Größe auf, damit sich das Ausgabedevice auf das Längenfeld verlassen kann.

Wenn du magst, kannst du ja mal *cTsToPes::GetPes() so ändern, dass es ein PES-Paket mit leerem Längenfeld (!PesHasLength(data)) komplett zurückgibt. Der Parameter &Length ist ja 'int' und kann das verkraften. Die Frage ist halt, ob alle Ausgabedevices mit PES-Paketen ohne Längenangabe zurecht kommen.

zillerbaer wrote:

Ja, bei live TV, Aufnahme Wiedergabe, Pause in Widergabe, etc..

Bei "Pause in Wiedergabe" wird lediglich dem Device gesagt, dass es "anhalten" soll. Die Daten werden ohne besondere Behandlung geschickt, sie sollten also beim Device mit oder ohne Pause genau gleich ankommen.

Bei "live TV" wird das, was vom Sender kommt, sofort und ohne weitere Behandlung an das Ausgabedevice geschickt, auch um möglichst schnelle Umschaltzeiten zu erhalten.

Bei der Wiedergabe einer Aufnahme sollte es eigentlich immer mit einem I-Frame losgehen, denn die Aufnahme startet ja erst bei einem I-Frame. Vorher kommt allerdings immer eine PAT/PMT - vielleicht meinst du das?

jojo61 wrote:

Wenn ich nun zum 1. Springe läuft der Film dort normal los. Wenn ich aber zum 2. Springe dann läuft der Film los und springt sofort zum 3. Schnittpunkt weil er ja die "rausgeschnittenen" Teile bei der wiedergabe überspringt. Das passiert nur mit deinem Patch weil er ohne den Patch ja schon nach dem Schnittpunkt losläuft und deswegen gar nicht bemerkt das er springen müsste.

Das verhält sich bei mir auch so, aber unabhängig von diesem Patch. Wenn "Setup/Replay/Pause replay when jumping to a mark" auf "no" steht und "Skip edited parts" auf "yes", dann verhält es sich so - auch schon vorher.

FireFly wrote:

Ich habe nur keine Idee, wie man die Daten aus cH264Parser in die Info Datei bringen kann ....

Das kann ich gerne machen. Zeig mir einfach im Code, wo die Info anfällt.

zillerbaer wrote:

Wenn PlayVideo das erste Mal nach Playmode == 0 aufgerufen wird, kommt regelmässig kein I-Frame.

Falls der Fix vdr-2-6-0-fix-dvbplayer-diff dieses Problem nicht behebt, kannst du mir bitte sagen, was genau ich tun muss, um es zu reproduzieren?

zillerbaer wrote:

Unschön ist auch das grosse Packete in Teilen kommen.

PlayVideo() sollte eigentlich immer vollständige PES-Pakete bekommen. Wann ist das denn nicht der Fall?

Ich habe das jetzt mit softhddevice probiert und kann auch bestätigen, dass mit dieser Änderung die Wiedergabe nach dem Anspringen einer Schnittmarke sauber an exakt dieser Stelle losläuft. Vorher war es tatsächlich so, dass teilweise der Ton schon lief und das Bild eine zeitlang stillstand, oder das Bild sofort weiter nach hinten sprang. Ich gehe also davon aus, dass diese Änderung richtig und wichtig ist und auch auf allen Devices positiv wirken dürfte.

jojo61 wrote:

Nur nun tritt ein anderes Problem auf: An einigen Schnittmarken läuft der Stream dann nicht ab der Schnittmarke los an der er steht sondern an der nächsten Schnittmarke.

Das konnte ich nicht nachvollziehen. Kannst du ein Testbeispiel zur Verfügung stellen, bei dem das auftritt?

Anbei der Fix als Diff.

Vielleicht liegt da ja tatsächlich noch ein Problem, das bisher halt nur niemandem aufgefallen ist bzw. niemanden gestört hat.

jojo61 : probier bitte mal, ob mein Vorschlag bei dir was bewirkt, und ich teste das morgen mit softhddevice.

Sagen wir mal so: es funktioniert, mehr wollte ich nicht ;-).