Recherche avancée

Sur d’autres sites (11036)

• Révision 18668 : Ajout de la DTD dans la structure retournée par infos_plugin() et infos_paquet().

  1er novembre 2011, par Eric Lupinacci

  Ne pas utiliser plugin_propre() sur les balises auteur, credit, copyright et licence pour éviter de prendre certains pseudos pour des items de langue : on utilise propre() simplement. Traitement complet des noms de plugin avec la DTD paquet : si il n’existe pas d’item de langue pour le nom, on (...)

• Revisiting Nosefart and Discovering GME

  30 mai 2011, par Multimedia Mike — Game Hacking

  I found the following screenshot buried deep in an old directory structure of mine :

  
  
  

  I tried to recall how this screenshot came to exist. Had I actually created a functional KDE frontend to Nosefart yet neglected to release it ? I think it’s more likely that I used some designer tool (possibly KDevelop) to prototype a frontend. This would have been sometime in 2000.

  However, this screenshot prompted me to revisit Nosefart.

  Nosefart Background
  Nosefart is a program that can play Nintendo Sound Format (NSF) files. NSF files are files containing components that were surgically separated from Nintendo Entertainment System (NES) ROM dumps. These components contain the music playback engines for various games. An NSF player is a stripped down emulation system that can simulate the NES6502 CPU along with the custom hardware (2 square waves, 1 triangle wave, 1 noise generator, and 1 limited digital channel).

  Nosefart was written by Matt Conte and eventually imported into a Sourceforge project, though it has not seen any development since then. The distribution contains standalone command line players for Linux and DOS, a GTK frontend for the Linux command line version, and plugins for Winamp, XMMS, and CL-Amp.

  The Sourceforge project page notes that Nosefart is also part of XBMC. Let the record show that Nosefart is also incorporated into xine (I did that in 2002, I think).

  Upgrading the API
  When I tried running the command line version of Nosefart under Linux, I hit hard against the legacy audio API : OSS. Remember that ?

  In fairly short order, I was able to upgrade the CL program to use PulseAudio. The program is not especially sophisticated. It’s a single-threaded affair which checks for a keypress, processes an audio frame, and sends the frame out to the OSS file interface. All that was needed was to rewrite open_hardware() and close_hardware() for PA and then replace the write statement in play(). The only quirk that stood out is that including <pulse/pulseaudio.h> is insufficient for programming PA’s simple API. <pulse/simple.h> must be included separately.

  For extra credit, I adapted the program to ALSA. The program uses the most simplistic audio output API possible — just keep filling a buffer and sending it out to the DAC.

  Discovering GME
  I’m not sure what to do with the the program now since, during my research to attempt to bring Nosefart up to date, I became aware of a software library named Game Music Emu, or GME. It’s a pure C++ library that can essentially play any classic video game format you can possible name. Wow. A lot can happen in 10 years when you’re not paying attention.

  It’s such a well-written library that I didn’t need any tutorial or documentation to come up to speed. Just a quick read of the main gme.h header library enabled me in short order to whip up a quick C program that could play NSF and SPC files. Path of least resistance : Client program asks library to open a hardcoded file, synthesize 10 seconds of audio, and dump it into a file ; ask the FLAC command line program to transcode raw data to .flac file ; use ffplay to verify the results.

  I might develop some other uses for this library.

• Need help on handling MPEG4V1 data

  14 septembre 2011, par Gediminas

  I'm in situation where I need to get a chunk of MPEG4V1 (Microsoft MPEG-4 VKI
  Codec V1) data located in the beginning of a packet (that was sent by some DVR unit).

  Packet structure looks something like this :

  • Compressed MPEG4 data.
  • Long integer - Number of events and tripwires.
  • Long integer - Number of events.
  • Event - Event's sequence.
  • Long integer - Number of tripwires.
  • Tripwire - Tripwires sequence.
  • Long integer - Cyclical redundant code (CRC).

  So there is no indication of how to know where does the MPEG4 data ends (Or is there ?),
  and from where should I start reading this additional data like "Number of events and tripwires" and etc...

  I uploaded two packet's so you could see how the actual data looks like :
  recvData1.txt,
  recvData2.txt.

  I've tried to decode those packets using FFmpeg library with avcodec_decode_video function and by removing byte by byte from the end of my recvData buffer in a hope for any results,
  but FFmpeg just allways returned with an error messages like this :

  "[msmpeg4v1 @ 038865a0] invalid startcode",
  "[msmpeg4v1 @ 038865a0] header damaged".

  I'm not that good specialist on knowing of how does the MPEG4 works from the inside,
  but judging by the error messages it's clearly seen that I'm missing some data for decoding at the start of the buffer.

  So I'm not sure of what part / kind of MPEG data I'm getting here..
  Maybe it's some kind of MPEG's "frame" data with it's "end" indication or something ?

  I've even compared the start of my recvData buffer to some of MPEG4V1 encoded video files I found on the net "http://www.trekmania.net/clips/video_clips4.htm" to check if the start of my buffer really contains the MPEG data ..and not some kind of DVR vendor specific stuff..

  And I noticed that there are about 20bytes of data
  (at the start of my packet data, and in .avi files right after about 180bytes..)
  that looks like some kind of header or something..

  Please check this image : "http://ggodis.gamedev.lt/stackOverflow/recvData.jpg"

  Maybe someone knows what this part of MPEG4V1 data represents ?

  P.S. ..I've checked the CRC values for my received packets and they were correct..