Recherche avancée

Sur d’autres sites (11233)

• avcodec/gdv : Remove unused variable

  30 septembre 2018, par Michael Niedermayer

  avcodec/gdv : Remove unused variable
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/gdv.c

• ffmpeg "Option preset not found."

  2 février 2015, par PiTheNumber

  I am trying to convert a .mpg to .flv with ffmpeg. On other servers I got it working but here with the ffmpeg clone (avconv) it just does not do it.

  Originally I was working with libfaac and preset fastfirstpass but thats not available in this build so I switched to the experimental acc and preset libx264-fast_firstpass :

  $ /usr/bin/ffmpeg -i /data/upload/videos/original/150128_Test_731_9d5b83.mpg
  
    -strict experimental -acodec aac -ab 128k -ar 44100 -vcodec libx264 -pass 1 
  
    -pre libx264-fast_firstpass -b 512k -s 360x204 
  
    -f flv /data/upload/videos/encoded/150129_Test_731_54f06a.flv
  
  
  
  avconv version 9.16-6:9.16-0ubuntu0.14.04.1, Copyright (c) 2000-2014 the Libav developers
  
    built on Aug 10 2014 18:16:02 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  
  [mpeg @ 0xc87de0] max_analyze_duration reached
  
  Guessed Channel Layout for  Input Stream #0.1 : stereo
  
  Input #0, mpeg, from '/data/upload/videos/original/150128_Test_731_9d5b83.mpg':
  
    Duration: 00:01:00.12, start: 0.989978, bitrate: 4814 kb/s
  
      Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x406 [PAR 406:405 DAR 16:9], 104857 kb/s, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
  
      Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 224 kb/s
  
  [libx264 @ 0xc8b4c0] using SAR=136/135
  
  [libx264 @ 0xc8b4c0] MB rate (26910000) > level limit (2073600)
  
  [libx264 @ 0xc8b4c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
  
  [libx264 @ 0xc8b4c0] profile Main, level 5.2
  
  [libx264 @ 0xc8b4c0] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=dia subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=30 rc=abr mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.25 aq=1:1.00
  
  Option preset not found.

  What does the error in the last line mean ?

  I already made sure the preset libx264-fast_firstpass.avpreset exists in /usr/share/avconv/ and if I change it to invalid ffmpeg complains with Preset invalid specified for stream 0:0, but could not be opened., so the preset is correct.

  Google does provide two results for this error. This chatlog and it’s pastebin about live streaming with the solution to add -f flv and some russian page. Nothing helped.

  Any advice ?

• Anomalie #3461 (Nouveau) : bug sur les urls à cause d’une mauvaise global $profondeur_url

  4 juin 2015, par Maïeul Rouquette

  Le symptome¶

  de temps en temps (mais assez fréquemment dans mon cas) lorsqu’on a un site dans un sous repertoire, les urls produite par #URL_ARTICLE et co contiennent des "../". Conséquent, lorsqu’on clique on remonte d’un niveau, et du coup on tombe sur une page 404.

  La cause¶

  Visiblement d’après https://core.spip.net/projects/spip/repository/revisions/20729 la cause serait une mauvaise globale $profondeur_url.
  Je cite ESJ

  Enfin compris pourquoi SPIP compile parfois des squelettes où la globale profondeur_url est incorrecte. Lorsqu’on place dans ecrire/.htaccess une redirection comme "ErrorDocument 403 / ?page=403", curieusement Apache met dans $_SERVER[’REQUEST_URI’] l’URL initiale (donc avec .../ecrire/...) tandis qu’il met dans $_SERVER[’SCRIPT_NAME’] l’URL de redirection (dans l’exemple ci-dessus une page à la racine). Du coup, la compilation de cette page à la racine se fait avec une profondeur d’URL qui est celle de ecrire/ et non de la racine. Pour peu que cette page et ses inclusions soient mises en cache, c’est toutes les autres pages qui les partagent qui se retouvent avec de mauvaises URL.

  Les tentatives de résolution¶

  Deux commits en 2.1 ont tenté de résoudre les pb :
  https://core.spip.net/projects/spip/repository/revisions/20729
  et https://core.spip.net/projects/spip/repository/revisions/20762

  Ils ont été reporté en 3.0 par
  - https://core.spip.net/projects/spip/repository/revisions/20744
  - https://core.spip.net/projects/spip/repository/revisions/20745
  puis annulé car visiblement non pleinement fonctionnels en

  - https://core.spip.net/projects/spip/repository/revisions/20746
  - https://core.spip.net/projects/spip/repository/revisions/20747

  à ma connaissance c’est le point mort depuis