vdrsync pre-alpha1

  • Hi Metrio


    Quote

    Ne Menge Handarbeit, aber die Cropwerte und den Dateinamen lassen sich nur *sehr* kompromissbehaftet automatisch ermitteln. Werde irgendwann mal die Dateinamen jeweils in einem File ablegen und Schritt 3 bis 5 per Script in einer Queue abarbeiten. Evtl. dann für jede Datei ein separates Verzeichnis anlegen, in welches auch die summary.vdr reinkommt. Aber im Moment komme ich so ganz gut klar.


    In der Tat, ne Menge Handarbeit;)
    Den Crop-Mechnismus von mplayer kannte ich noch gar nicht, denn habe ich mir gerade mal genauer angeschaut. Das scheint doch recht gut zu funktionieren, und den kann man auch schon auf das original .vdr File loslassen... Dann müsste man "nur" noch den output von


    mplayer -vop cropdetect 001.vdr


    einlesen, und könnte das weiter automatisieren. Hast Du auch schlechte Erfahrung mit dem cropdetect gemacht?


    Ich werde mal weiter "buddeln"...


    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi,


    einige Leute haben mir ein paar Aufnahmen / Patches geschickt, und deshalb gibt es jetzt die nächste vdrsync Version, in der ein paar Bugs behoben sein sollten.


    NEU:

    • Einige Sender setzen ein Bit im PES-Header falsch (oder ich verstehe es falsch), so dass die Audiospur vermurkst war (nein, nicht schon wieder das private_bit im Audioframe-Header ;)) Sollte jetzt gehen (Danke für die Aufnahme, dimitri)
    • Eine Aufnahme hatte ein Byte am Anfang des Videostreams zuviel (ORF), und liess sich deshalb nicht mplexen. Das wird jetzt vom Script korrigiert (Thanx weissnichobduhierstehenwillst)
    • Ich selber hatte eine Aufnahme, bei der die Timestamps in einem Audiostream zerschossen waren. Das Script versuchte daraufhin, A/Vsync durch Einfügen von 100,000,000,000 oder so Audioframes zu hinzubiegen. Das passiert im Hauptspeicher, das war nicht so toll (Quiz: Wie lange benötigt perl, um 1GB Hauptspeicher komplett vollzuschreiben? :rolleyes: ). Jetzt gibts einen Check, wenn der Shift zu gross ist, wird der Stream ignoriert.


    • Dann habe ich einen Patch von Ernie in vdrsync.pl integriert, der einen -divx switch implementiert. Statt tcmplex wird transcode angworfen, wenn -divx gesetzt wird. Als Parameter für transcode bisher nur: -y divx4 -w 1000. Kann man einfach am Anfang von vdrsync ändern.


    Wie immer, Happy Testing, und lasst hören, wenn was geht oder nicht geht


    Cheers


    doc


    PS: Ein Fehler mit den divx Parametern wurde behoben, dehalb sofort die Version 1.1.1b. Danke ernie.

    Files

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

    The post was edited 1 time, last by Doc ().

  • Hi,


    habe jetzt vesucht mit vdrconvert-0.0.2 und der neuesten vdrsync-0.1.1.1 eine DVD zu erstellen.
    Der Ton läuft jetzt wieder, nicht mehr verhackt, aber hinkt den Lippenbewegungen hinterher.


    Habe die DVD mit MPlayer, Xine, Ogle; und vlc wiedergegeben, ueberall dasselbe.


    Gibt es eine Möglichkeit alle das beim DVD authoring alle 15 min ein Kapitel erstellt wrid,
    so wie in der vdr2dvd-0.5.0 (ds.jar) Version ?.

    Gruß Marco


    HW: TT6400-S2
    SW: Fedora 36, kernel-5.17.12-300.fc36.x86_64, vdr-2.6.1-1.fc36.x86_64


    Fedora36 x86_64 Gnome Desktop 42.2 Ausgabe über das vdr-softhddevice plugin

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400


  • Hi Marco



    Zu 1)


    Kannst Du mir das erste MB der Aufnahme mailen? Irgendwas läuft da falsch....


    Zu 2)
    Da kann sicher Dimitri besser was zu sagen, es sollte auf jeden Fall möglich werden.
    Versuch mal in Zeile 53 von vdr2dvd.sh


    Code
    1. nice -${PRIO} dvdauthor -o ${UniqueDVDDIR} ${UniqueDir[Number]}/${Titel}.mpg


    durch


    Code
    1. nice -${PRIO} dvdauthor -o ${UniqueDVDDIR} -c 0,15:00,30:00,45:00,01:00:00,01:15:00,01:30:00,01:45:00,02:00:00,02:15:00,02:30:00,02:45:00,03:00:00 ${UniqueDir[Number]}/${Titel}.mpg


    auszutauschen.



    cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote


    Den Crop-Mechnismus von mplayer kannte ich noch gar nicht, denn habe ich mir gerade mal genauer angeschaut. Das scheint doch recht gut zu funktionieren, und den kann man auch schon auf das original .vdr File loslassen... Dann müsste man "nur" noch den output von


    mplayer -vop cropdetect 001.vdr


    einlesen, und könnte das weiter automatisieren. Hast Du auch schlechte Erfahrung mit dem cropdetect gemacht?


    "Schlecht" in dem Sinne eigentlich nicht. Man kann ja auch angeben, wie sensibel der Mechanismus reagiert, z.B. -vop cropdetect=40.


    Probleme dabei:
    - Arte hat zuweilen Dokus, bei welchen hier und da Schrift in den Rändern eingeblendet wird. z.B. Namen von Leuten, die gerade reden. In dem Balken liegt davon gewöhnlich eine von zwei bis drei Zeilen - weniger tragisch.
    - Wenn ich von N24 ne Doku aufnehme, schneide ich den Lauftextbalken unten weg. Ist erheblich angenehmer und lässt sich wohl nur manuell machen.
    - manchmal gibt es ganz unten oder oben am Bildrand einen weißen Streifen. Das wird nicht erkannt und lässt sich glaube ich auch nicht zufriedenstellend mit hohen crop-werten wegbügeln.
    - zuweilen wird kurz nach dem Anfang einer Aufnahme die Auflösung umgeschaltet. Pragmatisch wäre es, sich nach einem Wert zu richten, den man z.b. nach 1 min Spielzeit erhält.
    - und innerhalb von Aufnahmen kann sich auch schon mal was ändern - insbes. linke und rechte Ränder bei Dokus. In der Praxis ebenfalls weniger tragisch, und man könnte sich auch ohne merkliche Einbußen an den Minimalwerten orientieren.
    Denke mal, dass die meisten dieser Probleme bei Spielfilmen nicht vorkommen. Da sollte es reichen, den Wert nach 1 min Offset zu extrahieren.


    Ich hatte mich schon mal kurz am Automatisieren versucht, es aber u.a. aus den genannten Gründen sein gelassen.
    Idee dabei war: Mplayer anschmeißen und innerhalb der Aufnahme in z.B. 5-Minuten-Intervallen kurze Abschnitte scannen. Output pipen oder in einen Datei schreiben und diejenige Zeile raussuchen, die am häufigsten vorkommt - z.B. mit uniq.
    Oder aus allen a:b:c:d min(a-werte):min(b-werte):max(c-werte),max(d-werte).
    Problem dabei, welches sicherich nicht sonderlich schwer zu lösen ist: man muss den mplayer fernsteuern, damit der die Sprünge macht. Vielleicht werde ich mir das früher oder später nochmal ansehen.


    grüße


    metrio


  • sorry, aber wie bekomme ich 1 MB der Aufnahme. Welche Datei brauchst Du ?

    Gruß Marco


    HW: TT6400-S2
    SW: Fedora 36, kernel-5.17.12-300.fc36.x86_64, vdr-2.6.1-1.fc36.x86_64


    Fedora36 x86_64 Gnome Desktop 42.2 Ausgabe über das vdr-softhddevice plugin

    ViewSonic VX3276 HDMI-1 <------------> HDMI NVidia Geforce-gt-1030

    ViewSonic VX3276 HDMI-2 <------------> HDMI Technotrend S2-6400


  • Hi Marco

    einfach in das Verzeichnis mit der Aufnahme wechseln und


    dd if=./001.vdr of=./AVdesync.vdr bs=1024 count=1024


    eingeben, dann


    gzip AVdesync.vdr


    und ab die mail an vdrsync@gmx.net.


    In einem laaaangen Posting weiter oben habe ich beschrieben, wie Du mir auch noch debug output zuschicken kannst.


    cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Metrio,



    Ich habe mal einen Quick-Hack versucht, die Idee wäre, aus vdrsync heraus einfach ein paar Abschnitte zu analysieren, und die dann als Parameter für transcode oder mencoder zu verwurschten. Das Teil ist im Moment nur ein Proof-of_concept Hack....



    Bei einem Testfile ist der Output so:

    Code
    1. > ./pipe_mplayer.pl
    2. got crop area: X: 0..543 Y: 61..535 (-vop crop=544:474:0:62 92 times


    Meinst Du, darauf kann man aufbauen?


    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote

    Original von Doc
    [/code]
    Bei einem Testfile ist der Output so:

    Code
    1. > ./pipe_mplayer.pl
    2. got crop area: X: 0..543 Y: 61..535 (-vop crop=544:474:0:62 92 times


    Meinst Du, darauf kann man aufbauen?
    doc


    Lustig - hatte mich heute Mittag, bevor ich das gelesen hatte, auch drangesetzt und was gemacht. Allerdings noch ohne integrierte Auswertung.
    Ja - ich denke, das fast schon so lassen. Min-Werte zu nehmen, wie ich das in meinem letzten Postigng vorgeschlagen hatte, is etwas riskant - da können Ausruscher zu stark durchschlagen.
    Ne Variante wäre vielleicht, die kleinste Area zu nehmen, die mindestens n mal vorkommt.
    Habe deine Version eben mal ausprobiert. Da kommt was leicht anderes raus als bei mir, was teilweise an der Auswahl der Proben liegen mag:


    pipe_mplayer.pl
    got crop area: X: 5..704 Y: 0..575 (-vop crop=698:576:6:0 29 times
    got crop area: X: 6..704 Y: 0..575 (-vop crop=698:576:6:0 8 times


    croplook 001.mpg |uniq -c
    1 crop area: X: 5..704 Y: 0..575 (-vop crop=698:576:6:0)
    1 crop area: X: 5..705 Y: 0..575 (-vop crop=700:576:6:0)
    8 crop area: X: 5..706 Y: 0..575 (-vop crop=700:576:6:0)
    20 crop area: X: 5..707 Y: 0..575 (-vop crop=702:576:6:0)


    und mit vop cropdetect=90 (teils negative Werte!?)
    pipe_mplayer.pl
    got crop area: X: 8..700 Y: 2..574 (-vop crop=692:572:8:2 1 times
    got crop area: X: 8..595 Y: 2..573 (-vop crop=588:572:8:2 1 times
    got crop area: X: 720..0 Y: 576..0 (-vop crop=-720:-576:720:576 5 times
    got crop area: X: 223..554 Y: 2..243 (-vop crop=330:242:224:2 1 times
    got crop area: X: 8..699 Y: 2..574 (-vop crop=692:572:8:2 1 times
    got crop area: X: 106..569 Y: 2..387 (-vop crop=464:386:106:2 1 times
    got crop area: X: 720..0 Y: 3..19 (-vop crop=-720:16:720:4 1 times
    got crop area: X: 522..523 Y: 2..129 (-vop crop=2:128:522:2 1 times
    got crop area: X: 8..703 Y: 2..574 (-vop crop=696:572:8:2 2 times
    got crop area: X: 7..703 Y: 2..574 (-vop crop=696:572:8:2 23 times


    croplook 001.mpg |uniq -c
    1 crop area: X: 7..703 Y: 2..574 (-vop crop=696:572:8:2)
    4 crop area: X: 7..703 Y: 1..574 (-vop crop=696:572:8:2)
    9 crop area: X: 7..705 Y: 1..574 (-vop crop=698:572:8:2)
    14 crop area: X: 7..706 Y: 1..574 (-vop crop=698:572:8:2)
    2 crop area: X: 6..706 Y: 1..574 (-vop crop=700:572:6:2)


    Ob das mit den negativen Werten daran liegt, dass du unsauber geschnittene (?) Fragmente reinpipest, und dies den mplayer durcheinander bringt?
    Bei einem vdr-file (statt mpeg) ist meine Version eben auch mal abgeschmiert. Ist auch nur ein allererster Ansatz ohne Längencheck und Fehlerbehandlung. Ich kann zwar nicht so leicht überblicken, ob die Anzahl der Sprünge in beiden Versionen ähnlich ist, aber deine Version war erheblich schneller fertig.



    Werde das mal beobachten, aber ein Wert von 90 für Cropdetect scheint ganz ok zu sein. Zumindest bei einer Aufnahme, die ich hier habe, schneidet er die Artefakte oben und unten weg. Wenn mal zwei oder drei Pixel an den Rändern mehr abgeschnitten sind, dann ist das imo nicht weiter schlimm. Wenn auf der anderen Seite eine Pixelreihe zu wenig weggeschnitten wird, dann müssen unnötig Daten dafür verbraten werden, die scharfen Ränder zu encodieren.


    grüße


    metrio

  • Hi Metrio


    Quote

    Ob das mit den negativen Werten daran liegt, dass du unsauber geschnittene (?) Fragmente reinpipest, und dies den mplayer durcheinander bringt? Bei einem vdr-file (statt mpeg) ist meine Version eben auch mal abgeschmiert. Ist auch nur ein allererster Ansatz ohne Längencheck und Fehlerbehandlung. Ich kann zwar nicht so leicht überblicken, ob die Anzahl der Sprünge in beiden Versionen ähnlich ist, aber deine Version war erheblich schneller fertig.


    Ja, mein Hack schickt einfach die ersten XXX Bytes rein, sonst gar nix. Kein seek oder so, und der letze Frame ist defekt. Ich würde es gerne in vdrsync integrieren, und von dort kann ich dann "beliebige" Video-Schnippsel sampeln, dann korrekte.


    Und was auch noch nett wäre: Das müsste ja tatsächlich für Spielfilme mit schwarzen Balken ein automatisches setzen von Schnittmarken rund um die Werbung erlauben.... So als Option....


    Das meine Version schneller war, liegt ws, daran, dass ich weder seeke noch viel reinpipe....


    Jetzt get es erstmal drum, das vdrsync "schneiden" lernt, und dann greif ich das gerne nochmals auf...



    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote

    Original von Doc
    Und was auch noch nett wäre: Das müsste ja tatsächlich für Spielfilme mit schwarzen Balken ein automatisches setzen von Schnittmarken rund um die Werbung erlauben.... So als Option....


    Coole Idee - das könnte wirklich klappen.


    Quote


    Das meine Version schneller war, liegt ws, daran, dass ich weder seeke noch viel reinpipe....
    Jetzt get es erstmal drum, das vdrsync "schneiden" lernt, und dann greif ich das gerne nochmals auf...


    Mal gespannt:-). Werde meine Version noch ein klein wenig feinschleifen und etwas systematischer drauf achten, was bei verschiedenen Aufnahmen rauskommt. Vielleicht kann ich dir noch den ein oder anderen Tipp geben. Schade, dass wir nicht die gleiche Sprache benutzen.


    Grüße


    metrio

  • Hi Metrio,


    Quote

    Coole Idee - das könnte wirklich klappen.


    Mal gespannt:-). Werde meine Version noch ein klein wenig feinschleifen und etwas systematischer drauf achten, was bei verschiedenen Aufnahmen rauskommt. Vielleicht kann ich dir noch den ein oder anderen Tipp geben. Schade, dass wir nicht die gleiche Sprache benutzen.


    Ich bin für jeden Tipp dankbar ;) Und was die Sprache angeht - ich kann nur Perl :( (aber das habe hier im Board schon 1000 mal gesagt). Falls Du das Ding portieren willst, erkläre ich Dir gern, wie es verbrochen wurde ;)


    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote

    Original von Doc
    Ich bin für jeden Tipp dankbar ;) Und was die Sprache angeht - ich kann nur Perl :( (aber das habe hier im Board schon 1000 mal gesagt). Falls Du das Ding portieren willst, erkläre ich Dir gern, wie es verbrochen wurde ;)
    doc


    nene - ich glaube, du machst das schon ganz gut;-).
    Bin in Python noch ein ziemlicher Anfänger, und mir reicht es erst mal, wenn ich ein paar grundlegende Sachen damit geregelt kriege.


    grüße


    metrio

  • Hallo,


    Quote

    Und was auch noch nett wäre: Das müsste ja tatsächlich für Spielfilme mit schwarzen Balken ein automatisches setzen von Schnittmarken rund um die Werbung erlauben.... So als Option....


    Das wäre einfach zu geil :D


    Ich habe leider noch kein DVD-recorder stehe aber kurz davor so das ich zwischendurch mal hier reinschaue zum sehen was ihr so "treibt" ;)
    Echt klasse muss ich sagen !


    Ich hätte da auch eine kleine idee (hoffentlich hatte die nicht schon jemand hier gepostet - habe nichts gefunden). Bei AC3 aufnahmen z.B. bei Pro7 ist es ja so das sie bei der Werbung immer auf DD 2.0 umschalten. Wäre es hier nicht auch möglich die schnittmarken automatisch zu setzen ? So weit ich das weis sollte es auch mit aufnahmen von Premiere 1+2 klappen da sie auch bei filmanfang/ende auf AC3 schalten.


    Sehr gut wäre ein kleines extra tool der beide sachen oben machen könnte und marks.vdr schrieben kann - so das man es auch nutzen kann wenn man die aufnahme nicht auf DVD schreiben möchte :)
    Könnte man aus reccmds.conf aufrufen.


    Nur so einen traum ... :D


    Gruß
    Viking

  • Hi Viking,




    Erstmal danke für die Blumen :)


    Es gibt einen anderen Thread über Werbe-Erkennung, da hab ich auch mal was über Lautstärke gelesen (und LOGO-Erkennung).
    Ich würde mir das ganze so vorstellen:


    Auf jeden Fall ein eigenständiges Tool (oder vdrsync im Werbe-Modus, kommt auf dasselbe raus):


    • Alle 100 Sec (oder so) werden 20 Frames auf Ihre Ränder untersucht (cropdetect im mplayer)
    • Die crop Ergebnisse werden eingelesen und eine noch zu definierende Logik sagt dann "Film" oder "Werbung" (fürs Text parsen ist Perl dann natürlich wieder very nice;)). Kriterium: schwarzer Balken unten(!), damit "fliegende" Logos oben nicht stören
    • Dann geht man nochmals über die Marks, und untersucht jeden Frame von 100 vor jedem Mark bis 100 nach jedem mark und setzt die marks endgültig
    • Dann ist das Tool fertig, der User kann die marks überprüfen/ändern. Die Cropinfo könnte man auch irgendwo ablegen, damit SVCD/DIVX Produktion die benutzen können.
    • Und der user sollte es über rccmds.conf starten können


    Auch möglich wäre natürlich die Audio Geschichte, aber da muss man dann selber in die Audioframe header reinschauen (und nicht mplayer die Arbeit machen lassen). Das macht vdrsync sowieso, also ist es nicht soo schwer. Als Programmieranfänger wächst mir vdrsync langsam über den Kopf, und ich lasse mir mehr Zeit, um über ein gescheites Design nachzudenken, als alles schnell anzupfuschen. Es wird immer noch schlimm genug sein ;)


    Evt könnte ich auch Audio-Schnippsel rausschreiben und über tcprobe -i Audio-Schnippsel rauskriegen, was für ein Ton gerade vorliegt.


    Stand der Dinge: Ich habe gestern ein Script geschrieben, was mit Hilfe der index.vdr "beliebige" Teile der Aufnahme eigene Dateien schreibt. Das ist die Vorarbeit für die Schnittfunktion in vdrsync. Aber genau das Ding lässt sich mit dem hier geposteten Script (das weiter oben) zu einem "Schwarzer Balken Scanner" verheiraten :).


    Es kann sich nur um Monate handeln, bis ich dazu komme.....;)


    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote

    Original von Doc
    [*] Dann geht man nochmals über die Marks, und untersucht jeden Frame von 100 vor jedem Mark bis 100 nach jedem mark und setzt die marks endgültig
    [doc


    Du meinst, die 100 Sekunden davor und danach komplett mit mplayerdurchsuchen? Das könnte etwas dauern. Zumal es mir bisher nicht so vorkommt dass man so locker einen Einzelwert aus einer längeren Ausgaben von cropdetect einem konkreten Zeitpunkt zuordnen kann. (--verbose?).
    Denke, an den Kandidatenstellen wirst du am besten die Suchintervalle sukzessive (ggf. rekursiv) halbieren.
    Falls eine Zuordnung zwischen mplayer-Ausgaben und konkreten Zeitpunkten möglich ist, dann kann man irgendwo einen Schnitt machen und den nunmehr kleinen Bereich komplett durchsuchen. Andernfalls lässt man die Rekursion bis zu einem Interfall von 0,5 Sekunden durchlaufen - oder was auch immer sich bzgl. der gops als sinnvoll erweist. Bei einem Intervall von 100 Sekunden sollten da ca. 8 Schritte reichen. Aber 100 Sekunden ist imo auch sehr knapp. Gerade nachts kann die Werbung schon mal ziemlich kurz sein!


    grüße


    metrio

  • Quote

    Original von metrio


    Du meinst, die 100 Sekunden davor und danach komplett mit mplayerdurchsuchen? Das könnte etwas dauern.


    Eigentlich meinte ich 100 Frames also 100/25 = 4 Sekunden (oder so). Das ist aber ws zu kurz.

    Quote

    Original von metrio
    Zumal es mir bisher nicht so vorkommt dass man so locker einen Einzelwert aus einer längeren Ausgaben von cropdetect einem konkreten Zeitpunkt zuordnen kann. (--verbose?).


    Ich würde einzelne Gops aus dem Stream extrahieren und die einzeln an mplayer geben, geschnitten wird ja eh GOP-genau.


    Quote

    Original von metrio
    Falls eine Zuordnung zwischen mplayer-Ausgaben und konkreten Zeitpunkten möglich ist, dann kann man irgendwo einen Schnitt machen und den nunmehr kleinen Bereich komplett durchsuchen. Andernfalls lässt man die Rekursion bis zu einem Interfall von 0,5 Sekunden durchlaufen - oder was auch immer sich bzgl. der gops als sinnvoll erweist. Bei einem Intervall von 100 Sekunden sollten da ca. 8 Schritte reichen. Aber 100 Sekunden ist imo auch sehr knapp. Gerade nachts kann die Werbung schon mal ziemlich kurz sein!


    Die Zuordnung würde ich wie oben vorgeschlagen lösen, also GOP genau. Was die 100 sekunden angeht, so müssen wir wohl mit dem Wert spielen - und mit allen anderen auch ;) Und die Parameter natürlich konfigurierbar gestalten :)


    Cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage

  • Hi Doc,

    Quote

    Original von Doc
    Die Zuordnung würde ich wie oben vorgeschlagen lösen, also GOP genau. Was die 100 sekunden angeht, so müssen wir wohl mit dem Wert spielen - und mit allen anderen auch ;) Und die Parameter natürlich konfigurierbar gestalten :)
    doc


    Hast meinen Segen dafür;-)


    Habe noch etwas getestet:
    Als Wert für den Cropdetect steht bei mir momentan 60 hoch im Kurs. Vorspann und Abspann (sagen wir mal 60 Sekunden) lässt man bei der Ermittlung des Mittelwertes wohl besser weg.


    grüße


    metrio

  • Hi,


    ich habe es nicht lassen können, und mich ein wenig an dem Werbedingsbums versucht. Ich bin nicht sehr weit gekommen, aber ich kann jetzt aus einer Aufnahme gezielt GOPs rausholen und die an Mplayer mit cropdetect verfüttern, und die Ergebnisse parsen.


    Vorgehen:
    1) Ich hole alle 50 sec automatisch aus einem .vdr File ein VideoSchnippsel und schreibe den in eine Datei (in diesem Beispiel 3 GOPs ca. 36 Frames)
    2) Ich starte mplayer mit

    Code
    1. mplayer gops$i.vdr -vo null -ao null -vop cropdetect 2>/dev/null > crop$i.out


    mplayer sucht also damit in dem Schnippsel nach schwarzen Rändern, und schreibt die Ergebnisse in eine Datei
    3) Ich werte alle Dateien aus. Ich suche nach den Rändern oben und unten, und zähle, wie oft ein schwarzer Rand der Grösse X innerhalb dieser ca 36 Bilder vorkommt. Die Auzählung aller Dateien wird in eine Ergebnis-Datei geschrieben.


    Alles noch sehr improvisiert, einige Macken etc pp


    Hier mal das (bisher einzige;)) Beispiel für ein Ergebnis-File:




    Man kann sehen, dass in den ersten 35 Bildern kein (kaum ein) schwarzer Balken oben und unten zu sehen ist (Bildhöhe müsste 0 bis 576 oder so sein), lediglich bei 150 sec gibt es Balken...
    Das ist in der Aufnahme auch alles Werbung :D


    Dann startet der Film....


    Man sieht, dass schwarze Ränder da sind, manchmal sogar seeehr grooose. Das sind der Titel auf schwarzem Grund und Weltraumszenen ;)


    Dann kommt mal wieder eine Film-Unterbrechung, Werbeblock...


    Film geht weiter...


    Das sieht gar nicht schlecht aus :lol1


    Zumindest bei diesem Film scheint es möglich zu sein, Werbepausen grob anhand der fehlenden schwarzen Ränder identifizieren zu können.


    Im 2ten Schritt müsste das Skript jetzt versuchen, die genauen Ränder zu identifizieren.


    Ich werde jetzt aber erstmal in die Falle gehen, morgen/Wochenende/nächste Woche mal weiterbasteln, und das ganze Ding dann in einem neuen Thread posten. Dieser läuft ja langsam über ;)


    Wenn das wirklich klappen sollte, dann wäre das soooo :cool1 :cool1 :cool1 :cool1



    cheers


    doc

    Mitstreiter für VDRsync gesucht!
    Egal ob Perl Programmierer, Tester, Doku-Schreiber oder User, jede Hilfe ist willkommen. Infos hier im Board (nach vdrsync suchen) oder auf der vdrsync-Homepage