Forum Debian Users Gang

ffmpeg -i test.flv -vcodec libx264 new.mp4

Input #0, flv, from 'test.flv':  Duration: 00:00:17.00, start: 0.000000, bitrate: 679 kb/s
    Stream #0.0: Video: h264, yuv420p, 480x360 [PAR 1:1 DAR 4:3], 679 kb/s, 29.97 tbr, 1k tbn, 60 tbc
    Stream #0.1: Audio: aac, 44100 Hz, stereo, s16
Unknown encoder 'libx264'

deb http://ftp.pl.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.pl.debian.org/debian/ sid main non-free contrib

Kontynuować [T/n]? T
Odczytywanie dzienników zmian... Zrobione
eglibc (2.13-25) unstable; urgency=medium


  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/<triplet> instead of the more
  traditional /lib, where <triplet> is the multiarch triplet and can be
  retrieved with 'dpkg-architecture -qDEB_HOST_MULTIARCH'. Similarly the
  includes are now shipped in /usr/include/<triplet> instead of the more
  traditional /usr/include.


  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following options to your
  compiler:


    -B/usr/lib/<triplet> -I/usr/include/<triplet>


  Alternatively if the build system makes hard to pass the above options,
  you might try to set the LIBRARY_PATH and CPATH environment variables:
    LIBRARY_PATH=/usr/lib/<triplet>
    CPATH=/usr/include/<triplet>
    export LIBRARY_PATH CPATH


 -- Aurelien Jarno <aurel32@debian.org>  Mon, 09 Jan 2012 12:47:16 +0100


eglibc (2.13-7) unstable; urgency=low


  Starting with version 2.13, eglibc provides an SSSE3 optimized version
  of memcpy() on the amd64 architecture. This version might copy memory
  backward in some conditions, which causes issues if the source and
  destination overlap. memmove() should be used in such cases, but some
  programs still wrongly use memcpy().


  For this reason, on the amd64 architecture the Debian package provides
  two wrappers which can be use to workaround and/or debug the issue:
  - /usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so simply replace all
    calls to memcpy() by a call to memmove()
  - /usr/lib/x86_64-linux-gnu/libc/memcpy-syslog-preload.so does the same,
    but in addition logs (with rate limit) the issue to syslog, so that it
    can be detected and fixed.


  To use these wrapper on a single binary, the easiest way is to use the
  LD_PRELOAD environment variable:
  - LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so /path/to/binary
  - LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-syslog-preload.so /path/to/binary


  For system-wide usage, it is possible to add the path of one of the
  wrapper to /etc/ld.so.preload.


  For more details about the issue, please see:
    http://bugs.debian.org/625521
    http://sourceware.org/bugzilla/show_bug.cgi?id=12518


 -- Aurelien Jarno <aurel32@debian.org>  Sat, 11 Jun 2011 18:02:52 +0200


cmake (2.8.7-4) unstable; urgency=low


  From now on, pass either -DPythonInterp_FIND_VERSION=<version> or
  -DPythonLibs_FIND_VERSION=<version> respectively in order to tell cmake to
  look for the specific Python version. However, if an explicit Python version
  is requested via find_package(), it will override the one specified on the
  command line.
/tmp/tmpuXbSUb

./configure --enable-shared
Found yasm 0.8.0.2194
Minimum version is yasm-1.2.0
If you really want to compile without asm, configure with --disable-asm.

Czytanie list pakietów... Gotowe
Budowanie drzewa zależności
Odczyt informacji o stanie... Gotowe
yasm jest już w najnowszej wersji.