Recherche avancée

Sur d’autres sites (8096)

• How to port signal() to sigaction() ?

  28 septembre 2016, par Shark

  due to recent problems discovered with NDK12 and NDK13b2, i’m thinking of ’porting’ libx264’s use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

  The problem is, I’m not quite sure what’s the simple&fastest way to replace signal() calls with sigaction() ones.

  For all i see, it’s mainly used in x264-snapshot/common/cpu.c in the following manner :

  using the following signal handler :

  static void sigill_handler( int sig )
  
  {
  
      if( !canjump )
  
      {
  
          signal( sig, SIG_DFL );
  
          raise( sig );
  
      }
  
  
  
      canjump = 0;
  
      siglongjmp( jmpbuf, 1 );
  
  }

  This is the problematic x264_cpu_detect function... currently, i’m guessing i only need to tackle the ARM version, but i’ ; ; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

  FYI - the NDK13 beta2 still has "unstable" libc and the build doesn’t fail on this part, but rather the first invocation of the rand() function somewhere else... So i’m out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I’m doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

  the problematic part of function that invokes signal() :

  #elif SYS_LINUX
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      static void (*oldsig)( int );
  
  
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return 0;
  
      }
  
  
  
      canjump = 1;
  
      asm volatile( "mtspr 256, %0\n\t"
  
                    "vand 0, 0, 0\n\t"
  
                    :
  
                    : "r"(-1) );
  
      canjump = 0;
  
  
  
      signal( SIGILL, oldsig );
  
  
  
      return X264_CPU_ALTIVEC;
  
  }
  
  #endif
  
  
  
  #elif ARCH_ARM
  
  
  
  void x264_cpu_neon_test( void );
  
  int x264_cpu_fast_neon_mrc_test( void );
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      int flags = 0;
  
  #if HAVE_ARMV6
  
      flags |= X264_CPU_ARMV6;
  
  
  
      // don't do this hack if compiled with -mfpu=neon
  
  #if !HAVE_NEON
  
      static void (* oldsig)( int );
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return flags;
  
      }
  
  
  
      canjump = 1;
  
      x264_cpu_neon_test();
  
      canjump = 0;
  
      signal( SIGILL, oldsig );
  
  #endif
  
  
  
      flags |= X264_CPU_NEON;
  
  
  
      // fast neon -> arm (Cortex-A9) detection relies on user access to the
  
      // cycle counter; this assumes ARMv7 performance counters.
  
      // NEON requires at least ARMv7, ARMv8 may require changes here, but
  
      // hopefully this hacky detection method will have been replaced by then.
  
      // Note that there is potential for a race condition if another program or
  
      // x264 instance disables or reinits the counters while x264 is using them,
  
      // which may result in incorrect detection and the counters stuck enabled.
  
      // right now Apple does not seem to support performance counters for this test
  
  #ifndef __MACH__
  
      flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
  
  #endif
  
      // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
  
  #endif
  
      return flags;
  
  }
  
  
  
  #else
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      return 0;
  
  }

  So the question is really this : what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality ?

  EDIT :
  The reason i’m trying to get rid of signal() are these build errors :

  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'

  I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it’ beta state with it’s unstable libc - it’s currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i’ll just have to wait for it and retry after it’s release.

  But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

  EDIT2 :
  I also know that signal() usually works by using sigaction() under the hood, but maybe i won’t get bsd_signal related build-errors... since i’m suspecting that this one isn’t using it. It’s obviously using bsd_signal, which may or may not be the same underlying thing :/

