Recherche avancée

Sur d’autres sites (8985)

• Piwik Mobile 2.1 Beta for Android

  14 août 2014, par Thomas Steur — Piwik Mobile Releases

  Four years ago we published the first version of Piwik Mobile ! To celebrate this event, the next beta of Piwik Mobile 2 for Android is now available.

  Download Piwik Mobile 2.1 Beta for Android 4+

  What’s new in Piwik Mobile 2.1 ?

  Over the last weeks we’ve been working on this update which includes several performance and UI improvements, bugfixes and new features :

  • Support for Segmentation [#3243] – you can now apply your custom segments in Piwik Mobile
  • Better support for Events
  • Clickable URL’s in a visitor’s actions list
  • Expose a general setting to configure SSL certificate validation [#5282]
  • Fixed the Real-Time Map was not working on Android 4.4+ [#4413]
  • List of all closed issues

  We have also updated the underlying framework for better compatibility with new devices and changed some code to improve performance.

  Give us feedback

  Start using Piwik Mobile 2.1 now and send us any feedback or create an issue on our new Piwik Mobile 2 Issue Tracker.

  While the app should be already quite stable we can improve Piwik Mobile much better with your help !

  Download now

  Download Piwik Mobile 2.1 Beta for Android 4+

• ffmpeg drops time delay on last frame of animated GIF

  13 août 2014, par Austin

  I am trying to convert animated GIFs to MP4 files using ffmpeg and x264. However, I seem be suffering from the effects of this bug in ffmpeg that causes the delay time of the last frame of the GIF to be ignored. For very short GIFs, this is quite a problem.

  As a work around, I was thinking that I should be able to manually tell ffmpeg to freeze on the last frame for a certain amount of time, specifically the proper duration of that frame (which I can extract from the GIF). However, I can’t seem to find a good way to do this. Any suggestions ? I would really like to be able to do this without having to split to the GIF into frames before putting it into ffmpeg since that will mess up GIFs with a non-constant framerate (in addition to being much slower).

  I am using ffmpeg version 2.3, though I have also tried this with the latest git code without any improvement. The full ffmpeg commands I’m using look like this :

  ffmpeg -i animation.gif -vf "scale=trunc(in_w/2)*2:trunc(in_h/2)*2" -c:v libx264 -b:v 2000k -y -pix_fmt yuv420p -f mp4 animation.mp4

  Here is some console output :

  ffmpeg version 2.3 Copyright (c) 2000-2014 the FFmpeg developers
  
    built on Aug 11 2014 21:19:46 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  
    configuration: --enable-gpl --enable-libass --enable-libfreetype --enable-libtheora --enable-libvorbis --enable-libx264
  
    libavutil      52. 92.100 / 52. 92.100
  
    libavcodec     55. 69.100 / 55. 69.100
  
    libavformat    55. 48.100 / 55. 48.100
  
    libavdevice    55. 13.102 / 55. 13.102
  
    libavfilter     4. 11.100 /  4. 11.100
  
    libswscale      2.  6.100 /  2.  6.100
  
    libswresample   0. 19.100 /  0. 19.100
  
    libpostproc    52.  3.100 / 52.  3.100
  
  Input #0, gif, from 'animation.gif':
  
    Duration: N/A, bitrate: N/A
  
      Stream #0:0: Video: gif, bgra, 500x375, 100 tbr, 100 tbn, 100 tbc
  
  [libx264 @ 0x239ea00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x239ea00] profile High, level 3.1
  
  [libx264 @ 0x239ea00] 264 - core 142 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 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=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
  Output #0, mp4, to 'animation.mp4':
  
    Metadata:
  
      encoder         : Lavf55.48.100
  
      Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 500x374, q=-1--1, 2000 kb/s, 100 fps, 12800 tbn, 100 tbc
  
      Metadata:
  
        encoder         : Lavc55.69.100 libx264
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (gif (native) -> h264 (libx264))
  
  Press [q] to stop, [?] for help
  
  frame=    7 fps=0.0 q=-1.0 Lsize=       7kB time=00:00:00.05 bitrate=1222.1kbits/s dup=5 drop=0    
  
  video:7kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 13.542441%
  
  [libx264 @ 0x239ea00] frame I:1     Avg QP:34.86  size:  3657
  
  [libx264 @ 0x239ea00] frame P:3     Avg QP:30.86  size:   744
  
  [libx264 @ 0x239ea00] frame B:3     Avg QP:33.33  size:    49
  
  [libx264 @ 0x239ea00] consecutive B-frames: 42.9%  0.0%  0.0% 57.1%
  
  [libx264 @ 0x239ea00] mb I  I16..4: 10.2% 78.3% 11.6%
  
  [libx264 @ 0x239ea00] mb P  I16..4:  1.2%  5.0%  0.8%  P16..4: 11.7%  3.3%  1.2%  0.0%  0.0%    skip:76.8%
  
  [libx264 @ 0x239ea00] mb B  I16..4:  0.0%  0.1%  0.0%  B16..8:  3.7%  0.0%  0.0%  direct: 0.0%  skip:96.2%  L0:23.5% L1:76.5% BI: 0.0%
  
  [libx264 @ 0x239ea00] final ratefactor: 20.31
  
  [libx264 @ 0x239ea00] 8x8 transform intra:77.0% inter:79.4%
  
  [libx264 @ 0x239ea00] coded y,uvDC,uvAC intra: 39.5% 0.0% 0.0% inter: 2.7% 0.0% 0.0%
  
  [libx264 @ 0x239ea00] i16 v,h,dc,p: 38% 27%  7% 28%
  
  [libx264 @ 0x239ea00] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 12% 13%  7%  6% 10%  4%  8%  5%
  
  [libx264 @ 0x239ea00] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 38% 11% 14%  5%  8% 10%  5%  7%  2%
  
  [libx264 @ 0x239ea00] i8c dc,h,v,p: 100%  0%  0%  0%
  
  [libx264 @ 0x239ea00] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x239ea00] ref P L0: 99.1%  0.7%  0.3%
  
  [libx264 @ 0x239ea00] ref B L0: 85.0% 15.0%
  
  [libx264 @ 0x239ea00] ref B L1: 95.4%  4.6%
  
  [libx264 @ 0x239ea00] kb/s:689.83

• mpegts : Do not try to write a PMT larger than SECTION_SIZE

  12 août 2014, par Luca Barbato

  mpegts : Do not try to write a PMT larger than SECTION_SIZE
  Prevent out of array writes.
  Similar to what Michael Niedermayer did to address the same issue.
  Bug-Id : CVE-2014-2263
  
  CC : libav-stable@libav.org
  Signed-off-by : Diego Biurrun <diego@biurrun.de>
  

  • [DH] libavformat/mpegtsenc.c