Werbung und non-I-Frame-Schnitt

Zitat

Original von Brougs78
Kleiner Nachteil an der Geschichte: Du musst den Stream "aufnehmen", d.h. du musst dazu mit der Karte in den Transfermodus. Da bist du bei ähnlichen Problemem wie beim LiveBuffer.

Hm. Ich muss mich doch 'blos' in den Video-Stream einklinken. Bei Femon geht das doch auch problemlos...?

Ich möchte jetzt dmh nicht 'seinen' ganzen Thread verhunzen. Postet mir ggf. zum Thema I-Picture-Dekodierung im WSS-Thread weiter.

Zitat

Original von dmh
bitstreamout: Hatte es gestern abend (war dann doch zu müde) geschafft, ein Paar Filme tatsächlich zu schneiden, deren Schnitte - egal ob Cut-In oder -Out - nicht auf I-Frames lagen. Dabei habe ich aber folgendes festgestellt: Die Audio-Pakete liegen vom Zeitstempel her gesehen meist vor den Video-Paketen. Also Audio zum Beispiel 00:00:00.000 und Video dann 00:00:00.480. Diese Audio-Pakete gehören also zu dem vorhergehenden Bild/ern. Jetzt habe ich meine rekodierten Parts noch nicht mit Audio versehen und die Audio-Pakete, deren Zeitstempel vor dem Cut-In-Zeitstempel liegen, noch nicht entfernt. VDR's Clock läuft dann und findet wohl zu einem bestimmten Zeitstempel zwar Audio aber kein Video. Dadurch erscheinen beim Schauen Blockartefakte. Heute habe ich leider keine Zeit mehr, aber ich werde wahrscheinlich morgen mit dem Audio anfangen. Ich denke, dass nach entfernen von Audio-Pakten, deren Zeitstempel außerhalb des Cut-Ins liegen, diese Blockartefakte weg sind.

Kannst Du mir mal bitte genau erklären, wie das geht. Also ich habe eine Methode, die PES -> ES wandelt und eine sehr simple Methode, die ES -> PES wandelt. Für meine bisherigen Zwecke taten sie ihre Dienst gut. (Mal sehen, ob die noch erweitert werden müssen!?) Also warum 2 GOP? Und wo genau muss ich da Anfangen?

Jetzt sieht es zum Beispiel so aus:

I B B P B (Cut-In) -> B P B B I B ... I B B P B B P B B <- (Cut-Out) P B B I B B

Das heißt also, mein erstes Frame ist ein B-Frame und mein letztes Frame auch. Jetzt dekodiere ich das B-Frame. Und starte den Encoder. Der macht aus diesem Frame ein I Frame und dann habe ich gesagt, dass eine GOP maximal 12 Frames haben soll und maximal 2 B-Frames zwischen I- und P-Frames. Da ich ja 4 Frames rekodieren muss, entsteht dann I B B P und ist somit eine GOP mit lediglich 4 Bildern. Am Ende - das habe ich mir von dvbcut abgeschaut - werden nur B-Frames rekodiert. Soll heißen, ist der Cut-Out ein I- oder P-Frame passiert nix, ansonsten, sprich B-Frame, wird wieder eine neue GOP erstellt, im Beispiel bestehend aus 2 Frames ein I- und ein P-Frame. Reicht das nicht schon?

Oder wofür benötige ich dann 2 GOPs? Oder ist das für das Demultiplexing und Multiplexing gut. Das verstehe ich nämlich noch nicht. Auch nicht, wie Audio- und Video-Pakete gemixt werden und in welchem Verhältnis.

Alles anzeigen

In den GOPs sind ja auch die PES-Container füe Audio und AC3-Audio enthalten.
Da ein GOP in etwa meist 480ms dauert (12*(1000/25)) und der Zeitversatz
zwischen den Zeitstempeln von Audio und Video bis zu zwei GOPs betragen kann,
sollten meiner Meinung nach die Audio und Video Daten in diesem Bereich getrennt
geschnitten werden. Könnte etwa so aussehen:

I B A B P A B (VCut-In) -> B A P B A B I A B ... I B B A P B AA B P B A B <- (VCut-Out) P B A B I A B B AA


demulitplex


I B   B P   B (VCut-In) -> B   P B   B I   B ... I B B   P B    B P B   B <- (VCut-Out) P B   B I   B B


    A     A                  A     A     A   ...       A     AA      A                     A     A      AA


