Recherche avancée

Sur d’autres sites (10134)

• x264 CLI crash while encoding [migrated]

  28 août 2011, par Ithilion

  i'm having hard time with x264 CLI encoding.
  I'm trying to encode a blu-ray source (8gb .m2ts file) into a mp4 video, but x264.exe keeps always crashing at approximately 20% progress.

  This is the Avisynth script i'm using :

  Source="C:\Ithilion\Temp\Editing\Anime\input.m2ts"
  
  V=FFVideoSource(Source,fpsnum=24000,fpsden=1001)
  
  A=FFAudioSource(Source)
  
  AudioDub(V,A)
  
  
  
  GradFun2DBmod(str=1.2)
  
  
  
  aWarpSharp2(depth=20)
  
  LimitedSharpenFaster(strength=255)
  
  
  
  TextSub("C:\Ithilion\Temp\Editing\Anime\subs1.ass")
  
  TextSub("C:\Ithilion\Temp\Editing\Anime\subs2.ass")

  These are the commands i'm using for the encode :

  x264 --profile high10 --level 5.1 --crf 23 --bframes 10 --b-adapt 2 --direct auto
  
  --me umh --merange 24 --partitions all --rc-lookahead 60 --ref 16 --subme 10 
  
  --trellis 2 --deblock -2:-2 --psy-rd 0.6:0.0 --aq-strength 1 --acodec aac 
  
  --abitrate 256 --output "output.mp4" "input.avs"

  This is the error i get :

  Name of the application that generated the error: x264.exe, Version: 0.0.0.0, time stamp: 0x4e427829
  
  Module name that generated the error: KERNELBASE.dll, Version: 6.1.7601.17651, time stamp: 0x4e211319
  
  Exception Code: 0xc00000fd
  
  Fault offset 0x0000b9bc
  
  Process ID that generated the error: 0xaac
  
  Start time of the application that generated the error: 0x01cc64e7f962548a
  
  Path to the application that generated the error: C:\Ithilion\Temp\Editing\x264\x264.exe
  
  Path of the module that generated the error: C:\Windows\syswow64\KERNELBASE.dll
  
  ID alert: a702ec4e-d0e7-11e0-b4d3-0023547ccfc5

  I'm running Win7 64 on a Q9400 @3200mHz with 4 GB RAM

  Thanks in advance for your support
  Best regards

• A Better Process Runner

  1er janvier 2011, par Multimedia Mike — Python

  I was recently processing a huge corpus of data. It went like this : For each file in a large set, run 'cmdline-tool <file>', capture the output and log results to a database, including whether the tool crashed. I wrote it in Python. I have done this exact type of the thing enough times in Python that I’m starting to notice a pattern.

  Every time I start writing such a program, I always begin with using Python’s commands module because it’s the easiest thing to do. Then I always have to abandon the module when I remember the hard way that whatever ’cmdline-tool’ is, it might run errant and try to execute forever. That’s when I import (rather, copy over) my process runner from FATE, the one that is able to kill a process after it has been running too long. I have used this module enough times that I wonder if I should spin it off into a new Python module.

  Or maybe I’m going about this the wrong way. Perhaps when the data set reaches a certain size, I’m really supposed to throw it on some kind of distributed cluster rather than task it to a Python script (a multithreaded one, to be sure, but one that runs on a single machine). Running the job on a distributed architecture wouldn’t obviate the need for such early termination. But hopefully, such architectures already have that functionality built in. It’s something to research in the new year.

  I guess there are also process limits, enforced by the shell. I don’t think I have ever gotten those to work correctly, though.

• Anomalie #2188 (Fermé) : Altération de données entre sauvegarde et restauration

  11 août 2011, par cedric -

  doit être corrigé en SPIP 3.0 ou le module de sauvegarde restauration a été complètement refait. Ne sera pas corrigé en 2.1