ZFX + Developia

Ahoi

hier lungert ja so allerlei geballtes Wissen rum, da wird doch bestimmt auch jemand dabei sein, der sich mit Video, Streams und Decoding / Encoding auskennt :mrgreen:

Ich spiele gerade ein wenig mit AVCHD Streams und da juckt es mich natürlich in den Fingern, das Dekodieren und Anzeigen der Videos nicht immer anderen Applikationen zu überlassen. Intel bietet da ja ein nettes Media SDK mit Decoding / Encoding an, das ich mir grad anschaue. Demuxen kann das leider nicht, aber immerhin Dekodieren für lau. Beim Parsen des Streams und dem Füttern des Decoders scheint es mir aber so, dass die Größe und z.T. auch die Position der einzelnen Frames in dem Bistream nicht wirklich vorhergesagt werden kann.

Meine konkrete Frage im Moment ist, wie man beispielsweise einfach mal zu, sagen wir, Frame 459 von 12407 springen und den Frame anzeigen bzw. das Video ab dieser Stelle abspielen kann.

Ich kann den Stream zwar von Beginn an dekodieren und das Video als einzelne Frames abspielen. Aber wenn ich gleich von 0 auf 100 bzw. auf Frame 459 hopsen möchte, ohne 0-458 zu dekodieren, ginge das überhaupt? Einen Frame kann man ja zum Teil nur mit Informationen aus vorherigen Frames dekodieren wenn ich das Format richtig verstanden haben ... ? Wie machen das Media Player oder Schnittprogramme, wenn man den Slider zum Abspielen einfach mal an eine beliebige Stelle setzt?


Fragen über Fragen .... :roll:
Ciao,
Stefan

Ich kann dir mal ganz kurz was zum "zu Frame X springen" sagen: Es gibt sogenannte Key-Frames, die komplett gespeichert werden, also nicht von den vorherigen Frames abhängen. Um zu Frame X zu springen, musst du also den letzten Keyframe vor X decodieren und ab da jeden Frame bis zu X, da die alle anderen Frames durch Prädiktion inkrementell aufeinander aufbauen.

Ah, Danke. Das hilft schon mal als Info weiter. Sind die Keyframes denn so verteilt, dass man deren Positionen im Stream ausrechnen kann bzw. steht diese Info auch irgendwo in dem Stream Header drin? Wenn man die Keyframes auch erst suchen muss dann hätte man ja wenig gewonnen, außer dass man dann eine definierte Stelle hat ab der man erst decodieren muss :)

Soweit ich das weiß nein. Da der Inhalt der Frames dazwischen in seiner größe nicht definiert ist. Man hat ja bei wenigen Veränderungen eine hohe Kompressionsrate und bei vielen Veränderungen eine geringere, natürlich auch immer eine Frage des Formats.
Es müsste aber an jedem Frame einen header geben, der Auskunft über die Grölße gibt. Oder sind die Key-Frames verlinkt? Würde sinn machen. Die Key-Frames werden ja immer alle N-Frames dazwischen gepackt. Damit kann man dann ausrechnen wieviele Key-Frames man skippen kann und am wann man dann aus dem Key-Frame und den folgenden Frames Bilder erzeugen muss.

Irgendwie so läufts.

Es muss ein schnelles Verfahren geben, weil in solchen Tools wie cinelerra ja jedes Bild dargestellt werden kann und du Bild für Bild dadurch scrollen kannst. Auch beliebig Positionieren und so was alles. Da wäre ein rein sequentielles abarbeiten eine schlechte Lösung.
Wobei cinelerra aber eine TOC vom Videostream erzeugt. Wahrscheinlich die Positionen der Keyframes oder anderer für die Bildsuche wichtige Informationen.

Genug gelabert.

Also bei MPEG heißen die Keyframes I-Frames: http://en.wikipedia.org/wiki/MPEG-1#I-frames
Es scheint bei jedem Frame eine Art Header-Flag zu geben, ob I-, B-, P- oder sonstwas-Frame. Du müsstest also vom aktuellen Frame aus rückwärts die Frames nach dem nächsten I-Frame durchsuchen. Bei MPEG-1 stand bei, dass diese I-Frames alle 14-17 Frames kommen, allerdings neuere Encoder da auch Freiheiten haben, um die Abstände zu vergrößern, wenn sich nicht so viel ändert etc.

Vor einigen Jahren hatte ich mal die Aufgabe ein Debugging-Tool für die Analyse von MPEGI und II Streams zu schreiben. Mein etwas angestaubtes Wissen zu dieser Thematik sieht so aus: In dem Stream dürften keine Informationen vorliegen die es erlauben eine bestimmte Position (sei es Zeit oder Bild-Index) direkt anzuspringen. Ohne separatem Index geht das auch nicht wegen der hier ja bereits erwähnt an der variablen Größe der Einzelbilder (Bytes pro Sekunde sind alles andere als konstant). Eine gängige Methode scheint die binäre Suche im Stream zu sein, bei der man nach jedem Sprung wieder solange demuxed bis mal was mit einem Zeitstempel vorbeikommt. Anhand von diesem kann man sich dann für den nächsten Schritt der binären Suche entscheiden.