• How to port signal() to sigaction() ?

  28 septembre 2016, par Shark

  due to recent problems discovered with NDK12 and NDK13b2, i’m thinking of ’porting’ libx264’s use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

  The problem is, I’m not quite sure what’s the simple&fastest way to replace signal() calls with sigaction() ones.

  For all i see, it’s mainly used in x264-snapshot/common/cpu.c in the following manner :

  using the following signal handler :

  static void sigill_handler( int sig )
  
  {
  
      if( !canjump )
  
      {
  
          signal( sig, SIG_DFL );
  
          raise( sig );
  
      }
  
  
  
      canjump = 0;
  
      siglongjmp( jmpbuf, 1 );
  
  }

  This is the problematic x264_cpu_detect function... currently, i’m guessing i only need to tackle the ARM version, but i’ ; ; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

  FYI - the NDK13 beta2 still has "unstable" libc and the build doesn’t fail on this part, but rather the first invocation of the rand() function somewhere else... So i’m out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I’m doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

  the problematic part of function that invokes signal() :

  #elif SYS_LINUX
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      static void (*oldsig)( int );
  
  
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return 0;
  
      }
  
  
  
      canjump = 1;
  
      asm volatile( "mtspr 256, %0\n\t"
  
                    "vand 0, 0, 0\n\t"
  
                    :
  
                    : "r"(-1) );
  
      canjump = 0;
  
  
  
      signal( SIGILL, oldsig );
  
  
  
      return X264_CPU_ALTIVEC;
  
  }
  
  #endif
  
  
  
  #elif ARCH_ARM
  
  
  
  void x264_cpu_neon_test( void );
  
  int x264_cpu_fast_neon_mrc_test( void );
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      int flags = 0;
  
  #if HAVE_ARMV6
  
      flags |= X264_CPU_ARMV6;
  
  
  
      // don't do this hack if compiled with -mfpu=neon
  
  #if !HAVE_NEON
  
      static void (* oldsig)( int );
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return flags;
  
      }
  
  
  
      canjump = 1;
  
      x264_cpu_neon_test();
  
      canjump = 0;
  
      signal( SIGILL, oldsig );
  
  #endif
  
  
  
      flags |= X264_CPU_NEON;
  
  
  
      // fast neon -> arm (Cortex-A9) detection relies on user access to the
  
      // cycle counter; this assumes ARMv7 performance counters.
  
      // NEON requires at least ARMv7, ARMv8 may require changes here, but
  
      // hopefully this hacky detection method will have been replaced by then.
  
      // Note that there is potential for a race condition if another program or
  
      // x264 instance disables or reinits the counters while x264 is using them,
  
      // which may result in incorrect detection and the counters stuck enabled.
  
      // right now Apple does not seem to support performance counters for this test
  
  #ifndef __MACH__
  
      flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
  
  #endif
  
      // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
  
  #endif
  
      return flags;
  
  }
  
  
  
  #else
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      return 0;
  
  }

  So the question is really this : what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality ?

  EDIT :
  The reason i’m trying to get rid of signal() are these build errors :

  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'

  I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it’ beta state with it’s unstable libc - it’s currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i’ll just have to wait for it and retry after it’s release.

  But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

  EDIT2 :
  I also know that signal() usually works by using sigaction() under the hood, but maybe i won’t get bsd_signal related build-errors... since i’m suspecting that this one isn’t using it. It’s obviously using bsd_signal, which may or may not be the same underlying thing :/

