Recherche avancée

Sur d’autres sites (7572)

• Studying A Game Wave Disc

  23 novembre 2010, par Multimedia Mike — Game Hacking

  I picked up a used copy of game called Gemz — a rather flagrant Bejeweled clone — for a game console called Game Wave Family Entertainment System. Heard of it ? Neither had I. But the game media is optical, so I had to get it and study it.

  
  
  

  When mounted in Linux (as UDF), the disc is reported to contain 2.8 GB of data, so it has to be a DVD. 810 MB of that is dedicated to the movies/ directory. Multimedia format ? Just plain, boring MPEG files (very YouTube-friendly— here’s the opening animation). Deeper digging reveals some more subdirectories called movies/ that, combined, occupy the lion’s share of the disc space. Additionally, there are several single-frame .m2v files in a directory called iframes/ which are used to encode things like load screens.

  
  
  

  There are more interesting data files including .zbm files for images and fonts, and .zwf files for audio. I suspect that these stand for zipped bitmap and zipped wave file, respectively. They can’t be directly unzipped with ’gunzip’. Some of the numbers at the start of some files lead me to believe they can be easily decompressed with standard zlib facilities.

  Based on the binary files on the Gemz disc, I couldn’t find any data on what CPU this system might use. A little Googling led me to this page at the Video Game Console Library which pegs the brain as a Mediamatics 6811. Some searching for that leads me to a long-discontinued line of hardware from National Semiconductor.

  The Console Library page also mentions that the games were developed using the Lua programming language. Indeed, there are many Lua-related strings in the game’s binaries (’zlib’ also makes an appearance).

• Core : Fix TypeError in `showLabel` when using `groups` settings

  2 février 2016, par Arkni

  Core : Fix TypeError in `showLabel` when using `groups` settings
  The `this` inside `$.each()` refers to the current value of the
  
  `Objcet|Array` we iterate over, not the plugin instance.
  Ref jzaefferer/jquery-validation/pull/1614#discussion_r51156526
  Closes #1700.
  

• Can VLC's method for estimating the duration of a video be reproduced by the means of ffmpeg ?

  28 février, par archie

  This may seem to duplicate previous questions but it does not, as far as I can tell.

  


  I have a bash script for indexing images and videos to a thumbnails database. A user of my script complained that some videos of hers are skipped over with an error message "corrupted metadata" even though VLC can play them smoothly. These are about 10 videos out of some 15 thousand, but I'd like to solve the problem.

  


  I will focus on a single video from the bunch. File name : "Paper_and_discussion_M492.mkv", actual duration 02:03:47 (hh:mm:ss). The duration and bitrate fields in the video metadata are missing.

  


  ffmpeg  -hide_banner -i "Paper_and_discussion_M492.mkv" 2> ffmpeg_data.txt


  


  gives the following output :

  


    Input #0, matroska,webm, from 'Paper_and_discussion_M492.mkv':
  Metadata:
    COMPATIBLE_BRANDS: isomiso2avc1mp41
    MAJOR_BRAND     : isom
    MINOR_VERSION   : 512
    ENCODER         : Lavf58.76.100
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: hevc (Main), yuv420p(tv, progressive), 854x480 [SAR 1280:1281 DAR 16:9], 24 fps, 24 tbr, 1k tbn, 24 tbc (default)
    Metadata:
      HANDLER_NAME    : VideoHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libx265
  Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp (default)
    Metadata:
      HANDLER_NAME    : SoundHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libvorbis
At least one output file must be specified


  


  Therefore, as expected,

  


  ffprobe -i <file> -show_entries format=duration -v quiet -of csv="p=0"&#xA;</file>

  


  returns "N/A".

  


  Decoding the whole file does work :

  


  ffprobe -show_entries stream=r_frame_rate,nb_read_frames -select_streams v -count_frames -of compact=p=0:nk=1 -v 0 "Paper_and_discussion_M492.mkv"


  


  but it obviously takes a lot of time, especially for a > 2 hours video.

  


  The "faster answer" proposed by LSerni in https://superuser.com/questions/1179000/ffmpeg-get-duration-of-video-file-without-meta-data should give an estimate of duration based on bitrate ; but bitrate is also "N/A" in the incriminated file(s). Their command-line solution based on ffmpeg ends with an error "division by zero".

  


  However, if I open the file with VLC, it plays ok and VLC immediately shows the duration of the file as 02:03:47. I have checked that duration is precise. Search and jump are also very fast : if I skip 1 hr, playback promptly resumes at the right time.

  


  So, a doubt is gnawing at me : How does VLC succeed where I consistently fail ? It must have a way for recovering data that I might also be able to use to produce a correct estimate of duration.

  


  My question is : is it possible to reproduce VLC's method (or equivalent) by means of ffmpeg ?