Recherche avancée

Sur d’autres sites (13052)

• how to reencode with ffmpeg (with limited x264)

  26 mai 2012, par sarfraz

  Until now I used this script to reencode my rips for my box (tv decoder) :

  ^_^ ( ~ ) -> cat ~/++/src/convert.sh 
  
  #! /bin/bash
  
  
  
  name=$(path -r "$1") # it gives the file name without the extension
  
  
  
  [ "$1" = *.mp4 ] && ffmpeg -i "$name".mp4 -vcodec copy -acodec copy "$name".mkv
  
  x264 --preset veryfast --tune animation --crf 18 --vf resize:720,576,16:15 -o "$name".tmp.mkv "$name".mkv
  
  mkvmerge -o "$name [freeplayer sd]".mkv "$name".tmp.mkv --no-video "$1"
  
  rm -rf "$name".tmp.mkv
  
  [ "$1" = *.mp4 ] && rm -rf "$name".mkv
  
  exit 0
  
  
  
  #EOF

  It works on my ubuntu and archlinux laptops. But it doesn’t on my desktop witch runs fedora.
  Google says that the x264 package shiped by rpmfusion doesn,t support lavf and ffms2.
  And I cannot unistall it because smplayer (witch i like) needs it.

  Ok, so I have to compile it. Google then says "you have to build ffmpeg, ffms2 tnen x264 ensuring that the flags are correctly refered." Well, didn’t work (ffms2 cannot find LIBAV - even when I am telling where - and x264 does’t configure with lavf...)

  My question is : can I use ffmpeg alone to do what my script does.
  I have ffmpeg version 0.8.11, x264 0.116.2048 59cb2eb and gcc : 4.6.1 20110804 (Red Hat 4.6.1-7)

  Any hint wound be appreciated.

  EDIT : Ok, I found that : ffmpeg -i input file -acodec copy -vcodec libx264 -preset veryfast -tune animation [that part I don’t have] output

  PS : english is not my native, plz forgive any spelling fault.

• Map streams in ffmpeg based on title (to remove language variant)

  16 octobre 2024, par MappaM

  I have a few video files with English audio track and French audio track, because the family wants French and I prefer VO. With ffmpeg I can easily filter all tracks to keep eng and fre, the problem is there are multiple french dialects, one of them being Candian (VFQ).

  


  Therefore, with the following input streams :

  


    Stream #0:1(fre): Audio: eac3, 48000 Hz, 5.1(side), fltp, 768 kb/s (default)
    Metadata:
      title           : E-AC3 VFF
  Stream #0:2(fre): Subtitle: subrip (default) (forced)
    Metadata:
      title           : FORCED VFF
  Stream #0:3(fre): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
    Metadata:
      title           : AC3 VFQ
  Stream #0:4(fre): Subtitle: subrip
    Metadata:
      title           : FORCED VFQ
  Stream #0:5(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 768 kb/s
    Metadata:
      title           : E-AC3 VO


  


  The command -map 0:v: -map 0:m:language:eng -map 0:m:language:fre does not filter out anything, and I keep both audio which is wasteful. The only metadata that could be used to filter seems to be the title.

  


• Metal Gear Solid VP3 Easter Egg

  4 août 2011, par Multimedia Mike — Game Hacking

  Metal Gear Solid : The Twin Snakes for the Nintendo GameCube is very heavy on the cutscenes. Most of them are animated in real-time but there are a bunch of clips — normally of a more photo-realistic nature — that the developers needed to compress using a conventional video codec. What did they decide to use for this task ? On2 VP3 (forerunner of Theora) in a custom transport format. This is only the second game I have seen in the wild that uses pure On2 VP3 (first was a horse game). Reimar and I sorted out most of the details sometime ago. I sat down today and wrote a FFmpeg / Libav demuxer for the format, mostly to prove to myself that I still could.

  Things went pretty smoothly. We suspected that there was an integer field that indicated the frame rate, but 18 fps is a bit strange. I kept fixating on a header field that read 0x41F00000. Where have I seen that number before ? Oh, of course — it’s the number 30.0 expressed as an IEEE 32-bit float. The 4XM format pulled the same trick.

  Hexadecimal Easter Egg
  I know I finished the game years ago but I really can’t recall any of the clips present in the samples directory. The file mgs1-60.vp3 contains a computer screen granting the player access and illustrates this with a hexdump. It looks something like this :

  
  
  

  Funny, there are only 22 bytes on a line when there should be 32 according to the offsets. But, leave it to me to try to figure out what the file type is, regardless. I squinted and copied the first 22 bytes into a file :

   1F 8B 08 00   85 E2 17 38   00 03 EC 3A   0D 78 54 D5
   38 00 03 EC   3A 0D
  

  And the answer to the big question :

  $ file mgsfile
  mgsfile : gzip compressed data, from Unix, last modified : Wed Oct 27 22:43:33 1999
  

  A gzip’d file from 1999. I don’t know why I find this stuff so interesting, but I do. I guess it’s no more and less strange than writing playback systems like this.