Squeeze der Videospur - gibt's sowas ?

[Töppi]

Aber auch hier muss man vorher demultiplexen. Und das wollte ragtime glaube ich nicht

[ragtime]

Noe, es ging hier nicht um mich, sondern um Pixeljunkie, der beim Schnitt einer DVD ein asynchrones Video produzierte. Ich meinte nur er koenne das mit mplex wieder richten... Da er aber glaube ich ohnehin mit cuttermaran geschnitten hat, ist es natuerlich fuer ihn praktischer, das auch damit wieder zu richten. Das wusster er (und ich) bis vor kurzem nur noch nicht, dass das damit geht.

Wobei ich ja fast davon ueberzeugt bin, dass bei DVBcut (ohne multiplexen) die Asynchronitaet erst gar nicht aufgetreten waere... aber wenn er halt lieber mit cuttermaran arbeitet.

Bin kein Freund von unnoetigem demultiplexen,... das hast du schon richtig erkannt.

[Töppi]

Wobei die Asynchronitäten in diesen Fällen oft schon am Topf vor dem demultiplexen zu beobachten sind.
Ich demuxe alles mit ProjectX bevor ich es weiterverarbeite und Asynchronitäten sind mir bisher eigentlich nicht begegnet, außer das Ausgangsmaterial war bereits defekt.

[pixeljunkie]

[quote=""ragtime""]Da er aber glaube ich ohnehin mit cuttermaran geschnitten hat, ist es natuerlich fuer ihn praktischer, das auch damit wieder zu richten. Das wusster er (und ich) bis vor kurzem nur noch nicht, dass das damit geht.[/quote]

Ich wußte, dass Cuttermaran audio-delays setzen kann. Ich wußte jedoch nicht, dass man die neu gesetzten audio-delays in ein .ac3 exportieren kann, ohne den audio-stream vorher irgendwie sonst zu schneiden.

[quote=""ragtime""]
Wobei ich ja fast davon ueberzeugt bin, dass bei DVBcut (ohne multiplexen) die Asynchronitaet erst gar nicht aufgetreten waere... aber wenn er halt lieber mit cuttermaran arbeitet. Bin kein Freund von unnoetigem demultiplexen,... das hast du schon richtig erkannt. [/quote]

Ich versuche auch das Demuxen/Schneiden zu vermeiden, wo geht. Geht aber halt nicht immer. Direkt von .rec oder .vob nach Mpeg führt bei mir meist nicht zu dem, was ich haben will. PVAStrumento zB integriert alle mpga- aber nicht die .ac3 Audiospuren ... dann demuxe ich .rec oder .vob lieber gleich komplett, und setze mir die .mpg dann so zusammen, wie ich sie haben möchte, auch mit den audio-Spuren in der gewünschten Reihenfolge etc.

[ragtime]

Stimmt,... das mit der waehlbaren Reihenfolge bzw. ID ist auch noch etwas, was ich mir fuer DVBcut wuenschen wuerde... im Moment uebernimmt/sortiert er wohl die Audio PIDs des Transport Streams! Assynchonitaeten hab ich dabei aber noch so gut wie nie gehabt...

Uebrigens,... hab ich grade gesehen,... das mplex was bei GfD dabei ist, ist das richtige mit den einstellbaren Audiodelays. Und zumindest das globale Delay aller Audiostreams laesst sich dann auch bei GfD einstellen (bei demuxtem Input). Letzteres bringt natuerlich nur was, wenn das Ziel ne DVD sein soll... falls nicht muss man halt mplex von Hand aufrufen.

@Toeppi: Da hast du recht Ursache ist meist ein kaputter Inputstream... dieser wirkt sich aber oft nur dann auch fatal aus, wenn ich demuxe, da die elemenary Audio-Streams ja keine Zeitinformation mehr enthalten! Ergo, muss ich die Fehler vorm/beim demuxen irgendwie erkennen und reparieren (was PjX ja versucht zu tun)... demuxe ich aber erst gar nicht, kann ich mir das sparen!

[pixeljunkie]

[quote=""ragtime""]Uebrigens,... hab ich grade gesehen,... das mplex was bei GfD dabei ist, ist das richtige mit den einstellbaren Audiodelays. Und zumindest das globale Delay aller Audiostreams laesst sich dann auch bei GfD einstellen (bei demuxtem Input). Letzteres bringt natuerlich nur was, wenn das Ziel ne DVD sein soll... falls nicht muss man halt mplex von Hand aufrufen.[/quote]

