Recherche avancée

Sur d’autres sites (3628)

• Investigating Steam for Linux

  1er mars 2013, par Multimedia Mike — Game Hacking

  Valve recently released the final, public version of their Steam client for Linux, and the Linux world rejoiced. At least, it probably did. The announcement was 2 weeks ago on Valentine’s Day and I had other things on my mind, so I missed any fanfare. When framed in this manner, the announcement timing becomes suspect– it’s as though Linux enthusiasts would have plenty of time that day or something.

  
  
  

  Taming the Frontier
  Speculation about a Linux Steam client had been kicking around for nearly as long as Steam has existed. However, sometime last year, the rumors became more substantive.

  I naturally wondered how to port something like Steam to Linux. I have some experience with trying to make a necessarily binary-only program that runs on Linux. I’m fairly well-versed in the assorted technical challenges that one might face when attempting such a feat. Because of this, whenever I hear rumors that a company might be entertaining the notion of porting a major piece of proprietary software to Linux, my instinctive reflex is, “What ?! Why, you fools ?! Save yourselves !”

  At least, that’s how it used to be. The proposal of developing a proprietary binary for Linux has been rendered considerably less insane by a few developments, for example :

  1. The rise of Ubuntu Linux as a quasi de facto standard for desktop Linux computing
  2. The increasing homogeneity in personal desktop computing technology

  What I would like to know is how the Steam client runs on Linux. Does it rely on any libraries being present on the system ? Or does it bring its own ? The latter is a trick that proprietary programs can use– transport all of the shared libraries that the main program binary depends upon, install them someplace out of the way on the filesystem, probably in /opt, and then make the main program a shell script which sets a preload path to rely on the known quantity libraries instead of the copies already on the system.

  Downloading and Installing the Client
  For this exercise, I installed x86_64 desktop Ubuntu 12.04 Linux on a l33t gaming rig that was totally top of the line about 5 years ago, and that someone didn’t want anymore and handed down to me recently. So it should be ideal for this project.

  At first, I was blown away– the Linux client is in a .deb package that is less than 2 MB large. I unpacked the steam.deb file and found a bunch of support libraries — mostly X11 and standard C/C++ runtimes. Just as I suspected. Still, I can’t believe how small the thing is. However, my amazement quickly abated when I actually ran Steam and saw this :

  
  
  

  So it turns out steam.db is just the installer program which immediately proceeds to download an additional 160+ MB of data. So there’s actually a lot more information to possibly sift through.
  
  Another component of the installation is to basically run a big ‘apt-get install’ command to make sure a bunch of required packages are installed :

  
  
  

  After all these installation steps, the client was ready to run. However, whenever I tried to do so, I got this dialog which would cause Steam to close when the dialog was dismissed.

  
  
  

  Not a huge deal ; later NVIDIA drivers are fairly straightforward to install on Ubuntu Linux. After a few minutes of downloading, installing and restarting X, Steam ran with minimal complaint (it still had some issue regarding the video drivers but didn’t seem to consider it a deal-breaker).

  Using Steam on Linux

  So here’s Steam running on Linux :

  
  
  

  If you have experience with using Steam on Windows or Mac, you might observe that it looks exactly the same. I don’t have a very expansive library of games (I only started using Steam because purchasing a few computer components a few years ago entitled me to some free Steam downloads of some of the games on the list in the screenshot). I didn’t really expect any of the games to have Linux versions yet, but it turns out that the indie darling FTL : Faster Than Light has been ported to Linux. FTL was a much-heralded Kickstarter success story and sounded like something I wanted to support. I purchased this from Steam shortly after its release last year and was able to download the Linux version at no additional cost with a single click.

  It runs natively on Linux (note the Ubuntu desktop window decorations) :

  
  
  

  You might notice from the main Steam client that, despite purchasing FTL about a 1/2 year ago and starting it up at least a 1/2 dozen times, I haven’t really invested a whole lot of time into it. I only managed to get about 2 minutes further this time :

  
  
  

  What can I say ? This game just bores me to tears. It’s frustrating because I know that this is one of the cool games that all real gamers are supposed to like, but I practically catch myself nodding off every time I try to run through the tutorial. It’s strange to think that I’ve invested far more time into games that offer considerably less stimulation. That’s probably because I had far more free time compared to gaming options during those times.

  But that’s neither here nor there. We’ll file this under “games that aren’t for me.” I’m glad that people like FTL and a little indie underdog has met with such success. And I’m pleased that Steam on Linux works. It’s native and the games are also native, which is all quite laudable (there was speculation that everything would just be running on top of a Wine layer).

  Deeper Analysis
  So I set out wondering how Steam was able to create a proprietary program that would satisfy a large enough cross-section of Linux users (i.e., on different platforms and distros). Answer : well, they didn’t, per the stated requirements. The installation is only tuned to work on Ubuntu 12.04. However, it works on both 32- and 64-bit platforms, the only 2 desktop CPU platforms that matter these days (unless ARM somehow makes inroads on the desktop). The Steam client is quite clearly an x86_32 binary– look at the terminal screenshot above and observe that it’s downloading all :i386 support libraries.

  The file /usr/bin/steam isn’t a binary but a launcher shell script (something you’ll also see if you investigate /usr/bin/firefox on a Linux system). Here’s an interesting tidbit :

  function detect_platform()
  
    # Maybe be smarter someday
    # Right now this is the only platform we have a bootstrap for, so hard-code it.
    echo ubuntu12_32
  
  

  I wager that it’s possible to get Steam running on other distributions, it probably just takes a little more effort (assuming that Steam doesn’t put too much effort into thwarting such attempts).

  As for the FTL game, it comes with binaries and libraries for both x86_32 and x86_64. So, good work to the dev team for creating and testing both versions. FTL also distributes versions of the libraries it expects to work with.

  I suspect that the Steam client overall is largely a WWW rendering engine underneath the covers. That would help explain how Valve is able to achieve such a consistent look and feel, not only across OS platforms, but also through a web browser. When I browse the Steam store through Google Chrome, it looks and feels exactly like the native desktop client. When I first thought of how someone could port Steam to Linux, I immediately wondered about how they would do the UI.

  A little Googling for “steam uses webkit” (just a hunch) confirms my hypothesis.

