Recherche avancée

Sur d’autres sites (6248)

• Writing A Dreamcast Media Player

  6 janvier 2017, par Multimedia Mike — Sega Dreamcast

  I know I’m not the only person to have the idea to port a media player to the Sega Dreamcast video game console. But I did make significant progress on an implementation. I’m a little surprised to realize that I haven’t written anything about it on this blog yet, given my propensity for publishing my programming misadventures.

  
  
  

  This old effort had been on my mind lately due to its architectural similarities to something else I was recently brainstorming.

  Early Days
  Porting a multimedia player was one of the earliest endeavors that I embarked upon in the multimedia domain. It’s a bit fuzzy for me now, but I’m pretty sure that my first exposure to the MPlayer project in 2001 arose from looking for a multimedia player to port. I fed it through the Dreamcast development toolchain but encountered roadblocks pretty quickly. However, this got me looking at the MPlayer source code and made me wonder how I could contribute, which is how I finally broke into practical open source multimedia hacking after studying the concepts and technology for more than a year at that point.

  Eventually, I jumped over to the xine project. After hacking on that for awhile, I remembered my DC media player efforts and endeavored to compile xine to the console. The first attempt was to simply compile the codebase using the Dreamcast hobbyist community’s toolchain. This is when I came to fear the multithreaded snake pit in xine’s core. Again, my memories are hazy on the specifics, but I remember the engine having a bunch of threading hacks with comments along the lines of “this code deadlocks sometimes, so on shutdown, monitor this lock and deliberately break it if it has been more than 3 seconds”.

  Something Workable
  Eventually, I settled on a combination of FFmpeg’s libavcodec library for audio and video decoders, xine’s demuxer library, and xine’s input API, combined with my own engine code to tie it all together along with video and output drivers provided by the KallistiOS hobbyist OS for Dreamcast. Here is a simple diagram of the data movement through this player :

  
  
  

  Details and Challenges
  This is a rare occasion when I actually got to write the core of a media player engine. I made some mistakes.

  xine’s internal clock ran at 90000 Hz. At least, its internal timestamps were all in reference to a 90 kHz clock. I got this brilliant idea to trigger timer interrupts at 6000 Hz to drive the engine. Whatever the timer facilities on the Dreamcast, I found that 6 kHz was the greatest common divisor with 90 kHz. This means that if I could have found an even higher GCD frequency, I would have used that instead.

  So the idea was that, for a 30 fps video, the engine would know to render a frame on every 200th timer interrupt. I eventually realized that servicing 6000 timer interrupts every second would incur a ridiculous amount of overhead. After that, my engine’s philosophy was to set a timer to fire for the next frame while beginning to process the current frame. I.e., when rendering a frame, set a timer to call back in 1/30th of a second. That worked a lot better.

  As I was still keen on 8-bit paletted image codecs at the time (especially since they were simple and small for bootstrapping this project), I got to use output palette images directly thanks to the Dreamcast’s paletted textures. So that was exciting. The engine didn’t need to convert the paletted images to a different colorspace before rendering. However, I seem to recall that the Dreamcast’s PowerVR graphics hardware required that 8-bit textures be twiddled/swizzled. Thus, it was still required to manipulate the 8-bit image before rendering.

  I made good progress on this player concept. However, a huge blocker for me was that I didn’t know how to make a proper user interface for the media player. Obviously, programming the Dreamcast occurred at a very low level (at least with the approach I was using), so there were no UI widgets easily available.

  This was circa 2003. I assumed there must have been some embedded UI widget libraries with amenable open source licenses that I could leverage. I remember searching and checking out a library named libSTK. I think STK stood for “set-top toolkit” and was positioned specifically for doing things like media player UIs on low-spec embedded computing devices. The domain hosting the project is no longer useful but this appears to be a backup of the core code.

  It sounded promising, but the libSTK developers had a different definition of “low-spec embedded” device than I did. I seem to recall that they were targeting something along with likes of a Pentium III clocked at 800 MHz with 128 MB RAM. The Dreamcast, by contrast, has a 200 MHz SH-4 CPU and 16 MB RAM. LibSTK was also authored in C++ and leveraged the Boost library (my first exposure to that code), and this all had the effect of making binaries quite large while I was trying to keep the player in lean C.

  Regrettably, I never made any serious progress on a proper user interface. I think that’s when the player effort ran out of steam.

  The Code
  So, that’s another project that I never got around to finishing or publishing. I was able to find the source code so I decided to toss it up on github, along with 2 old architecture outlines that I was able to dig up. It looks like I was starting small, just porting over a few of the demuxers and decoders that I knew well.

  I’m wondering if it would still be as straightforward to separate out such components now, more than 13 years later ?

  The post Writing A Dreamcast Media Player first appeared on Breaking Eggs And Making Omelettes.