AV-Offset


                            (ACut-In) -+                                               (ACut-Out) -+  
    A     A                  A     A   | A   ...       A     AA      A                     A     A |    AA


Korrektur


    A     A   (ACut-In) ->  A   ...       A     AA      A  ...   A     A   <- (ACut-Out) AA


Cut


I B   B P   B || P B   B I   B B
    A     A   || AA


Multiplex


I B A B P A B || P AA B B I B B

Wenn Du also die PES-Container in die einzelnen ES-Streams zerlegtst, solltest
Du den AV-Offset berücksichtigen. Denn der führt dazu, das Audio nach dem
Video-CutIn noch zu Bildern vor dem Video-CutIn gehören und Audio nach dem
Video-CutOut zu Bildern vor dem Video-CutOut gehören (das letzte Wort der Werbung).
Eventuell läßt sich das bei Aufnahmen, die durch den Remuxer mit Reinhards *Repacker
gelaufen sind, durch einfaches Sortieren nach den PTS-Zeitstempel der einzelnen
Audio PES-Container erledigen.

Werner

dmh

Wenn ich mich nicht irre macht es doch ProjectX auch so, oder? Was dabei rauskommt ist ein Schnitt ohne jeglichen Anfangsversatz.

Zitat

Original von dmh
Ahhh, danke. Sehe das jetzt schon etwas klarer. Dabei ist dann aber nur der Versatz in dem MPEG-Strom gemeint, also sprich in Bytes. Man könnte also den Byte-Abstand zweier (nahezu) gleicher Audio- und Video-PTS berechnen. Wie gesagt, um den Ton kümmere ich mich morgen.

Hmmm ... ob das mit reinen Byte-Abständen machbar ist? Eventuell als temporäre
Index-Liste ala index.vdr als temporäre Datei in /dev/shm/. D.h. eine Zuordnung
von PTS auf den Startoffset eines AC3 oder Mpeg-Audio Frames.

Zitat

Das Demultiplexing mache ich ja in der Tat schon, da avcodec_decode_video einen normalen ES-Strom erwartet und PES nicht verarbeiten kann. Nur das Multiplexing habe ich noch nicht in Betracht gezogen, daher auch die Probleme mit den Blockartefakten.

Ohne das funktioniert die firmware nicht korrekt.

Zitat

Kann mir jemand vielleicht einen Hinweis geben, wo ich etwas über Multiplexing erfahren kann? Oder hat der vdr durch den *Repacker schon einen eigenen simplen Multiplexer, dem ich einfach einen Videostrom und einen oder mehrere Audioströme gebe und er mir einen PES-Strom ausspuckt? Die Audioströme müssten dabei so sein, dass die erste Audio-PTS mit der ersten Video-PTS übereinstimmt, right?

In remux.c gab es eigentlich schon immer einen remuxer, der TS nach PES und
dann in ES + PTS auspackt und in neue PES-Frames steckt. Das nun die c*Repacker
Klassen, jeweils ein Viedo- bzw Audio-Datenframe in genau ein PES-Container stecken,
ist neu

Zitat

Falls der vdr das nicht kann, in welchem Verhältnis müssen Audio- und Videodaten gemixt werden?

Solange es weit unterhalb der buffer-Grenzen von Treiber und der firmware
liegt eigentlich beliebig.

Zitat

Macht es evtl. sogar Sinn die PTS am Anfang des Videos auf 00:00:00.000 zu setzen und bei jedem Schnitt die PTS nahtlos in einanderübergehenzulassen?

Wenn die PTS-Zeiten continuierlich verlaufen, sehe ich nur Vorteile und solange
die PTS nicht mit 33Bit max startet, ist IMHO alles im grünen Bereich.

Werner

Hi,

ich hatte auch schon den Gedanken, die PES-Pakete aus den c*Repackern in separaten Puffern abzulegen, die Puffer dann der Reihe nach abzugrasen und jeweils das Paket mit den niedrigsten PTS weiterzureichen.

Bei den Audio-Streams sollte das nicht zu kompliziert sein, denn deren PTS sind aufsteigend.

Beim Video-Stream existiert das Problem, dass die Frames in Dekodier-Reihenfolge erscheinen und die PTS deshalb bei den B-Frames zurückspringen. Man müsste hier also sicherstellen, dass die Audio-Daten spätestens beim Wiedergabezeitpunkt des Frames vorliegen.

Ein Beispiel unter der Annahme, dass es für jedes Video-Paket auch ein Audio-Paket und ein Dolby-Paket gibt:

