Posts by illCP

Quote from Selur

Not supported WAV file header.

[...]

vermute das WavSplit das Problem ist.

Tatsache, darauf hatte ich gar nicht geachtet. Die theoretisch korrekte Syntax ist offenbar

AvsDec.exe -d "mehrkanaligesAudio.avs" | WavSplit.exe -s - "{0}"

scheitert aber entweder daran, dass AvsDec Raw ohne WAV-Header erzeugt, oder WavSplit irgendein generelles Problem hat.

avs2pipemod.exe -wav=16bit "mehrkanaligesAudio.avs" | WavSplit.exe -s  "{0}"

klappt ebenso nicht.

Die Beschreibung

Quote

Decode avisynth audio stream to raw audio file and split multi-channel WAV files into single channel WAV files.

ist offenbar etwas irreführend und soll vermutllich nicht bedeuten, dass man beides in einem Schritt erledigen kann, sondern dass AvsDec einen Raw-Stream erzeugt, und (völlig unabhängig davon) WavSplit Multikanal-WAV-Dateien in Mono-WAVs aufteilen kann.

Ich habe zwischenzeitlich eine andere funktionierende CLI-Lösung gefunden, und zwar eac3to:

eac3to.exe "input.ac3" "output.wavs"

Schön simpel, man braucht noch nicht einmal AVISynth oder ähnliches dazwischen und kann bei Bedarf auch ohne Zwischenschritt direkt zwischen diversen Formaten konvertieren, sogar den neueren HD-Audio-Geschichten.

Vielen Dank euch beiden!

Hallo zusammen,

in den seltenen Fällen, in denen ich eine mehrkanalige AC3- oder DTS-Datei in einzelne Mono-WAVs zerlegen möchte, verwende ich normalerweise BeHappy, was auch wunderbar funktioniert. Nun möchte ich aber zahlreiche Dateien automatisiert und auf einen Schlag verarbeiten und nicht jede einzeln in das BeHappy-GUI ziehen müssen. Generell scheint es sich bei BeHappy allerdings um eine reine UI-Anwendung zu handeln, die keine CLI-Optionen hat, zumindest finde ich keinerlei Informationen darüber.

Nach einigem Suchen und Ausprobieren habe ich AvsDec (https://github.com/wieslawsoltes/AvsDec) gefunden, das u.a. auch eine aktuelle Version von WavSplit enthält. In der README.md heißt es unter "Features":

Quote

Support for pipe output or input whenever possible.

Das heißt für mich, dass ich die AvsDec.exe und die WavSplit.exe irgendwie via Pipe verbinden kann, so dass AvsDec einen Audiostream aus einem AVISynth-Skript liest und dekodiert und direkt an WavSplit "weiterpiped".

Die Frage ist: Wie? Bzw. geht das unter Windows überhaupt oder ist das irgendeine Geschichte, die z.B. nur mit WINE unter Linux funktionieren würde? Und geht das in einer Batch-Datei oder muss ich zur PowerShell greifen? Die Dokumentation von AvsDec schweigt sich dazu leider vollkommen aus, Beispiele finde ich auch nirgends.

Ein kleiner Auszug aus meinen zahllosen gescheiterten Versuchen:

AvsDec.exe "mehrkanaligesAudio.avs" | WavSplit.exe "{0}"
AvsDec.exe -d "mehrkanaligesAudio.avs" | WavSplit.exe "{0}"
AvsDec.exe -d "mehrkanaligesAudio.avs" | WavSplit.exe -s "{0}"
WavSplit.exe -s "{0}" < AvsDec.exe -d "audio01.avs"
WavSplit.exe -s < AvsDec.exe -d "audio01.avs"

Ich kriegs nicht hin bzw. die korrekte Syntax (falls diese denn unter Windows überhaupt existiert) nicht zusammen. Weiß jemand Rat?

Quote from HQ-LQ

eine meine wertvolleren ideen ist,
dass man im radion den genauen zeitunkt ermittelt wann das lied gespielt wird

Das ist das Problem: Irgendwann zwischen ungefähr 1988 und 1997 "Ein paar Sonntage" ist also "ca. 20 Jahre" ;). Ich kann mich auch nicht erinnern, dieses Lied später nochmal gehört zu haben, d.h. es war damals im Radio ziemlich präsent, später nicht mehr.

