Recherche avancée

Sur d’autres sites (9782)

• Http Live Streaming - Segmenting mp3 on Linux

  14 mai 2012, par krisbulman

  I simply want to segment an mp3 for HTTP Live Streaming in any linux distro (preferably CentOS) for the purpose of audio streaming to an iOS app.

  Out of the linux segmenters, I can get the following to compile in CentOS.

  1. http://wiki.andy-chu.com/doku.php?id=http_live_streaming (not sure last time this was updated)

  2. m3u8-segmenter on github (updated months ago)

  3. https://github.com/carsonmcdonald/HTTP-Live-Video-Stream-Segmenter-and-Distributor [ruby wrappers + c] (last updated 2 years ago, and a v2 branch 9 months old)

  In order to prep the file for segmenting, here is the ffmpeg conversion string to generate a valid ts file :

  $ ffmpeg -er 4 -i input.mp3 -f mpegts -acodec libmp3lame -ar 22050 -ab 32k -vn output.ts

  Each of the segmenters require various input switches, all quite simple, and all crash out with a seg fault. #2 actually does some segmenting, but faults after 56 segments every time. I've tried various mp3s with the same results. The issue queues for 2 & 3 are full, with no responses in months of the same issues.

  Others must be doing this in a live production environment that isn't running OSX.. what are your methods ?

• How Many Default Languages ?

  26 janvier 2012, par Multimedia Mike — Programming

  I was thinking back to my childhood, when my family first owned a computer. It was an MS-DOS-powered IBM PC. The default OS came with 2 programming environments, such as they were : GW-BASIC and batch files. It was a start, I suppose. I guess most any microcomputer you can name from that era came with some kind of BASIC interpreter. That defined the computer’s “out of the box” programmability.

  Then I started wondering how this compares to computers (operating systems/distributions, really) these days. So I installed a fresh version of the latest Ubuntu Linux version (11.10 as of this writing ; x86_32) and looked for programmability (without installing anything else). This is what I came up with :

  1. gcc/C (only the C compiler ; other components of the GNU compiler collection are installed separately)
  2. Perl
  3. Python
  4. C#, as furnished by Mono
  5. Bash — can’t forget about the shell as a full-featured programming language (sh is also present, but not t/csh)
  6. JavaScript — since Firefox is installed per default, JS counts
  7. GNU Assember — thanks to Reimar for the reminder that if gcc is present, gas necessarily needs to be there as well

  I checked on C++, Objective C, Java, Ada, Fortran, Go, Lua, Ruby, Tcl, PHP, R and other languages I could think of, but the above items were the only ones present by default. At the same time, I checked my Mac OS X (10.6) box and it also has Ruby and PHP installed. It has a bunch of other languages, courtesy of Xcode, so I can’t certify anything about its out of the box programmability.

  Still, I think “embarrassment of riches” pretty well sums it up. I try not to be crotchety old fogey complaining that kids these days don’t know how good they have it ; rather, I’m genuinely excited for anyone who wants to leap into computer programming in this day and age.

• Mathematically lossless encoding and decoding of RGB24 image sequence

  25 avril 2013, par curryage

  I am trying to encode a RGB24 image sequence into a mathematically (not merely visually) lossless video. huffyuv was suggested on many online forums so I tried the following.

  ffmpeg -i frames\%06d.png  -vcodec huffyuv test.avi

  The resulting video was then decoded into frames again using ffmpeg

  ffmpeg -i test.avi outframes\%06d.png

  However, the input and output frames are not bit-by-bit identical as promised by huffyuv here. Any idea how I can accomplish this ? My eventual goal is to read the video file using OpenCV but I am willing to cross that bridge later once I obtain a losslessly encoded video file.

  This SO question mentions an attempt to obtain a lossless h264 avi and the summary of responses seems to indicate h264 cannot completely accomplish lossless encoding.

  Once again, to emphasize, I am interested in bit-by-bit identical encoding, not just visually similar. Large file sizes are acceptable as is large compression/decompression time.