• creating video from sequence of images javacv

  7 janvier 2016, par vach

  For creating video from sequence of images in android I used javacv 0.6 library, but I meet problem :
  It normally works on htc Sensation(Android 4.0.1, Processor type armv7) and htc Desire(Android 2.3.3, Processor type arm7) phones, but it doesn’t work on htc Wildfire
  (Android 2.3.5,Processor type armv6) phone particularly it fails in this part of code

  FFmpegFrameRecorder recorder = new FFmpegFrameRecorder(videoFilePath,       
  
  TalkingPhotoConstants.VIDEO_FRAME_WIDTH,TalkingPhotoConstants.VIDEO_FRAME_HEIGHT);

  in the attached code.

  public class MovieCreator extends AsyncTask {
  
  
  
  private opencv_core.IplImage[] iplimage;
  
  private String audioFilePath;
  
  
  
  
  
  private ProgressDialog progressDialog;
  
  private Context context;
  
  private List<talkframe> frames;
  
  
  
  public MovieCreator(Context context, opencv_core.IplImage[] images, String audioFilePath,           
  
  List<talkframe> frames) {
  
      this.context = context;
  
      this.iplimage = images;
  
      this.audioFilePath = audioFilePath;
  
      this.frames = frames;
  
  
  
  }
  
  
  
  private String createMovie() {
  
  
  
      String videoName = TalkingPhotoConstants.TMP_VIDEO_NAME;
  
      String path = TalkingPhotoConstants.RESOURCES_TMP_FOLDER;
  
      String videoFilePath = path + videoName;
  
      String finalVideoName = TalkingPhotoConstants.FINAL_VIDEO_NAME + 
  
      System.currentTimeMillis() + ".mp4";
  
      String finalVideoPath = TalkingPhotoConstants.RESOURCES_FOLDER + finalVideoName;
  
  
  
      try {
  
  
  
          FFmpegFrameRecorder recorder = new FFmpegFrameRecorder(videoFilePath, 
  
          TalkingPhotoConstants.VIDEO_FRAME_WIDTH,TalkingPhotoConstants.VIDEO_FRAME_HEIGHT);
  
  
  
  
  
          //int frameCount = iplimage.length;
  
          int frameCount = frames.size();
  
          recorder.setAudioCodec(AV_CODEC_ID_AMR_NB);
  
          recorder.setVideoCodec(AV_CODEC_ID_MPEG4);
  
  
  
          recorder.setVideoBitrate(120000);
  
          recorder.setFrameRate(TalkingPhotoConstants.VIDEO_FRAME_RATE);
  
  
  
          recorder.setPixelFormat(AV_PIX_FMT_YUV420P);
  
          recorder.setFormat("mp4");
  
  
  
          recorder.start();
  
  
  
  
  
          for (int i = 0; i &lt; frameCount; i++) {
  
              TalkFrame currentFrame = frames.get(i);
  
              long duration = currentFrame.getDuration();
  
              opencv_core.IplImage iplImage = cvLoadImage(currentFrame.getImageName());
  
  
  
              for (int j = 0; j &lt; TalkingPhotoConstants.VIDEO_FRAME_RATE * duration; j++) {
  
                  recorder.record(iplImage);
  
  
  
              }
  
  
  
          }
  
  
  
          recorder.stop();
  
  
  
          mergeAudioAndVideo(videoFilePath, audioFilePath, finalVideoPath);
  
  
  
      } catch (Exception e) {
  
          Log.e("problem", "problem", e);
  
          finalVideoName = "";
  
      }
  
      return finalVideoName;
  
  }
  
  
  
  private boolean mergeAudioAndVideo(String videoPath, String audioPath, String outPut)  
  
  throws Exception {
  
      boolean isCreated = true;
  
      File file = new File(videoPath);
  
      if (!file.exists()) {
  
          return false;
  
      }
  
  
  
  
  
      FrameGrabber videoGrabber = new FFmpegFrameGrabber(videoPath);
  
      FrameGrabber audioGrabber = new FFmpegFrameGrabber(audioPath);
  
  
  
      videoGrabber.start();
  
      audioGrabber.start();
  
      FrameRecorder recorder = new FFmpegFrameRecorder(outPut,
  
              videoGrabber.getImageWidth(), videoGrabber.getImageHeight(),
  
              audioGrabber.getAudioChannels());
  
  
  
  
  
      recorder.setFrameRate(videoGrabber.getFrameRate());
  
      recorder.start();
  
      Frame videoFrame = null, audioFrame = null;
  
      while ((audioFrame = audioGrabber.grabFrame()) != null) {
  
          videoFrame = videoGrabber.grabFrame();
  
          if (videoFrame != null) {
  
              recorder.record(videoFrame);
  
          }
  
          recorder.record(audioFrame);
  
  
  
      }
  
      recorder.stop();
  
      videoGrabber.stop();
  
      audioGrabber.stop();
  
      return isCreated;
  
  }
  
  
  
  @Override
  
  protected Boolean doInBackground(String... params) {
  
      String fileName = createMovie();
  
      boolean result = fileName.isEmpty();
  
      if (!result) {
  
          VideoDAO videoDAO = new VideoDAO(context);
  
          videoDAO.open();
  
          videoDAO.createVideo(fileName);
  
          videoDAO.close();
  
      }
  
      //Utils.cleanTmpDir();
  
      return result;
  
  }
  
  
  
  @Override
  
  protected void onPreExecute() {
  
      progressDialog = new ProgressDialog(context);
  
      progressDialog.setTitle("Processing...");
  
      progressDialog.setMessage("Please wait.");
  
      progressDialog.setCancelable(false);
  
      progressDialog.setIndeterminate(true);
  
      progressDialog.show();
  
  }
  
  
  
  @Override
  
  protected void onPostExecute(Boolean result) {
  
      if (progressDialog != null) {
  
          progressDialog.dismiss();
  
  
  
      }
  
  }
  
  </talkframe></talkframe>

  }

  There is no exception.

  1.how can i fix it ?

  2.I have a version that problem is connected with device’s processor type.

  If I’m right how can I solve it ?

  Thanks in advance.