Zelfde show, verschillende advertentiescan-tijden

General Support / Questions Commerciële verhuizing
1

Ik heb 2 afleveringen van dezelfde show/bron, met hetzelfde profiel en comskip.ini, die extreem verschillende advertentie-scantijden hebben. Het profiel dat ik gebruik is alleen voor testen, dus het is ingesteld om niet te transcoden. De originele bestanden zijn ongeveer even groot en lijken in orde. Iemand enig idee waarom sommige specifieke bestanden meer dan een uur nodig hebben?

“Normale” logfile
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)

Bijzonder trage logfile
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: Na verder testen vond ik geen probleem met de ingebouwde profielen. Op dit moment gebruik ik 2 aangepaste profielen, maar ik heb geen idee waarom dit bij sommige opnames FPS-problemen veroorzaakt en bij andere niet.

Heel vaak deze regels in de 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: Het is waarschijnlijk geen profielprobleem. Hoewel het wijzigen van het profiel werkte voor één van de problematische opnames, vertoont het merendeel van de andere opnames hetzelfde gedrag.

Hier zijn mijn 2 aangepaste profielen. De ene is voor NVENC-encoding en de andere is om comskip-logs te krijgen zonder encoding.

[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: Het probleem zit in de oudere comskip-versie die met MCEBuddy wordt meegeleverd. Ik zag een vergelijkbaar probleem dat 4/5 jaar geleden is aangepakt hier.

2

Het is geen profielprobleem. Het is een Comskip-probleem. Vergelijkbare videobestanden, hetzelfde INI-bestand — de ene wordt door Comskip verwerkt met 800 fps, de andere met 25 fps.

Het enige waar ik aan kan denken is: is de CPU bezig met iets anders terwijl de tragere Comskip draait? Zo niet, probeer dan te upgraden naar de nieuwste versie van Comskip of gebruik ShowAnalyzer.

3

Het is 100% een bug in de oudere gebundelde versie van Comskip. Erik heeft het opgelost, want met een nieuwere versie treedt dit probleem niet op.

Ik dacht dat het een profielprobleem was, want toen ik het profiel wijzigde, werkte het zoals verwacht. Ik moet een bestand hebben gebruikt dat ik dacht dat fout was, maar dat in werkelijkheid in orde was.