Recherche avancée

Sur d’autres sites (4832)

• avcodec : add DFPWM1a codec

  8 mars 2022, par Jack Bruienne

  avcodec : add DFPWM1a codec
  From the wiki page (https://wiki.vexatos.com/dfpwm) :
  
  > DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec
  
  > created by Ben “GreaseMonkey” Russell in 2012, originally to be used
  
  > as a voice codec for asiekierka's pixmess, a C remake of 64pixels.
  
  > It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole
  
  > low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding
  
  > creates a high-pitched whine, it is often followed by some post-processing
  
  > filters to make the stream more listenable.
  It has recently gained popularity through the ComputerCraft mod for
  
  Minecraft, which added support for audio through this codec, as well as
  
  the Computronics expansion which preceeded the official support. These
  
  both implement the slightly adjusted 1a version of the codec, which is
  
  the version I have chosen for this patch.
  This patch adds a new codec (with encoding and decoding) for DFPWM1a.
  
  The codec sources are pretty simple : they use the reference codec with
  
  a basic wrapper to connect it to the FFmpeg AVCodec system.
  To clarify, the codec does not have a specific sample rate - it is
  
  provided by the container (or user), which is typically 48000, but has
  
  also been known to be 32768. The codec does not specify channel info
  
  either, and it's pretty much always used with one mono channel.
  
  However, since it appears that libavcodec expects both sample rate and
  
  channel count to be handled by either the codec or container, I have
  
  made the decision to allow multiple channels interleaved, which as far
  
  as I know has never been used, but it works fine here nevertheless. The
  
  accompanying raw format has a channels option to set this. (I expect
  
  most users of this will not use multiple channels, but it remains an
  
  option just in case.)
  This patch will be highly useful to ComputerCraft developers who are
  
  working with audio, as it is the standard format for audio, and there
  
  are few user-friendly encoders out there, and even fewer decoders. It
  
  will streamline the process for importing and listening to audio,
  
  replacing the need to write code or use tools that require very
  
  specific input formats.
  You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test
  
  out DFPWM playback. To use it, run the program and type this command :
  
  "attach left speaker" Then run "speaker play <file.dfpwm>" for each file.
  
  The app runs in a sandbox, so files have to be transferred in first ;
  
  the easiest way to do this is to simply drag the file on the window.
  
  (Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.)
  Sample DFPWM files can be generated with an online tool at
  
  https://music.madefor.cc. This is the current best way to encode DFPWM
  
  files. Simply drag an audio file onto the page, and it will encode it,
  
  giving a download link on the page.
  I've made sure to update all of the docs as per Developer§7, and I've
  
  tested it as per section 8. Test files encoded to DFPWM play correctly
  
  in ComputerCraft, and other files that work in CC are correctly decoded.
  
  I have also verified that corrupt files do not crash the decoder - this
  
  should theoretically not be an issue as the result size is constant with
  
  respect to the input size.
  Signed-off-by : Jack Bruienne <jackbruienne@gmail.com>
  

  • [DH] Changelog
  • [DH] MAINTAINERS
  • [DH] doc/general_contents.texi
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/allcodecs.c
  • [DH] libavcodec/codec_desc.c
  • [DH] libavcodec/codec_id.h
  • [DH] libavcodec/dfpwmdec.c
  • [DH] libavcodec/dfpwmenc.c
  • [DH] libavcodec/utils.c
  • [DH] libavcodec/version.h

• fftools/ffprobe : drop -show_format_entry

  14 mars 2022, par Anton Khirnov

  fftools/ffprobe : drop -show_format_entry
  Deprecated since 2012.
  

  • [DH] fftools/ffprobe.c

• Winamp and the March of GUI

  1er juillet 2012, par Multimedia Mike — General, ars technica, gui, user interface, winamp

  Ars Technica recently published a 15-year retrospective on the venerable Winamp multimedia player, prompting bouts of nostalgia and revelations of "Huh ? That program is still around ?" from many readers. I was among them.

  
  
  

  I remember first using Winamp in 1997. I remember finding a few of these new files called MP3s online and being able to play the first 20 seconds using the official Fraunhofer Windows player— full playback required the fully licensed version. Then I searched for another player and came up with Winamp. The first version I ever used was v1.05 in the summer of 1997. I remember checking the website often for updates and trying out every single one. I can’t imagine doing that nowadays— programs need to auto-update themselves (which Winamp probably does now ; I can’t recall the last time I used the program).

  Video Underdog
  The last time Winamp came up on my radar was early in 2003 when a new version came with support for a custom, proprietary multimedia audio/video format called Nullsoft Video (NSV). I remember the timeframe because the date is indicated in the earliest revision of my NSV spec document (back when I was maintaining such docs in a series of plaintext files). This was cobbled together from details I and others in the open source multimedia community sorted out from sample files. It was missing quite a few details, though.

  Then, Winamp founder Justin Frankel — introduced through a colleague on the xine team — emailed me his official NSV format and told me I was free to incorporate details into my document just as long as it wasn’t obvious that I had the official spec. This put me in an obnoxious position of trying to incorporate details which would have been very difficult to reverse engineer without the official doc. I think I coped with the situation by never really getting around to updating my doc in any meaningful way. Then, one day, the official spec was released to the world anyway, and it is now mirrored here at multimedia.cx.

  I don’t think the format ever really caught on in any meaningful way, so not a big deal. (Anytime I say that about a format, I always learn it saw huge adoption is some small but vocal community.)

  What’s Wrong With This Picture ?
  What I really wanted to discuss in this post was the matter of graphical user interfaces and how they have changed in the last 15 years.
  
  I still remember when I first downloaded Winamp v1.05 and tried it on my Windows machine at the time. Indignantly, the first thought I had was, "What makes this program think it’s so special that it’s allowed to violate the user interface conventions put forth by the rest of the desktop ?" All of the Windows programs followed a standard set of user interface patterns and had a consistent look and feel... and then Winamp came along and felt it could violate all those conventions.

  I guess I let the program get away with it because it was either that or only play 20-second clips from the unregistered Fraunhofer player. Though incredibly sterile by comparison, the Fraunhofer player, it should be noted, followed Windows UI guidelines to the letter.

  As the summer of 1997 progressed and more Winamp versions were released, eventually one came out (I think it was v1.6 or so) that supported skins. I was excited because there was a skin that made the program look like a proper Windows program— at least if you used the default Windows color scheme, and had all of your fonts a certain type and size.

  Skins were implemented by packaging together a set of BMP images to overlay on various UI elements. I immediately saw a number of shortcomings with this skinning approach. A big one was UI lock-in. Ironically, if you skin an app and wish to maintain backwards compatibility with the thousands of skins selflessly authored by your vibrant community (seriously, I couldn’t believe how prolific these things were), then you were effectively locked into the primary UI. Forget about adding a new button anywhere.

  Another big problem was resolution-independence. Basing your UI on static bitmaps doesn’t scale well with various resolutions. Winamp had its normal mode and it also had double-sized mode.

  Skins proliferated among many types of programs in the late 1990s. I always treasured this Suck.com (remember them ? that’s a whole other nostalgia trip) essay from April, 2000 entitled Skin Cancer. Still, Winamp was basically the standard, and the best, and I put away my righteous nerd rage and even dug through the vast troves of skins. I remember settling on Swankamp for a good part of 1998, probably due to the neo-swing revival at the time.

  
  
  

  Then again, if Winamp irked me, imagine my reaction when I was first exposed to the Sonique Music Player in 1998 :

  
  
  

  The New UI Order
  Upon reflection, I realize now that I had a really myopic view of what a computer GUI should be. I thought the GUIs were necessarily supposed to follow the WIMP (windows, icons, mouse, pointer) paradigm and couldn’t conceive of anything different. For a long time, I couldn’t envision a useful GUI on a small device (like a phone) because WIMP didn’t fit well on such a small interface (even though I saw various ill-fated attempts to make it work). This thinking seriously crippled me when I was trying to craft a GUI for a custom console media player I was developing as a hobby many years ago.

  I’m looking around at what I have open on my Windows 7 desktop right now. Google Chrome browser, Apple iTunes, Adobe Photoshop Elements, and VMware Player are 4 programs which all seem to have their own skins. Maybe Winamp doesn’t look so out of place these days.