vdr -> mpeg: vdrsync vs ProjectX

  • Soweit ich es verstanden habe, werden bei der Umwandlung vom VDR-Format in "normales" MPEG-2 nur die Daten umsortiert, aber nicht verändert.
    Sollten dann vdrsync und ProjectX (mit der Option -tom2p) nicht das gleiche Ergebnis liefern? Tun sie aber nicht. Die Größen der resultierenden Dateien weichen sogar um etwa 1% voneinader ab.


    1361805312 vdrsync.mpg
    1345119653 px_tom2p.m2p


    Arbeitet ein Programm falsch oder habe ich etwas falsch verstanden?

  • Naja, beim Demuxen (kann VDRSync das?) sollte das gleiche rauskommen.
    Aber wenn man MPEG haben will muss ja wieder gemuxt werden. Und da kann man sehr viele unterschiedliche Varianten wählen in der Art wie man die vielen kleinen Packete ineinanderschachtelt.


    Wobei: VDR ist doch eigendlich auch MPEG. Eigendlich sollte das Umbenennen reichen, oder?
    Das remuxen ist ja eigendlich nur gut um an den Anfangs-/End-und Schnittstellen die überflüssigen und fehlenden Tonpakete wieder zu ordnen.
    Wobei ich da weder VDRSync noch ProjektX (im direkten VDR->MPEG) traue. Erfahrungsgemäss kommt oft nur Murks bei raus wenn man die Dateien bearbeitet ohne sie vorher in A und V zu trennen (dann gespeichert in Einzeldateien).


    cu

  • Zitat

    Original von Keine_Ahnung
    Erfahrungsgemäss kommt oft nur Murks bei raus wenn man die Dateien bearbeitet ohne sie vorher in A und V zu trennen (dann gespeichert in Einzeldateien).


    Diese Erfahrung kann ich nicht teilen ich bin mit den Resultat meistens zufrieden aber ich verarbeite das mpeg meistens noch weiter... ich hab alles schon probiert mit demuxen und dann wieder mit mplex muxen oder es so lassen und nur schneiden. In meinen Augen macht das keinen Unterschied aber ich mach das auch nur wenn ich das Video für mein Handy oder ipod konvertieren möchte.
    Um DVD zu erstellen nutze ich entweder Burn oder unter Ubuntu devede.

  • hi,


    das sind alles gaaaaanz alte probleme die mit vdrsync, pvastrumento oder px gelöst wurden (so weit das ging)


    0. umbenenn, vdr zeichnet in mpeg2 pes auf, die meiten programme verstehen nur mpeg2 ps(8dvd) oder mpeg2 ts (transport stream), pes war nie sehr verbreitet, umbenennen hilft nur wenn das betreffende programm auch mit pes umgehen kann


    1. audioversatz am anfang des datenstroms, a und v sind immer um xxx ms versetzt, programme die das beim schneiden nicht berücksichtigen und einfach hart ein einer stelle der datei schneiden (z.b. vdr selbst) verlieren z.b. ton am anfang und haben dann einen ton überstand am ende, somit fehlen an einer ausgeführten schnittmarke frames da der überstand am ende einen anderen timecode hat und nicht zum bild hinter der schnittmarke passt, das sind zwar nur 150-400 ms aber wenn man das mehrfach summiert kommt schnell etwas >500 ms zudammen und das merkt man dann


    das ist auch der grunf warum Keine_Ahnung der meinung ist man müsse erst demuxen, dabei wird die verschränkung von a und v aufgehoben und wenn der demuxer richtig arbietet hat der das versatz problem am anfang auch gleich korrigiert


    2. fehlerbereinigung, dvb daten können beim empfang verloren gehen (fehlende packete), die dvb dekoder hardware überspielt das mit ein paar tricks aber eine programm das wie ein erbsenzähler jedes packet umlabeln will hat bei einer fehlenden nummer ein peroblem, wenn man das ignoriert gibts im laufe des films versatz, man muss die fehlende packete mit dummys ersetzen
    dazu kommen noch sachen wie sich schlagartig ändernde timecodes im sendestrom da der encoder beim sender resetet wurde oder ...


    px oder vdrsync sollten versuchen diese fehlenden packete zu kompensieren aber wenn man eine geschnittene vdr aufnahme hat dann gibts an jeder schnittmarke einen stolperer im datenstrom (manche tools kommen unter umständen nicht mit dd klar)
    die vermutlich beste methode ist es die aufnahme von vdr mit px oder vdrsync zu korrigieren und danach den timecode der schnittmarken datei von vdr zu nutzen um die aufnahme zu schneiden - dafür gab es in pvas eine option


    3. als sahnehäubchen kommt noch oben drauf das die alte ff karte den timecode im datenstrom verändert hat so das die tools es schwerer hatten als wenn man den originalen timecode vom sender wie bei einer budget karte hat (deshalb auch die vielen bemühungen/umbauten damit die die ff karte den ts direkt an das system/vdr gibt)


    btw. der ganze spass geht mit h.264 teilwiese von vorn los da man fehlende packete nur ergänzen kann wenn man deren korrekten syntaktischen aufbau (und evtl auch inhalt) im griff hat

  • Zitat

    Originally posted by IG88
    das ist auch der grunf warum Keine_Ahnung der meinung ist man müsse erst demuxen, dabei wird die verschränkung von a und v aufgehoben und wenn der demuxer richtig arbietet hat der das versatz problem am anfang auch gleich korrigiert


    Fast ;)
    Ich habe auch die Erfahrung gemacht des es viele Programme schlichtweg nicht auf die Reihe bekommen fremdgemuxte Dateien direkt zu schneiden.
    Weil, A und V sind ja verschränkt in einer Datei. Um richtig zu schneiden muß das an der Schnittstelle virtuell auseinandergefummelt, geschnitten und neu verschränkt werden. Und dabei vertun sich die meisten Programme. Insbesondere wenns ne Datei ist die sie nicht selber gemuxt haben.


    cu

  • Das Problem ist mir bekannt ich kann das halt blos ned so gut umschreiben aber du hast das super erklärt.


    Naja pvastrumento scheidet bei mir aus ... vielleicht läuft es mit wine hab es noch nie ausprobiert.


    Aber meines Wissens nach ist die Option das zu korrigieren in projectX automatisch aktiviert.

  • Zitat

    Original von Keine_Ahnung
    da kann man sehr viele unterschiedliche Varianten wählen in der Art wie man die vielen kleinen Packete ineinanderschachtelt.


    Ich würde das Thema gerne noch einmal aufwärmen:
    Schwerpunktmäßig beschäftigen sich die Antworten mit geschnittene Aufnahmen. Wenn wir mal nur ungeschnittene Aufnahmen betrachten, entfallen die entsprechenden Effekte. Was bleibt dann noch übrig, was die Unterschiede der Dateien erklärt? Soweit ich das verstanden habe, lässt der Standart einen Spielraum in der Struktur innerhalb der Datei zu. Das kann auch einen Unterschied bei der Dateigröße in der Größenordnung verursachen? (siehe Ursprungsfrage)
    Was haben diese unterschiedlichen Strukturen für praktische Auswirkungen?
    Oder gibt es da noch etwas Anderes?

  • Zitat

    Originally posted by RolfGF
    Schwerpunktmäßig beschäftigen sich die Antworten mit geschnittene Aufnahmen. Wenn wir mal nur ungeschnittene Aufnahmen betrachten, entfallen die entsprechenden Effekte.


    Warum sollten sie hier entfallen?


    Zitat

    Originally posted by RolfGF
    Was bleibt dann noch übrig, was die Unterschiede der Dateien erklärt? Soweit ich das verstanden habe, lässt der Standart einen Spielraum in der Struktur innerhalb der Datei zu. Das kann auch einen Unterschied bei der Dateigröße in der Größenordnung verursachen? (siehe Ursprungsfrage)


    Ja. Es gibt ja auch unterschiedliche Strategien um Leeräume mit Nullen zu füllen damit die Schwankungen in der Bitrate in der Datei harmonischer sind.


    Zitat

    Originally posted by RolfGF
    Was haben diese unterschiedlichen Strukturen für praktische Auswirkungen?


    Keine, wenn alles richtig gemacht wurde.


    Mach dir da nicht so viele Gedanken, das ist alles ungeheuer komplex. Wenn du mit Videos arbeitest musst du den Anspruch aufgeben da jedes Bit in der riesigen Datei unter Kontrolle haben zu wollen. Versuchst du da zuviel Kontrolle aufrecht zu erhalten dann verrennst du dich in Richtung Zeitverschwendung.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!