Es gibt aber sicher auch Formate die da mehr Untertützung leisten. Kann sein das die binäre Suche auch nur ein Fallback ist. Aber bei on-the-fly-encoding weiß man ja vorher nicht an welcher Byte-Position welcher Frame gespeichert sein wird und kann demzufolge schlichtweg keinen Header mit Index-Informationen anhängen. Wenn in eine Datei gespeichert wird könnte man das natürlich nachträglich machen.

Einfache Bildbearbeitungsprogramme erlauben nur das schneiden an I-Frames. Das lieg daran das sie an diesen Stellen einfach den Datenstrom kappen können ohne den Decoder zu stören. Ansonsten müssten sie das Bild erst dekodieren und dann selbst einen I-Frame enkodieren, was erstens verlustbehaftet ist und zweitens eine lizenz für einen Encoder erfordert (da bin ich nicht ganz sachkundig, aber dieser ganze Codec-Kram steht ja bekanntlich unter der Terrorherrschaft von Patent-Nazis).

Praktisch gesehen sollte die API eines brauchbaren Multimedia-SDKs aber so was wie eine seek-Funktion abieten die dann so effizient ist wie es die verwendeten Daten eben erlauben.

Danke für den ganzen Input. Ich habe leider kein wirklich eindeutige Beschreibung des AVC Formats gefunden wo solche Dinge für "Laien" verständlich stehen. Und dass der ganze Kram dann noch in einem Container steckt und mit dem Audio zusammengewürfelt ist macht es auch nicht leichter. Aber das bestätigt meine Befürchtung, dass man sich die Daten erstmal selber irgendwie indizieren muss. Und dann halt leider vom nächstvorherigen I-Frame zu der gewünschten Stelle hindecodieren.

Da muss ich wohl erstmal ein paar Performancetests mit dem Software-Decoder machen. Im Sinne des Think-Big möchte man ja auch mit größeren "Projekten" sinnvoll arbeiten können. In Adobe Premiere habe ich bei (für mich) größeren Projekten locker 20 GB an Videodaten von denen im Zuschnitt gut ein Viertel verwendet wird. Und das ist der noch komprimierte Video- und Audio-Stream. Das schließt schon mal den Ansatz aus, sich die dekodierten Frames irgendwo zu cachen. Da muss man wohl direkt on-the-fly dekodieren und rendern *grml*

Und das wiederum heisst wohl, jede Videodatei erstmal demuxen, dekodieren und I-Frame Positionen mitschreiben.

da bin ich nicht ganz sachkundig, aber dieser ganze Codec-Kram steht ja bekanntlich unter der Terrorherrschaft von Patent-Nazis

Also den Terror und die Nazis würde ich erstmal streichen. Aber ich kann dich da gerne sachkundiger machen. Jeder einzelne Codec wurde von jemandem entwickelt und patentiert. Möchte man den Codec verwenden dann benötigt man dafür eine Lizenz die einem das erlaubt. Die Preise variieren dabei je nach Format (professionelle Broadcasting Codecs kosten entsprechend mehr) und nach Menge. Wenn man viele Lizenzen kauft wird's billiger ;) Wenn man Freeware Produkte entwickelt kann das bei den Consumer-Formaten wie AVC u.U. auch kostenfrei sein.

Für das Geld hat man aber außer einem Nutzungsrecht noch gar nix. Bei Bedarf muss man also gfs. noch für ein Decoder/Encoder/Transcoder SDK Geld bezahlen. Auch hier gelten dieselben Kriterien wie bei den Nutzungsrechten. Je professioneller desto teurer und je mehr desto günstiger je Stück. Ich spiele aber gerade mit dem Intel Media SDK welches man kostenfrei benutzen kann. Das kann Decoding/Encoding/Transcoding aber leider kein De-/Muxing. Hardwarebeschleunigt ist es auf Intel-CPU mit integrierten Intel Grafikprozessor, aber es gibt auch einen Software-Fallback für armselige Rechner wie meinen Desktop Core i7 der nur eine kleine Nvidia GeForce Karten anstelle eines fetzenden Intel GMA hat :D

Aber im CUDA SDK soll es gerüchteweise auch einen h264 De-/En-/Transcoder geben mit dem man seiner Hardware immerhin auf Nvidia Grafikkarten Beine machen könnte.

Um noch mal auf die Terroristen zu sprechen zu kommen: Im Gegensatz zu den verpönten Software-Patenten auf allgemeine Algorithmen, GUI-Elemente oder ähnliches habe ich kein Problem damit, dass man Codecs lizensieren muss. Immerhin ermöglichen diese kleinen Racker eine erstaunliche Bildqualität bei erstaunlich geringer Datenmenge. Das hat sich jemand schon schlau überlegt und soll damit auch zu Recht Geld verdienen. Es ist ja niemand gezwungen das zu benutzen, aber allein der Verbreitungsgrad trotz der Kosten zeigt wohl, dass es im Broadcasting und Entertainmentbereich keine vernünftigen Alternativen gab. Im Zeitalter des Geiz ist geil hat sich leider zu sehr die Mentalität festgesetzt, dass man alles sofort für umsonst in bestmöglicher Qualität haben möchte. Aber Geld für seine eigene Arbeit möchte trotzdem jeder so viel wie möglich bekommen. Irgendetwas passt da kopfmässig nicht zusammen.

