Audiospur einige Millisekunden zu lang bei x264 und x265?

[MatthiasD]

Hallo,

ich schneide meine TV-Aufnahmen von Satellit mit avidemux und habe nun von Version 2.7.1 nach 2.7.4 VC++ nightly 190729 upgedatet.

Seitdem scheint avidemux beim encoden ins x264- und x265-Format die Audiospur beim  hinteren Schnittpunkt eines selektierten Abschnitts etwas zu spät zu schneiden.
Es sind also, wenn die ersten Frames hinter einem Film nicht gerade lautlos sind, die ersten Töne hinter dem Schnittpunkt als Kratzen zu hören.

Ich hab mal eine Beispielaufnahme mit dazugehörigen Encodings bei wetransfer hochgeladen: https://we.tl/t-DjRk3RMjdE
Die ts-Datei ist unverändert, also nicht geschnitten worden oder dergleichen.


Ich habe versucht der Sache näher zu kommen:

- nur beim x264- und x265 codec zeigt sich das Verhalten, die anderen Encoder schneiden bei mir exakt, als Beispiel habe ich auch ein xvid4-Encoding hochgeladen;
  auch copy statt eines videoencoders schneidet exakt
- bei allen Aufnahmen ist das Verhalten jetzt zu beobachten, also nicht z. B. nur bei manchen Sendern oder so
- Version 2.7.1 hat bei mir immer so geschnitten, dass der Ton zum nächsten Frame nicht zu hören war, also perfekt
- Ich habe das Verhalten bei zwei weiteren Versionen ausprobiert, 2.7.3 final und 2.7.3 nightly 190727 und gleiches Verhalten festgestellt
- den hinteren nutzlosen Bereich wegschneiden und dann encoden bringt keine Besserung, die gleichen Audiofragmente sind dann immer noch zu hören
- ich habe 2 Muxer ausprobiert: mkvmuxer  und  mp4muxer  .. gleiches Verhalten
- ich habs auf 3 PC's getestet mit 2 verschiedenen Sat-Receivern ... auch gleiches Verhalten
- Der vordere Schnittpunkt ist exakt, also ist die Audiospur nicht komplett verschoben/asynchron
- Um die Töne hinter dem Film zu vermeiden muss ich zwischen 1-5 Frames früher schneiden. Kurios ist dabei, dass, wenn ich mit dem 'Resample FPS'-Filter die Framerate von 50 auf 25 verringere, sich die Anzahl der wegzuschneidenen Frames UNGEFÄHR verdoppelt. Erwartet hätte ich einen Unterschied von 0-1 Frames.

Hat jemand ne Idee?

[eumagga0x2a]

Die ursprüngliche TS-Datei ist so beschaffen, dass wir eine sehr hohe Verzögerung beim ersten Keyframe haben. Im Copy-Modus wird sie weggerechnet, beim Encodieren nicht (das ist verbesserungswürdig). Das konkrete Problem ist leicht mit dem erneuten Speichern des neukodierten Videos im Copy-Modus zu kompensieren.

[MatthiasD]

Vielen Dank für die Antwort!
Ich hab's noch nicht ganz verstanden, deswegen hake ich mal nach:

Im Copy-Modus wird sie weggerechnet, beim Encodieren nicht

soll heissen 'Im Copy-Modus und beim Encodieren -ausser mit x264 und x265- wird sie weggerechnet, beim Encodieren mit x264 und x265 nicht, und auch nur beim rechten Schnittpunkt wird sie nicht weggerechnet' ??
Folgt daraus dann nicht, dass bei der encodierten Datei der Audiostream etwas gestaucht ist und diese Stauchung auch bei dem genannten Workaround nicht verschwindet?

Ist die erwähnte Verzögerung beim ersten Keyframe, die, die mediainfo als 'Delay relative to video' angibt? Am Beispiel der hochgeladenen ts-Datei wären das  für die 4 Audiospuren dann 458ms, 438ms, 514ms, 426ms.
Falls ja, habe ich bei HD-Aufnahmen regelmässig Verzögerungen um 500ms, bei manchen Sendern wie arte sogar 1000ms. Ich habe mal ein anderes Aufnahmeprogramm ausprobiert, und dieses hat sogar bei allen HD-Sendern mindestens 1000ms. Und das auf 2 verschiedenen Computern mit 2 modell-unterschiedlichen TV-Receivern.

Eine Frage habe ich noch zu dem Workaround. Er scheint zu funktionieren - danke für den Tipp! -, aber warum ist das so?
Ist nicht nach dem ersten Encoding die Verzögerung beim ersten Keyframe bzw. die Information wie lang diese in der ts-datei war eliminiert?  'Delay relative to video' der encodierten Datei ist nämlich bei meinem Beispiel jetzt nur noch 21ms (bei der ersten Tonspur).


Für den Fall dass es überlesen wurde: Version 2.7.1 hat bei mir korrekt geschnitten; vielleicht ist ja bei einer der nachfolgenden Versionen ein 'Codeschnipsel' verloren gegangen.

[eumagga0x2a]

Ich hab's noch nicht ganz verstanden

Ich selber hatte es nicht ganz verstanden, daher eine konfuse und falsche Erklärung.

Im Copy-Modus wird sie weggerechnet, beim Encodieren nicht

soll heissen 'Im Copy-Modus und beim Encodieren -ausser mit x264 und x265- wird sie weggerechnet, beim Encodieren mit x264 und x265 nicht, und auch nur beim rechten Schnittpunkt wird sie nicht weggerechnet' ??
Folgt daraus dann nicht, dass bei der encodierten Datei der Audiostream etwas gestaucht ist und diese Stauchung auch bei dem genannten Workaround nicht verschwindet?

Wie handhaben anscheinend den Fall, dass B-frames deaktiviert sind wie beim Baseline-Profil von x264 (so wie im hochgeladenen neukodierten Sample) und DTS fehlen nicht ganz korrekt. Im nächsten Release-Zyklus werde ich mich dieses kleinen Problems annehmen.

Der Audiostream ist nicht gestaucht, es ist das Video, dass unnötig stark verzögert ist – der Ton kommt zu früh.

Ist die erwähnte Verzögerung beim ersten Keyframe, die, die mediainfo als 'Delay relative to video' angibt? Am Beispiel der hochgeladenen ts-Datei wären das  für die 4 Audiospuren dann 458ms, 438ms, 514ms, 426ms.

Ja, das hat direkt damit zu tun. Das Speichern im Copy-Modus entsorgt den Anfang von Audio, so dass Video-Verzögerung auf ein Minimum, gegeben durch die Anzahl von Referenz-Bildern und die Bildwiederholrate, reduziert werden kann ohne die Synchronisation zu verlieren.

Für den Fall dass es überlesen wurde: Version 2.7.1 hat bei mir korrekt geschnitten; vielleicht ist ja bei einer der nachfolgenden Versionen ein 'Codeschnipsel' verloren gegangen.

Das ist nicht überlesen worden. Ich hatte einfach keine Zeit um dieser Beobachtung auf den Grund zu gehen. 2.7.1 hatte AFAIR noch den Bug mit verlorenen letzten Frames bzw. manche Demuxer berechneten die Länge des Videos falsch und die letzten Frames passten nicht mehr rein, außerdem fehlte bei MPEG-TS der Ton in der ersten GOP.

Vielleicht glichen solche Bugs die Wirkung des anderen Problems wieder aus.