AutoMKV: Fehler beim Audiokonvertieren mit FFMPEG, Alternative?

Hallo,

ich versuche gerade ein 720p MKV (.h264) in ein XVid-AVI (SD) zu konvertieren, doch schon ganz am Anfang wirft mir der FFMPEG.exe beim Audio-Konbertieren tausende Fehlermeldungen dieser Art um die Ohren:

[NULL @ 02E8BE30]error, non monotone timestamps 196318080 >= 196318080

Was ist denn da kaputt? Offenbar kommt FFMPEG mit dem Audiostream nicht zurecht, kann man AutoMKV anweisen, den Audiostream anders zu extrahieren? Oder wie sonst kann ich das Problem umgehen?

Hi,

die Mediainfo liefere ich gerne nach, bitteschön:

Video
ID                               : 1
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 5 frames
Codec ID                         : V_MPEG4/ISO/AVC
Duration                         : 57mn 52s
Bit rate                         : 4 453 Kbps
Width                            : 1 280 pixels
Height                           : 720 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Original frame rate              : 23.976 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.193
Stream size                      : 1.77 GiB (94%)
Writing library                  : x264 core 116 r2074+5M 
Encoding settings                : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


Audio
ID                               : 2
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Codec ID                         : A_AC3
Duration                         : 57mn 52s
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 81.4 MiB (4%)

Zur Quelle des Videos: ich wollte mir eigentlich jeglichen Kommentar dazu ersparen außer dass deine Vermutung unzutreffend ist. Abgesehen davon: was hat das mit dem Thema zu tun? An dem grundlegenden Problem würde das aber ohnehin nichts ändern, also kann man sich diese Diskussion doch wirklich sparen!

ich habe häufig Videos, die in 720p oder 1080p vorliegen, meist in MKV, MOV oder MP4 Containern verpackt, die ich gelegentlich auf einem normalen XVid-tauglichen DVD-Player wiedergeben möchte. Wonach ich suche ist eine einfache Lösung, derartige Dateien möglichst zuverlässig zu transkodieren.

Das Problem bei FFMpeg scheint ja nicht ganz neu zu sein, allerdings habe ich hier keinen DTS sondern einen AC3 Stream. Ich kenne mich nicht so detailliert aus, dass ich aufgrund der Medieninformationen oben auf die Ursache des Problems schließen könnte, vermute aber dass es da einen Bug in FFMpeg gibt, der wenn ich die Google-Ergebnisse richtig deute seit über einem Jahr ungefixt ist, was scheinbar nicht für FFMpeg spricht.

Dein Ansatz oben ist sicher hilfreich, mittelfristig hätte ich aber am liebsten eine "one-Klick-Lösung", die auch zuverlässig funktioniert, und nicht alle Nase lang über solche Kleinigkeiten stolpert.

Noch ein paar Worte zu AutoMKV. das macht dann übrigens trotzdem weiter, startet VirtualdubMod durch, das bleibt aber an der GUI hängen. Beendet man das manuell, wird trotzdem der Enkoder angeworfen, und das ganze stürzt gnadenlos ab. Außerdem beschwert sich VirtualDubMod generell, wenn ihm UNC-Pfade übergeben werden, damit kommt es nicht zurecht. AutoMKV akzeptiert aber ungeachtet dessen dennoch UNC-Pfade, obwohl es damit zwangsläufig gegen die Wand fährt. Qualitätssicherung ist da also offenbar nicht wirklich ein Thema, auch darum wäre ich für Alternativen dankbar.

Die Kritik an den UNC-Pfaden bezog sich ja nicht darauf, dass sie nicht funktionieren, sondern dass ich sie angeben kann, und das nicht abgefangen wird. Ich habe inzwischen einige Server rumstehen, und zahlreiche Shares, ich habe mir einfach angewohnt mit UNC-Pfaden zu arbeiten. Wenn ich aber weiss, dass es nicht funktioniert, kann ich auch schnell einen auf einen Laufwerksbuchstaben mappen, ist ja kein Problem, man sollte es nur wissen, bevor das Programm loslegt und ins offene Messer rennt...

Schade übrigens, dass AutoGK nicht mit MKV-Inputs zurechtkommt, warum eigentlich?

XMedia recode hat mein obiges "exotisches" File übrigens ohne Murren konvertiert, inkl. Resize.