Recherche avancée

Sur d’autres sites (3867)

• Revision 9626a0cb62 : Resolve compiler warning. conversion from 'const int64_t' to 'int', possible lo

  20 octobre 2014, par Paul Wilkins

  Changed Paths :
   Modify /vp9/encoder/vp9_encodeframe.c

  
  
  Resolve compiler warning.

  conversion from ’const int64_t’ to ’int’, possible loss of data.

  Change-Id : I471a73bba5d448d9be0ef9cbf1590fa73aa74be1

• Dealing with long conversion times on nginx, ffmpeg and Ruby on Rails

  19 avril 2013, par Graeme

  I have developed a Ruby on Rails-based app which allows users to upload videos to one of our local servers (Ubunto 10.04 LTS). The server uses nginx.

  Through the paperclip-ffmpeg gem, videos are converted to mp4 format using the ffmpeg library.

  Everything appears to be working fine in production, except Rails' own 500 page (not the customised version I have provided - but that's a different issue) is displayed whenever certain videos are uploaded. Otherwise, videos are being converted as expected.

  Having done a bit of investigation, I think the default 500 page is being displayed because a 502 error has occurred. I think what is happening, having uploaded the videos locally, is that some videos are taking an extensive amount of time to convert, and that an interruption is occurring on the server (I'm not a server expert by any means).

  Using the excellent Railscasts episode on deployment, I use Capistrano to deploy the app. Here's the unicorn.rb file :

  root = "XXXXXXX"
  
  working_directory root
  
  pid "#{root}/tmp/pids/unicorn.pid"
  
  stderr_path "#{root}/log/unicorn.log"
  
  stdout_path "#{root}/log/unicorn.log"
  
  
  
  listen "/tmp/unicorn.XXXXXXXXX.sock"
  
  worker_processes 2
  
  timeout 200

  And here's the nginx.conf file. Note that client_max_body_size has been set to a fairly hefty 4Gb ! :

  upstream unicorn {
  
    server unix:/tmp/unicorn.XXXXXXXXX.sock fail_timeout=0;
  
  }
  
  
  
  server {
  
    listen 80 default deferred;
  
    root XXXXXXXXX;
  
  
  
  
  
    location ^~ /assets/ {
  
      gzip_static on;
  
      expires max;
  
      add_header Cache-Control public;
  
    }
  
  
  
    try_files $uri/index.html $uri @unicorn;
  
    location @unicorn {
  
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  
      proxy_set_header Host $http_host;
  
      proxy_read_timeout 600; 
  
      proxy_redirect off;
  
      proxy_pass http://unicorn;
  
    }
  
  
  
    error_page 500 502 503 504 /500.html;
  
    client_max_body_size 4G;
  
    keepalive_timeout 10;
  
  
  
  }

  So, my question is...how could I edit (either of) the above two files to deal with the extensive time that certain videos take to convert through ffmpeg - possibly up to an hour, 2 hours or even more ?

  Should I extend timeout in the former and/or keepalive_timeout in the latter - or is there a more efficient way (given that I've no idea how long certain videos will take to convert) ?

  Or, is there possibly a more significant issue I should consider - e.g. the amount of memory in the server ?

  I'm not an nginx/server expert, so any advice would be useful (particularly where to put extra lines of code) - however, as the rest of the app just "works", I'm not keen to make a huge amount of changes !

• Revision cec763bd97 : set_vt_partitioning : fix type conversion warning double -> int64 + make thresho

  9 octobre 2014, par James Zern

  Changed Paths :
   Modify /vp9/encoder/vp9_encodeframe.c

  
  
  set_vt_partitioning : fix type conversion warning

  double -> int64
  + make threshold_multiplier an int

  Change-Id : I6d3607fdf13d670f57c9d9b04a80acb2be1346a0