Aber zurück zum Thema. Ich komme wohl um ein Preprocessing der Daten nicht umhin. Damit brauche ich mir immerhin um zu viel Freizeit an den kommenden Abenden keine Sorgen zu machen :D

Weitere Kommentare sind natürlich jederzeit willkommen. Vor allem wenn jemand schon Erfahrungen im Schneiden von Video-Streams hat ... also in der Programmierung von Schnittprogrammen meine ich.

Ciao,
Stefan

PS: Gerade eben beim Studieren des MPEG Transport Stream Containerformats gefunden: Camcorder haben die üblichen 188 Byte Pakete eines MTS um jeweils 4 Byte ergänzt. Diese enthalten einen Timecode der wohl eine Zeitangabe und Framenummer repräsentiert. Das liest sich doch schon mal vielversprechend :)

Naja... also deine Darstellung der Patentproblematik scheint mir doch etwas zu beschönend. Es ist ja nicht so das irgend welche hart arbeitenden Codec-Entwickler Dekaden in dunklen Kellern getüftelt haben um uns dann das einzige brauchbare Verfahren anbieten zu können für das sie nun in alle Ewigkeit entlohnt werden müssen. Bei einem ehrlichen Preis-Leistungsverhältnis zahl ich doch gern, da ist nichts mit Geiz-Ist-Geil-Alles-muss-umsonst-sein. Aber man soll doch bitte keine alternativen Entwicklungen behindern.

Das Problem ist aber das die ganzen Techniken so breitbandig durch Patentansprüche vermint sind das es kaum mehr möglich ist einen patentfreien Codec zu entwickeln. Das bedroht z.B. Theora. Auch Webm ist bedroht. Von daher finde ich es nicht ganz unpassen zu sagen das solche Entwicklungen durch die Patenansprüche "terrorisiert" werden.

Wenn du was in richtung Schnitt-Software anschauen willst, dann kannst du cinelerra nehmen. Das ist open-source und funktioniert ganz gut. Scheint auch mittlerweile besser dokumentiert zu sein, als noch vor ein paar Jahren.
Speicherfresser sind solche Tools immer.
Ich benutze cinelerra wirklich nur äusserst selten, einfach weil ich vom Videoschnitt sowas von keine Ahnung habe, aber es ist immer wieder eine Freude, wenn ich mal wieder was von dem Tool verstanden habe.

Ich möchte es gerne weitgehend vermeiden, mir Sourcen von anderen Tools anzuschauen. Das verhindert das Produzieren eigener Ideen :)

Wenn der Timecode das sagt, was er angeblich tun soll, dann wäre das ein guter Ansatz direkt an eine fast beliebige Stelle im Stream zu springen und dann von dort aus zu dekodieren. Im Moment scheine ich zwar alle Infos in dem MTS Container korrekt zu parsen, aber wie ich den Timecode interpretieren soll ist mir noch ein Rätsel. Das sind vier Byte die HH:MM:SS::FRAME enthalten sollen. Aber die Werte die ich darin finde ergeben so erstmal keinen Sinn :-(?)

@Codec Terror
Die Behinderung anderer, freier Codecs ist ein anderes Thema. Mir ging es darum nicht gleich gegen alles zu sein was etwas kostet, was man aber gerne umsonst nutzen möchte. Ein h264 hat beispielsweise u.a. den Vorteil, dass es in Hardware und auch bei Software Lösungen und Middleware SDK sehr verbreitet ist. Da stecken viele Leute viel Geld rein und natürlich wollen dann auch viele damit etwas verdienen. Das finde ich legitim.

Ciao,
Stefan

VLMC ist ein Non-Linear Editor der auf derselben Code Base wie der VLC Media Player aufbaut (noch nicht downloadbar - Projektseite: http://www.videolan.org/vlmc/) und transcodieren von Videostreams aus ziemlich vielen Codecs sollte damit machbar sein (selbst der VLC Media Player - http://www.videolan.org/vlc/ - kann zwischen verschiedenen Codecs konvertieren). Bis der VLMC da ist, ist VLC eine gute alternative - zumindest was die Konvertierung angeht. Und viele der Funktionen sind als separate libs erhaeltlich (Beispiel: http://www.videolan.org/developers/x264.html).

Gruss

Ich will ja selber machen und keine Fremdware benutzen ;)

Allerdings schwirren so viele hübsch aussehende Dokumente durch das Web, von denen einige dann doch heimlich Fehler enthalten. Vor ein paar Tagen habe ich stundenlang nach einem Bug gesucht bis sich herausstellte, dass ein Spec-Chart an dem ich mich orientiert hatte ein Byte in einem bestimmten Header im Stream nicht aufgeführt hatte welches in der originalen Spec aber drinsteht. :twisted:

Dafür war der Chart aber wesentlich bunter und übersichtlicher, deswegen hatte ich den bis dato benutzt :x