---

Geschrieben von piwi_6 am 21.03.2007 um 14:19:

  Hab am Ende eines Clips immer 2 grüne Frames:-(

Hallo in die Runde,
nachdem das beim letzten Mal so super geklappt hat, ( nochmal Dank an Selur!!) versuch ich es jetzt mit dem nächsten Problem.
Wie schon mal beschrieben schneiden wir aus einer 2 GB Xvid Datei kleinere Clips heraus ( ausführlicher ist es hier beschrieben:
Xvid Codec verschiebt Bild und Ton um 2 Frames
und nun haben wir das Phänomen, dass bei einigen Clips die letzen beiden Frames komplett grün sind. Dies passiert aber nur, wenn wir die clips mit unserer eigenen Software schneiden, die mit directshow arbeitet. Schneide ich denselben Clips mit VirtualDub entstehen die grünen Frames nicht. Soweit ich weiss arbeitet virtual Dub mit Video for Windows, oder stimmt das nicht (oder nicht mehr) ?
Wir haben die maximale Keyframerate auf 20 gesetzt und wenn ich z.B. einen Clib mit 235 frames schneide, wird Frame 234 als Keyframe gesetzt, dieser ist dann grün und der letzte 235 ist ebenfalls grün. Aber eigentlich sollta ja der Frame 220 der letzte Keyframe sein, oder?
Vielen Dank schon mal im voraus!!

---

Geschrieben von Selur am 21.03.2007 um 14:26:

 

Zitat:

Soweit ich weiss arbeitet virtual Dub mit Video for Windows, oder stimmt das nicht (oder nicht mehr) ?

Stimmt.

Zitat:

Wir haben die maximale Keyframerate auf 20 gesetzt und wenn ich z.B. einen Clib mit 235 frames schneide, wird Frame 234 als Keyframe gesetzt, dieser ist dann grün und der letzte 235 ist ebenfalls grün. Aber eigentlich sollta ja der Frame 220 der letzte Keyframe sein, oder?

Der maximale Keyframeabstand legt nur ein Maximum fest, d.h. ohne das Material zu kennen kann man da nix sagen.

Zitat:

nun haben wir das Phänomen, dass bei einigen Clips die letzen beiden Frames komplett grün sind. Dies passiert aber nur, wenn wir die clips mit unserer eigenen Software schneiden

Achtet ihr auch darauf, dass ihr nur an Keyframes schneidet?

Cu Selur

---

Geschrieben von piwi_6 am 21.03.2007 um 15:06:

 

Also eigentlich schneiden wir nicht unbedingt von keyframe bis keyframe. Unsere Schnittgrenzen sind durch die Handlungen der Patienten im Video bestimmt.
Wir schneiden zuerst ein Stück mit Übermaß heraus, wandeln das in unkomprimiertes DV format, und daraus schneiden wir dann wieder das Stück heraus,das wir brauchen.

---

Geschrieben von Selur am 21.03.2007 um 16:54:

 

Zitat:

Also eigentlich schneiden wir nicht unbedingt von keyframe bis keyframe.

Das könnte zum Problem werden.

Zitat:

Wir schneiden zuerst ein Stück mit Übermaß heraus, wandeln das in unkomprimiertes DV format

So lange ihr in einem Keyframebasierten Format editiert dürft ihr nur von Key-frame zu Keyframe schneiden, ansonsten entstehen am Ende nicht decodierbare Frames, die bei einem Reencoden dann grün oder sonst was werden können.

Cu Selur

---

Geschrieben von piwi_6 am 22.03.2007 um 10:36:

 

Aud diesem Grund decodieren wir das Stück, das wir rausschneiden wollen erst wieder ins DV- Format, wo dann jeder Frame ein Keyframe ist, um dann wieder Xvid draus zu machen.

---

Geschrieben von piwi_6 am 22.03.2007 um 10:42:

 

Also wir machen aus dem DV band eine ca. 13 GB grosse AVI datei (eine Stunde Film) mit Adobe Premiere, dann komprimieren wir diese Datei mit Xvid auf 2 GB (max Keyframe 20, target bitrate so eingestellt, dass wir 2 GB bekommen) , dann nehmen wir diese datei, suchen das Stück, das wir schneiden wollen raus, decodieren dieses zurück in DV-Format und komprimieren das dann wieder in Xvid.
Direkt zu schneiden und dann immer von Keyframe zu Keyframe ist etwas problematisch, weil die Clips, die wir schneiden teilweise nur wenige Sekunden lang sind. einige Beispiele sind zu sehen auf unserer Homepage unter:
http://www.charite.de/bml/main.php?action=research&bid=14&showres=con&page=1

---

Geschrieben von scrat am 22.03.2007 um 13:05:

 

hey!

warum schneidet ihr nicht gleich mit adobe premiere und komprimiert dann nach xvid?


mfg
scrat

---

Geschrieben von piwi_6 am 22.03.2007 um 14:02:

 

weil wir gleichzeitig noch Datenfiles auslesen, und diese Daten sind codiert auf der Tonspur, das läuft über selbstentwickelte Soft- und Hardware, damit aus diesen Tönen (Pulsintervallmodulierte Signale) dann eine Ascii- Datein gemacht werden kann

---

Geschrieben von Selur am 22.03.2007 um 18:02:

 

Also ihr macht folgendes:
1. Original DV Material nach Xvid (Mit Adobe Premiere)
2. Diesen Clip öffnet ihr dann mit eurer eigenen Software, wählt einen Bereich aus, speichert diesen Teil wieder als DV-avi und lest gleichzeitig Daten aus dem Audiostream aus.
3. Ihr komprimiert das DV-Avi wieder nach Xvid.

Richtig? Oder öffnet ihr mit eurer Anwendung erst das erste xvid avi?

Davon ausgegangen ich habe es richtig nachvollzogen habe ich die Vermutung, dass ihr einen Fehler in eurer Software beim Dekomprimieren und anschließenden Komprimieren nach Xvid macht. Falls ihr B-Frames in Xvid erlaubt, deaktiviert diese. Es könnte sein, dass im ersten Xvid dort wo ihr schneidet ein B-Frame ist, da B-Frames aber nicht nur forward-references haben kann es sein, dass da etwas mit dem Videobuffer nicht richtig läuft und deshalb das B-Frame nicht richtig dekodiert wird und ihr so gründe Frames erhaltet.

Cu Selur

---

Geschrieben von piwi_6 am 03.04.2007 um 09:50:

 

Soweit ist fast alles richtig, wir nehmen die DV Datei ( ca 1 h, 13 GB) komprimieren sie mit Xvid, so dass wir eine 2 GB Datei bekommen ( 1 h), dann öffnen wir diese mit unserer Software, suchen einen Clip ( ca 20 sec ) raus, dieser wird dann mit übermass wieder decomprimiert, also nicht DV Codec.
Und dann wird dieser Clip mit unserer Software in XVid komprimiert und sollte dann fertig sein zur Veröffentlichung im Internet, wobei wir gerade am überlegen sind, evtl. auf WMV umzusteigen, da die Leute, die sich nachher die Ergebnisse unserer Forschung im Internet ansehen ( Ärzte, Physiotherpeuten etc. ) oft keine Admin-Rechte haben und daher den Xvid COdec oft nicht installieren können.

Mit den B-Frames ( das sind doch B-VOPs, oder?) hatten wir schon mal Probleme
Xvid Codec verschiebt Bild und Ton um 2 Frames
als diese der Grund dafür waren, dass sich Bild und Ton um 2 frames verschoben haben. Diese haben wir damals dann komplett rausgenommen nach dem Tipp von Selur ( Danke nochmal:-) )

---

Geschrieben von Selur am 03.04.2007 um 10:50:

 

Zitat:

B-Frames ( das sind doch B-VOPs, oder?)

Ja Aus irgendeinem Grund werden sie bei MPEG4 eigentlich Korrekterweise B-VOPs genannt, da es aber nichts anderes sind als B-Frames,...

Zitat:

dann öffnen wir diese mit unserer Software, suchen einen Clip ( ca 20 sec ) raus, dieser wird dann mit übermass wieder decomprimiert

Sind die grünen Frames schon beim unkomprimierten Material zu sehen? Vielleicht läuft etwas beim Dekomprimieren schief.

Cu Selur

Ps.: WMV hat vor allem den Vorteil, dass keine Lizenzgebühren und der gleichen Anfallen, so lange man keinen echten Streamingserver da hat.

---

Geschrieben von piwi_6 am 03.04.2007 um 12:20:

 

Hallo,

ich hab mir grad einen der temporären (dekomprimierten) Clips angesehen. Darin ist noch kein grüner Frame zu sehen. bei den Eigenschaften steht allerdings, dass er "MS-YUV"codiert ist!?!

---

Geschrieben von piwi_6 am 03.04.2007 um 13:17:

 

So hier nochmal ein kleines update zu dem Problem.
Wir haben jetzt ein wenig mit den Einstellungen des Decoders herumgespielt. Die Grünen frames kommen nur, wenn wir mit YUY2 und YV12 decodieren. Wenn wir stattdessen RGB 24 oder RGB 32 nehmen, sind die beiden letzten Frames Schwarz und nicht grün. ( bie "no Force" sind sie auch Gruen)
in allen Fällen haben wir dan Häkchen Compatibilitiy Renderer angeklickt.

---

Geschrieben von Selur am 03.04.2007 um 14:08:

 

Ich könntet mal einen Verlustfreien Codec der Yv12 unterstützt zum Encoden nehmen.

Kann natürlich sein, dass es Probleme bei der Farbumwandlung gibt.

Cu Selur

---

Geschrieben von piwi_6 am 03.04.2007 um 17:05:

 

Meinst du damit z.B. den SonyDv Codec?
WIr haben auch die Idee gehabt, die Position des letzten Keyframes zu bestimmen, so daß dieser eben nicht im vorletzten Frame ist. Kann natuerlich aber auch( wenn es denn überhaupt geht) zur Folge haben, dass trotzdem alle Frames nach dem letzten Keyframe grün sind. Aber bisher haben wir das Problem nur, wenn der vorletzte Frame ein Keyframe ist. bei einem Clip von 250 Frame z.B. sollte ja eigentlich bei Keyframe abstand 20 der Frame 240 ein Keyframe sein. Bei uns ist aber der Frame 249 Keyframe (Grün) und 250 ist auch grün.
Komischerweise tritt dieser Effekt das IMMER der vorletzte Frame Keyframe und damit auch Grün ist nur bei einigen der 2GB Dateien auf und zwar bei denen, die bis zu einem bestimmten Datum gemacht wurden. Bei denen die danach entstanden, tritt der Effekt nur dann auf, wenn zufällig der vorletzte Frame ein Keyframe ist ( Bei einem Clips von 250 Frame nicht, sondern nur bei z.B. 241 Frames)
Wir haben auch schon eine der "alten" 2GB Dateien neu von der Kasette digitalisiert, auf 2 Gb komprimiert, und daraus geschnitten, aber auch das half nicht:-(

---

Geschrieben von Selur am 03.04.2007 um 19:31:

 

Zitat:

bei einem Clip von 250 Frame z.B. sollte ja eigentlich bei Keyframe abstand 20 der Frame 240 ein Keyframe sein.

Nur wenn der Codec nicht selbständig vorher mal ein Keyframe setzen will. 20 wäre ja nur das Maximum.

Zitat:

Meinst du damit z.B. den SonyDv Codec?

Eher den huffyuv Codec der mit ffdshow kommt.

Cu Selur

---

Geschrieben von piwi_6 am 04.04.2007 um 11:04:

 

Könnte man dem Codec denn über irgendeine Einstellung sagen, das er nicht willkürlich einen Keyframe setzten darf?
Bezüglich des ffdshow-huffyuv Codecs hatten wir uns eigentlich gedacht, dass wir lieber den Xvid codec zum codieren und zum decodieren nehmen, weil das wohl die geringsten Probleme bringt, oder ist die Überlegung grundsätzlich falsch?

---

Geschrieben von Selur am 04.04.2007 um 12:27:

 

Zitat:

Könnte man dem Codec denn über irgendeine Einstellung sagen, das er nicht willkürlich einen Keyframe setzten darf?

Nein, da man kein Minimum für die GOP-Größe=I-Frame Abstand setzen kann. Wenn ihr ffdshows Mpeg4/Xvid-Variante nehmt geht das. (habe ich gerade mal geguckt)

ffdshow-huffyuv hatte ich als Ersatz für den DV-Codec im Sinn, da DV-Codecs gerne mal so ihre Eigenarten haben.

Zitat:

wir lieber den Xvid codec zum codieren und zum decodieren nehmen, weil das wohl die geringsten Probleme bringt, oder ist die Überlegung grundsätzlich falsch?

Nein die Überlegung ist an sich nicht falsch stellt nur beim Encoden anscheinend das Problem mit der GOP-Größe dar.

Cu Selur

---

Geschrieben von piwi_6 am 05.04.2007 um 09:41:

 

Zitat:

ffdshow-huffyuv hatte ich als Ersatz für den DV-Codec im Sinn, da DV-Codecs gerne mal so ihre Eigenarten haben.

wir sind natuerlich ein wenig an den DV Codec gebunden, da wir den Film von einer DV Casette holen. damit wäre jeder andere Codec nur ein weiterer Schritt im Prozess, der wahrscheinlich wieder eneue Probleme in sich birgt.

---

Geschrieben von Selur am 05.04.2007 um 13:40:

 

Nochmal Zusammenfassen:

1. von der Camera auf die Platte (-> DV-Material SonyDVCodec, 1 h ca. 13 GB)
2. Umwandeln des DV-Materials mit Adobe Premiere nach Xvid (1h ca. 2GB)
3. Öffnen des Xvid Streams mit eurer Software, Auswahl von ca. 20 Sekunden Material und unkomprimiertes Speichern
4. Öffnen des unkomprimierten Clips und komprimieren des selbigen als Xvid/WMV.

=>
a. Bis zu Schritt 3 ist kein Problem mit grünen Frames auf. (Hier sind alle Frames zu sehen.)
b. Je nach Einstellung im Decoder erscheinen die Frames nach dem letzten I-Frame grün oder schwarz, gehen aber verloren.

Hoffe das stimmt jetzt alles.

Man könnte mal, erstmal zum Test, gucken ob es eventuell hilft das Material im Zwischenschritt mit ffdshow-huffyuv anstatt unkomprimiert zu speichern, so würde keine Yv12->RGB Wandlung passieren und man wüsste ob es an dieser Wandlung liegt.

Cu Selur