Recherche avancée

Sur d’autres sites (8667)

• Programmatically specify rtmp s to be pulled from

  16 juillet 2014, par Stanislav

  I am sorry in advance if question might look a little bit silly, but I am very new to the current topic so hope you understand.

  Our current video streaming is performed with red5, and the client that receives the video is the flash client.

  My goal is to get the stream address of my red5 stream and programmatically send notification to nginx-rtmp to pull it.

  So let’s say I have the following nginx-rtmp configuration :

     application big {
  
         live on;
  
         exec_pull /home/stan/bin/ffmpeg -i rtmp://142.204.133.103/$app/${name}  -vcodec flv -an -f flv rtmp://localhost:1937/anotherapp/${name};
  
     }
  
  
  
     application anotherapp {
  
         live on;
  
    }

  Now I want notify nginx-rtmp and say : "Hey, here is rtmp ://142.204.133.103/red5app/livestream stream, can you please pull it, transcode and retransmit to "anotherapp" ?

  I can do it either from ActionScript3 or Java code, I just need a small example of how it’s usually done, because I got confused :(

  Thank you, guys.

• On ALAC’s Open Sourcing

  1er novembre 2011, par Multimedia Mike — Codec Technology

  Apple open sourced their lossless audio codec last week. Pretty awesome ! I have a theory that, given enough time, absolutely every codec will be open source in one way or another.

  I know I shouldn’t bother reading internet conversation around any news related to multimedia technology. And if I do read it, I shouldn’t waste any effort getting annoyed about them. But here are some general corrections :

  • ALAC is not in the same league as — nor is it a suitable replacement for — MP3/AAC/Vorbis or any other commonly used perceptual audio codec. It’s not a matter of better or worse ; they’re just different families of codecs designed for different purposes.
  • Apple open sourced ALAC, not AAC– easy mistake, though there’s nothing to ‘open source’ about AAC (though people can, and will, argue about its absolute ‘open-ness’).
  • There’s not much technical room to argue between ALAC and FLAC, the leading open source lossless audio compressor. Both perform similarly in terms of codec speeds (screamingly fast) and compression efficiency (results vary slightly depending on source material).
  • Perhaps the most frustrating facet is the blithe ignorance about ALAC’s current open source status. While this event simply added an official “open source” status to the codec, ALAC has effectively been open source for a very long time. According to my notes, the ALAC decoding algorithm was reverse engineered in 2005 and added into FFmpeg in March of the same year. Then in 2008, Google — through their Summer of Code program — sponsored an open source ALAC encoder.

  From the multimedia-savvy who are versed in these concepts, the conversation revolves around which would win in a fight, ALAC or FLAC ? And who between Apple and FFmpeg/Libav has a faster ALAC decoder ? The faster and more efficient ALAC encoder ? I contend that these issues don’t really matter. If you have any experience working with lossless audio encoders, you know that they tend to be ridiculously fast to both encode and decode and that many different lossless codecs compress at roughly the same ratios.

  As for which encoder is the fastest : use whatever encoder is handiest and most familiar, either iTunes or FFmpeg/Libav.

  As for whether to use FLAC or ALAC — if you’ve already been using one or the other for years, keep on using it. Support isn’t going to vanish. If you’re deciding which to use for a new project, again, perhaps choose based on software you’re already familiar with. Also, consider hardware support– ALAC enjoys iPod support, FLAC is probably better supported in a variety of non-iPod devices, though that may change going forward due to this open sourcing event.

  For my part, I’m just ecstatic that the question of moral superiority based on open source status has been removed from the equation.

  Code-wise, I’m interested in studying the official ALAC code to see if it has any corner-case modes that the existing open source decoders don’t yet account for. The source makes mention of multichannel (i.e., greater than stereo) configurations, but I don’t know if that’s in FFmpeg/Libav.

• Salty Game Music

  31 mai 2011, par Multimedia Mike — General

  Have you heard of Google’s Native Client (NaCl) project ? Probably not. Basically, it allows native code modules to run inside a browser (where ‘browser’ is defined pretty narrowly as ‘Google Chrome’ in this case). Programs are sandboxed so they aren’t a security menace (or so the whitepapers claim) but are allowed to access a variety of APIs including video and audio. The latter API is significant because sound tends to be forgotten in all the hullabaloo surrounding non-Flash web technologies. At any rate, enjoy NaCl while you can because I suspect it won’t be around much longer.

  After my recent work upgrading some old music synthesis programs to user more modern audio APIs, I got the idea to try porting the same code to run under NaCl in Chrome (first Nosefart, then Game Music Emu/GME). In this exercise, I met with very limited success. This blog post documents some of the pitfalls in my excursion.

  
  
  

  Infrastructure
  People who know me know that I’m rather partial — to put it gently — to straight-up C vs. C++. The NaCl SDK is heavily skewed towards C++. However, it does provide a Python tool called init_project.py which can create the skeleton of a project and can do so in C with the '-c' option :

  ./init_project.py -c -n saltynosefart
  

  This generates something that can be built using a simple ‘make’. When I added Nosefart’s C files, I learned that the project Makefile has places for project-necessary CFLAGS but does not honor them. The problem is that the generated Makefile includes a broader system Makefile that overrides the CFLAGS in the project Makefile. Going into the system Makefile and changing "CFLAGS =" -> "CFLAGS +=" solves this problem.

  Still, maybe I’m the first person to attempt building something in Native Client so I’m the first person to notice this ?

  Basic Playback
  At least the process to create an audio-enabled NaCl app is well-documented. Too bad it doesn’t seem to compile as advertised. According to my notes on the matter, I filled in PPP_InitializeModule() with the appropriate boilerplate as outlined in the docs but got a linker error concerning get_browser_interface().

  Plan B : C++
  Obviously, the straight C stuff is very much a second-class citizen in this NaCl setup. Fortunately, there is already that fully functional tone generator example program in the limited samples suite. Plan B is to copy that project and edit it until it accepts Nosefart/GME audio instead of a sine wave.

  The build system assumes all C++ files should have .cc extensions. I have to make some fixes so that it will accept .cpp files (either that, or rename all .cpp to .cc, but that’s not very clean).

  Making Noise
  You’ll be happy to know that I did successfully swap out the tone generator for either Nosefart or GME. Nosefart has a slightly fickle API that requires revving the emulator frame by frame and generating a certain number of audio samples. GME’s API is much easier to work with in this situation — just tell it how many samples it needs to generate and give it a pointer to a buffer. I played NES and SNES music play through this ad-hoc browser plugin, and I’m confident all the other supported formats would have worked if I went through the bother of converting the music data files into C headers to be included in the NaCl executable binaries (dynamically loading data via the network promised to be a far more challenging prospect reserved for phase 3 of the project).

  Portable ?
  I wouldn’t say so. I developed it on Linux and things ran fine there. I tried to run the same binaries on the Windows version of Chrome to no avail. It looks like it wasn’t even loading the .nexe files (NaCl executables).

  Thinking About The (Lack Of A) Future
  As I was working on this project, I noticed that the online NaCl documentation materialized explicit banners warning that my NaCl binaries compiled for Chrome 11 won’t work for Chrome 12 and that I need to code to the newly-released 0.3 SDK version. Not a fuzzy feeling. I also don’t feel good that I’m working from examples using bleeding edge APIs that feature deprecation as part of their naming convention, e.g., pp::deprecated::ScriptableObject().

  Ever-changing API + minimal API documentation + API that only works in one browser brand + requiring end user to explicitly enable feature = … well, that’s why I didn’t bother to release any showcase pertaining to this little experiment. Would have been neat, but I strongly suspect that this is yet another one of those APIs that Google decides to deprecate soon.

  See Also :

  • I eventually got a second wind and made this work using the C interface.