Wobei mir gerade einfällt, dass ich da schon einigermaßen Englisch beherrscht haben muss, also müsste es eigentlich nach 1993 gewesen sein. Und um so mehr ich "Don't leave" von Faithless höre (von 1996), um so mehr bilde ich mir zumindest ein, dass das ungefähr der gleiche Zeitraum gewesen sein muss, also wohl zwischen 1993 und 1997.

Nach den Lyrics in verschiedenen Variationen habe ich auch schon öfters gegoogelt, bisher leider ohne Erfolg. Ich kann natürlich auch nicht ausschließen, dass sich dieses Textfragment einfach falsch in meinem Kopf festgesetzt hat. Es könnte auch "communication is [low/lost/raw/stall]" gewesen sein, hier habe ich diverses gegoogelt - sehr frei übersetzt war es aber "wir können uns nicht unterhalten, weil irgendwas mit der Kommunikation ist", da bin ich mir ziemlich sicher.

Ich bin auch schon die Top 100 der späten 80er bis Ende der 90er durchgegangen und habe mir so ziemlich alle Titel, die mir nichts sagten, auf YouTube angehört. Auch hier leider kein Erfolg.

"Tarantula" von Faithless (https://www.youtube.com/watch?v=39j9mvXuz4k) ist gefühlt verdammt nah dran - was ich suche ist (glaube ich) langsamer, hat weniger Drums und die Stimme ist eher etwas melancholisch "gehaucht". Irgendwas von Faithless scheint es aber nicht zu sein: +faithless +communication +lyrics ergibt keine brauchbaren Suchergebnisse.

Hi,

ich möchte nochmal meine Frage von 2011 in diesem Thread bumpen/aktualisieren, da ich den Titel immer noch nicht finden konnte:

Alles soweit ich mich erinnere, ist schon ein paar Sonntage her :):

Der Song muss irgendwo aus dem Zeitraum späte 80er bis Mitte 90er stammen, vermutlich frühe 90er. Ich bin mir ziemlich sicher, dass es sich nicht um einen Nummer-Eins-Hit handelte, er wurde aber in unserem Lokalradio öfter gespielt, kann also auch nicht völlig exotisch/unbekannt sein.

Es ist ein sehr ruhiges, athmosphärisches, melancholisches und recht langsames Stück, soweit ich mich erinnere eine Art langsames Drum'n'Bass mit vielen flächigen Sounds. Die Lyrics sind von einem Mann mit recht tiefer, melancholischer Stimme eher gesprochen als gesungen.

Das einzige, woran ich mich konkret erinnere, ist eine Textzeile

How can we [speak/talk], communication is [poor?]
oder
It's hard to [speak/talk], communication is [poor?]

oder ähnlich bzw. sinngemäß. Weiterhin glaube ich mich zu erinnern, dass "Love" im Refrain vorkam.

