Recherche avancée

Sur d’autres sites (6598)

• Is 'Android+FFMpeg' friendship really available ?

  26 janvier 2016, par vold_by

  The question does not mean that I’m interested if ffmpeg code can be used on Andoid. I know that it can. I’m just asking if somebody has the real performance progress with that stuff.
  I’ve created the question after several weeks of experiments with the stuff and I’ve had enough...
  I do not want to write to branches where people even do not say what kind of video they decode (resolution, codec) and talk only about some mystical FPS. I just don’t understand what they want to do. Also I’m not going to develop application only for my phone or for Android 2.2++ phones that have some extended OpenGL features. I have quite popular phone HTC Desire so if the application does not work on it, so what’s next ?

  Well, what do I have ?

  1. FFMpeg source from the latest HEAD branch. Actually I could not buld it with NDK5 so I decided to use stolen one.

  2. Bambuser’s build script (bash) with appropriate ffmpeg source ([web] : http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz).
     It builds well after some corrections by using NDK5.

  3. Rockplayer’s gelded ffmpeg source code with huge Android.mk in the capacity of build script ([web] : http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip).
     It builds by NDK3 and NDK5 after some corrections. Rockplayer is probably the most cool media player for Android and I supposed that I would have some perks using it’s build.

  I had suitable video for a project (is not big and is not small) : 600x360 H.264.

  Both libraries we got from clauses 2 and 3 provide us possibility to get frames from video (frame-by-frame, seek etc.). I did not try to get an audio track because I did not need one for the project. I’m not publishing my source here because I think that’s traditional and it’s easy to find.

  Well, what’s the results with video ?
  HTC Desire, Android 2.2
  600x360, H.264
  decoding and rendering are in different threads

  1. Bambuser (NDK5 buld for armv5te, RGBA8888) : 33 ms/frame average.
  2. Rockplayer (NDK3 build for neon, RGB565) : 27 ms/frame average.

  It’s not bad for the first look, but just think that these are results only to decode frames.
  If somebody has much better results with decoding time, let me know.

  The most hard thing for a video is rendering. If we have bitmap 600x360 we should scale one somehow before painting because different phones have different screen sizes and we can not expect that our video will be the same size as screen.

  What options do we have to rescale a frame to fit it to screen ?
  I was able to check (the same phone and video source) those cases :

  1. sws_scale() C function in Bambuser’s build : 70 ms/frame. Unacceptable.
  2. Stupid bitmap rescaling in Android (Bitmap.createScaledBitmap) : 65 ms/frame. Unacceptable.
  3. OpenGL rendering in ortho projection on textured quad. In this case I did not need to scale frame. I just needed to prepare texture 1024x512 (in my case it was RGBA8888) containig frame pixels and than load it in GPU (gl.glTexImage2D). Result : 220 ms/frame to render. Unacceptable. I did not expect that glTexImage2D just sucked on Snapdragon CPU.

  That’s all.
  I know that there is some way to use fragment shader to convert YUV pixels using GPU, but we will have the same glTexImage2D and 200 ms just to texture loading.

  But this is not the end. ...my only friend the end... :)
  It’s not hopeless condition.

  Trying to use RockPlayer you definitely will wonder how they do that damn frame scaling so fast. I suppose that they have really good experience in ARM achitecture. They most probably use avcodec_decode_video2 and than img_convert (as I did in RP version), but then they use some tricks (depends of ARM version) for scaling.
  Maybe they also have some "magic" buld configuration for ffmpeg decreasing decoding time but Android.mk that they published is not THE Android.mk they use. Dunno...

  So, now it looks like you can not just buld some easy JNI bridge for ffmpeg and than have real media player for Android platform. You can do this only if you have suitable video that you do not need to scale.

  Any ideas ? I hope for you ;)

• What Every Programmer Should Know

  24 décembre 2012, par Multimedia Mike — General

  During my recent effort to force myself to understand Unicode and modern text encoding/processing, I was reminded that this is something that “every programmer should just know”, an idea that comes up every so often, usually in relation to a subject in which the speaker is already an expert. One of the most absurd examples I ever witnessed was a blog post along the lines of “What every working programmer ought to know about [some very specific niche of enterprise-level Java programming]“. I remember reading through the article and recognizing that I had almost no knowledge of the material. Disturbing, since I am demonstrably a “working programmer”.

  For fun, I queried the googles on the matter of what ever programmer ought to know.

  Specific Topics
  Here is what every programmer should know about : Unicode, time, memory (simple), memory (extremely in-depth), regular expressions, search engine optimization, floating point, security, basic number theory, race conditions, managed C++, VIM commands, distributed systems, object-oriented design, latency numbers, rate monotonic algorithm, merging branches in Mercurial, classes of algorithms, and human names.

  Broader Topics
  20 subjects every programmer should know, 97 things every programmer should know, 12 things every programmer should know, things every programmer should know (27 items), 10 papers every programmer should read at least twice, 10 things every programmer should know for their first job.

  Meanwhile, I remain fond of this xkcd comic whose mouseover text describes all that a person genuinely needs to know. Still, the new year is upon us, a time when people often make commitments to bettering themselves, and it couldn’t hurt (much) to at least skim some of the lists and find out what you never knew that you never knew.

  What About Multimedia ?
  Reading the foregoing (or the titles of the foregoing pieces), I naturally wonder if I should write something about what every programmer should know about multimedia. I think it would look something like a multimedia programming FAQ. These are some items that I can think of :

  1. YUV : The other colorspace (since most programmers are only familiar with RGB and have no idea what to make of the YUV that comes out of most video decoding APIs)
  2. Why you can’t easily seek randomly to any specific frame in a video file (keyframe/interframe discussion and their implications)
  3. Understand your platform before endeavoring to implement multimedia software (modern platforms, particularly mobile platforms, probably provide everything you need in the native APIs and there is likely little reason to compile libavcodec for the platform)
  4. Difference between containers and codecs (longstanding item, but I would argue it’s less relevant these days due to standardization on the MPEG — MP4/H.264/AAC — stack)
  5. What counts as a multimedia standard in this day and age (comparing the foregoing MPEG stack with the WebM/VP8/Vorbis stack)
  6. Trade-offs to consider when engineering a multimedia solution
  7. Optimization doesn’t always work the way you think it does (not everything touted as a massive speed-up in the world of computing — whether it be multithreaded CPUs, GPGPUs, new SIMD instruction sets — will necessarily be applicable to multimedia processing)
  8. A practical guide to legal issues would not be amiss
  9.  ???

  What other items count as “something multimedia-related that every programmer should know” ?

• What do I use instead of init_put_byte in a ffmpeg program ?

  4 février 2013, par Tom Brito

  I'm trying to fix a program, and one issue is the use of the deprecated init_put_byte (avio.h). But there's no documentation saying what do I change it for. Where can I find anything about it ?

  This page shows the function being substituted by avio_init_context, but my version have only the init_put_byte (deprecated).

  My version (as in "/usr/local/include/libavformat/version.h") is :

  #define LIBAVFORMAT_VERSION_MAJOR 52
  
  #define LIBAVFORMAT_VERSION_MINOR 103
  
  #define LIBAVFORMAT_VERSION_MICRO  0

  —update

  I did a grep -R "_init_context" /usr/local/include/libavformat/*", but I found nothing. There's no function with this suffix.