Globales audio-delay kannst du meist in der Pfeife rauchen ... zumindest bei DVDs. Probleme tauchen da nämlich in 99,99% der Fälle immer nur mit der deutschen Synchronspur auf, hingegen fast nie mit der (englischen, französischen) Originalspur. Wenn du aber beide Spuren in deinem mpeg beibehalten möchtest, aber nur eine ein spezielles audio-delay benötigt, dann wirst du wohl oder übel wieder bei einem demuxer landen.

Übrigens: ich finde diese Cuttermaran-Lösung oberklasse, wirklich so simpel und so effektiv. Da ich darum jetzt weiss, kann ich meinen Mpeg-Software-Fuhrpark deutlich verringern auf PVAStrumento, Cuttermaran und ImagoMpeg-Muxer, und sonst nix ...

[quote=""ragtime""]
@Toeppi: Da hast du recht Ursache ist meist ein kaputter Inputstream... dieser wirkt sich aber oft nur dann auch fatal aus, wenn ich demuxe, da die elemenary Audio-Streams ja keine Zeitinformation mehr enthalten! Ergo, muss ich die Fehler vorm/beim demuxen irgendwie erkennen und reparieren (was PjX ja versucht zu tun)... demuxe ich aber erst gar nicht, kann ich mir das sparen![/quote]

Das mag stimmen, solange du dein file-format nicht aus irgendeinem Grund später mal wieder anfassen mußt. Willst du also etwa dein Mpeg-archiv nach DivX oder h264 konvertieren, weil du vielleicht einen mobilen Player hast, der entweder kein mpeg2 lesen oder mit NTFS hantieren kann (wie zB mein Archos AV700), dann kommst du um eine spätere Kompression nicht herum. Kompressoren "demuxen" und "muxen" aber quasi automatisch. Was dann im fertigen DivX zu Effekten führen kann, die im originalen Mpeg2-File schlicht nicht zu erkennen waren. Genaus erging es mir übrigens mit jener DVD, von der ich hier schrieb: im VOB bzw. Mpeg2 war alles kosher, aber in DivX kam es dann plötzlich zu diesem audio-Sprung.

Ich halte deshalb meine Files gerne in einer Form vor, von der ich weiss, dass sie allen Eventualitäten gerecht wird ...

[ragtime]

[quote=""pixeljunkie""]... Kompressoren "demuxen" und "muxen" aber quasi automatisch. Was dann im fertigen DivX zu Effekten führen kann, die im originalen Mpeg2-File schlicht nicht zu erkennen waren. Genaus erging es mir übrigens mit jener DVD, von der ich hier schrieb: im VOB bzw. Mpeg2 war alles kosher, aber in DivX kam es dann plötzlich zu diesem audio-Sprung.
[/quote]

Also ich bin ja nun nicht der V/A-Encoding-Experte... aber meiner Ansicht nach kann man so oder so "demuxen"...

Wenn das Ergebniss des demux-Vorgangs ein elementary stream (ES) ist (im "duemmsten" Fall wird im Hintergrund einfach ein temporaeres File erzeugt), hast du bei kaputten/fehlenden frames verloren, da die Beziehung zw. den Audio und Video-Paketen weg ist und das Audiosignal schlicht "zusammengeschoben" wird ... es existieren ja gar keine Pakete mit Zeitinformationen mehr. Viele GUIs oder Skripte arbeiten der Einfachheit halber genau so...

Passiert das "Quasi-Demuxen" aber on-the-fly im Memory, existieren die Paketstrukturen bzw. -informationen sehr wohl noch und koennen nach Drop-Outs wieder richtig zugeordnet werden. Die jeweilige Encoding-Bibliothek bekommt die Daten paketweise und die Zuordnung uebernimmt das rufende Programm... im schlimmsten Fall fehlt halt Audio UND Video-Frame oder das jeweils fehlende/kaputte Frame wird durch ein leeres (Stille/Schwaerze oder Wiederholungsframe) ersetzt... Asynchronitaeten sollten da ausgeschloossen sein!

Werde mich aber nochmal bei nem Experten ensprechend informieren...

Ich halte deshalb meine Files gerne in einer Form vor, von der ich weiss, dass sie allen Eventualitäten gerecht wird ...

Das sind hoffentlich aber keine elementary Streams...?

[pixeljunkie]

[quote=""ragtime""]Also ich bin ja nun nicht der V/A-Encoding-Experte... aber meiner Ansicht nach kann man so oder so "demuxen"... [/quote]

Deshalb sagte ich ja oben, dass ich lieber selber "ordentlich" demuxe/muxe um ein einwandfreies mpeg zu haben, bevor ich das nach DivX oder sonstwas konvertiere.

[quote=""ragtime""]
Wenn das Ergebniss des demux-Vorgangs ein elementary stream (ES) ist
[/quote]

what else, my dear raggie?

