Recherche avancée

Sur d’autres sites (7851)

• ARM compiler update

  15 janvier 2010, par Mans — ARM, Compilers

  Since my last shootout, all the tested vendors have updated their compilers. Here is a quick update on each of them.

  Both the 4.3 and 4.4 branches of FSF GCC have had bugfix releases, bringing them to 4.3.4 and 4.4.2, respectively. Neither update contains anything particularly noteworthy.

  The CodeSourcery 2009q3 release sees an update to a GCC 4.4 base, a significant change from the 4.3 base used in 2009q1. The update is a mixed blessing. In fact, it is mostly a curse and hardly a blessing at all. On the bright side, the floating-point speed regressions in 2009q1 are gone, 2009q3 being a few per cent faster even than 2007q3. Unfortunately, this improvement is completely overshadowed by a major speed regression on integer code, a whopping 24% in one case. This ties in with the slowdown previously observed with FSF GCC 4.4 compared to 4.3.

  ARM RVCT 4.0 is now at Build 697. This update fixes some bugs and introduces others. Notably, it no longer builds FFmpeg correctly. The issue has been reported to ARM.

  Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.

  In light of the above, my recommendations remain unchanged :

  • For a free compiler, choose CodeSourcery 2009q1. It beats GCC 4.3.4 by 5-10% in most cases.
  • GNU purists are best served by GCC 4.3.4, which is up to 20% faster than 4.4.2 and rarely slower.
  • When price is not a concern, ARM RCVT is a good option, outperforming GCC by up to a factor 2.
  • In all cases, disable any auto-vectorisation features.

  Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.

• Android-How to pass back frames from FFmpeg back to Android

  23 octobre 2013, par yarin

  It is an architecture question-i am really interesting about the answer

  I building an app with following goals :

  1.record video with effect in real time(using FFmpeg)

  2.display the customized video in real time for the user while he recording

  So,after 1 month of working...i decide to remember that goal number 2 is worth to thinking about :)
  I have a ready skeleton app that record video with effect in real time.
  but i have to preview this customized frame back to the user.

  My options (and this is my question) :

  1.Each frame that pass from onPreviewFrame(byte[] video_frame_data, Camera camera) to ffmpeg with JNI to encode-will sending back to android through the same JNI after i apply the effects(i mean : onPreviewFrame->JNI to FFMPEG->immediately apply effect->send the costumed frame back to android side for display->encode the costumed frame).

  Advantages : it is look like is the most easy to use.

  Disadvantages : use the JNI twice or the passing back the frame could consume time(i really don't now if it really big price to pay,cuz it is only byte array or int array per frame to send to android side)

  2.I heard about openGL on ndk,but i think that the surface it self created on the android side-so is it really going to be better ?
  i prefer to use other surface that i using now in java

  3.Create an video player on FFmpeg to preview each customized frame in real time.

  Thank for your helping,i hope that the first solution is available and not consume to much expensive time in terms of real time processing

• Video upload size

  16 mai 2014, par Jonas m

  I’m having a hard time figuring this one out, so hopefully, some of you who has tried this before, will take the time to reply and share your knowledge.

  I’m working on a site, which after release, will be feeded in the television and other commercial places. The site asks the user to upload a video with a story, and we expect alot of people to do so.

  My problem is the whole storage/space talk. A normal, unencoded iPhone recording easily fills around 100-120 MB for a minute or two.

  I’ve tried setting up and using FFMPEG to re-encode the movies, but the problem is, that one encoding sucks up 100% of the CPU, leaving the site inaccisible for anybody else.

  Is there anything you could suggest, which would be sufficient for such a site ? The client is on a budget, so price is a consideration aswell. Best of all would be a free alternative to etc. FFMPEG, but with less CPU usage.

  My specs are as follows
  CentOs 6 on a
  1GB ram DigitalOcean cloud service with nginx + php-fpm and mysql.

  Im hoping for some cleaver folks to answer this !
  Thanks in advance.
  Jonas