I2   B0   B1   P5   B3   B4   P8   B6   B7   P11   B9   B10   I14   B12   B13   P17   B15
      A0   A1   A2   A3   A4   A5   A6   A7   A8    A9   A10   A11   A12   A13   A14   A15   A16   A17
       D0   D1   D2   D3   D4   D5   D6   D7   D8    D9   D10   D11   D12   D13   D14   D15   D16   D17

Und nochmals kurz erklärt:
In etwas zum Zeitpunkt an dem P5 beim Dekoder erscheint, wird I2 ausgegeben. Demnach sollten also spätestens hier A0 und D0 vorliegen.

Nach dem Schnitt fände sich also folgendes in der Datei wieder:

I2 B0 A0 D0 B1 A1 D2 P5 A2 D2 P3 A3 D3 B4 A4 D4 ...

Da pro Video-Frame typischerweise mehr als ein PES-Paket zu 2048 Byte anfällt, sollten die Audio-Daten mitunter in das Bild eingewoben werden. Annahme: P5 besteht aus 4 PES-Paketen (a, b, c, d), dann sähe es wie folgt aus:

P5a A2 P5b D2 P5c P5d

Noch ein Wort zu den c*Repackern:
Es würde wahrscheinlich Sinn machen, wenn in die PES-Pakete ohne Zeitstempel deren berechneter Zeitstempel eingetragen wird. Nachträglich kann das ohne nochmaliges Umpacken nicht erledigt werden, da die PES-Pakete auf 2048 Byte aufgefüllt sind und für die zusätzlichen 5 Bytes des Zeitstempels kein Platz mehr ist (die Pakete sollen ja 2048 Byte nicht überschreiten).

Bye.

Zitat

Original von rnissl
ich hatte auch schon den Gedanken, die PES-Pakete aus den c*Repackern in separaten Puffern abzulegen, die Puffer dann der Reihe nach abzugrasen und jeweils das Paket mit den niedrigsten PTS weiterzureichen.

Eventuell könnte man das mit memory mapping auf die jeweilige *.vdr
Datei und einer Indizierung, die mittels c*Repacker-Klassen erstellt wurde,
lösen. Die Indizierung könnte man mit mehreren offenen linked list von
structs fertig sortiert an eine zu schreibende cMutliplex-Klasse übergeben,
die dann die passenden ES-Daten in zu generierende PES-Container steckt.

Zitat

Bei den Audio-Streams sollte das nicht zu kompliziert sein, denn deren PTS sind aufsteigend.

Beim Video-Stream existiert das Problem, dass die Frames in Dekodier-Reihenfolge erscheinen und die PTS deshalb bei den B-Frames zurückspringen. Man müsste hier also sicherstellen, dass die Audio-Daten spätestens beim Wiedergabezeitpunkt des Frames vorliegen.

Das ist klar, denn die temporale Referenz sollte erhalten bleiben. Über so einen
struct könnte bzw. sollte man, neben der PTS, auch Typ und ggf deren
Eigenschaften in passenden unions berücksichtigen.

Werner

Zitat

Original von dmh

Ist zwar nur nebensächlich, interessiert mich aber im Moment. Habe gegoogelt nach "/dev/shm" und dabei herausbekommen, dass es "shared memory" bedeutet und hauptsächlich für Interprozesskommunikation verwendet wird. Da können wohl zwei Prozesse Daten über einen gemeinsamen Speicherbereich austauschen.

Warum also /dev/shm? Oder kann man den auch als sehr schnellen Speicher verstehen, wie eine Art Ramdisk?

