Recherche avancée

Sur d’autres sites (13836)

• ffmpeg libz.so dependency

  26 février 2014, par malaprop malaprop

  we are trying to install ffmpeg on our RH linux servers.

  Trouble is that it works on one not on the other and we have no idea why. The working and the non working server have the same config information :

      ffmpeg version 0.10.2 Copyright (c) 2000-2012 the FFmpeg developers
  
      built on Apr 19 2012 14:00:25 with gcc 4.1.2 20080704 (Red Hat 4.1.2-51)
  
      configuration : —enable-gpl —enable-version3 —enable-shared —enable-nonfree —enable-postproc —enable-libfaac —enable-libmp3lame —enable-libopencore-amrnb —enable-libopencore-amrwb —enable-libtheora —enable-libvorbis —enable-libvpx —enable-libx264 —enable-libxvid —enable-x11grab —extra-cflags=-I/usr/local/include —extra-ldflags=-L/usr/local/lib
  
      libavutil      51. 35.100 / 51. 35.100
  
      libavcodec     53. 61.100 / 53. 61.100
  
      libavformat    53. 32.100 / 53. 32.100
  
      libavdevice    53.  4.100 / 53.  4.100
  
      libavfilter     2. 61.100 /  2. 61.100
  
      libswscale      2.  1.100 /  2.  1.100
  
      libswresample   0.  6.100 /  0.  6.100
  
      libpostproc    52.  0.100 / 52.  0.100
  
      Hyper fast Audio and Video encoder
  

  The error we are getting is :

      ffmpeg version 0.10.2 Copyright (c) 2000-2012 the FFmpeg developers
  
        built on Apr 19 2012 14:00:25 with gcc 4.1.2 20080704 (Red Hat 4.1.2-51)
  
        configuration : —enable-gpl —enable-version3 —enable-shared —enable-nonfree —enable-postproc —enable-libfaac —enable-libmp3lame —enable-libopencore-amrnb —enable-libopencore-amrwb —enable-libtheora —enable-libvorbis —enable-libvpx —enable-libx264 —enable-libxvid —enable-x11grab —extra-cflags=-I/usr/local/include —extra-ldflags=-L/usr/local/lib
  
      libavutil      51. 35.100 / 51. 35.100
  
      libavcodec     53. 61.100 / 53. 61.100
  
      libavformat    53. 32.100 / 53. 32.100
  
      libavdevice    53.  4.100 / 53.  4.100
  
      libavfilter     2. 61.100 /  2. 61.100
  
      libswscale      2.  1.100 /  2.  1.100
  
      libswresample   0.  6.100 /  0.  6.100
  
      libpostproc    52.  0.100 / 52.  0.100
  
      Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '4598_Testvideo_MP4-H264-6MBit_AAC-44KHz-192KBit_720p.mp4' :
  
        Metadata :
  
          major_brand : mp42
  
          minor_version : 0
  
          compatible_brands : mp42mp41
  
          creation_time : 2012-01-25 10:58:21
  
        Duration : 00:02:13.56, start : 0.000000, bitrate : 5472 kb/s
  
          Stream #0:0(eng) : Video : h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 5280 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc
  
          Metadata :
  
            creation_time : 2012-01-25 10:58:21
  
            handler_name : Mainconcept MP4 Video Media Handler
  
          Stream #0:1(eng) : Audio : aac (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 189 kb/s
  
          Metadata :
  
            creation_time : 2012-01-25 10:58:21
  
            handler_name : Mainconcept MP4 Sound Media Handler
  
      [buffer @ 0x3160ea0] w:1280 h:720 pixfmt:yuv420p tb:1/1000000 sar:1/1 sws_param :
  
      [scale @ 0x31629a0] w:1280 h:720 fmt:yuv420p -> w:480 h:270 fmt:yuv420p flags:0x4
  
      [libvpx @ 0x314ab40] v0.9.6
  
      [libvpx @ 0x314ab40] Failed to initialize encoder : ABI version mismatch
  
      Output #0, webm, to 'outputvideo.webm' :
  
        Metadata :
  
          major_brand : mp42
  
          minor_version : 0
  
          compatible_brands : mp42mp41
  
          creation_time : 2012-01-25 10:58:21
  
          Stream #0:0(eng) : Video : vp8, yuv420p, 480x270 [SAR 1:1 DAR 16:9], q=-1—1, 2500 kb/s, 90k tbn, 25 tbc
  
          Metadata :
  
            creation_time : 2012-01-25 10:58:21
  
            handler_name : Mainconcept MP4 Video Media Handler
  
          Stream #0:1(eng) : Audio : none, 44100 Hz, stereo, s16, 128 kb/s
  
          Metadata :
  
            creation_time : 2012-01-25 10:58:21
  
            handler_name : Mainconcept MP4 Sound Media Handler
  
      Stream mapping :
  
        Stream #0:0 -> #0:0 (h264 -> libvpx)
  
        Stream #0:1 -> #0:1 (aac -> libvorbis)
  
      Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
  

  I've looked at the dependent libraries using ldd and did find one differenct. the library libz.so was not listet in the system that doesn't work. ie

      /lib64/ld-linux-x86-64.so.2 (0x00000035a9000000)
  
      libavcodec.so.53 => /usr/local/lib/libavcodec.so.53 (0x00002ae5189a8000)
  
      libavdevice.so.53 => /usr/local/lib/libavdevice.so.53 (0x00002ae518204000)
  
      libavfilter.so.2 => /usr/local/lib/libavfilter.so.2 (0x00002ae51840e000)
  
      libavformat.so.53 => /usr/local/lib/libavformat.so.53 (0x00002ae51869c000)
  
      libavutil.so.51 => /usr/local/lib/libavutil.so.51 (0x00002ae519e17000)
  
      libc.so.6 => /lib64/libc.so.6 (0x00000035a9400000)
  
      libfaac.so.0 => /usr/lib64/libfaac.so.0 (0x0000003407800000)
  
      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000035ac000000)
  
      libmp3lame.so.0 => /usr/lib64/libmp3lame.so.0 (0x0000003407000000)
  
      libm.so.6 => /lib64/libm.so.6 (0x00000035aa000000)
  
      libogg.so.0 => /usr/local/lib/libogg.so.0 (0x00002ae51b35b000)
  
      libopencore-amrnb.so.0 => /usr/lib64/libopencore-amrnb.so.0 (0x0000003409800000)
  
      libopencore-amrwb.so.0 => /usr/lib64/libopencore-amrwb.so.0 (0x0000003407c00000)
  
      libpostproc.so.52 => /usr/local/lib/libpostproc.so.52 (0x00002ae5197ba000)
  
      libpthread.so.0 => /lib64/libpthread.so.0 (0x00000035a9c00000)
  
      libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000035aa400000)
  
      libswresample.so.0 => /usr/local/lib/libswresample.so.0 (0x00002ae5199c6000)
  
      libswscale.so.2 => /usr/local/lib/libswscale.so.2 (0x00002ae519bce000)
  
      libtheoradec.so.1 => /usr/local/lib/libtheoradec.so.1 (0x00002ae51b141000)
  
      libtheoraenc.so.1 => /usr/local/lib/libtheoraenc.so.1 (0x00002ae51af05000)
  
      libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00002ae51a8fe000)
  
      libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00002ae51acd9000)
  
      libvpx.so.0 => /usr/lib64/libvpx.so.0 (0x00002ae51a687000)
  
      libx264.so.120 => /usr/local/lib/libx264.so.120 (0x00002ae51a320000)
  
      libxvidcore.so.4 => /usr/lib64/libxvidcore.so.4 (0x00002ae51a03a000)
  
      linux-vdso.so.1 =>  (0x00007ffff63f6000)
  

  as opposed to

      /lib64/ld-linux-x86-64.so.2 (0x0000003074c00000)
  
      libavcodec.so.53 => /usr/local/lib/libavcodec.so.53 (0x00002b2038eeb000)
  
      libavdevice.so.53 => /usr/local/lib/libavdevice.so.53 (0x00002b2038746000)
  
      libavfilter.so.2 => /usr/local/lib/libavfilter.so.2 (0x00002b2038950000)
  
      libavformat.so.53 => /usr/local/lib/libavformat.so.53 (0x00002b2038bdf000)
  
      libavutil.so.51 => /usr/local/lib/libavutil.so.51 (0x00002b203a368000)
  
      libc.so.6 => /lib64/libc.so.6 (0x0000003075000000)
  
      libfaac.so.0 => /usr/lib64/libfaac.so.0 (0x00002b203bcef000)
  
      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003003400000)
  
      libmp3lame.so.0 => /usr/lib64/libmp3lame.so.0 (0x000000310ae00000)
  
      libm.so.6 => /lib64/libm.so.6 (0x0000003075c00000)
  
      libogg.so.0 => /usr/lib64/libogg.so.0 (0x00002b203bf01000)
  
      libopencore-amrnb.so.0 => /usr/lib64/libopencore-amrnb.so.0 (0x00002b203bac1000)
  
      libopencore-amrwb.so.0 => /usr/lib64/libopencore-amrwb.so.0 (0x00002b203b8ab000)
  
      libpostproc.so.52 => /usr/local/lib/libpostproc.so.52 (0x00002b2039d0b000)
  
      libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003075800000)
  
      libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000360ea00000)
  
      libswresample.so.0 => /usr/local/lib/libswresample.so.0 (0x00002b2039f18000)
  
      libswscale.so.2 => /usr/local/lib/libswscale.so.2 (0x00002b203a11f000)
  
      libtheoradec.so.1 => /usr/local/lib/libtheoradec.so.1 (0x00002b203b693000)
  
      libtheoraenc.so.1 => /usr/local/lib/libtheoraenc.so.1 (0x00002b203b457000)
  
      libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00002b203ae50000)
  
      libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00002b203b22a000)
  
      libvpx.so.0 => /usr/lib64/libvpx.so.0 (0x00002b203abd9000)
  
      libx264.so.120 => /usr/local/lib/libx264.so.120 (0x00002b203a871000)`enter code here`
  
      libxvidcore.so.4 => /usr/lib64/libxvidcore.so.4 (0x00002b203a58c000)
  
      libz.so.1 => /lib64/libz.so.1 (0x0000003076000000)
  
      linux-vdso.so.1 =>  (0x00007fff6adfd000)
  

  I wanted to ask whether this has something to do with the problem. before i try to figure out how come the libz.so appears i nthe one list and not the other.

  btw the ld.so.conf files are identical.

