ZitatMuss dann auch erstmal empirisch schauen, ob ein Rekodieren des Audios evtl. auch noch nötig ist, weil's immer noch zu ungenau ist.
Denke ich nicht: AC3-Frames dauern je nach Samplingrate 32-48ms und MP2 ist noch kürzer. Das sollte eigentlich an Genauigkeit reichen 
Meine Güte,
da fährt man nur kurz von Arbeit nach Hause, und dann ist der ganze Thread schon wieder vollgeschrieben. Alle Achtung!
Also: Wenn ich die Sourcen mir so anschaue haben wir dort doch zwei Arbeitsschritte (und damit Baustellen)
1. Marken setzen/verschieben/etc. (In menu.c/.h)
Hier sollte es wohl prinzipiell möglich sein, an I-Frames den Start zu setzen (wird ja jetzt schon gemacht) und als Erweiterung an B-/P-Frames das Ende einer Sequenz zu setzen. Für das Darstellen und bewegen ist auch dvdplayer.c/.h beteiligt, oder?
2. Schnitt der Aufnahme starten (in cutter.c/.h)
Hier ist doch die Stelle, an der letztlich der ganze Schnitt berechnet wird. Warum nicht einfach die entsprechende Routine von Cuttermaran nehmen und in den VDR übertragen? Die berechnet definitiv den Stream nicht neu, wenn die Schnittpunkte wie oben gesetzt wurden. Und bisher hatte ich nie Probleme mit interlaced Aufnahmen.
Von wegen interlaced. Klar, einige Sender senden die Filme interlaced.
ABER: Schau dir mal die Dinger mit AVISynth an: Die sind zwar in den Headern als Interlaced markiert, tatsächlich ist es aber oft progressives Material! Einige Fieslinge unter den Sendeanstalten wechseln sogar mitten im Film!!! Ganz schlimme Beispiele sind die amerikanischen Serien, die ganz übel von NTSC auf PAL gepusht wurden.
ZitatOriginal von Alien
Warum nicht einfach die entsprechende Routine von Cuttermaran nehmen und in den VDR übertragen? Die berechnet definitiv den Stream nicht neu, wenn die Schnittpunkte wie oben gesetzt wurden. Und bisher hatte ich nie Probleme mit interlaced Aufnahmen.
Nun, Cuttermaran arbeitet bereits mit demultiplexten synchronisierten Streams. Das Glück haben wir beim VDR noch nicht. Es sei denn, dieser *repacker macht das möglich, was ich aber noch nicht so ganz verstanden habe. 
Da sich hier so viele mpeg Experten tummeln:
Gibt es eine einfache Möglichkeit, nur die I-Pictures zu dekodieren? Das müsste doch theoretisch mit recht wenig rechenaufwand gehen? Dann wäre ich bei meiner Letterbox-Erkennung das Problem los, dass ich nur das VDR-Bild mit ggf. offenem OSD analysieren kann...
Also scheint ja nun doch einige zu interessieren:
Mein Plugin (welches ich gerade entwickle) heißt Cut-A-Lot und macht (bisher) folgendes:
Es benutzt das Aufnahmemenü, um ein Recording auszuwählen. Anschließend zeigt es das Video an, genauso wie es beim Start eines Recordings wäre. Dann kann man die Schnittmarken mit '0' setzen und zwar überall, egal ob I-Frame oder nicht. Mit '7' und '9' werden Schnittmarken angesprungen, '4' und '6' verschieben die Schnittmarken zum nächsten I-Frame und '1' und '3' verschieben die Schnittmarken zum nächsten Frame. '2' startet den Schnitt. Im Moment werden aber nur Einzelbilder angezeigt, auf "Play" drücken kann man (noch) nicht.
Auch Nicht-I-Frames können bis jetzt angezeigt werden, dazu verwende ich avcodec von ffmpeg, wandle beispielsweise ein B-Frame in ein AVFrame um und wandle dieses dann wieder in ein I-Frame um, welches dann mit DeviceStillPicture() angezeigt werden kann.
Im Moment - weiß nicht, ob ich das noch ändere, aber für's Debugging ist ganz gut - kann man mit '5' die Zeitanzeige des Players zwischen hh:mm:ss.ff, hh:mm:ss (Bildtyp, also I, P, B) und hh:mm:ss.ff (Zeitstempel des Bildes) umschalten.
Der Schnitt kann bisher folgendes:
Er geht zur ersten In-Marke, rekodiert den Anfang bis zum nächsten I-Frame. Dann kopiert er einfach das Original bis vor das letzten I-Frame vor der Out-Marke.
Das Rekodieren des Schlusses funktioniert noch nicht richtig, da mache ich jetzt weiter...
Also an die Arbeit, dmh!
Aber der Cutter könnte ja demuxen und wieder muxen, während er den Schnitt durchführt. Somit hätten wir genau die gleiche Situation als wenn wir den Stream erst durch ProjectX und dann durch Cuttermaran jagen würden.
Die Marks sind doch in einer Liste angeordnet. Kannst das nicht so einrichten, dass alle ungeraden Marks nur auf I-Frames positionierbar sind? Dann sparst du dir das Suchen.
Hi,
ein paar Worte zu den c*Repackern: sie stellen sicher, dass jeder Audio-Frame in ein eigenes PES-Paket gesteckt wird (sofern ein Paket ausreicht) und dass nach jedem Video-Frame ein neues PES-Paket begonnen wird.
Vorteil: das aufwendige Scannen nach StartCodes kann für die meisten Anwendungen auf das Prüfen einiger Bytes am Anfang des PES-Pakets reduziert werden.
Beispiele:
- cRemux::ScanVideoPacket() in VDR-1.3.45.
- radio Plugin.
In vdr-xine-0.7.8 ist in xineDevice.c ein wenig "unschöner" Code versteckt, der PTS berechnet, wenn diese nicht vorhanden sind. Suche nach videoFrameDuration bzw. audioFrameDuration und deren Verwendungen.
ACHTUNG: der Code für Video berechnet die Zeitstempel so, dass ich damit gut die Puffergröße für vdr-xine feststellen kann. Die berechneten Zeitstempel sind so nur für B-Frames korrekt. Für I- und P-Frames sind sind sie auf den letzen P- bzw. I-Frame verschoben. Aber man könnte auch leicht die Zeitstempel abgreifen, die nicht verschoben sind.
Bye.
Solche eine erweiterte Schnittfunktion habe ich mir schon länger gewünscht, und fände es wirklich toll, wenn jemand sowas programmieren würde.
=> Also mach weiter. 
Hi,
ZitatOriginal von dmh
...
Also gegen diese Supertools kann und möchte ich natürlich nicht anstinken. ProjectX kann noch viel mehr als Cut-A-Lot jemals können wird.
War ja auch nicht so gemeint. Ich wollte nur darauf hinweisen, dass der Cutter im Prinzip komplett durch diese Tool ersetzt werden "könnte" weil eben die gleichen Voraussetzungen gelten: 1. Schnittpunkte setzen, 2. schneiden. Der Cutter scannt sowieso die gesamte Datei. Dann "könnte" er auch den Workflow "demux-cut-remux" durchlaufen.
ZitatOriginal von dmg
...
Alien, das verstehe ich nicht. Wie meinst Du das? Also zu meinem Erstaunen habe ich bereits am Anfang festgestellt, dass die Marks beliebige Positionen, egal ob I-, P- oder B-Frames, speichern können. Und das funktioniert auch soweit schon.
Schon klar. Die Marks kannst du an beliebiger Stellen setzen. ABER: GOPs fangen nun mal immer mit einem I-Frame an. Darum läuft dein "Schnitt" ja auch so:
ZitatOriginal von dmh
Der Schnitt kann bisher folgendes:
Er geht zur ersten In-Marke, rekodiert den Anfang bis zum nächsten I-Frame. Dann kopiert er einfach das Original bis vor das letzten I-Frame vor der Out-Marke.
Wenn du also die ungeraden Marks nur an I-Frames positionieren lässt (so wie das VDR jetzt schon macht), kannst du dir das umkodieren und suchen sparen.
Ist ja auch nur ein Vorschlag. Ich hatte nur bisher die Erfahrung gemacht, dass die Anfänge weniger das Problem sind. Es wäre eben schön, wenn man das Ende eines GOP besser aussuchen könnte. Und einen GOP zu verkleinern sollte weniger kompliziert sein, als zu rekodieren.
So long,
Alien
Liebe MPEG-Experten,
seid doch bitte so nett und antwortet mir auf meine Frage, ob (und ggf. wie) es möglich ist, nur die I-Pictures zu dekodieren...
na dann versuche ich es mal.
Klar ist es kein Problem nur I-Frame zu dekodieren. Im prinzip sind die Dinger nix anders als JPEG-Pictures (mit zusätzlichen MPEG-Headern). Da der bisherige VDR-Cutter sowieso nur an I-Frames schneidet, kannst du dich an dessen Sourcen orientieren. Denn immer wenn du eine Markierung für den Schnitt verschiebst, stellt VDR das entsprechende I-Frame dar (schau mal bei dvbplayer.c/.h).
Ich selbst verwende beispielsweise das softdevice. Vielleicht schaust du einfach auch mal dort rein. Dann kannst du sehen, wie es zur Darstellung das I-Frame "dekodiert".
Letztlich hängt es natürlich von deinem Use-Case ab, was du mit dekodieren meinst.
Ciao,
Alien
Alien
Danke!
Wie geasgt geht es um das Thema hier, also darum zu erkennen, wie breit die PAN-Bereiche (schwarzen Balken) in einem 4:3-Letterbox-Bild sind, womit ein TV oder Beamer automatisch den korrekten zoom (via WSS signalisiert) einstellen kann. Derzeit greife ich dafür auf das /dev/video<x>-Device der FF zurück. In den Bildern, die ich darüber grabben kann, ist leider das OSD (des VDR) mit enthalten, womit die Erkennung der PAN-Bereiche natürlich bei offenem OSD verfälscht wird. Nun möchte ich irgend wie an das 'nakte' Video-Bild gelangen und da fällt mir keine andere Möglichkeit ein, als den Video-Strem selbst zu dekodieren. Das Dekodieren sollte jedoch mit möglichst wenig Aufwand bzw. Rechnerleistung geschehen. Ich brauche nur etwa ein, zwei Bilder pro Sekunde, nur monochrom (schwarz/weiss) und nicht mal in der vollen Auflösung...und da war jetzt meine Idee, 'einfach' nur die I-Frames zu dekodieren. Nur wie/wo fange ich da an?
Wenn das Ganze etwas weiter gedien ist, möchte ich auch eine Kopplung mit Framebuffer, Softdevice oder ähnlichen Lösungen, die das Bild über VGA rauswerfen, realisieren. Da geht WSS ja nicht, d.h. man müsste das fertig gezoomte/scalierte Bild aus der VGA drücken...
Arbeitet das OSDPIP-Plugin in nicht genauso so, wie du es beschreibst? Also nur I-Frames dekodieren usw.? Vielleicht kannst du dir da was abschauen.
Gruß
Nordlicht
ZitatOriginal von dmh
Also gegen diese Supertools kann und möchte ich natürlich nicht anstinken. ProjectX kann noch viel mehr als Cut-A-Lot jemals können wird.
Das index.vdr enthält leider nur die Positionen zu den Zeitstempel der Bilder
nicht aber für die verschiedenen Tonspuren.
Da Du es geschafft hast, die B/P-Frames in I-Frames zu wandeln, bleibt eigentlich
nur noch die Audio- und Video-Datenframes um die Schnittmarken herum im
Bereich von 2 GOP's zu demultiplexen und nach dem Schnitt wieder zu multiplexen.
Dann kann man a) Bild-genau schneiden und b) der Ton ist innerhalb von 24ms für
Mpeg-Audio und 32ms für AC3 passend zum Bild setzen.
Wenn Du letzteres nicht machst, dann wirst Du feststellen das Audio bis zu 800ms
früher kommt als das Bild. Dann würdest Du trotz bildgenauem Schneiden
dennoch den Ton aus dem ausgeschnitten Bereich hören (zB Werbung). In
anderen Worten, Bild und Ton sind parallel im VDR-File, aber leider mit einem
Versatz in der PTS, der es notwendifg macht die Schnittmarken für Bild und Ton
getrennt an verschiedenen Stellen zu setzen. Ohne Demutliplexen geht da
IMHO nichts ...
Werner
habichthugo: Das Dekodieren von i-Frames kannst Du sehr leicht mit avcodec von ffmpeg machen. Ich könnte Dir da ein paar Beispiel-Sourcen zukommen lassen, wenn Du wissen möchtest, wie es geht. Dabei kannst Du Dir ein Bild direkt als 32bit RGB-Bild ausgeben lassen, mit dem Du sicherlich Deine schwarzen Balken filtern kannst. Das Schwierige wird aber sein, dass Du einen cMyReceiver schreiben musst, der den MPEG-Strom erhält. Das habe ich auch noch nicht gemacht, aber da können Dir bestimmt andere Leute im Board hier helfen. Also für das Dekodieren mit ffmpeg gibt's Sourcen. Zum Beispiel gibt's hier schon mal was, was allerdings für aktuelle Versionen von ffmpeg angepasst werden muss. OSDPiP arbeitet meines Wissens nach auch mit ffmpeg.
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.
ZitatOriginal von bitstreamout
im
Bereich von 2 GOP's zu demultiplexen und nach dem Schnitt wieder zu multiplexen.
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.
rnissl: Danke, werde mir cRemux mal anschauen... Vielleicht kann ich ja ein paar von meinen selbstgeschriebenen Methoden ersetzen...
ZitatOriginally posted by Brougs78
Du musst den Stream "aufnehmen"
Was macht denn der cReceiver? Der steht ja in PLUGINS.html. Nimmt der direkt auf?!? Ich dachte, der stellt den Stream einfach nur in einem uchar *buffer zur Verfügung? Aber vielleicht ist das ja der Transfermodus... Kurze Aufklärung für den dummen dmh, bitte. ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
