Recherche avancée

Sur d’autres sites (4992)

• Re-solving My Search Engine Problem

  28 juillet 2012, par Multimedia Mike — General, swish-e

  14 years ago, I created a web database of 8-bit Nintendo Entertainment System games. To make it useful, I developed a very primitive search feature.

  A few months ago, I decided to create a web database of video game music. To make it useful, I knew it would need to have a search feature. I realized I needed to solve the exact same problem again.

  Requirements
  The last time I solved this problem, I came up with an excruciatingly naïve idea. Hey, it worked. I really didn’t want to deploy the same solution again because it felt so silly the first time. Surely there are many better ways to solve it now ? Many different workable software solutions that do all the hard work for me ?

  The first time I attacked this, it was 1998 and hosting resources were scarce. On my primary web host I was able to put static HTML pages, perhaps with server side includes. The web host also offered dynamic scripting capabilities via something called htmlscript (a.k.a. MIVA Script). I had a secondary web host in my ISP which allowed me to host conventional CGI scripts on a Unix host, so that’s where I hosted the search function (Perl CGI script accessing a key/value data store file).

  Nowadays, sky’s the limit. Any type of technology you want to deploy should be tractable. Still, a key requirement was that I didn’t want to pay for additional hosting resources for this silly little side project. That leaves me with options that my current shared web hosting plan allows, which includes such advanced features as PHP, Perl and Python scripts. I can also access MySQL.

  Candidates
  There are a lot of mature software packages out there which can index and search data and be plugged into a website. But a lot of them would be unworkable on my web hosting plan due to language or library package limitations. Further, a lot of them feel like overkill. At the most basic level, all I really want to do is map a series of video game titles to URLs in a website.

  Based on my research, Lucene seems to hold a fair amount of mindshare as an open source indexing and search solution. But I was unsure of my ability to run it on my hosting plan. I think MySQL does some kind of full text search, so I could have probably made a solution around that. Again, it just feels like way more power than I need for this project.

  I used Swish-e once about 3 years ago for a little project. I wasn’t confident of my ability to run that on my server either. It has a Perl API but it requires custom modules.

  My quest for a search solution grew deep enough that I started perusing a textbook on information retrieval techniques in preparation for possibly writing my own solution from scratch. However, in doing so, I figured out how I might subvert an existing solution to do what I want.

  Back to Swish-e
  Again, all I wanted to do was pull data out of a database and map that data to a URL in a website. Reading the Swish-e documentation, I learned that the software supports a mode specifically tailored for this. Rather than asking Swish-e to index a series of document files living on disk, you can specify a script for Swish-e to run and the script will generate what appears to be a set of phantom documents for Swish-e to index.
  

  When I ’add’ a game music file to the game music website, I have a scripts that scrape the metadata (game title, system, song titles, composers, company, copyright, the original file name on disk, even the ripper/dumper who extracted the chiptune in the first place) and store it all in an SQLite database. When it’s time to update the database, another script systematically generates a series of pseudo-documents that spell out the metadata for each game and prefix each document with a path name. Searching for a term in the index returns a lists of paths that contain the search term. Thus, it makes sense for that path to be a site URL.

  But what about a web script which can search this Swish-e index ? That’s when I noticed Swish-e’s C API and came up with a crazy idea : Write the CGI script directly in C. It feels like sheer madness (or at least the height of software insecurity) to write a CGI script directly in C in this day and age. But it works (with the help of cgic for input processing), just as long as I statically link the search script with libswish-e.a (and libz.a). The web host is an x86 machine, after all.

  I’m not proud of what I did here— I’m proud of how little I had to do here. The searching CGI script is all of about 30 lines of C code. The one annoyance I experienced while writing it is that I had to consult the Swish-e source code to learn how to get my search results (the "swishdocpath" key — or any other key — for SwishResultPropertyStr() is not documented). Also, the C program just does the simplest job possible, only querying the term in the index and returning the results in plaintext, in order of relevance, to the client-side JavaScript code which requested them. JavaScript gets the job of sorting and grouping the results for presentation.

  Tuning the Search
  Almost immediately, I noticed that the search engine could not find one of my favorite SNES games, U.N. Squadron. That’s because all of its associated metadata names Area 88, the game’s original title. Thus, I had to modify the metadata database to allow attaching somewhat free-form tags to games in order to compensate. In this case, an alias title would show up in the game’s pseudo-document.

  Roman numerals are still a thorn in my side, just as they were 14 years ago in my original iteration. I dealt with it back then by converting all numbers to Roman numerals during the index and searching processes. I’m not willing to do that for this case and I’m still looking for a good solution.

  Another annoying problem deals with Mega Man, a popular franchise. The proper spelling is 2 words but it’s common for people to mash it into one word, Megaman (see also : Spider-Man, Spiderman, Spider Man). The index doesn’t gracefully deal with that and I have some hacks in place to cope for the time being.

  Positive Results
  I’m pleased with the results so far, and so are the users I have heard from. I know one user expressed amazement that a search for Castlevania turned up Akumajou Densetsu, the Japanese version of Castlevania III : Dracula’s Curse. This didn’t surprise me because I manually added a hint for that mapping. (BTW, if you are a fan of Castlevania III, definitely check out the Akumajou Densetsu soundtrack which has an upgraded version of the same soundtrack using special audio channels.)

  I was a little more surprised when a user announced that searching for ’probotector’ correctly turned up Contra : Hard Corps. I looked into why this was. It turns out that the original chiptune filename was extremely descriptive : "Contra - Hard Corps [Probotector] (1994-08-08)(Konami)". The filenames themselves often carry a bunch of useful metadata which is why it’s important to index those as well.

  And of course, many rippers, dumpers, and taggers have labored for over a decade to lovingly tag these songs with as much composer information as possible, which all gets indexed. The search engine gets a lot of compliments for its ability to find many songs written by favorite composers.