• 2011 In Open Source Multimedia

  5 janvier 2012, par Multimedia Mike — Open Source Multimedia

  Sometimes I think that the pace of multimedia technology is slowing down. Obviously, I’m not paying close enough attention. I thought I would do a little 2011 year-end review of what happened in the world of open source multimedia, mainly for my own benefit. Let me know in the comments what I missed.

  The Split
  The biggest deal in open source multimedia was the matter of the project split. Where once stood one project (FFmpeg) there now stands two (also Libav). Where do things stand with the projects now ? Still very separate but similar. Both projects obsessively monitor each other’s git commits and prodigiously poach each other’s work, both projects being LGPL and all. Most features that land in one code base end up in the other. Thus, I refer to FFmpeg and Libav collectively as “the projects”.

  Some philosophical reasons for the split included project stagnation and development process friction. Curiously, these problems are fond memories now and the spirit of competition has pushed development forward at a blinding pace.

  People inside the project have strong opinions about the split ; that’s understandable. People outside the project have strong opinions about the split ; that’s somewhat less understandable, but whatever. After 5 years of working for Adobe on the Flash Player (a.k.a. the most hated software in all existence if internet nerds are to be believed on the matter), I’m so over internet nerd drama.

  For my part, I just try to maintain some appearance of neutrality since I manage some shared resources for the open source multimedia community (like the wiki and samples repo) and am trying to keep them from fracturing as well.

  Apple and Open Source
  It was big news that Apple magnanimously open sourced their lossless audio codec. That sets a great example and precedent.

  New Features
  I mined the 'git log' of the projects in order to pick out some features that were added during 2011.

  First off, Apple’s ProRes video codec was reverse engineered and incorporated into the multimedia libraries. And for some weird reason, this is an item that made the rounds in the geek press. I’m not entirely sure why, but it may have something to do with inter-project conflict. Anyway, here is the decoder in action, playing a video of some wild swine, one of the few samples we have :

  
  
  

  Other new video codecs included a reverse engineered Indeo 4 decoder. Gotta catch ‘em all ! That completes our collection of Indeo codecs. But that wasn’t enough– this year, we got a completely revised Indeo 3 decoder (the previous one, while functional, exhibited a lot of code artifacts betraying a direct ASM ->C translation). Oh, and many thanks to Kostya for this gem :

  
  
  

  That’s the new Origin Xan decoder (best known for Wing Commander IV cinematics) in action, something I first started reverse engineering back in 2002. Thanks to Kostya for picking up my slack yet again.

  Continuing with the codec section, there is a decoder for Adobe Flash Screen Video 2 — big congrats on this ! One of my jobs at Adobe was documenting this format to the outside world and I was afraid I could never quite make it clear enough to build a complete re-implementation. But the team came through.

  Let’s see, there are decoders for VBLE video, Ut Video, Windows Media Image (WMVP/WMP2), Bink audio version ‘b’, H.264 4:2:2 intra frames, and MxPEG video. There is a DPX image encoder, a Cirrus Logic AccuPak video encoder, and a v410 codec.

  How about some more game stuff ? The projects saw — at long last — an SMJPEG demuxer. This will finally allow usage and testing of the SMJPEG IMA ADPCM audio decoder I added about a decade ago. Funny story behind that– I was porting all of my decoders from xine which included the SMJPEG ADPCM. I just never quite got around to writing a corresponding demuxer. Thanks to Paul Mahol for taking care of that.

  Here’s a DFA playback system for a 1995 DOS CD-ROM title called Chronomaster. No format is too obscure, nor its encoded contents too cheesy :

  
  
  

  There’s now a demuxer for a format called XMV that was (is ?) prevalent on Xbox titles. Now the projects can handle FMV files from many Xbox games, such as Thrillville.

  
  
  

  The projects also gained the ability to play BMV files. I think this surfing wizard comes from Discworld II. It’s non-computer-generated animation at a strange resolution.

  
  
  

  More demuxers : xWMA, PlayStation Portable PMP format, and CRI ADX format ; muxer for OpenMG audio and LATM muxer/demuxer.

  One more thing : an AVX-optimized fast Fourier transform (FFT). If you have a machine that supports AVX, there’s no way you’ll even notice the speed increase of a few measly FFT calls for audio coding/decoding, but that’s hardly the point. The projects always use everything on offer for any CPU.

  Please make me aware of features that I missed in the list !

  Continuous Testing
  As a result of the split, each project has its own FATE server, one for FFmpeg and one for Libav. As of the new year, FFmpeg has just over 1000 tests while Libav had 965. This is one area where I’m obviously ecstatic to see competition. Some ad-hoc measurements on my part indicate that the total code coverage via the FATEs has not appreciably increased. But that’s a total percentage. Both the test count and the code count have been steadily rising.

  Google Summer of Code and Google Code-In
  Once again, the projects were allowed to participate in the Google Summer of Code as well as Google Code-In. I confess that I didn’t keep up with these too carefully (and Code-In is still in progress as of this writing). I do know that the project split occurred after FFmpeg had already been accepted for GSoC season 2011 and the admins were gracious enough to allow FFmpeg and Libav to allow both projects to participate in the same slot as long as they could both be mature about it.

  Happy New Year
  Let’s see what we can accomplish in 2012.

