Beiträge von FireFly

    Und wenn das "writing 1 byte into a region of size 0 overflows the destination" ein Compilerfehler ist?

    Mit g++ 7.5.0 gibts lt. Post #8 den Fehler ja nicht.

    Aus Post #2:

    Code
    In file included from /usr/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
                     from /usr/include/c++/13.2.1/memory:81,
                     from videoinput.h:27,
                     from videoinput.c:27:
    In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]’,

    Er macht dort ja noch nichts außer #include <memory> (OK, config.h hat er schon eingelesen)


    Kannst Du den kompletten VDR und Plugins mal mit g++ 7.5.0 und dessen Headerfiles compilieren und laufen lassen?

    Da müssen um den if-Block noch Klammern drum, weil's mehr als eine Zeile ist.

    und da "this" und "&String" dann ja identisch sind langt eine Ausgabe (bläht das Logfile nicht ganz so viel auf ;-))

    Code
     if (this == &String) {
        esyslog("cString move identical, string \"%s\"", s?s:"NULL");
        return *this;
     } 

    Netztteil evtl. zu schwach? Hatte ich kürzlich bei einem Odroid C2. Da hat auch nur die rote LED geleuchtet ohne dass er gebootet hat (dann würde auch Debuggen nichts bringen weil er erst gar nicht startet). Mit einem stärkeren Netzteil gings dann einwandfrei.

    Hier mal mein erster Wurf:

    Die wichtigsten Änderungen:

    • scanType hinzugefügt (sofern ffprobe den findet, bei 1080p und 2160p bei meinen Testaufnahmen z.B. nicht)
    • kein root nötig, dafür wird geprüft ob Schreibrechte auf die Info-Datei vorhanden sind. Kopien haben den gleichen Owner
    • Startverzeichnis kann als Parameter übergeben werden, default (ohne Parameter) ist weiterhin /video
    • PES-Aufnahmen werden explizit geprüft und übersprungen
    • Einrückungen der Ausgaben zu einer Aufnahme der besseren Übersichtlichkeit wegen

    Das -read_intervalls habe ich übernommen, das stimmt aber nicht mit dem Kommentar darüber überein, oder?

    FireFly , wie macht das denn VDR?

    Der VDR parsed bei MPEG2 den Sequence Header und die Sequence Extension, bei H.264 und H.265 das Sequence Parameter Set.


    Das i/p schenke ich mir, da es ja nur im Infotext der Aufnahmen erscheint.

    Das habe ich implementiert, muss das Skript aber jetzt an Deine Änderungen anpassen ;) Wobei da noch die Frage ist, wie man mit Fällen wie Kabel eins umgeht - 576p gibts IMHO nicht im Standard

    Dazu meint ETSI:

    Zitat

    NOTE:

    An encoded resolution of 704 × 576 pixels is often used to encode just the active 702 pixel portion of the video line, excluding the analogue blanking that may be present at the start and end of the full 720 pixel digital video line.

    Ist also korrekt.

    Neben 720 x 576 sind übrigens auch 544 x 576 und 480 x 576 bei MPEG2 (=H.262) offiziell erlaubt.

    MegaV0lt Mit diesem Patch sollte es funktionieren. Kannst Du ihn bitte testen?

    Vielleicht lässt sich so was wie der Fix vom SoftHDDevice auch im VDR einbauen?

    Der Fix nicht, aber man könnte die Zeilenanzahl auf 1080 setzen, wenn sie zwischen 1081 und 1090 liegt. Und sich dann die komplette Berechnung des Cropping sparen? Lt. ETSI TS101154 V2.6.1 ist auch nur 1080 erlaubt und keine 1088 in der darzustellenden Auflösung.

    kls: Was meinst Du dazu?

    Bisher sehe ich keinen Fehler in der Berechnung. Kannst Du nochmal ein paar Parameter mehr ausgeben lassen?

    Außerdem wäre interessant, was das Femon-Plugin als Größe anzeigt.

    Diff
    --- remux.c.orig        2024-01-05 12:03:20.724972851 +0100
    +++ remux.c     2024-01-22 17:12:09.752022618 +0100
    @@ -1621,6 +1621,7 @@
                else if (chroma_format_idc == 2)
                   CropUnitX = 2;
                }
    +        dsyslog("H.264 Parm: w=%d h=%d l=%d r=%d t=%d b=%d  uX=%d uY=%d %d %d %c", frame_Width, frame_Height, frame_crop_left_offset, frame_crop_right_offset, frame_crop_top_offset, frame_crop_bottom_offset, CropUnitX, CropUnitY, frame_mbs_only_flag, chroma_format_idc, separate_colour_plane_flag?'t':'f');
             frame_Width -= CropUnitX * (frame_crop_left_offset + frame_crop_right_offset);
             frame_Height -= CropUnitY * (frame_crop_top_offset + frame_crop_bottom_offset);
             }

    Hier bei n-tv HD

    Natürlich ein verschlüsselter Sender, den ich nicht testen kann :rolleyes:


    Baue mal diesen Patch in remux.c ein:

    Diff
    --- remux.c.orig        2024-01-05 12:03:20.724972851 +0100
    +++ remux.c     2024-01-22 14:09:22.483053076 +0100
    @@ -1621,6 +1621,7 @@
                else if (chroma_format_idc == 2)
                   CropUnitX = 2;
                }
    +        dsyslog("H.264 Parm: w=%d h=%d l=%d r=%d t=%d b=%d  uX=%d uY=%d", frame_Width, frame_Height, frame_crop_left_offset, frame_crop_right_offset, frame_crop_top_offset, frame_crop_bottom_offset, CropUnitX, CropUnitY);
             frame_Width -= CropUnitX * (frame_crop_left_offset + frame_crop_right_offset);
             frame_Height -= CropUnitY * (frame_crop_top_offset + frame_crop_bottom_offset);
             }

    Dann mache eine kurze Aufnahme (Routine wird nur beim Start einmal aufgerufen) und schicke den Output

    Na da bin ich aber gespannt: Wie erkenne ich das?

    Das würde mich auch interessieren. Lässt der VDR die ganze Zeit das Device geöffnet? Und auf dem zuletzt getuneten Kanal? Dann hätte man keine Chance das zu erkennen. Bisher war das ja kein Problem wenn andauernd Daten durch das Koaxkabel in die Tunerkarte und von dort an das Device-File gelangen, aber bei Ethernet ist das schon irgendwie suboptimal.

    Macht das satip-Plugin das genauso?