[quote=""ragtime""]
(im "duemmsten" Fall wird im Hintergrund einfach ein temporaeres File erzeugt),
[/quote]

macht so ziemlich jedes Programm, dass ich kenne ... aber lass mich raten: nicht ffmpeg und DVBCut, stimmt's ?


[quote=""ragtime""]
hast du bei kaputten/fehlenden frames verloren, da die Beziehung zw. den Audio und Video-Paketen weg ist und das Audiosignal schlicht "zusammengeschoben" wird ... es existieren ja gar keine Pakete mit Zeitinformationen mehr. Viele GUIs oder Skripte arbeiten der Einfachheit halber genau so...
[/quote]

"viele" ist leger untertrieben, ich würde mal die These wagen, 9 von 10 Proggies machen das so. Und genauso, wie du es sagst ist es: ohne Information zu den PTS-Zeiten, welche dann halt beim demuxen regelmäßig verloren gehen, kann das beste Programm der Welt beim remuxen Fehler nicht mehr ausgleichen. Woher sollte es denn wissen, dass da mal x-Audiopakete waren, die da jetzt aber nicht mehr sind ? Und schwuppsdiwupps ist Videopaket x nicht mehr synchron mit Audioppaket x, sondern Audiopaket Y. Und alle folgenden Pakete haben dasselbe Problem.


[quote=""ragtime""]
Passiert das "Quasi-Demuxen" aber on-the-fly im Memory, existieren die Paketstrukturen bzw. -informationen sehr wohl noch und koennen nach Drop-Outs wieder richtig zugeordnet werden. Die jeweilige Encoding-Bibliothek bekommt die Daten paketweise und die Zuordnung uebernimmt das rufende Programm... im schlimmsten Fall fehlt halt Audio UND Video-Frame oder das jeweils fehlende/kaputte Frame wird durch ein leeres (Stille/Schwaerze oder Wiederholungsframe) ersetzt... Asynchronitaeten sollten da ausgeschloossen sein!
[/quote]

Ob die temporäre Datei nun im RAM oder auf der HD steht ist ja völlig egal, und einen demuxer, der die PTS-Zeiten laufend on the fly abgleichen und fehlende Pakete vielleicht sogar noch auffüllen würde, kenne ich nicht. Zumindest nicht im open source/Consumer-Bereich, im Profi-Bereich mag es sowas geben.


[quote=""ragtime""]
Werde mich aber nochmal bei nem Experten ensprechend informieren...
[/quote]

Die werden dir mit ziemlicher Sicherheit sagen, dass es nahezu unumgänglich ist, den Originalstream so gut wie möglich zu fixen (mittels ProjectX oder PVA-Strumento). Was ja im Endeeffekt auch das ist, was ich tue. Aber was genau muss man tun, um mittels derartiger Progs den Originalstream zu fixen ? - Jep: demuxen! ... womit wird wieder - nachdem wir diese schöne Schleife gezogen haben - zurück auf Feld 1 wären.

[ragtime]

Nein, gar nicht erst demuxen...

Das Programm dass die Audio -und Videodaten aus nem Container rausnimmt, sei es zum Schneiden, Transcoden oder auch nur zum Umpacken hat die Timestamps zu beachten und das dementsprechend gefaelligst wieder in den neuen Container reinzupacken... ganz einfach!

Das du den Eindruck hast, dass das 90% der Progies nicht so machen liegt daran, dass es nur ne Handvoll (OpenSource) Programme gibt und die 1000 Tools die unter Windows kursieren nur GUIs dafuer sind und darunter werkelt dann ffmpeg, mencoder, transcode, mplex, replex, dvdauthor.... usw. ... und deswegen ist es natuerlich oft einfacher (oder schlichtweg notwendig) elementary streams extern zu verarbeiten... lame fuers Audio, divx fuers Video und wieder zusammengemuxt... das heisst aber nicht, dass die zugrundeliegenden Coder Audio&Video nicht auch zusammen verarbeiten koennten,... aber natuerlich auch nicht, dass sie ordentlich programmiert sind und intern die Timestamps tatsaechlich beachten und im Fehlerfall richtig reagieren.

Ich persoenlich bin mit meiner Toolchain 'DVBcut->ffmpeg/dvdauthor' sehr zufrieden. Asynchronitaeten kenn ich nicht und spare zusaetzlich noch Zeit und Plattenplatz... aber jedem das Seine. Alles geht damit auch nicht (mit ES ist man natuerlich flexibler) und Garantien, dass jeder noch so kaputte Stream funktioniert gibt es schon gar nicht (zum Reparieren ist PjX wohl besser) aber viele Fehler wirken sich halt auch gar nicht negativ aus!