• The 11th Hour RoQ Variation

  12 avril 2012, par Multimedia Mike — Game Hacking, dreamroq, Reverse Engineering, roq, Vector Quantization

  I have been looking at the RoQ file format almost as long as I have been doing practical multimedia hacking. However, I have never figured out how the RoQ format works on The 11th Hour, which was the game for which the RoQ format was initially developed. When I procured the game years ago, I remember finding what appeared to be RoQ files and shoving them through the open source decoders but not getting the right images out.

  I decided to dust off that old copy of The 11th Hour and have another go at it.

  
  
  

  Baseline
  The game consists of 4 CD-ROMs. Each disc has a media/ directory that has a series of files bearing the extension .gjd, likely the initials of one Graeme J. Devine. These are resource files which are merely headerless concatenations of other files. Thus, at first glance, one file might appear to be a single RoQ file. So that’s the source of some of the difficulty : Sending an apparent RoQ .gjd file through a RoQ player will often cause the program to complain when it encounters the header of another RoQ file.

  I have uploaded some samples to the usual place.

  However, even the frames that a player can decode (before encountering a file boundary within the resource file) look wrong.

  Investigating Codebooks Using dreamroq
  I wrote dreamroq last year– an independent RoQ playback library targeted towards embedded systems. I aimed it at a gjd file and quickly hit a codebook error.

  RoQ is a vector quantizer video codec that maintains a codebook of 256 2×2 pixel vectors. In the Quake III and later RoQ files, these are transported using a YUV 4:2:0 colorspace– 4 Y samples, a U sample, and a V sample to represent 4 pixels. This totals 6 bytes per vector. A RoQ codebook chunk contains a field that indicates the number of 2×2 vectors as well as the number of 4×4 vectors. The latter vectors are each comprised of 4 2×2 vectors.

  Thus, the total size of a codebook chunk ought to be (# of 2×2 vectors) * 6 + (# of 4×4 vectors) * 4.

  However, this is not the case with The 11th Hour RoQ files.

  Longer Codebooks And Mystery Colorspace
  Juggling the numbers for a few of the codebook chunks, I empirically determined that the 2×2 vectors are represented by 10 bytes instead of 6. Now I need to determine what exactly these 10 bytes represent.

  I should note that I suspect that everything else about these files lines up with successive generations of the format. For example if a file has 640×320 resolution, that amounts to 40×20 macroblocks. dreamroq iterates through 40×20 8×8 blocks and precisely exhausts the VQ bitstream. So that all looks valid. I’m just puzzled on the codebook format.

  Here is an example codebook dump :
  

  ID 0x1002, len = 0x0000014C, args = 0x1C0D
    0 : 00 00 00 00 00 00 00 00 80 80
    1 : 08 07 00 00 1F 5B 00 00 7E 81
    2 : 00 00 15 0F 00 00 40 3B 7F 84
    3 : 00 00 00 00 3A 5F 18 13 7E 84
    4 : 00 00 00 00 3B 63 1B 17 7E 85
    5 : 18 13 00 00 3C 63 00 00 7E 88
    6 : 00 00 00 00 00 00 59 3B 7F 81
    7 : 00 00 56 23 00 00 61 2B 80 80
    8 : 00 00 2F 13 00 00 79 63 81 83
    9 : 00 00 00 00 5E 3F AC 9B 7E 81
    10 : 1B 17 00 00 B6 EF 77 AB 7E 85
    11 : 2E 43 00 00 C1 F7 75 AF 7D 88
    12 : 6A AB 28 5F B6 B3 8C B3 80 8A
    13 : 86 BF 0A 03 D5 FF 3A 5F 7C 8C
    14 : 00 00 9E 6B AB 97 F5 EF 7F 80
    15 : 86 73 C8 CB B6 B7 B7 B7 85 8B
    16 : 31 17 84 6B E7 EF FF FF 7E 81
    17 : 79 AF 3B 5F FC FF E2 FF 7D 87
    18 : DC FF AE EF B3 B3 B8 B3 85 8B
    19 : EF FF F5 FF BA B7 B6 B7 88 8B
    20 : F8 FF F7 FF B3 B7 B7 B7 88 8B
    21 : FB FF FB FF B8 B3 B4 B3 85 88
    22 : F7 FF F7 FF B7 B7 B9 B7 87 8B
    23 : FD FF FE FF B9 B7 BB B7 85 8A
    24 : E4 FF B7 EF FF FF FF FF 7F 83
    25 : FF FF AC EB FF FF FC FF 7F 83
    26 : CC C7 F7 FF FF FF FF FF 7F 81
    27 : FF FF FE FF FF FF FF FF 80 80
  

  Note that 0x14C (the chunk size) = 332, 0x1C and 0x0D (the chunk arguments — count of 2×2 and 4×4 vectors, respectively) are 28 and 13. 28 * 10 + 13 * 4 = 332, so the numbers check out.

  Do you see any patterns in the codebook ? Here are some things I tried :

  • Treating the last 2 bytes as U & V and treating the first 4 as the 4 Y samples :
    
    
    
  • Treating the last 2 bytes as U & V and treating the first 8 as 4 16-bit little-endian Y samples :
    
    
    
  • Disregarding the final 2 bytes and treating the first 8 bytes as 4 RGB565 pixels (both little- and big-endian, respectively, shown here) :
    
    
    
  • Based on the type of data I’m seeing in these movies (which appears to be intended as overlays), I figured that some of these bits might indicate transparency ; here is 15-bit big-endian RGB which disregards the top bit of each pixel :
    
    
    

  These images are taken from the uploaded sample bdpuz.gjd, apparently a component of the puzzle represented in this screenshot.

  Unseen Types
  It has long been rumored that early RoQ files could contain JPEG images. I finally found one such specimen. One of the files bundled early in the uploaded fhpuz.gjd sample contains a JPEG frame. It’s a standard JFIF file and can easily be decoded after separating the bytes from the resource using ‘dd’. JPEGs serve as intraframes in the coding scheme, with successive RoQ frames moving objects on top.

  However, a new chunk type showed up as well, one identified by 0×1030. I have never encountered this type. Where could I possibly find data about this ? Fortunately, iD Games recently posted all of their open sourced games at Github. Reading through the code for their official RoQ decoder, I see that this is called a RoQ_PACKET. The name and the code behind it are both supremely unhelpful. The code is basically a no-op. The payloads of the various RoQ_PACKETs from one sample are observed to be either 8784, 14752, or 14760 bytes in length. It’s very likely that this serves the same purpose as the JPEG intraframes.

  Other Tidbits
  I read through the readme.txt on the first game disc and found this nugget :

          g)      Animations displayed normally or in SPOOKY MODE
                  SPOOKY MODE is blue-tinted grayscale with color cursors, puzzle
  
                  and game pieces.  It is the preferred display setting of the
  
                  developers at Trilobyte.  Just for fun, try out the SPOOKY
  
                  MODE.
  

  The MobyGames screenshot page has a number of screenshots labeled as being captured in spooky mode. Color tricks ?

  Meanwhile, another twist arose as I kept tweaking dreamroq to deal with more RoQ weirdness : After modifying my dreamroq code to handle these 10-byte vectors, it eventually chokes on another codebook. These codebooks happen to have 6-byte vectors again ! Fortunately, I was already working on a scheme to automatically detect which codebook is in play (plugging the numbers into a formula and seeing which vector size checks out).