Also /dev/shm/ ist ein tmpfs, in dem Du Dateien anlegen kannst. Das geht
schon mit `echo xxx > /dev/shm/yyy'. Die Datei ist in einer Art Ramdisk
enthalten, und läßt sich via mmap auch in den Speicherbereich eines
Programms abbilden. Im bitstreamout plugin verwende ich das dazu, um
grosse und kontinuierliche Speicherbereiche zu erhalten. Das Interface dazu
ist in shm_memory_tool.c und shm_memory_tool.h enthalten. Der Zugriff
ist schneller als über virtuelle Speicheradressen. Wenn Du keine Ramdisk
möchtest, wäre eventuell posix_typed_mem_open(3) eine Alternative.

Mit mmap() erspart man sich auch das Einlesen von Dateien von der Festplatte
in einen Speicherbereich. Nur beim Parsen der Daten sollte man sich halt
merken, was wo genau liegt und zu welcher relativen Adresse im gemappten
Bereich.

Werner

Zitat

Original von dmh
Ich denke, dass die Lösung des Problems darin bestehen könnte, als dass man nun die index.vdr-Datei in Präsentierreihenfolge füllen sollte. Also für den vdr war es nicht wichtig, ob B- und P-Frames an der richtigen Stelle standen, da vdr ja nur I-Frames benutzt.

Für einen framegenauen Schritt, muss die index.vdr-Datei nun einfach so gefüllt werden, wie die Präsentierreihenfolge ist.

Werde das nun mal testen...

EDIT: Leider hat sich herausgestellt, dass dieser Lösungsweg aus folgendem Grund nicht funktioniert: Die index.vdr-Datei erwartet den FileOffset in aufsteigender Reihenfolge. Diese Voraussetzung ist aber beim Speichern in Präsentierreihenfolge nicht gegeben. Die Länge eines Frames berechnet sich nämlich aus (Offset Paket n+1) - (Offset Paket n). Schade. Vielleicht kann man einfach in die index.vdr-Datei ein paar "stuffing" Pakete einfügen...

Alles anzeigen

Was hälst du davon, Deine eigene Liste zumindest für zwei, drei GOPs um
die Schnittpunkte im Speicher zu halten? Scannen mußt Du ja sowieso, also
warum nicht die Daten für spätere Schneiden vorhalten. Dürfte dem User
kaum auffallen, dass da im Hintergrund vor dem bildweisen Verschieben der
Schnittmarken ein Scanner und B/P-to-I-Frame-Transformator im Hintergrund
läuft ... oder?

Werner

Zitat

Original von dmh
Ich "leihe" mir einfach zwei vorhergehende B-Frames und packe sie an eine entsprechende Stelle mit PTS kleiner als die des neu generierten I-Frames. Dann sollte der VDR die auch nicht mehr spielen. Beim GOP genauen Schnitt hat man ja auch zwei B-Frames, welche nicht mehr dekodiert werden können und deren PTS kleiner ist als derjenige des ersten I-Frames. Jetzt ist natürlich die Frage, ob auch P-Frames in eine nachfolgende GOP dürfen?!?

Wenn die GOP als geschlossen markiert wurde, sollte das funktionieren.
Bei P-Frames dürfte das nicht funktionieren. Was spricht eigentlich
dagegen, um die Schnittmarken herum, nur I-Frames zu verwenden?
Wenn in einer GOP nur I-Frames auftreten hast Du die ganzen
Probleme nicht. Wie man wegen der erhöhten Bandbreite aus I-Frames
wieder eine IBBP-Sequenz ohne vollständige Dekodierung/Enkodierung
macht, weis ich nicht (im Prinzip geht das). Aber eventuell ist es möglich
einfach eine Sequenz von I-Frames um die Schnittmarken herum zu
verwenden und auch abzuspielen. Damit fallen jedenfalls die Backward
Referenzen der B-Frames weg.

Werner

Zitat

Original von dmh
Also das Problem ist im Moment nicht die neuerzeugte GOP, das macht libavcodec schon ordentlich und funktioniert wohl auch. Könnte ihr (libavcodec) zwar sagen, dass nur I-Frames verwendet werden sollen, aber das brauche ich nicht, weil er eine neue abgeschlossene GOP erzeugt.

Kann man die libavcodec eventuell dazu veranlassen, keinen geschlossenen
GOPs zu produzieren, d.h. ihr das Referenzbild aus dem vorherigen GOP
zu geben, damit sie die passenden B-Frames gleich mitliefert bzw. von
selbst includiert?

Zitat

Das Problem ist, dass der Index der einzelnen Frames mit Hilfe der index.vdr-Datei berechnet wird und bei meinem jetzigen Verfahren versagt. Und zwar werden die Indizes der I-Frames nicht mehr richtig angezeigt und GOP-Größen nicht mehr richtig berechnet.

Wie wird das den bisher gelöst? Die invalid B-Frames stehen in der index.vdr und
werden durch das abgeschlossene GOP nicht abgespielt. Im Prinzip kann da also
statt der echten B-Frames auch ein dummy B-Frame eingesetzt und die offsets im
index.vdr passend korrigiert werden.

Werner

Hallo dmh,

gibt es hier was neues, oder biste mit dem neuen burn-plugin beschäftigt?

Reine Neugier.

V_R