Posts by kfb77

Das ist wohl Folge von diesem Commit.

Vermutlich muss in Live von #if auf #ifdef geändert werden.

Richtig, es geht hier nicht um Cookies.

Es geht um die Erhebung/Verarbeitung/Speicherung von personenbezogener Daten. Das ist wie gesagt schon die IP Adresse. Und ein Token auf dem Rechner zu hinterlassen, um ihn zukünftig eindeutig zu identifizieren, ist das auch. Das ist im Opensource Umfeld nicht gerne gesehen, rechtlich aber durchaus möglich, wenn die aktuell geltenden Vorschriften einhalten werden. Und wie hier schon gepostet wurde, musst du da absolut wasserdicht sein. Auf dieses Eis würde ich nicht gehen.

Du zitiert aus meinem Post #24 "Broser Einstellungen" und stellst dar, dass VDR kein Browser ist.

Das war nie meine Aussage. In dem Post #24 zeigte ich eine vielleicht zukünftige Verbesserung der in deinem Post #22 angesprochenen Cookie Dialog der Web Seiten an.

Der Post hatte an keiner Stelle einen Bezug zu VDR.

Das hast du jetzt aber aus dem Kontext geholt. Die zitiert auf meine Antwort zu diesem Post von dir:

Quote from kls

Weswegen inzwischen so gut wie jede Webseite erstmal einen (oft bildfüllenden) "Cookie-Dialog" einblendet, über den man entweder einfach alles akzeptieren kann, oder aufwendig bestimmen kann, ob und welche Cookies man zulässt. Als Reaktion darauf haben dann vermutlich die meisten eine Software installiert, die diese Banner automatisch beantwortet. Das Blöde ist ja, dass, wenn man alle Cookies ablehnt, das Banner bei jedem neuen Besuch wieder kommt, denn ohne Cookie kann sich die Webseite ja nicht merken, dass dieser Benutzer keine Cookies will ;-).

Quote from kls

Weswegen inzwischen so gut wie jede Webseite erstmal einen (oft bildfüllenden) "Cookie-Dialog" einblendet, über den man entweder einfach alles akzeptieren kann, oder aufwendig bestimmen kann, ob und welche Cookies man zulässt.

Das wird irgendwann zukünftig besser werden: Der aktuelle Entwurf der EU ePrivacy-VO sieht vor, dass eine grundsätzliche Zustimmung/Ablehnung in den Browser Einstellungen möglich sein muss. Das ist aber bis jetzt weder verabschiedet, noch technisch umgesetzt.

Quote from kls

das meinetwegen gerne auch nur nach opt-in

Das wäre die Mindestvoraussetzung um DSGVO konform zu sein.

Edit: Das gilt natürlich für die gesamte Funktion, weil das Token, dass du ablegen willst, entspricht technisch einem Cookie. Auch das erfordert nach DSGVO, wenn es funktional nicht zwingend notwendig ist, eine aktive Zustimmung des Nutzers.

Ich zitiere mal von hier.

In einem Urteil des Europäischen Gerichtshofs (EuGH) aus dem Jahr 2016 (Az. C-582/14) entschieden die Richter, dass sowohl statische als auch dynamische IP-Adressen zu den personenbezogenen Daten zählen. 

Eine IP-Adresse kann zu einer Person zurückverfolgt werden. Aus diesem Grund spielt hier die Datenschutzgrundverordnung (DSGVO) eine entscheidende Rolle bei der Verarbeitung von IP-Adressen. Denn personenbezogene Daten dürfen Webseitenbetreiber nur erheben, verarbeiten oder speichern, wenn dies notwendig ist.

Quote from kls

Das würde die Teilnehmerzahl aber deutlich verringern, da wieder jeder selber aktiv werden müsste.

Was hat den höheren Wert ? Schutz von persönlichen Daten, oder eine korrekte Nutzerstatistik ?

Ich finde das keine gute Idee, Programme sollten nicht nach Hause telefonieren, wenn es funktional nicht zwingend benötigt wird.

Habe ich nie ausprobiert, ich versuche immer sinnvolle Werte zu verwenden, selbst wenn es heute geht, weiß man ja nie, was nach dem nächsten FFmpeg Update passiert.

Ich finde den Vorschlag von zillerbaer gut: sende doch einfach das gleiche Packet so lange zum Decoder, bis du das Frame zurück bekommst.

Das war ja mein 2. Vorschlag. Denke aber dran, dass damit diese Decoder Instanz keine weitete Pakete mehr annimmt.

"the decoder has been flushed, and no new packets can be sent to it (also returned if more than 1 flush packet is sent)"

Jeder Wert muss größer sein, als der zuvor. Üblicherweise ist der DTS Abstand im Video Stream gleich avpkt->duration.

DTS hast du auch angepasst ? Muss streng monoton steigend und vor PTS sein.