• Parsing The Clue Chronicles

  30 décembre 2018, par Multimedia Mike — Game Hacking

  A long time ago, I procured a 1999 game called Clue Chronicles : Fatal Illusion, based on the classic board game Clue, a.k.a. Cluedo. At the time, I was big into collecting old, unloved PC games so that I could research obscure multimedia formats.

  
  
  

  Surveying the 3 CD-ROMs contained in the box packaging revealed only Smacker (SMK) videos for full motion video which was nothing new to me or the multimedia hacking community at the time. Studying the mix of data formats present on the discs, I found a selection of straightforward formats such as WAV for audio and BMP for still images. I generally find myself more fascinated by how computer games are constructed rather than by playing them, and this mix of files has always triggered a strong “I could implement a new engine for this !” feeling in me, perhaps as part of the ScummVM project which already provides the core infrastructure for reimplementing engines for 2D adventure games.

  Tying all of the assets together is a custom high-level programming language. I have touched on this before in a blog post over a decade ago. The scripts are in a series of files bearing the extension .ini (usually reserved for configuration scripts, but we’ll let that slide). A representative sample of such a script can be found here :

  clue-chronicles-scarlet-1.txt

  What Is This Language ?
  At the time I first analyzed this language, I was still primarily a C/C++-minded programmer, with a decent amount of Perl experience as a high level language, and had just started to explore Python. I assessed this language to be “mildly object oriented with C++-type comments (‘//’) and reliant upon a number of implicit library functions”. Other people saw other properties. When I look at it nowadays, it reminds me a bit more of JavaScript than C++. I think it’s sort of a Rorschach test for programming languages.

  Strangely, I sort of had this fear that I would put a lot of effort into figuring out how to parse out the language only for someone to come along and point out that it’s a well-known yet academic language that already has a great deal of supporting code and libraries available as open source. Google for “spanish dolphins far side comic” for an illustration of the feeling this would leave me with.

  It doesn’t matter in the end. Even if such libraries exist, how easy would they be to integrate into something like ScummVM ? Time to focus on a workable approach to understanding and processing the format.

  Problem Scope
  So I set about to see if I can write a program to parse the language seen in these INI files. Some questions :

  1. How large is the corpus of data that I need to be sure to support ?
  2. What parsing approach should I take ?
  3. What is the exact language format ?
  4. Other hidden challenges ?

  To figure out how large the data corpus is, I counted all of the INI files on all of the discs. There are 138 unique INI files between the 3 discs. However, there are 146 unique INI files after installation. This leads to a hidden challenge described a bit later.

  What parsing approach should I take ? I worried a bit too much that I might not be doing this the “right” way. I’m trying to ignore doubts like this, like how “SQL Shame” blocked me on a task for a little while a few years ago as I concerned myself that I might not be using the purest, most elegant approach to the problem. I know I covered language parsing a lot time ago in university computer science education and there is a lot of academic literature to the matter. But sometimes, you just have to charge in and experiment and prototype and see what falls out. In doing so, I expect to have a better understanding of the problems that need to solved and the right questions to ask, not unlike that time that I wrote a continuous integration system from scratch because I didn’t actually know that “continuous integration” was the keyword I needed.

  Next, what is the exact language format ? I realized that parsing the language isn’t the first and foremost problem here– I need to know exactly what the language is. I need to know what the grammar are keywords are. In essence, I need to reverse engineer the language before I write a proper parser for it. I guess that fits in nicely with the historical aim of this blog (reverse engineering).

  Now, about the hidden challenges– I mentioned that there are 8 more INI files after the game installs itself. Okay, so what’s the big deal ? For some reason, all of the INI files are in plaintext on the CD-ROM but get compressed (apparently, according to file size ratios) when installed to the hard drive. This includes those 8 extra INI files. I thought to look inside the CAB installation archive file on the CD-ROM and the files were there… but all in compressed form. I suspect that one of the files forms the “root” of the program and is the launching point for the game.

  Parsing Approach
  I took a stab at parsing an INI file. My approach was to first perform lexical analysis on the file and create a list of 4 types : symbols, numbers, strings, and language elements ([]{}()=., :). Apparently, this is the kind of thing that Lex/Flex are good at. This prototyping tool is written in Python, but when I port this to ScummVM, it might be useful to call upon the services of Lex/Flex, or another lexical analyzer, for there are many. I have a feeling it will be easier to use better tools when I understand the full structure of the language based on the data available.
  
  The purpose of this tool is to explore all the possibilities of the existing corpus of INI files. To that end, I ran all 138 of the plaintext files through it, collected all of the symbols, and massaged the results, assuming that the symbols that occurred most frequently are probably core language features. These are all the symbols which occur more than 1000 times among all the scripts :

     6248 false
     5734 looping
     4390 scripts
     3877 layer
     3423 sequentialscript
     3408 setactive
     3360 file
     3257 thescreen
     3239 true
     3008 autoplay
     2914 offset
     2599 transparent
     2441 text
     2361 caption
     2276 add
     2205 ge
     2197 smackanimation
     2196 graphicscript
     2196 graphic
     1977 setstate
     1642 state
     1611 skippable
     1576 desc
     1413 delayscript
     1298 script
     1267 seconds
     1019 rect
  

  About That Compression
  I have sorted out at least these few details of the compression :

  bytes 0-3    "COMP" (a pretty strong sign that this is, in fact, compressed data)
  bytes 4-11   unknown
  bytes 12-15  size of uncompressed data
  bytes 16-19  size of compressed data (filesize - 20)
  bytes 20-    compressed payload
  

  The compression ratios are on the same order of gzip. I was hoping that it was stock zlib data. However, I have been unable to prove this. I wrote a Python script that scrubbed through the first 100 bytes of payload data and tried to get Python’s zlib.decompress to initialize– no luck. It’s frustrating to know that I’ll have to reverse engineer a compression algorithm that deals with just 8 total text files if I want to see this effort through to fruition.

  Update, January 15, 2019
  Some folks expressed interest in trying to sort out the details of the compression format. So I have posted a followup in which I post some samples and go into deeper details about things I have tried :

  Reverse Engineering Clue Chronicles Compression

  The post Parsing The Clue Chronicles first appeared on Breaking Eggs And Making Omelettes.

• Decoding Video using FFMpeg for android

  29 novembre 2014, par Rahul Upadhyay

  I tried to decode video using FFMpeg library from the sample examples available on internet, i figure it out with new version of ffmpeg,
  here is the code which I called from my class file,

     private static native int decodeVideo(String filename);
  
     decodeVideo(getString(R.string._sdcard_abc_3gp));

  now in .c file located in JNI dir,I wrote this code,

   jint Java_ru_dzakhov_ffmpeg_test_MainActivity_decodeVideo(JNIEnv* env, jobject
  
  javaThis,jstring filename) {   
  
    AVFormatContext *pFormatCtx;
  
    int             i, videoStream;
  
    AVCodecContext  *pCodecCtx;
  
    AVCodec         *pCodec;
  
    AVFrame         *pFrame;
  
    AVFrame         *pFrameRGB;
  
    AVPacket        packet;
  
    int             frameFinished;
  
    int             numBytes;
  
    uint8_t         *buffer;
  
  
  
    // Register all formats and codecs
  
    av_register_all();
  
  
  
    // Open video file
  
  
  
        const jbyte *str;
  
        str = (*env)->GetStringUTFChars(env, filename, NULL);
  
  
  
        if(av_open_input_file(&pFormatCtx, str, NULL, 0, NULL)!=0)
  
        {
  
            LOGI("Can't open file '%s'\n", str);
  
            return 1;
  
        }
  
        else
  
        {
  
            LOGI("File is opened\n");
  
            LOGI("File '%s', Codec %s",pFormatCtx->filename,pFormatCtx->iformat->name);
  
        }
  
  
  
  
  
    // Dump information about file onto standard error
  
  
  
    LOGI("dump_format");
  
    dump_format(pFormatCtx, 0, filename, 0);
  
    LOGI("dump_format DONE");
  
    // Find the first video stream
  
    videoStream=-1;
  
    for(i=0; inb_streams; i++)
  
      if(pFormatCtx->streams[i]->codec->codec_type==CODEC_TYPE_VIDEO)
  
        //if(pFormatCtx->streams[i]->codec->codec_type==AVMEDIA_TYPE_VIDEO)
  
        {
  
            LOGI("videoStream:: %d",videoStream);
  
        videoStream=i;
  
        break;
  
      }
  
    if(videoStream==-1)
  
      return -1; // Didn't find a video stream
  
  
  
    // Get a pointer to the codec context for the video stream
  
    pCodecCtx=pFormatCtx->streams[videoStream]->codec;
  
  
  
    // Find the decoder for the video stream
  
    pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
  
    if(pCodec==NULL) {
  
      fprintf(stderr, "Unsupported codec!\n");
  
      LOGI("Unsupported codec!\n");
  
      return -1; // Codec not found
  
    }
  
    // Open codec
  
    if(avcodec_open(pCodecCtx, pCodec)<0){
  
        LOGI("Codec Opened!\n");
  
      return -1; // Could not open codec
  
    }
  
    // Allocate video frame
  
    pFrame=avcodec_alloc_frame();
  
  
  
    // Allocate an AVFrame structure
  
    pFrameRGB=avcodec_alloc_frame();
  
    if(pFrameRGB==NULL){
  
  
  
        LOGI("checking --->>> pFrameRGB==NULL\n");
  
      return -1;
  
    }
  
    // Determine required buffer size and allocate buffer
  
  
  
    LOGI("Determine required buffer size and allocate buffer\n");
  
    numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
  
                                pCodecCtx->height);
  
  
  
    LOGI("numBytes %d",numBytes);
  
  
  
    buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
  
  
    // Assign appropriate parts of buffer to image planes in pFrameRGB
  
    // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
  
    // of AVPicture
  
    avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
  
                   pCodecCtx->width, pCodecCtx->height);
  
  
  
    // Read frames and save first five frames to disk
  
    i=0;
  
    while(av_read_frame(pFormatCtx, &packet)>=0) {
  
      // Is this a packet from the video stream?
  
      if(packet.stream_index==videoStream) {
  
        // Decode video frame
  
          avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished,&packet);
  
                             //packet.data, packet.size);
  
  
  
        // Did we get a video frame?
  
        if(frameFinished) {
  
          // Convert the image from its native format to RGB
  
          /*Temporarily down
  
           *
  
           * img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24,
  
                      (AVPicture*)pFrame, pCodecCtx->pix_fmt, pCodecCtx->width,pCodecCtx->height);*/
  
  
  
          // Save the frame to phone memory
  
            LOGI("Saving Frame\n");
  
           SaveFrame(pFrameRGB, pCodecCtx->width, pCodecCtx->height, ++i);
  
           LOGI("After Saving Frame\n");
  
        }
  
      }
  
  
  
      // Free the packet that was allocated by av_read_frame
  
      av_free_packet(&packet);
  
    }
  
  
  
    // Free the RGB image
  
    av_free(buffer);
  
    av_free(pFrameRGB);
  
  
  
    // Free the YUV frame
  
    av_free(pFrame);
  
  
  
    // Close the codec
  
    avcodec_close(pCodecCtx);
  
  
  
    // Close the video file
  
    av_close_input_file(pFormatCtx);
  
  
  
    return 0;
  
  }

  after compiling the code i get this in log,

  07-04 10:58:38.961: D/dalvikvm(1010): Trying to load lib /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so 0x4051e878
  
  07-04 10:58:38.971: D/dalvikvm(1010): Added shared lib /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so 0x4051e878
  
  07-04 10:58:38.971: D/dalvikvm(1010): No JNI_OnLoad found in /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so 0x4051e878, skipping init
  
  07-04 10:58:39.011: I/System.out(1010): Creating Engine
  
  07-04 10:58:39.011: I/mylib(1010): initiated
  
  07-04 10:58:39.011: I/System.out(1010): Decoding Video
  
  07-04 10:58:39.011: I/System.out(1010): passing video::/sdcard/NativeMedia.ts
  
  07-04 10:58:39.101: W/dalvikvm(231): disableGcForExternalAlloc: false
  
  07-04 10:58:39.121: I/DEBUG(71): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  
  07-04 10:58:39.121: I/DEBUG(71): Build fingerprint: 'htc_asia_india/htc_icong/icong:2.3.3/GRI40/68450.5:user/release-keys'
  
  07-04 10:58:39.121: I/DEBUG(71): pid: 1010, tid: 1010  >>> ru.dzakhov.ffmpeg.test <<<
  
  07-04 10:58:39.121: I/DEBUG(71): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 8102de90
  
  07-04 10:58:39.121: I/DEBUG(71):  r0 0000ac28  r1 40521b98  r2 40526340  r3 42157cc8
  
  07-04 10:58:39.121: I/DEBUG(71):  r4 bee7d368  r5 00000004  r6 40521b98  r7 42157c88
  
  07-04 10:58:39.121: I/DEBUG(71):  r8 bee7d348  r9 42157c80  10 42157c6c  fp 42f0f04c
  
  07-04 10:58:39.121: I/DEBUG(71):  ip 8102de91  sp bee7d348  lr 80018378  pc 8102de90  cpsr a0000030
  
  07-04 10:58:39.121: I/DEBUG(71):  d0  4140000041600000  d1  3ff0000041680000
  
  07-04 10:58:39.121: I/DEBUG(71):  d2  bf80000000000000  d3  0000000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  d4  0000000000000000  d5  3ff000003f800000
  
  07-04 10:58:39.121: I/DEBUG(71):  d6  bff000003f800000  d7  4160000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  d8  0000000000000000  d9  0000000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  d10 0000000000000000  d11 0000000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  d12 0000000000000000  d13 0000000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  d14 0000000000000000  d15 0000000000000000
  
  07-04 10:58:39.121: I/DEBUG(71):  scr 20000012
  
  07-04 10:58:39.221: I/DEBUG(71):          #00  pc 0002de90  /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #01  pc 0004f13c  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #02  pc 0001d584  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #03  pc 00022b8c  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #04  pc 00021a80  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #05  pc 0006060a  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #06  pc 0006828e  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #07  pc 0001d584  /system/lib/libdvm.so
  
  07-04 10:58:39.221: I/DEBUG(71):          #08  pc 00022b8c  /system/lib/libdvm.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #09  pc 00021a80  /system/lib/libdvm.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #10  pc 0006045c  /system/lib/libdvm.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #11  pc 0004c430  /system/lib/libdvm.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #12  pc 00037638  /system/lib/libandroid_runtime.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #13  pc 00038456  /system/lib/libandroid_runtime.so
  
  07-04 10:58:39.231: I/DEBUG(71):          #14  pc 00008ca2  /system/bin/app_process
  
  07-04 10:58:39.231: I/DEBUG(71):          #15  pc 00014f24  /system/lib/libc.so
  
  07-04 10:58:39.231: I/DEBUG(71): code around pc:
  
  07-04 10:58:39.231: I/DEBUG(71): 8102de70 003d9cd0 00000408 0029e598 0029e5de 
  
  07-04 10:58:39.231: I/DEBUG(71): 8102de80 0029e5d8 0029e5d8 0029e5cc 0029e5c8 
  
  07-04 10:58:39.231: I/DEBUG(71): 8102de90 4ff0e92d b0994604 f0004615 6823f945 
  
  07-04 10:58:39.231: I/DEBUG(71): 8102dea0 46294620 32a4f8d3 47982200 46044f81 
  
  07-04 10:58:39.231: I/DEBUG(71): 8102deb0 a8172300 22004621 9300447f f9c0f060 
  
  07-04 10:58:39.231: I/DEBUG(71): code around lr:
  
  07-04 10:58:39.231: I/DEBUG(71): 80018358 3497c004 3488c004 3afffff9 e2888004 
  
  07-04 10:58:39.231: I/DEBUG(71): 80018368 eafffff9 e899000c e594c008 e12fff3c 
  
  07-04 10:58:39.231: I/DEBUG(71): 80018378 e3550000 1594c00c 188c0003 e914a3f0 
  
  07-04 10:58:39.231: I/DEBUG(71): 80018388 e1a05e22 e5946004 e3a02000 e4d6c001 
  
  07-04 10:58:39.231: I/DEBUG(71): 80018398 e35c0000 0a000007 e2822001 e35c0044 
  
  07-04 10:58:39.231: I/DEBUG(71): stack:
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d308  000001b4  
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d30c  c0000000  
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d310  80018540  /system/lib/libdvm.so
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d314  0000cf98  
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d318  42157c6c  
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d31c  afd139d9  /system/lib/libc.so
  
  07-04 10:58:39.231: I/DEBUG(71):     bee7d320  0002de91  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d324  0000000e  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d328  80018540  /system/lib/libdvm.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d32c  00000070  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d330  42157c6c  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d334  00238100  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d338  00000000  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d33c  00000000  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d340  df002777  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d344  e3a070ad  
  
  07-04 10:58:39.241: I/DEBUG(71): #00 bee7d348  423692b4  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d34c  0000cf98  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d350  40521b98  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d354  8102de91  /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d358  80018540  /system/lib/libdvm.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d35c  0000cf98  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d360  bee7d368  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d364  800499df  /system/lib/libdvm.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d368  42157c80  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d36c  42d58795  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d370  8102de91  /data/data/ru.dzakhov.ffmpeg.test/lib/libmylib.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d374  bee7d418  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d378  00016de0  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d37c  0000ac28  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d380  00000001  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d384  bee7d418  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d388  42157c80  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d38c  40521b98  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d390  423692b4  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d394  800499a1  /system/lib/libdvm.so
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d398  42157c80  
  
  07-04 10:58:39.241: I/DEBUG(71):     bee7d39c  8004f13f  /system/lib/libdvm.so
  
  07-04 10:58:39.241: I/DEBUG(71): #01 bee7d3a0  00000002  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3a4  0000000e  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3a8  bee7d418  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3ac  0000cf98  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3b0  400198b8  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3b4  42d5861c  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3b8  42157c98  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3bc  bee7d410  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3c0  40521b98  
  
  07-04 10:58:39.251: I/DEBUG(71):     bee7d3c4  8001d588  /system/lib/libdvm.so

  Unable to understand what’s exact problem is there ?
  Here SaveFrame function is used it looks like,

  void SaveFrame(AVFrame *pFrame, int width, int height, int iFrame) {
  
    FILE *pFile;
  
    char szFilename[32];
  
    int  y;
  
  
  
    // Open file
  
    LOGI("Opening file!");
  
    sprintf(szFilename, "frame%d.ppm", iFrame);
  
  
  
    pFile=fopen(szFilename, "wb");
  
    if(pFile==NULL)
  
      return;
  
  
  
    // Write header
  
    fprintf(pFile, "P6\n%d %d\n255\n", width, height);
  
    //LOGI("width::"+width+"Height::"+height);
  
    // Write pixel data
  
    for(y=0; ydata[0]+y*pFrame->linesize[0], 1, width*3, pFile);
  
    }
  
    // Close file
  
    fclose(pFile);
  
  }

  in log I didn’t get any Log which i placed in the code !

  Please help me out,

  Thanks