Recherche avancée

Sur d’autres sites (5051)

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

• hwcontext_vulkan : add support for allocating all planes in a single allocation

  7 décembre 2021, par Wenbin Chen

  hwcontext_vulkan : add support for allocating all planes in a single allocation
  VAAPI on Intel can import external frame, but the planes of the external
  
  frames should be in the same drm object. A new option "contiguous_planes"
  
  is added to device. This flag tells device to allocate places in one
  
  memory. When device is derived from vaapi this flag will be enabled.
  
  A new flag frame_flag is also added to AVVulkanFramesContext. User
  
  can use this flag to force enable or disable this behaviour.
  
  A new variable "offset "is added to AVVKFrame. It describe describe the
  
  offset from the memory currently bound to the VkImage.
  Signed-off-by : Wenbin Chen <wenbin.chen@intel.com>
  
  Further-modifications-by : Lynne <dev@lynne.ee>
  

  • [DH] libavutil/hwcontext_vulkan.c
  • [DH] libavutil/hwcontext_vulkan.h

• cbs : Allow non-blank packets in ff_cbs_write_packet

  17 juin 2019, par Andreas Rheinhardt

  cbs : Allow non-blank packets in ff_cbs_write_packet
  Up until now, ff_cbs_write_packet always initialized the packet
  
  structure it received without documenting this behaviour ; furthermore,
  
  the packet's buffer would (on success) be overwritten with the new
  
  buffer without unreferencing the old. This meant that the input packet
  
  had to be either clean (otherwise there would be memleaks) in which case
  
  the initialization is redundant or uninitialized. ff_cbs_write_packet
  
  was never used with uninitialized packets, so the initialization was
  
  redundant. Worse yet, it forced callers to use more than one packet and
  
  made it difficult to add side-data to a packet designated for output,
  
  because said side-data could only be attached after the call to
  
  ff_cbs_write_packet.
  This has been changed. It is now allowed to use a non-blank packet.
  
  The currently existing buffer will be unreferenced and replaced by
  
  the new one, as will be the accompanying fields (i.e. data and size).
  
  The rest isn't touched at all.
  This change will enable us to use only one packet in the bitstream
  
  filters that rely on CBS.
  This commit also updates the documentation of ff_cbs_write_extradata
  
  and ff_cbs_write_packet (to better describe existing behaviour and in
  
  the latter case to also describe the new behaviour).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/cbs.c
  • [DH] libavcodec/cbs.h