LigHs Vorschlag "Faithless" ging schon in die richtige Richtung: "Don't leave" (http://www.jamiecatto.com/dontleave.html) ist zwar nicht der gesuchte Song, allerdings dem gesuchten nicht ganz unähnlich.

Ich finde hier seit Jahren nix - irgendwelche Ideen?

Quote from LigH

Da hatte ein Broadcaster ja mal gar keine Ahnung.

Interlaced (bzw. teilweise wohl nicht sauber deinterlactes) 720p50 auf den öffentlich-rechtlichen HD-Sendern kommt vor, das kann ich durch diverse DVB-S-Aufnahmen (u.a. heute-Show, Extra-3) so bestätigen.

Auf den ÖR-HD-Sendern passieren generell einige seltsame, nicht wirklich nachvollziehbare Dinge: Die heute-Show scheint generell in SD aufgenommen und auf den 720p-Sender hochskaliert zu werden, das Bild ist enorm matschig. Extra-3 ist meist in echtem HD; Wiederholungen (z.B. auf EinsPlus oder einem anderen Spartensender) sind manchmal allerdings ebenfalls hochskaliertes SD.

Quote from Selur

Schade, dass hier sonst keine Ahnung oder Interesse zu haben scheint.

Jura ist ab einem bestimmten Komplexitätsgrad eigentlich keine Rechts-"Wissenschaft" mehr, sondern eher Rechts-"Philosophie" - es geht primär darum, das Gericht davon zu überzeugen, dass die eigene Sicht und Auslegung die richtige ist. Selbst wenn du deine Fragen einem auf dem Gebiet kompetenten Rechtsanwalt stellst, wirst du keine klaren, "schwarz-weißen" Antworten mit "Ja" oder "Nein" bekommen, sondern auf Kenntnissen und Erfahrungen basierende persönliche Einschätzungen mit sehr vielen "Meiner Ansicht nach..."-, "Müsste"-, "Könnte"- und "Sollte"-Formulierungen und Verweisen, was mal wer wo und wieso in einem ähnlichen Fall entschieden hat.

Als juristischer Laie Gesetzestexte zu lesen hat in der Regel wenig Sinn - zunächst mal muss man dieses meist staksige Geschwurbel verstehen bzw. deuten können, und dann hoffen, dass das Gelesene in diesem Fall überhaupt anwendbar ist, es keine anderen Gesetze gibt, die wiederum irgendetwas einschränken (man denke hier z.B. an den "Kopftuchstreit": Religionsfreiheit vs. Neutralitätsgebot), und zu guter Letzt dass das Gericht, vor dem ein diesbezüglicher Fall landet, das genau so oder zumindest ähnlich sieht/auslegt. Außerdem gibt es zu Gesetzestexten Kommentare, Kommentare zu Kommentaren, Musterurteile etc., die man auch zunächst einmal kennen und begreifen muss. Das Ganze versucht halt, die Realität abzubilden; Die ist komplex und nicht jede Frage eindeutig mit "Ja" oder "Nein" zu beantworten.

Und in wie vielen Gesetzen tauchen extrem dehnbare Begriffe wie "In erheblichem Maße", "angemessen", "hinreichend", "(un)zumutbar" etc. auf? Für sowas gibt's dann meist irgendeinen Kommentar oder ein Urteil, in dem ein Gericht entschieden hat, ob dieses oder jenes angemessen, hinreichend, zumutbar ist. Was natürlich nicht heißt, dass ein anderes Gericht in einem nahezu identischen Fall zum gleichen Urteil kommt - es kommt nicht allzu selten vor, dass sich zwei Urteile zweier Gerichte zu einem Thema völlig widersprechen.

Am Spruch "Vor Gericht und auf hoher See ist man in Gottes Hand" ist durchaus was dran.

http://pel.hu/down/SUPread.exe kann mit SUPs umgehen. Ich benutze das ausschließlich für OCR und habe die aktuellste Version noch nicht ausprobiert, http://pel.hu/down/SUPread.txt sagt allerdings

Quote

Subtitle positon change (drag anywhere)

Hallo zusammen,

habe ich SD-Material mit 704 Pixel Breite, sollte das (bis auf zwei Pixel) korrekte SAR ja 12:11 (4:3) bzw. 16:11 (16:9) sein, also 704 => 768 bzw. 704 => 1024.

Streng genommen sollte das ja ebenso für 720 Pixel Breite gelten, allerdings spuckt mir z.B. der MPC-HC in den Eigenschaften eines anamorphen Videos mit 720 Pixel Breite, das mit SAR 16:11 encodet wurde, "AR 349:192" aus - das streng genommen falsche, aber irgendwie korrekter aussehende "AR 16:9" bekomme ich nur angezeigt, wenn ich für 720 Pixel anamorph als SAR 64:45 (720 => 1024) auswähle, was ja wieder eher falsches "Generic PAR" wäre.

Frage: Kann 12:11 / 16:11 bei 720 Pixel Breite irgendwo (z.B. auf Hardware-Playern) Probleme bereiten - bzw. sind 48:45 / 64:45 überhaupt ein "reguläres" SAR? Eine Google-Suche danach ergibt irgendwie nicht viel, 12:11 und 16:11 findet man des Öfteren.

Quote from Ghitulescu

Das sagt nicht anderes dass manche Leute einfach Glück hatten.

18 € (VHB!)

Quote from TheGenesis

Lohnt sich das, mit 1080p zu encoden oder ist der Unterschied zu 720p auf großen TVs wirklich so gravierend?

Vor meinem 46" LCD im Abstand von ~3,5 m meine ich einen leichten(!) Unterschied wahrnehmen zu können, der mir allerdings nur auffällt, wenn ich 1080 und 720p direkt nacheinander schaue. Wirklich deutlich sichtbar ist das nur bei geringeren Abständen, so ca. 1 bis 2 m. Trotzdem bevorzuge ich die größtmögliche Auflösung - evtl. schaut man das irgendwann nochmal auf einer größeren Glotze oder auf kleinerer Fläche in geringerem Abstand.

Quote from Ghitulescu

Ich würde nicht ca. 80€ für gebrauchte Ware als günstig betrachten.

Ich habe für meine 500 USB vor ca. einem dreiviertel Jahr irgendwas bei knapp unter 30 € incl. Versand bezahlt - und das Ding ist quasi neuwertig.

Quote from GGRUB

Die Pinnacle 500-USB Box ist schwer zu bekommen.

Das stimmt, ich habe mehrere Wochen warten müssen bis ich ein Angebot gesehen habe; Momentan scheints kein einziges zu geben.

Quote from TheGenesis

hat denn niemand ne Connection nach Amiland?

Am ehesten vermutlich jemand bei forum.doom9.org.

Quote from Tom Keller

Hast du denn mal die Wiedergabe mit einem Decoder gegen getestet, bei dem die Decodierung über DXVA erfolgt?

Mit LAV tritt der Fehler bei "DXVA (copy-back)" auf, nicht jedoch bei "DXVA (native)".

CoreAVC mag den DXVA-Modus bei mir irgendwie generell nicht... sowohl MPC-HC als auch VLC hängen sich auf bzw. bleiben schwarz, wenn ich CoreAVC auf DXVA stelle.

Quote from Tom Keller

Ich glaube nicht, dass Donald Graft in dem Fall großartig was machen kann.

Naja, zumindest hat er soweit ich weiß einen guten Draht zur einigen Entwicklern bei nVidia.

Quote from Tom Keller

ist davon auszugehen, dass sich der per CUVID angesprochene Hardwaredecoder da an irgendwas "verschluckt". Ich bezweifle daher irgendwie ein wenig, dass dem Problem softwareseitig beizukommen ist...

Ich denke nicht, dass es sich um ein Problem der Hardware an sich handelt, vermutlich eher irgendwas an der CUDA-/CUVID-API, die ja hier vermutlich verwendet wird. D.h. möglicherweise ließe sich das sogar mit einem Treiberupdate seitens nVidia beheben.

Aber erstmal abwarten - möglicherweise handelt es sich ja nichtmal um einen richtigen Bug. Genauso könnte es ja auch sein, dass der Encoder der BBC Müll produziert hat, CUVID hier strikt reagiert und die reinen Software-Encoder sich aus irgendeinem Grund etwas "nachlässiger" verhalten. Oder das Ganze tritt aufgrund irgendeiner exotischen Software-Hardware-Konstellation nur bei mir auf.

Quote from LigH

(..., threads=1)

Ja, sonst gibt's einen "Insane"-Fehler. Schon etwas merkwürdig, dass man den threads-Wert dann nicht gleich standardmäßig mit 1 initialisiert, wenn man weiß, dass hier aktuell Probleme auftreten.

Quote from LigH

Wenn du DGDecNV nutzen kannst, tu das, bei solchem Material ist der deutlich zuverlässiger.

Ich hoffe, dass sich Donald Graft (oder jemand anderes mit CUDA-/CUVID-Erfahrung) mein Fehler-Beispiel im englischen Doom9 anschaut - zugegebenermaßen ist das in diesem speziellen Fall kein wirklich schlimmer Bug (sieht man kaum und taucht bisher offenbar nur in diesem einen speziellen Stream auf), aber es wäre schon blöd, wenn das nach stunden- oder tagelangen Encodes nochmal irgendwo (und dort möglicherweise schlimmer/öfter) passiert, ohne dass ich es unmittelbar bemerke.

Quote from LigH

FFMS2 ist frame-akkurat

Ich begreife immer noch nicht so ganz, was das bedeutet bzw. wie genau sich das auswirkt:

Akkurat: Verarbeitende Schicht fordert von AviSynth Frame 42 an => exakt Frame 42 der Quelle wird geliefert.
Nicht akkurat: Verarbeitende Schicht fordert von AviSynth Frame 42 an => je nachdem, irgendwas in zeitlicher Nähe wird geliefert.

Soweit klar, aber wirkt sich das auch bei purem sequenziellem Zugriff aus, also wenn ohne spezifische Sprünge (also ein simples DirectShowSource() ohne Trim() oder ähnliches) dazwischen von Frame 0 bis zum letzten angefordert wird? Also kann aus 1,2,3,4,5 z.B. 1,3,4,7,8 oder 3,2,5,4,1 werden?

Quote from Tom Keller

und diese GRF-Datei dann statt des Videos per DirectShowSource laden.

Oh, das war mir so noch nicht bekannt, danke!

An dieser Stelle anzumerken: Fürs Video-Decoding muss DirectShowSource() mit Audio=false aufgerufen werden:

DirectShowSource("test.grf", Audio=false)

da AviSynth beim Laden einer Filterkette nur einen Stream unterstützt und sonst einen Fehler wirft:

Quote

DirectShowSource: Only 1 stream supported for .GRF files, one of Audio or Video must be disabled.

Wie sieht das eigentlich hier mit der "frame accuracy" aus? Sowohl ffMPEGSource2 als auch die DGIndex-Tools legen ja vorher immer einen Index an. Spielt das nur eine Rolle, falls ich später im AviSynth-Script bestimmte Frames auswähle, die dann möglicherweise nicht exakt mit der Frame-Nummer der Quelle übereinstimmen, oder kann es ebenso passieren, dass in der DirectShow-Kette zwischendurch Frames "verschluckt" werden und fehlen, ohne dass ich irgendwie versuche auf bestimmte Frames zuzugreifen und die Quelle einfach von 0 bis Ende durchlaufen lasse?

Quote from Tom Keller

FFMS2/FFVideoSource hatte wohl schon immer Probleme mit direkt darüber geladenen Transportstreams.

Mittlerweile glaube die Ursache gefunden zu haben: Das Zappeln liegt an (offenbar zufällig) wechselnden "Frame Structs" (laut DGIndexNV) - diese wechseln bei meinen BBC One HD-Streams lustig zwischen "MBAFF" und "Fields (TFF)". Das erste Frame ist laut DGIndexNV MBAFF, dann folgen ca. 100 Frames TFF-Fields, anschließend wieder einige Frames MBAFF. Zwischendurch scheint minutenlang jedes Frame MBAFF zu sein, um für einige Sekunden von Field-Frames unterbrochen zu werden... Und genau hier scheint ffMPEGSource über die Field-Frames zu stolpern, die MBAFF-Frames sind OK.

Hierbei handelt es sich wohl größtenteils(!) um Fake-Interlacing, das Ausgangsmaterial ist ganz offensichtlich 25p, in der Bild-für-Bild-Ansicht in DGIndexNV sehe ich Vollbilder - abgesehen von den ersten paar Sekunden/GOPs, in denen offenbar "echtes" 1080i vorliegt, hier sehe deutlich Kämme, die durch Aktivierung des PureVideo-Deinterlacers verschwinden.

Auf jeden Fall scheint ffVideoSource hiermit nicht klarzukommen, unabhängig vom Container des Videostreams - ich habe auch probiert, den TS-Inhalt mit TSDoctor in ein MKV zu muxen und das zu öffnen. Das Resultat ist nach wie vor teilweise wildes "Gezappel", teilweise falsches Combing. Siehe Anhang: Dieses Frame ist eigentlich progressiv bzw. nur "fake interlaced" - schaue ich mir das in DGIndexNV mit deaktiviertem PureVideo-Deinterlacer an, sehe ich keinen einzigen Kamm.

Hallo zusammen,

meine Doctor Who-Aufnahmen von BBC One HD treiben mich gerade ein wenig in den Wahnsinn... DGIndexNV (und scheinbar alles andere, was CUDA verwendet) produziert merkwürdige Artefakte, DGIndexDI kriege ich nicht ans Laufen, da ich DiAVC nicht aktiviert bekomme und noch auf Rückmeldung vom Entwickler warte, per FFVideoSource "zappelt" das Bild größtenteils hin und her...

// EDIT: DiAVC nebst DGIndexDI läuft jetzt - und produziert am Anfang der Ausgabe einige Frames Müll...

Sollte sich hierzu keine saubere Lösung finden lassen, bleibt wohl nur noch DirectShowSource() - hier würde ich dann wohl auf LAV setzen, das zeigt sich bisher problemlos.

Frage: Hat AviSynth selbst eine Möglichkeit, die Filterkette/den verwendeten Decoder-Filter anzuzeigen - z.B. als Overlay über dem Video? Kann ich direkt in AviSynth ggf. sogar selbst irgendwie festlegen, welcher DS-Filter verwendet werden soll - abseits von Herumgefummel mit Merits?

Oder muss ich mit den DS-Filter-Merits spielen (wenn ja, womit in Windows 7? Das Windows 7 Preferred DirectShow Filter Tweak Tool scheint mir recht rudimentär und funktioniert auch nicht hundertprozentig - zumindest kriege ich damit H.264 im MPC-HC nicht mehr mit ffdshow dekodiert, seit CoreAVC und LAV installiert sind), mir das Ganze in GraphEdit anschauen und mich darauf verlassen, dass DirectShowSource() es wohl genauso machen wird?

Quote from akapuma

Es gibt bereits Kompaktkameras in der 100€-Klasse, die so etwas können, z.B. die Pentax VS20:

Hier wäre ein Test unter realen Bedingungen interessant - ohne es ausprobiert zu haben behaupte ich jetzt mal, dass Fehl- und Nichterkennungsquote selbst unter guten Bedingungen deutlich über 50% liegen dürften - je nachdem. Die Biometrie des Gesichts eines kleinen Mädchens von der eines erwachsenen Mannes zu unterscheiden, während die Gesamtauswahl an zu unterscheidenden/erkennenden Personen im einstelligen Bereich liegt, dürfte sich wesentlich einfacher darstellen als z.B. eine Person aus einer Menge von zehn oder mehr erwachsenen Männern, die sich möglicherweise recht ähnlich sehen, zuverlässig zu erkennen.

Facebook hat ja z.B. auch ein solches Feature; Die haben allerdings zusätzlich zur reinen Bildverarbeitung/-erkennung die Möglichkeit, die Erkennungswahrscheinlichkeit anhand diverser relationaler Verknüpfungen (Freundeslisten, ggf. Kenntnisse über den Aufenthaltsort einer Person zum Zeitpunkt der Foto-Aufnahme etc.) zu verbessern.

Abgesehen davon ist ein Foto nochmal was anderes als ein Video. Prinzipiell werden bei der Verarbeitung eines Videos zwar auch nur die einzelnen Bilder betrachtet, hier spielt allerdings die Performance eine erhebliche Rolle. Bei einem Foto kann sich der Erkennungs-Algorithmus alle Zeit der Welt nehmen, bei einem Video muss er vor dem nächsten Bild fertig sein. Untersuchte man aus einem 25 fps-Video nur jede Sekunde ein Bild, dürfte der Algorithmus nicht länger als eine Sekunde dauern. Um so höher die gewünschte zeitliche Auflösung, um so schneller muss die Erkennung ablaufen - auf Kosten der Präzision und/oder der Hardware-Performance.

// EDIT:

Generell ist es äußerst schwierig, den Menschen und seine Sinnesorgane zu simulieren - bei der Bilderkennung verhält sich ähnlich wie bei der Spracherkennung. Z.B. habe ich http://www.nuance.de/dragon/whats-new-version-12/index.htm in einer älteren Version im Einsatz. Auch wenn ich grundsätzlich durchaus beeindruckt von der Leistung bin, habe ich selbst unter optimalen Bedingungen (Software ordentlich "angelernt", hochwertiges Headset mit Mikrofon in bestimmtem Abstand vor dem Mund, Stille im Büro) noch eine Fehlerquote von über 20 %. Dann haben wir mal versucht, der Software Audiodateien aus einem digitalen Diktiergerät mit Außenaufnahmen (Audioqualität natürlich nicht mit direkter Aufnahme zu vergleichen, diverse Nebengeräusche wie Wind und Straßenverkehr) zu übergeben - keine Chance, mit einer Fehlerquote von ~80% völlig nutzlos.

Quote from x2001

Macht von Euch wer SDK bzw. die Programmierung dahinter und weiß, was sowas ungefähr kosten würde?

Gesetzt den Fall, dieses SDK hält tatsächlich was das Video verspricht: Äußerst(!) grob über den Daumen würde ich je nach Funktionsumfang und diversen anderen Faktoren von mindestens einem hohen vierstelligen Euro-Betrag ausgehen (so derjenige sich mit diesem SDK bereits auskennt und sich nicht zuvor noch langwierig einarbeiten muss), zusammen mit Kosten für Testaufbauten während der Entwicklung (Kamera, Beleuchtung etc.) dürfte sich das sehr schnell im fünfstelligen Bereich bewegen.

Dabei würde ich nicht davon ausgehen, dass ein solches System wirklich zuverlässig funktioniert:

Zunächst mal sind "Gesichtserkennung" (ist dies ein Gesicht - ja oder nein?) und "Gesichtserkennung" (ist dies Hansi, Susi, Peter oder Andrea?) zwei verschiedene Paar Schuhe. Ersteres ist verhältnismäßig(!) trivial (und mittlerweile auch in etlichen relativ günstigen Foto- und Videokameras enthalten, wo es recht gut funktioniert), letzteres ausreichend zuverlässig zum Laufen zu bekommen grenzt schon an schwarzer Magie - selbst unter Laborbedingungen.

Nicht umsonst wird im diesem Marketing-Video auf diverse Fehlerquellen bzw. störende Einflüsse hingewiesen - wenn du einen solchen Algorithmus mit einer 30€-Webcam im Wohnzimmer betreibst, dürfte das grundsätzlich zum Scheitern veruteilt sein. Während man unter Laborbedingungen - mit hochwertiger Kamera nebst hochwertigem Objektiv (mehrere hundert bis mehrere tausend Euro) und absolut gleichmäßiger Ausleuchtung - möglicherweise einigermaßen brauchbare/zuverlässige Resultate erzielt, kann sich das am jeweiligen Einsatzort völlig anders darstellen.

Sprich: Als Privatperson "zum Spaß" kannst du das vergessen - es sei denn, du bist tatsächlich gewillt, einen mindestens fünfstelligen Betrag in etwas zu investieren, für dessen Zuverlässigkeit vermutlich niemand die Hand ins Feuer legen möchte.

Quote from TheGenesis

Darf man fragen, was du da alles reingepackt hast?

Die "üblichen Verdächtigen": Szenen mit vielen schnellen Bewegungen/Details, Szenen mit Nebel/Rauch und einige ruhige Sequenzen mit größeren, unbewegten Flächen. Das habe ich jetzt einfach mal als meinen persönlichen, repräsentativen "Standard" festgelegt.

Quote from Chetwood

Hab mich schon immer gewundert, wie man mit Standbildern die Effizienz der Kodierung von Bewegtbildern einschätzen will

Indem man sich bewusst ist, dass ein Bewegtbild aus einer Anreihung von Standbildern besteht.

Sagen wir so: Qualitative Bewertungen von Videos sind grundsätzlich subjektiv - zwar lässt sich mit SSIM, PSNR oder ähnlichem auch ein objektiver Vergleich anstellen, ein solcher "synthetischer" Wert muss allerdings noch lange nichts darüber aussagen, wie Person w mit Sehstärke x im Abstand y vor Gerät z die Qualität wahrnimmt.

Ein direkter Vergleich zweier Standbilder des gleichen Frames ist zunächst mal deutlich einfacher und präziser als zwei Videos nach- oder nebeneinander zu betrachten - jedes Bild im PAL-Video wird nur 0,04 Sekunden angezeigt (bei einem direkten Vergleich an zwei verschiedenen Stellen auf einem oder zwei Wiedergabegerät/en, bei einem aufeinanderfolgenden Vergleich in einem zeitlichen Abstand), meine Standbilder wechseln direkt zwischen Original und Encode an der selben Stelle auf dem Monitor in einem per Mausklick frei wählbaren Zeitraum.

Ob man die Unterschiede bzw. den Qualitäts-/Detail-Verlust und die ggf. vorhandenen, sichtbaren Makroblock-Grenzen beim Abspielen tatsächlich als so signifikant wahrnimmt wie bei einem Vergleich der Einzelbilder steht auf einem anderen Blatt. CRF und diverse andere Settings/Features moderner Videokompressions-Algorithmen setzen ja beispielsweise darauf, Verluste psychovisuell möglichst zu "verstecken", z.B. in schnell wechselnden Bildfolgen mit viel Bewegung, wo sie dem Betrachter möglichst kaum bis überhaupt nicht auffallen. Habe ich mir nun zufällig ein solches Frame herausgepickt, sieht das Resultat als Standbild-Vergleich möglicherweise schlecht aus, obwohl man den Unterschied im laufenden Video deutlich weniger bis überhaupt nicht wahrnimmt.

Andersherum kann ich mir kaum vorstellen, dass ich ein abgespieltes Video als qualitativ schlechter empfinde als den direkten Vergleich der einzelnen Frames. Natürlich sollte man die Videos auch nochmal "laufend" vergleichen, allerdings werden Unterschiede/Verluste zwischen den Videos bei einem Standbild-Vergleich tendenziell immer signifikanter hervortreten. Sprich: Um so weniger Unterschiede zwischen den einzelnen Frames ich erkenne, um so näher bin ich am Original - mein subjektiver Qualitätseindruck des abgespielten Videos ist möglicherweise besser, dürfte aber kaum schlechter sein. Das ist aus meiner Sicht die "objektivste Subjektivität".