Recherche avancée

Sur d’autres sites (2201)

• Cracking Aztec Game Audio

  7 juin 2011, par Multimedia Mike — Game Hacking

  Here’s a mild multimedia-related reverse engineering challenge for you. It’s pretty straightforward for those skilled in the art.

  The Setup
  One side effect of running this ridiculously niche interest blog at the intersection of multimedia, reverse engineering, and game hacking is that people occasionally contact me for assistance on those very matters. So it was when one of my MobyGames peers asked if I can help to extract some music from a game called Aztec Wars. The game consists of 2 discs, each with a music.xbe file that contains multiple tunes and is hundreds of megabytes large.

  
  
  

  That’s all the data I received from the first email. At first I’m wondering what makes people think I have some magical insight into cracking these formats with such little information. Ordinarily, I would need to have the entire data file to work with and possibly the game binaries. But I didn’t want to ask him to upload hundreds of megabytes of data and I didn’t feel like downloading it ; commitment issues and all.

  But then I gathered a little confidence and remembered that the .xbe files are probably just Game Resource Archive Formats (GRAF) which are, traditionally, absurdly simple. I asked my colleague to send me a hexdump of the first kilobyte of one of the .xbe GRAFs ('hexdump -C -n 1024 music.xbe > file') as well as the total file size of the GRAF.

  The Hexdump
  The first music.xbe file is 192817376 bytes large. These are the first 1024 144 bytes (more than enough) :

  00000000  01 00 00 00 60 04 00 00  14 00 00 00 01 00 00 00  |....`...........|
  00000010  0d 00 00 00 48 00 00 00  94 39 63 01 1c a4 21 03  |....H....9c..¤ !.|
  00000020  7a d2 54 04 04 28 ad 05  d8 88 fd 06 d8 88 fd 06  |zÒT..(­.Ø.ý.Ø.ý.|
  00000030  2a 6e 46 08 2a 6e 46 08  2a 6e 46 08 2a 6e 46 08  |*nF.*nF.*nF.*nF.|
  00000040  50 13 2f 0a e0 28 7e 0b  52 49 46 46 44 39 63 01  |P./.à( .RIFFD9c.|
  00000050  57 41 56 45 66 6d 74 20  10 00 00 00 01 00 02 00  |WAVEfmt ........|
  00000060  44 ac 00 00 10 b1 02 00  04 00 10 00 64 61 74 61  |D¬...±......data|
  00000070  fc 13 63 01 00 00 00 00  00 00 00 00 00 00 00 00  |ü.c.............|
  00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  

  The Challenge
  Armed with only the information in the foregoing section, figure out a method for extracting all the audio files in that file and advise on their playback/conversion. Ideally, this method should require minimal effort from both you and the person on the other end of the conversation.

  The Resolution
  The reason I ask is because I came up with a solution but knew, deep down, that there must be a slightly easier way. How would you solve this ?

  The music files in question are now preserved on YouTube (until they see fit to remove them for one reason or another).

• Adding FFMPEG Layer to HLS streaming causes video playback issues

  25 juin 2023, par Moe

  I have been searching a lot about HLS streaming and have succeeded to create a simple HLS streaming server with nodejs, the problem now is I need to add a layer of ffmpeg encoding to the .ts chunks before streaming to the user, without this layer everything works fine and on my server only 3 requests are seen :

  


  manifest.m3u8
output_000.ts
output_000.ts
output_001.ts
output_002.ts


  


  But then when I add a simple ffmpeg layer that literally copies everything from the ts file and output the stream (I will add of course dynamic filters to each request, thats why I need this ffmpeg layer), the player goes insane and request the whole video in just 5 seconds or something :

  


  manifest.m3u8
output_000.ts
output_000.ts
output_001.ts
output_002.ts
output_001.ts
output_003.ts
output_002.ts
...
output_095.ts


  


  I have also notices that the numbers aren't increasing uniformly and suspect this is part of the issue, I have tried adding more ffmpeg options to not do anything to the .ts files that are being fed to it as they are a part of a bigger video.

  


  Here's my NodeJS server (NextJS API route) :

  


  
const fs = require(`fs`);
const path = require(`path`);
const {exec, spawn} = require(`child_process`);
const pathToFfmpeg = require(`ffmpeg-static`);

export default function handler(req, res) {
  
    const { filename } = req.query;
    console.log(filename);
    const filePath = path.join(process.cwd(), 'public', 'stream', `${filename}`);
    const inputStream = fs.createReadStream(filePath);

    // first check if that is ts file..
    if(filename.indexOf(`.ts`) != -1){
  
      const ffmpegProcess = spawn(pathToFfmpeg, [
        '-f', `mpegts`,
        '-i', 'pipe:0', // specify input as pipe
        '-c', 'copy', 
        '-avoid_negative_ts', '0',
        `-map_metadata`, `0`,  // copy without re-encoding
        '-f', 'mpegts', // output format
        'pipe:1'        // specify output as pipe
      ], {
        stdio: ['pipe', 'pipe', 'pipe'] // enable logging by redirecting stderr to stdout
      });
      res.status(200);
      res.setHeader('Content-Type', 'application/vnd.apple.mpegurl');
      res.setHeader('Cache-Control', 'no-cache');
      res.setHeader('Access-Control-Allow-Origin', '*');
 

      // ffmpegProcess.stderr.pipe(process.stdout); // log stderr to stdout
  
      inputStream.pipe(ffmpegProcess.stdin);
      ffmpegProcess.stdout.pipe(res);
  
      ffmpegProcess.on('exit', (code) => {
        if (code !== 0) {
          console.error(`ffmpeg process exited with code ${code}`);
        }
      });
    }else{
      // if not then stream whatever file as it is
      res.status(200);
      res.setHeader('Content-Type', 'application/vnd.apple.mpegurl');
      inputStream.pipe(res);
    }
  }


  


  I have tried to feed the request's player appropriate headers but that didn't work, I have also tried to add the '-re' option to the ffmpeg encoder itself and hoped for minimal performance hits, but that also caused playback issue due to being too slow.

  


• FFmpeg CRF control using x264 vs libvpx-vp9

  19 octobre 2016, par igon

  I have some experience using ffmpeg with x264 and I wanted to do a comparison with libvpx-vp9. I tested a simple single pass encoding of a raw video, varying the crf settings and presets both with x264 and libvpx-vp9. I am new to libvpx and I followed this and this carefully but I might have still specified wrong combination of parameters since the results I get do not make much sense to me.

  For x264 I did :

  ffmpeg -i test_video.y4m -c:v libx264 -threads 1 -crf <crf> -preset <preset> -y output.mkv 
  
  </preset></crf>

  and obtained the following results :

  codec  , settings                        , time        , PSNR      ,bitrate
  
  libx264,['-crf', '20', '-preset', 'fast'],13.1897280216, 42.938337 ,15728
  
  libx264,['-crf', '20', '-preset', 'medium'],16.80494689, 42.879753 ,15287
  
  libx264,['-crf', '20', '-preset', 'slow'],25.1142120361, 42.919206 ,15400
  
  libx264,['-crf', '30', '-preset', 'fast'],8.79047083855, 37.975141 ,4106
  
  libx264,['-crf', '30', '-preset', 'medium'],9.936599016, 37.713778 ,3749
  
  libx264,['-crf', '30', '-preset', 'slow'],13.0959510803, 37.569511 ,3555

  This makes sense to me, given a crf value you get a value of PSNR and changing the preset can decrease the bitrate but increase the time to encode.

  For libvpx-vp9 I did :

  ffmpeg -i test_video.y4m -c:v libvpx-vp9 -threads 1 -crf <crf> -cpu-used <effort> -y output.mkv 
  
  </effort></crf>

  First of all I thought from tutorials online that the -cpu-used option is equivalent to -preset in x264. Is that correct ? If so what is the difference with -quality ? Furthermore since the range goes from -8 to 8 I assumed that negative values where the fast options while positive values the slowest. Results I get are very confusing though :

  codec     , settings                      , time        , PSNR     ,bitrate
  
  libvpx-vp9,['-crf', '20', '-cpu-used', '-2'],19.6644911766,32.54317,571
  
  libvpx-vp9,['-crf', '20', '-cpu-used', '0'],176.670887947,32.69899,564
  
  libvpx-vp9,['-crf', '20', '-cpu-used', '2'],20.0206270218,32.54317,571
  
  libvpx-vp9,['-crf', '30', '-cpu-used', '-2'],19.7931578159,32.54317,571
  
  libvpx-vp9,['-crf', '30', '-cpu-used', '0'],176.587754965,32.69899,564
  
  libvpx-vp9,['-crf', '30', '-cpu-used', '2'],19.8394429684,32.54317,571

  Bitrate is very low and PSNR seems unaffected by the crf setting (and very low compared to x264). The -cpu-used setting has very minimal impact and also seems that -2 and 2 are the same option.. What am I missing ? I expected libvpx to take more time to encode (which is definitely true) but at the same time higher quality transcodes. What parameters should I use to
  have a fair comparison with x264 ?

  Edit : Thanks to @mulvya and this doc I figured that to work in crf mode with libvpx I have to add -b:v 0. I re-ran my tests and I get :

      codec     , settings                                 , time        , PSNR     ,bitrate
  
  libvpx-vp9,['-crf', '20', '-b:v', '0', '-cpu-used', '-2'],57.6835780144,45.111158,17908
  
  libvpx-vp9,['-crf', '20', '-b:v', '0', '-cpu-used', '0'] ,401.360313892,45.285367,17431
  
  libvpx-vp9,['-crf', '20', '-b:v', '0', '-cpu-used', '2'] ,57.4941239357,45.111158,17908
  
  libvpx-vp9,['-crf', '30', '-b:v', '0', '-cpu-used', '-2'],49.175855875,42.588178,11085
  
  libvpx-vp9,['-crf', '30', '-b:v', '0', '-cpu-used', '0'] ,347.158324957,42.782194,10935
  
  libvpx-vp9,['-crf', '30', '-b:v', '0', '-cpu-used', '2'] ,49.1892938614,42.588178,11085

  PSNR and bitrate went up significantly by adding -b:v 0