Ich habe 2 Episoden derselben Sendung/Quelle, mit demselben Profil und comskip.ini, die stark unterschiedliche Werbeerkennungszeiten haben. Das Profil, das ich nutze, ist nur für Tests, daher ist es so eingestellt, dass es nicht transkodiert. Die Originaldateien sind von ähnlicher Größe und scheinen in Ordnung zu sein. Irgendeine Idee, warum bestimmte Dateien über eine Stunde brauchen?
„Normaler“ Log-Datei
King of the Hill S05E01 2000-10-01 The Perils of Polling 2023-08-08-1300-wk.mpg-Manual - No crop-2023-08-09T09-04-55.log (518,5 KB)
Ungewöhnlich langsame Log-Datei
King of the Hill S05E02 2000-11-05 The Buck Stops Here 2023-08-08-1330-wk.mpg-Manual - No crop-2023-08-09T09-09-52.log (1,6 MB)
EDIT: Nach weiteren Tests habe ich keine Probleme mit den eingebauten Profilen festgestellt. Ich nutze momentan 2 benutzerdefinierte Profile, aber keine Ahnung, warum es bei manchen Aufnahmen FPS-Probleme auslöst, bei anderen nicht.
Tonnenweise dieser Zeilen im comskip-Log:
Frame Rate set to 119.880 f/s
DFps[1]= 59.940 f/s
RFps[1]= 59.940 f/s
AFps[1]= 59.940 f/s
Frame Rate corrected to 59.940 f/s
EDIT #2: Zweifelhaft, dass es ein Profil-Problem ist. Obwohl das Wechseln des Profils bei einer der problematischen Aufnahmen funktionierte, zeigt es bei den meisten anderen Aufnahmen dasselbe Verhalten.
Hier sind meine 2 benutzerdefinierten Profile. Eines ist für die Nutzung von NVENC-Encoding, das andere dient dazu, comskip-Logs ohne Encoding zu erhalten.
[HEVC MKV NVENC 34cq]
Description=HEVC in MKV hard set to use NVidia.
order=handbrake
DisableEncoderReordering=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e nvenc_h265_10bit --encoder-preset slowest -q 34 --encopts="rc-lookahead=32:temporal-aq=1:spatial_aq=1"
handbrake-audio=--aencoder copy --audio-copy-mask ac3,eac3,truehd,dts,dtshd,mp3,flac --audio-fallback ffac3 -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-DisableSoftwareEncoderFallback=true
AllowAllCopyRemuxing=true
CustomCommandPath=C:\Windows\System32\curl.exe
CustomCommandParameters= -XPUT http://192.168.50.83:8089/dvr/pruner/deleted
CustomCommandHangPeriod=30
CustomCommandCritical=false
CustomCommandUISession=false
CustomCommandShowWindow=false
CustomCommandExitCodeCheck=false
PostCustomCommandPath=C:\Windows\System32\cmd.exe
PostCustomCommandParameters="/c del "%destinationpath%\%convertedfilename%.srt""
PostCustomCommandHangPeriod=60
PostCustomCommandCritical=false
PostCustomCommandUISession=false
PostCustomCommandShowWindow=false
PostCustomCommandExitCodeCheck=false
[MP4 Unprocessed LOGS]
Description=Logs Only
order=ffmpeg,copy
copy-ext=.ts
copy-remuxto=.mkv
copy-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec copy -map 0:v -sn
ffmpeg-audio=-acodec copy -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
FixedResolution=true
SkipCropping=true
AutoDeinterlace=false
DisableEncoderReordering=true
CopyLogFile=true
EDIT #3: Das Problem liegt bei der älteren comskip-Version, die mit MCEBuddy ausgeliefert wird. Ich habe ein ähnliches Problem vor 4/5 Jahren hier gesehen.