VDR-Testreihe zum Frame-Detector - Bitte um Mithilfe!

  • Hallo!


    Ich brauche Hilfe von VDR-Nutzern.


    Warum?


    Mir ist beim Programmieren mit dem VDR eine Merkwürdigkeit aufgefallen. Beim Analysieren von Videos verpasst das Programm manchmal den Moment, zu dem es aufnehmen könnte, und fängt erst kurz darauf an - je nachdem, welche Datenmengen er auf einmal analysiert. Der Unterschied ist für den Nutzer eher unbedeutend, aber es wäre trotzdem besser, das Programm so zu ändern, dass es sich unabhängig von Zufällen vorhersagbar verhält. Voreingestellt ist, dass mindestens 5 * 188 Bytes vorliegen müssen. Bei meinen Aufnahmen braucht es aber manchmal 6 * 188 Bytes, um den Anfang zuverlässig zu erkennen.


    Und jetzt kommt das Problem: Ich weiß nicht, ob 6 nun die magische Zahl ist (und Klaus ist sich auch nicht sicher). Daher habe ich Progrämmchen geschrieben, das Aufnahme-Dateien auf dieses Problem hin untersucht. Je mehr Leute das auf je mehr unterschiedliche Dateien loslassen, desto mehr können wir darüber erfahren.


    Wie?


    Um helfen zu können, muss man in der Lage sein, einen VDR zu kompilieren.
    Zuerst führt man im VDR-Verzeichnis aus:
    > make


    Was für den Einsprungpunkt des VDR kompiliert wurde, löschen wir wieder - das Testprogramm hat ja seinen eigenen Einsprungpunkt
    (keine Sorge, das lässt sich jederzeit mit einem neuen "make" wiederherstellen):
    > rm vdr.o


    Dann kompiliert man die angehängte Datei:
    > g++ -c framedetectortest.cpp


    Anschließend verlinkt man sie:
    g++ -o framedetectortest *.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg -lrt


    Nun hat man das Programm framedetectortest, das man auf seine VDR-Aufnahmedateien (*.ts) loslassen kann:
    ./framedetectortest 00002.ts


    Die Ausgabe sieht zum Beispiel so aus:
    Checking file at offset 0
    Without frame limit... Found I frame after 99452 bytes
    With frame limit 5... Found I frame after 220336 bytes
    With frame limit 6... Found I frame after 99452 bytes
    TS package frame size needed for this video block: 6
    Maximum TS package frame size needed for this video recording: 6


    Und dann bräuchte ich Rückmeldung, was getestet worden ist (Kabel, Satellit, Terristrisch? HD, SD? Land?) und welche Zahl ("Maximum TS package frame size") am Ende rauskam. Das Ergebnis ist auch dann interessant, wenn es 5 oder 6 ist!


    Ciao,
    Eike


    PS: Ich werd das ganze später noch auf Englisch posten.


  • Anschließend verlinkt man sie:
    g++ -o framedetectortest framedetectortest.o remux.o ringbuffer.o thread.o tools.o i18n.o sections.o channels.o device.o audio.o ci.o receiver.o transfer.o player.o osdbase.o status.o skins.o osd.o config.o font.o sources.o menu.o recording.o videodir.o timers.o epg.o dvbplayer.o menuitems.o remote.o keys.o interface.o plugin.o cutter.o themes.o svdrp.o eit.o eitscan.o shutdown.o filter.o sourceparams.o dvbsubtitle.o pat.o sdt.o nit.o dvbdevice.o diseqc.o recorder.o dvbci.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg


    Ich bekomme mit VDR 2.1.3:



    Passt das nicht für die aktuelle develop, oder ist es ein anderes Problem?

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Passt das nicht für die aktuelle develop, oder ist es ein anderes Problem?


    Verdammt. :)
    Ich habe die 2.0 genommen. Bei der 2.1 dürfte zusätzlich positioner.o benötigt werden.
    Klappt es damit?


    Ciao,
    Eike

  • Vermutlich ist es so geschickter...


    So funktioniert es ...


    Habs mal über ca. 10 Aufnahmen laufen lassen, DVB-C, Kabel BW.


    Ergebnis bei mir: Eine ältere Aufnahme aus 2010 mit "5", der Rest mit "6"


    Grüße, Peter


    Edit: Habs noch etwas weiter eingegrenzt: Meine letzte Aufnahme mit "5" ist vom 04.02.2012, ab 07.02.2012 mit "6"


    Edit2: ^ ^ ^ ^ ^ stimmt auch nicht, ist doch irgendwie gemischt, die neueren sind aber doch in der Mehrzahl "6" ^ ^ ^ ^

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    3 Mal editiert, zuletzt von lostinspc ()

  • Hallo,


    bei (gepatchtem) VDR 2.0.5 hat die erste Variante auch nicht funktioniert. Aber mit der 2. hats dann gebaut.


    Bei den meisten sinds 5. Bei ARD HD DVB-S2 ganz aktuell und früher auch 6. Mich würde auch interessieren, warum man damit so geizen muss.


    Gruß

    Gen2VDR v5.1
    ---------------
    Intel DG45ID mit Core2Duo E4300, 2,5GB DDR2, Gainward G210 1024MB passiv, SSD, cineS2 + DuoFlex S2 unicable, TT Budget T-1500, MSI Mega Sky 580 DVB-T USB-Stick, Atric Einschalter, 3TB Video HDD

  • Bei 2.0.4 bekomme ich:

    Code
    gentoo64 vdr-2.0.4 # g++ -o framedetectortest *.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg
    tools.o: In function `cTimeMs::Now()':
    /usr/local/vdr/vdr-2.0.4/tools.c:674: undefined reference to `clock_gettime'
    /usr/local/vdr/vdr-2.0.4/tools.c:655: undefined reference to `clock_getres'
    /usr/local/vdr/vdr-2.0.4/tools.c:659: undefined reference to `clock_gettime'
    collect2: ld returned 1 exit status


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Hallo!



    Ich hätte ja nicht gedacht, dass sich gleich in der ersten Nacht die ersten darauf stürzen, danke!


    Die Anleitung hab ich jetzt mal so geändert, dass sie mit mehr VDR-Versionen funktionieren sollte.


    Bei
    2.0.4 bekomme ich:

    Code
    gentoo64 vdr-2.0.4 # g++ -o framedetectortest 
    *.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg
    tools.o: In function `cTimeMs::Now()':
    /usr/local/vdr/vdr-2.0.4/tools.c:674: undefined reference to `clock_gettime'
    /usr/local/vdr/vdr-2.0.4/tools.c:655: undefined reference to `clock_getres'
    /usr/local/vdr/vdr-2.0.4/tools.c:659: undefined reference to `clock_gettime'
    collect2: ld returned 1 exit status


    Ich hab's grad probiert, mit einem "reinen" VDR 2.0.4 bekomm ich das nicht.


    Laut Google sollte aber -lrt am Ende der Kommandozeile helfen.


    Ciao,
    Eike

  • Ich habe gerade mal ein paar Aufnahmen getestet. Bei den meisten reichen 5 Frames bis zum I-Frame.
    Bei ORF1 HD, DVB-S2, S19,2E sind mindestens 6 Frames notwendig.


    Es handelt sich nicht um "Frames" (genau die will die Funktion ja erst erkennen) sondern um "TS-Pakete".


    Zitat


    Eine Frage: Warum geizt man so mit dem getesteten Frames?


    Das ist einfach um den Aufwand so gering wie möglich zu halten. Es hat bis jetzt anscheinend gereicht, nur maximal 5 TS-Pakete zu scannen um den Frame-Typ zu erkennen.
    So wie es sich in den Postings hier abzeichnet scheint 6 das neue Maximum zu sein. Ich werde den Wert dann mal auf 10 erhöhen, dann sollten wir wieder einige Reserve haben ;-).


    Klaus

  • Habe hier einen krassen Ausreißer.


    Maximum TS package frame size needed for this video recording: 23


    Handelt sich um "Quarks & Co/Krankenhaus mit Nebenwirkungen" vom 14.1.14 von S19.2 WDR HD (12421 MHz/H).
    Der sendet in DVB-S mit 720p.


  • Das habe ich aus den Ausgaben des Testprogramms so interpretiert.


    Es war ein "Frame" ("Window" könnte man glaub ich auch sagen) aus x TS-Paketen gemeint.
    Also: Wieviele TS-Pakete muss der Detector jeweils auf einen Haufen ankucken, damit er zuverlässig das erste passende I-Frame erkennt.

  • Hallo!

    Habe hier einen krassen Ausreißer.


    Maximum TS package frame size needed for this video recording: 23


    Handelt sich um "Quarks & Co/Krankenhaus mit Nebenwirkungen" vom 14.1.14 von S19.2 WDR HD (12421 MHz/H).
    Der sendet in DVB-S mit 720p.


    Verdammt! Musst du die 6-Party so stören? ;)
    Kannst du mir den entsprechenden Teil (1 MB sollte vermutlich reichen?) ausschneiden und mailen?
    Falls das Forum so große Mails nicht zulässt => eike bei ein-eike.de.


    Ciao,
    Eike

  • -lrt hat geholfen. Mein vdr ist ungepatcht, liegt wohl an der Umgebung (gentoo 64bit)


    Erster Schnelldurchgang mit Aufzeichnungen von SAT


    Fast alle 5


    Zwei Ausnahmen:


    arte HD 6
    NDR FS NDS HD 6


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Hier bei Kabel D in München scheinen die Encoder brav zu sein - die liefern immer nur 5:
    http://pastebin.com/f49tePme

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das Finden und Ausschneiden der betr. Stelle scheint nicht möglich.
    Anhand der Offset-Ausgabe im Verhältnis zur Dateigrösse schätze ich die Stelle ungefähr ab, gebe vorne und hinten ein paar Minuten hinzu, um mich anzunähern. Das 1. Schnittergebnis liefert im Test dann aber andere Werte als erwartet, aus der anfänglichen 23 ist dann eine 11, 17 oder 18 geworden, je nachdem wie die Schnittmarken sitzen. Wenn der Schnipsel im nächsten Anlauf nochmal gekürzt wird, sinken auch die Paketgrößen. Bin dann auch wieder auf 5-6. ???


    edit: Das syslog sagt an den betr. Stellen zur Aufnahmezeit continuity error ==> Fehler in der Aufnahme und daher irrelevant.

    Einmal editiert, zuletzt von rdnzl ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!