Das bedeutet dann, dass alle Plugins ihre Makefiles anpassen müssen.

don't fix it if it's not broken

Quote from rell

Wenn vom VDR nur I-Frames kommen, dürfte doch jedes avpkt, das ich an ffmpeg schicke, keine Referenzen für ein fertiges frame benötigen?

Richtig. Aber der Decoder weiß ja nicht, dass du nur I-Frame schicken willst und hält diese zurück, weil ja noch B-Frames kommen könnten, die ein PTS vor dem I-Frame haben. Erst wenn der PTS Abstand zu groß wird, in deinem Fall wohl 3 I-Frames (wie auch immer der Decoder entscheidet, wann das der Fall ist), gibt er dir das älteste I-Frame zurück.

Quote from rell

Hier ist es jetzt so, dass das erste Frame erst geholt werden kann, wenn 3 Aufrufe von avcodec_send_packet geschickt wurden.

Ist bei H.264 notwendig, weil es B-Frames geben kann, die vor das letzte I-Frame verweisen. Bei MPGEG2 gibt es die nicht.

Quote from rell

Allerdings kommt nicht das Frame zurück, das zuerst geschickt wurde, sondern das mit dem kleinsten pts.

Ist normal. Aufgabe des Decoders ist es, die Decoding Reihenfolge in die Darstellungsreihenfolge umzusortieren. Also kleines PTS zuerst. An Rückwärts abspielen hat da wohl keiner gedacht. Interessant, dass das den MPG2 Decoder nicht interessiert. Vermutlich weil er eh nicht umsortieren muss.

Ich kenne kein Flag, das dem Decoder sagen kann, er soll rückwärts die Daten hergeben.

Ich sehe da nur zwei (wilde) Ansätze:

- Entweder du baust vor dem Decodieren die PTS/DTS so um, dass es für den Decoder so aussieht, als ob er vorwärts decodiert.

- Oder du flashed nach jedem Frame die Decoder Queue (av_send_packet(..., nullptr). Danach muss du aber den Decoder neu initialisieren.

Das nächste Problem wird H.264 interlaced werden, mir ist es in markad nicht gelungen, da nur I-Frames zu dekodieren. Wenn du nur die die Pakete decodierst, die das Key Flag gesetzt haben, bekommst du nur Halbbilder.

wmautner war doch im richtigen Thread mit seinem Problem:

Ich habe seine Aufnahme runtergeladen und kann das Problem reproduzieren. Aber nicht nur mit der von markad geschnitten Aufnahme, sondern auch mit der originalen 00001.ts.

Getestet mit den FFmpeg Parametern aus seinen Log File (zusätzlich: -y -loglevel verbose):

 ffmpeg -y -loglevel verbose -hide_banner -fflags +igndts+genpts -hwaccel cuvid -hwaccel_output_format cuda -c:v:0 mpeg2_cuvid -i "/media/Video/VDR/Archiv_5/Forensik_–_Der_Schlüssel_zur_Wahrheit/2024-10-06.22.03.19-0.rec/00001.ts" -map 0:v:0 -map 0:1 -map 0:2 -c:v:0 hevc_nvenc -preset medium -profile:v:0 main -rc vbr -cq 36 -g 50 -c:1 libfdk_aac -b:1 96k -c:2 libfdk_aac -b:2 96k -mpegts_flags system_b -map_chapters -1 -metadata service_name=vdr-transcode_hevc_nvenc "/media/Video/VDR/Archiv_5/Forensik_–_Der_Schlüssel_zur_Wahrheit/2024-10-06.22.03.19-0.rec/ffmeg.ts"

Ausgabe siehe Log File.

log.txt

Log File vom Test mit aktuellen FFmpeg git master. Mit FFmpeg 6.1.2 funktionieren beide Dateien, 00001.ts und markad Schnitt.

Mit meiner SD Test Aufnahme von DVB-S funktioniert es mit mit beiden FFmpeg Versionen und mit beiden Dateien.

Das ist entweder ein Bug im aktuellen FFmpeg (oder das aktuelle will andere Parameter haben, da ist auch was von "deprecated" drin im Log File, aber Audio), oder ein Bug im DVB-C Stream. Auf jeden Fall ist markad da raus, da es ja mit der originalen VDR TS auch nicht funktioniert.

Nehme ich gerne für meine Test Sammlung, falls da doch was anders ist, wie bei DVB-S.

Über was hast du das aufgezeichnet ? Das ist MPEG2 SD progressive, so was habe ich nicht.

Kannst du mir einen tar auf das ganze Aufnahmeverzeichnis irgendwo hochladen und mir per PM den Download Link senden ?

Edit: zu viel HD gemacht in der letzten Zeit. Habe Blödsinn geschrieben, ich teste mal mit einer Aufnahme von mir. Mit VAAPI läuft es schon mal.