• 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.

• ffmpeg mp4 to mpeg and back again

  5 décembre 2012, par brux

  I am concatenating mp4 files, from research I have found out you must first encode to mpeg and contatenate those, then convert the larger mpeg file back to mp4.

  For simplicity I am just attempting to convert a.mp4 to mpeg and then back to mp4 (i dont need to worry about the concatenation for now)

  Here is how I first convert to my intermediary mpeg from mp4 :

      ffmpeg -i a.mp4 -q:v 2 -vcodec mpeg2video -acodec copy b.mpg

  The file is encoded with no errors, to convert back to mp4 I do :

      ffmpeg -i b.mpg -vcodec libx264 -acodec copy out.mp4

  Everything seems to work with no errors but out.mp4 just plays the first few frames and then freezes, and the time is skipping randomly as the duration passes for the file. No sound is heard also.

      *****************************************                              
  
      Here is the output of the first command
  
      *****************************************
  
  
  
  $ ffmpeg -i a.mp4 -q:v 2 -vcodec mpeg2video -acodec copy b.mpg
  
      ffmpeg version 0.9, Copyright (c) 2000-2011 the FFmpeg developers
  
        built on Jun 12 2012 20:43:50 with gcc 4.4.3
  
        configuration: --enable-cross-compile --arch=arm --cpu=cortex-a8 --target-os=linux --enable-runtime-cpudetect --prefix=/data/data/org.witness.sscvideoproto --enable-pic --disable-shared --enable-static --cross-prefix=/home/n8fr8/dev/android/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- --sysroot=/home/n8fr8/dev/android/ndk/platforms/android-3/arch-arm --enable-version3 --enable-gpl --enable-small --enable-memalign-hack --disable-yasm --disable-doc --enable-decoder=mjpeg --enable-decoder=rawvideo --enable-encoder=libx264 --enable-muxer=mp4 --enable-demuxer=image2 --enable-demuxer=mjpeg --enable-demuxer=mp4 --enable-demuxer=mov --enable-parser=mjpeg --enable-filter=buffer --enable-filter=buffersink --enable-filter=drawbox --enable-filter=overlay --enable-filter=redact --enable-protocol=file --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-ffserver --disable-network --enable-libx264 --enable-zlib --extra-cflags=-I../x264 --extra-ldflags=-L../x264 --disabl  libavutil    51. 32. 0 / 51. 32. 0
  
        libavcodec   53. 42. 0 / 53. 42. 0
  
        libavformat  53. 24. 0 / 53. 24. 0
  
        libavfilter   2. 53. 0 /  2. 53. 0
  
        libswscale    2.  1. 0 /  2.  1. 0
  
        libpostproc  51.  2. 0 / 51.  2. 0
  
      [mov,mp4,m4a,3gp,3g2,mj2 @ 0xb05a90] multiple edit list entries, a/v desync might occur, patch welcome
  
  
  
      Seems stream 1 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 43.08 (517/12)
  
      Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'j.mp4':
  
        Metadata:
  
          major_brand     : isom
  
          minor_version   : 0
  
          compatible_brands: isom3gp4
  
          creation_time   : 1946-12-04 21:52:33
  
        Duration: 00:00:05.31, start: 0.000000, bitrate: 1584 kb/s
  
          Stream #0:0(eng): Audio: aac (mp4a / 0x6134706D), 16000 Hz, mono, s16, 96 kb/s
  
          Metadata:
  
            creation_time   : 1946-12-04 21:52:33
  
            handler_name    : SoundHandle
  
          Stream #0:1(eng): Video: h264 (avc1 / 0x31637661), yuv420p, 720x480, 1599 kb/s, SAR 65536:65536 DAR 3:2, 13.97 fps, 43.08 tbr, 90k tbn, 180k tbc
  
          Metadata:
  
            creation_time   : 1946-12-04 21:52:33
  
            handler_name    : VideoHandle
  
      [buffer @ 0xb247f0] w:720 h:480 pixfmt:yuv420p tb:1/1000000 sar:65536/65536 sws_param:
  
      [mpeg @ 0xb23d10] VBV buffer size not set, muxing may fail
  
      Output #0, mpeg, to 'out.mpg':
  
        Metadata:
  
          major_brand     : isom
  
          minor_version   : 0
  
          compatible_brands: isom3gp4
  
          creation_time   : 1946-12-04 21:52:33
  
          encoder         : Lavf53.24.0
  
          Stream #0:0(eng): Video: mpeg2video, yuv420p, 720x480 [SAR 65536:65536 DAR 3:2], q=2-31, 200 kb/s, 90k tbn, 50 tbc
  
          Metadata:
  
            creation_time   : 1946-12-04 21:52:33
  
            handler_name    : VideoHandle
  
          Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 16000 Hz, mono, 96 kb/s
  
          Metadata:
  
            creation_time   : 1946-12-04 21:52:33
  
            handler_name    : SoundHandle
  
      Stream mapping:
  
        Stream #0:1 -> #0:0 (h264 -> mpeg2video)
  
        Stream #0:0 -> #0:1 (copy)
  
      Press [q] to stop, [?] for help
  
      frame=   20 fps=  0 q=0.0 size=      14kB time=00:00:00.38 bitrate= 301.8kbits/s dup=15 frame=   34 fps= 28 q=0.0 size=     132kB time=00:00:00.66 bitrate=1638.4kbits/s dup=25 frame=   45 fps= 25 q=0.0 size=     230kB time=00:00:00.88 bitrate=2141.1kbits/s dup=33 frame=   55 fps= 22 q=0.0 size=     294kB time=00:00:01.08 bitrate=2230.0kbits/s dup=40 frame=   66 fps= 21 q=0.0 size=     306kB time=00:00:01.21 bitrate=2061.5kbits/s dup=48 frame=   79 fps= 21 q=0.0 size=     436kB time=00:00:01.56 bitrate=2289.6kbits/s dup=57 frame=   88 fps= 20 q=0.0 size=     514kB time=00:00:01.74 bitrate=2419.9kbits/s dup=63 frame=  100 fps= 21 q=0.0 size=     584kB time=00:00:01.98 bitrate=2416.2kbits/s dup=71 frame=  110 fps= 20 q=0.0 size=     618kB time=00:00:02.17 bitrate=2326.6kbits/s dup=78 frame=  116 fps= 19 q=0.0 size=     650kB time=00:00:02.24 bitrate=2377.1kbits/s dup=82 frame=  132 fps= 20 q=0.0 size=     830kB time=00:00:02.62 bitrate=2595.2kbits/s dup=94 frame=  144 fps= 20 q=0.0 size=     904kB time=00:00:02.86 bitrate=2589.4kbits/s dup=103frame=  156 fps= 20 q=0.0 size=     970kB time=00:00:03.10 bitrate=2563.3kbits/s dup=112frame=  168 fps= 20 q=0.0 size=    1006kB time=00:00:03.20 bitrate=2575.4kbits/s dup=121frame=  179 fps= 20 q=0.0 size=    1138kB time=00:00:03.56 bitrate=2618.7kbits/s dup=129frame=  191 fps= 20 q=0.0 size=    1240kB time=00:00:03.80 bitrate=2673.2kbits/s dup=138frame=  203 fps= 20 q=0.0 size=    1342kB time=00:00:04.04 bitrate=2721.2kbits/s dup=147frame=  215 fps= 20 q=0.0 size=    1426kB time=00:00:04.22 bitrate=2765.6kbits/s dup=156frame=  227 fps= 20 q=0.0 size=    1536kB time=00:00:04.52 bitrate=2783.8kbits/s dup=165frame=  239 fps= 20 q=0.0 size=    1646kB time=00:00:04.76 bitrate=2832.8kbits/s dup=174frame=  248 fps= 20 q=0.0 size=    1726kB time=00:00:04.94 bitrate=2862.2kbits/s dup=181frame=  248 fps= 19 q=0.0 Lsize=    1738kB time=00:00:04.94 bitrate=2882.1kbits/s dup=181 drop=0
  
      video:1665kB audio:62kB global headers:0kB muxing overhead 0.639219%
  
  
  
      *****************************************                              
  
      Here is the output of the second command
  
      *****************************************
  
  
  
  $ ffmpeg -i out.mpg -vcodec libx264 -acodec copy out1.mp4
  
      ffmpeg version 0.9, Copyright (c) 2000-2011 the FFmpeg developers
  
        built on Jun 12 2012 20:43:50 with gcc 4.4.3
  
        configuration: --enable-cross-compile --arch=arm --cpu=cortex-a8 --target-os=linux --enable-runtime-cpudetect --prefix=/data/data/org.witness.sscvideoproto --enable-pic --disable-shared --enable-static --cross-prefix=/home/n8fr8/dev/android/ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- --sysroot=/home/n8fr8/dev/android/ndk/platforms/android-3/arch-arm --enable-version3 --enable-gpl --enable-small --enable-memalign-hack --disable-yasm --disable-doc --enable-decoder=mjpeg --enable-decoder=rawvideo --enable-encoder=libx264 --enable-muxer=mp4 --enable-demuxer=image2 --enable-demuxer=mjpeg --enable-demuxer=mp4 --enable-demuxer=mov --enable-parser=mjpeg --enable-filter=buffer --enable-filter=buffersink --enable-filter=drawbox --enable-filter=overlay --enable-filter=redact --enable-protocol=file --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-ffserver --disable-network --enable-libx264 --enable-zlib --extra-cflags=-I../x264 --extra-ldflags=-L../x264 --disabl  libavutil    51. 32. 0 / 51. 32. 0
  
        libavcodec   53. 42. 0 / 53. 42. 0
  
        libavformat  53. 24. 0 / 53. 24. 0
  
        libavfilter   2. 53. 0 /  2. 53. 0
  
        libswscale    2.  1. 0 /  2.  1. 0
  
        libpostproc  51.  2. 0 / 51.  2. 0
  
      [mp1 @ 0xb0d420] Header missing
  
          Last message repeated 8 times
  
      [mpeg @ 0xb05a90] Could not find codec parameters (Audio: mp3, 0 channels, s16)
  
      Input #0, mpeg, from 'out.mpg':
  
        Duration: 00:00:05.24, start: 1.000000, bitrate: 2712 kb/s
  
          Stream #0:0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [SAR 1:1 DAR 3:2], 104857 kb/s, 50 fps, 50 tbr, 90k tbn, 100 tbc
  
          Stream #0:1[0x1c0]: Audio: mp3, 0 channels, s16
  
      [buffer @ 0xb77ca0] w:720 h:480 pixfmt:yuv420p tb:1/1000000 sar:1/1 sws_param:
  
      [libx264 @ 0xb0c6e0] using SAR=1/1
  
      [libx264 @ 0xb0c6e0] using cpu capabilities: ARMv6 NEON
  
      [libx264 @ 0xb0c6e0] profile High, level 3.1
  
      [libx264 @ 0xb0c6e0] 264 - core 119 r2113 cc129ad - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - 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=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=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
  
      Output #0, mp4, to 'out1.mp4':
  
        Metadata:
  
          encoder         : Lavf53.24.0
  
          Stream #0:0: Video: h264 (![0][0][0] / 0x0021), yuv420p, 720x480 [SAR 1:1 DAR 3:2], q=-1--1, 50 tbn, 50 tbc
  
      Stream mapping:
  
        Stream #0:0 -> #0:0 (mpeg2video -> libx264)
  
      Press [q] to stop, [?] for help
  
      frame=  248 fps=  3 q=31.0 Lsize=     419kB time=00:00:04.92 bitrate= 697.5kbits/s
  
      video:415kB audio:0kB global headers:0kB muxing overhead 0.863133%
  
      [libx264 @ 0xb0c6e0] frame I:3     Avg QP:16.46  size:  3927
  
      [libx264 @ 0xb0c6e0] frame P:102   Avg QP:22.91  size:  3884
  
      [libx264 @ 0xb0c6e0] frame B:143   Avg QP:27.16  size:   116
  
      [libx264 @ 0xb0c6e0] consecutive B-frames: 18.1%  8.9% 18.1% 54.8%
  
      [libx264 @ 0xb0c6e0] mb I  I16..4: 56.3% 42.7%  1.0%
  
      [libx264 @ 0xb0c6e0] mb P  I16..4:  6.1%  9.9%  0.6%  P16..4: 33.2%  4.9%  2.2%  0.0%  0.0%    skip:43.1%
  
      [libx264 @ 0xb0c6e0] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  6.7%  0.0%  0.0%  direct: 0.1%  skip:93.2%  L0:53.5% L1:45.4% BI: 1.2%
  
      [libx264 @ 0xb0c6e0] 8x8 transform intra:57.0% inter:85.5%
  
      [libx264 @ 0xb0c6e0] coded y,uvDC,uvAC intra: 36.0% 71.6% 24.9% inter: 4.4% 11.6% 0.6%
  
      [libx264 @ 0xb0c6e0] i16 v,h,dc,p: 35% 21% 10% 34%
  
      [libx264 @ 0xb0c6e0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 22% 34%  3%  3%  4%  2%  4%  5%
  
      [libx264 @ 0xb0c6e0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 19% 11%  4% 12% 12%  7%  5%  6%
  
      [libx264 @ 0xb0c6e0] i8c dc,h,v,p: 49% 22% 22%  7%
  
      [libx264 @ 0xb0c6e0] Weighted P-Frames: Y:2.9% UV:2.0%
  
      [libx264 @ 0xb0c6e0] ref P L0: 79.5%  8.1%  9.8%  2.5%  0.0%
  
      [libx264 @ 0xb0c6e0] ref B L0: 91.9%  7.5%  0.6%
  
      [libx264 @ 0xb0c6e0] ref B L1: 94.8%  5.2%
  
      [libx264 @ 0xb0c6e0] kb/s:684.84