in letzter Zeit wieder häufige Abstürze beim Schnitt

[Cypheros]

Das mit den I-Frames ist leider nicht so einfach, da Microsoft leider vergessen hat dies in seine API mit einzubauen. Aber ich verfolge da einige vielversprechende Ansätze um dies zukünftig eine visuelle Anzeige des Frame-Typen zu bekommen.

[Mam]

Das mit den I-Frames ist leider nicht so einfach, da Microsoft leider vergessen hat dies in seine API mit einzubauen. Aber ich verfolge da einige vielversprechende Ansätze um dies zukünftig eine visuelle Anzeige des Frame-Typen zu bekommen.

Kopf hoch! Mann wächst ja an seinen Aufgaben, nicht? 

Außerdem kommst Du ohne die Info eh nicht weiter, Du musst ja genau die Stellen wissen, zwischen denen neu zu kodieren ist, und das sind nun mal die IFrames.

[Cypheros]

Hi, I-Frames kann ich im Stream problemlos erkennen, was ich ja auch beim Schnitt von H264-Aufnahmen benutze.
Doch wenn ich die Vorschau über DirectShow mache, dann weiß ich nicht welches Bild exakt zu welchem Teil des Streams behört. Wiedergabereihenfolge und Streamreihenfolge sind unterschiedlich und es werden auch Bilder gepuffert.

[Mam]

Hi, I-Frames kann ich im Stream problemlos erkennen, was ich ja auch beim Schnitt von H264-Aufnahmen benutze.

Föhn!, aah schön!
Wie wäre es mit folgender Logik:

a) dekodiere alle Frames zum Zeitpunkt X wobei IFrame1 < X und IFrame2 > X (lege alle Bilder in nen Puffer ab) (Die IFrames sind jeweils ZWEI IFrames von X entfernt)
b) Zeige als Bilder in der Leiste an X-5 bis X+5
c) lasse den bösen User wuseln (auch immer wieder gerne schwungvoll mit dem Mausrad, das ist echt entspannender, als Klickorgien)
d) klickt er im PLUS Bereich, so verschiebe die angezeigten Bilder nach links (wird dabei IFrame2 >X übersprungen, so die ersten Bilder im Puffer löschen, die ganze Liste aufrutschen, und hinten die neuen Bilder anhängen. Anschliessend wieder nach B)
e) klickt er im MINUS Bereich, so wie in d beschrieben, nur genau andersherum (also nach rechts scrollen, hinten löschen, neue dekodierte Bilder hinten anhängen) und ebenfalls wieder ab nach B)

Sollte der böse User einen Schnittpunkt setzen, enthält Dein Puffer schon genau die neu zu kodierenden Bilder, also spar keinen Speicher und dekodiere sie in voller Auflösung in den Puffer. Du wirst sie irgendwann brauchen.

(Damit das Ganze nicht zu einfach wird, musst Du das mit den Tonspuren genauso halten, wobei PCM wohl kein Problem sein sollten, bei AC3 weis ich nicht, aber da kann man eventuell ein paar ms Ruhe einfügen?)

Apropos Ton 
Wo ich doch gerade beim Wünschen wäre.... 
Hust, Hust..
Wie wäre es unter der Einzelbildleiste noch mit einem VU Meter vom ersten PCM Kanal? Bei langen Schwarzblenden verliert man beim Schnitt manchmal die Orientierung....
(nur mal so ein Gedanke...)

Ach ja, noch was, wo ich schom beim Kaffee ins Träumen komme...
Bei dem ganzen Videokram mit den großen Dateien, da wird es doch mit 32Bit öfters sehr umständlich, nicht war? Irgendwann mal umsteigen auf 64Bit, das spart viel Tipparbeit....

[Cypheros]

Hi, bei HD mit 1920x1080 x 3 (RGB)  x 25 FPS sind das 155.520.000 also 155MB pro Sekunde.

[Mam]

Hi, bei HD mit 1920x1080 x 3 (RGB)  x 25 FPS sind das 155.520.000 also 155MB pro Sekunde.

Ja? und ?
a) Du brauchst ja gar keine ganze Sekunde, oder, wie weit sind 3 IFrames voneinander entfernt?
b) "Size does not matter", meine kleine Spielkiste hier hat 8Gb, aber es gibt auch deutlich grössere Kisten hier (32Gb). Nur mit 32Bit Programmen hilft Dir das nicht viel weiter, da ist dann bei max 3Gb Ende (eigentlich ja nur 2Gb).
c) was ist schon 1Gb Puffer unter Freunden? 

[Cypheros]

Naja es gibt auch User, die nicht so gut bestückt sind wie Du 

Zur Zeit reduziere ich die Auflösung bei der Einzelbild-Ansicht und benutze das YUY2-Format um mit 2 Byte pro Pixel auszukommen.

Aber trotzdem bleibt das Problem, dass ich zwar hinter dem Videodecoder die Bilder abfangen kann, mir der Decoder aber nicht sagt ob es sich um ein I/P oder B-Frame handelt.

[Mam]

Naja es gibt auch User, die nicht so gut bestückt sind wie Du 

Also die Tendenz geht ja wie immer zu MEHR und BILLIGER. Ich glaub, 8Gb sind jetzt so bei 30-60€ ? (schon lange kein Ram mehr gekauft).
Das Problem wird mehr und mehr die 32Bit Grenze.

Zur Zeit reduziere ich die Auflösung bei der Einzelbild-Ansicht und benutze das YUY2-Format um mit 2 Byte pro Pixel auszukommen.

Löblich, aber ich bin überzeugt, Du wirst es bereuen. Irgendwann willst Du wirklich wieder die Einzelbilder zusammensetzen und darfst dann das Ganze nachholen. Und da Du nur bei einem IFrame aufsetzen kannst, musst Du dann eh wieder alle Bilder bis zum Schnittpunkt neu berechnen lassen, und darfst sie dann wegschmeissen.
Außerdem kostet die Quetscherei nur ekelig viel Rechenzeit und verzögert die GUI.

Aber trotzdem bleibt das Problem, dass ich zwar hinter dem Videodecoder die Bilder abfangen kann, mir der Decoder aber nicht sagt ob es sich um ein I/P oder B-Frame handelt.

Leider kenne ich mich mit den einschlägigen APIs nicht aus, und kann Dir da nicht helfen. So rein intuitiv (aus fast 30 Jahren "Programming with Mikrosaft") würde ich persönlich GAR NICHTS von denen verwenden, sondern vielleicht mal einen Blick auf VLC werfen. Die bieten auch Libs & APIs an und die sind vielleicht länger gültig, als M$ Kram.