• Annual Release of External-Videos plugin – we’ve hit v1.0

  13 janvier 2017, par silvia

  This is the annual release of my external-videos wordpress plugin and with the help of Andrew Nimmolo I’m proud to annouce we’ve reached version 1.0 !

  So yes, my external-videos wordpress plugin is now roughly 7 years old, who would have thought ! During the year, I don’t get the luxury of spending time on maintaining this open source love child of mine, but at Christmas, my bad conscience catches up with me – every year ! I then spend some time going through bug reports, upgrading the plugin to the latest wordpress version, upgrading to the latest video site APIs, testing functionality and of course making a new release.

  This year has been quite special. The power of open source has kicked in and a new developer took an interest in external-videos. Andrew Nimmolo submitted patches over all of 2016. He decided to bring the external-videos plugin into the new decade with a huge update to the layout of the settings pages, general improvements, and an all-round update of all the video site APIs which included removing their overly complex SDKs and going straight for the REST APIs.

  Therefore, I’m very proud to be able to release version 1.0 today. Thanks, Andrew !

  Enjoy – and I look forward to many more contributions – have a Happy 2017 !

  —

  NOTE : If you’re upgrading from an older version, you might need to remove and re-add your social video sites because the API details have changed a bit. Also, we noticed that there were layout issues on WordPress 4.3.7, so try and make sure your WordPress version is up to date.

• ffmpeg - when scaling, how to keep shapes of people's heads

  19 janvier 2017, par Dave

  Ok, I’m quite familiar with FFMPEG utility in general, and have used it for
  years to cut short snippets from videos, etc. But it’s only in the last
  month that and I decided to learn to use it to transcode with video-filters
  etc. (Before that, I was using other tools such as ’Handbrake’ and ’FreeMake’
  and VLC, etc.)

  For my ffmpeg transcodes, my target output resolution will always be constant, from one transcode run to the next. But the resolution and display aspect-ratio of the input file, from one transcode run to the next, will vary...could be almost any values.
  The input files will never already have black-bars when displayed.

  So, the relevant portion [ i.e. the video-filter(s) part) of my cmd line ] presently is as follows :

  ffmpeg ... -vf "scale=720:406,setsar=1,pad=720:506:0:40:Black" ...

  Also note : I do NOT use the "-aspect" option in the cmd-line. (Maybe I’ll
  need to (???) to solve my issue, but I’m unsure about how that interacts
  with scaling.)

  ( EDIT : Oh, I happen to have chosen that resolution value of 720x406, for
  the image-area (i.e. inside the top/bottom black bars) because it
  has an aspect ratio of 16:9 (Of course, 16:9 ratio is common these days. )

  My cmd always executes cleanly and produces an output file (a WebM, tho I doubt
  that container types and/or vcodec choices matter at all to scaling algorithm issues).

  So the issue/problem that I’m trying to solve is how to prevent any stretching
  in either direction. In other words, a round soccer ball in the input file
  must yield a round ball in the output file ! (NOT oval-shaped in either axis).

  ( Edit #2 : Oh, I forgot to mention that I’m not have the same amount of stretching from one ffmpeg output file to the next. Sometimes there is
  no stretch in my output file, and with some other input file, the
  people are too tall in the output, and some other output file will have
  people are too wide. I’m assuming
  there is some single cmd that will always work for each randomly sized
  input file, WITHOUT having to resort to examining meta-data of each
  input and then having to adjust portions of the needed ffmpeg cmd.
  I assume this because I have used a tool called "FreeMake" that needs
  no such adjustment. When you do a ’scale’ with that program, it asks
  you to choose one of four adjustment-algorithms labeled "original"
  "stretched", "zoom..." and "auto". If I recall correctly, it was the
  "auto" choice that prevented any stretching.)

  The goal of that last filter (i.e. the "pad=720:506:0:40:Black" phrase) is to
  add a black bar of 40 pixels to the top and 60 pixels to the bottom.
  (That filter IS producing the black-bands, as desired. I mention it,
  because I’m unsure whether it could be having any effect on the altered
  shape of the ’round soccer ball’). If the "pad" filter IS part of the
  issue, then maybe I’ll need to make multiple ffmpeg cmds to achieve
  my overall goal (!?!?). [I’d LIKE to be able to do everything in just
  one ffmpeg cmd, as shown.]

  OK ?

  So are there any image-processing and ffmpeg gurus out there that
  know how to fix my problem ?

  TIA...

  Dave