Recherche avancée

Sur d’autres sites (9482)

• Evolution #3071 : Performance boucle DATA sur CSV

  15 octobre 2013, par esj -

  De l’utilité de faire "svn cp" et non une copie dans éditeur perso pour que l’historique d’un code soit facile à retrouver.

  Ce code est apparu en 2007 dans r10948 qui répondait à une difficulté signalée dans Spip-contrib, à laquelle il fut répondu par un code, documenté sur spipnet comme il se doit :
  http://contrib.spip.net/Creer-de-grands-tableaux-dans-SPIP,9#forum401060

  Cette fonction faisait alors 3 lignes, c’était plus rapide à écrire que de regarder si PHP avait l’équivalent en magasin.
  Ensuite, il y a eu quantités de signalements de problèmes, ce format propriétaire à l’origine ayant un RFC tardif et imprécis dont tout le monde se fout,
  d’où un code qui n’a pas cessé de croître avec les années (r11111, r11113, r13859, r14013 surtout). Au vu du commentaire dans la doc PHP de fgetcsv, ce code semble toujours d’actualité. En tout cas il y a intérêt à vérifier que les cas signalés dans les logs des commit ci-dessous sont bien pris en compte par cette fonction avant de mettre le code des autres à la poubelle sans chercher à comprendre, marque de fabrique de SPIP3.

• Video compressing not working with ffmpeg4android_lib library

  18 décembre 2019, par Nand Kishor Patidar

  When I am trying video compressing with ffmpeg4android_lib library then it is working on debug mode(Not google play store app) after that when I check live on play store the video compressing is not working and found that the application crashed. After the crash, it gives the error :-
  videokitLibPath not exits : /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so
  My App Log is below :

  1576657500.663 20809-20809/com.practice.presto D/MyPracticeAudioVideo: outside wifi file type 2
  
  1576657500.807 20809-22043/com.practice.presto D/MyPracticeAudioVideo: Worker started
  
  1576657500.807 20809-22043/com.practice.presto D/MyPracticeAudioVideo: new file video path /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4
  
  1576657500.808 20809-22043/com.practice.presto D/MyPracticeAudioVideo: Acquire wake lock
  
  1576657500.812 20809-22043/com.practice.presto I/ffmpeg4android: checkForPermissions() called
  
  1576657500.814 20809-22043/com.practice.presto I/ffmpeg4android: permission already granted
  
  1576657500.830 20809-22043/com.practice.presto D/MyPracticeAudioVideo: ffmpeg -y -i /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4 -strict experimental -s 320x240 -r 25 -aspect 4:3 -vcodec mpeg4 -b 150k -ab 48000 -ac 2 -ar 22050 /storage/emulated/0/pp/1576657432247.mp4
  
  1576657500.831 20809-22043/com.practice.presto I/ffmpeg4android: running ffmpeg4android_lib: 41.07.00_LM41_00
  
  1576657500.831 20809-22043/com.practice.presto D/ffmpeg4android: {"ffmpeg","-y","-i","/storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4","-strict","experimental","-s","320x240","-r","25","-aspect","4:3","-vcodec","mpeg4","-b","150k","-ab","48000","-ac","2","-ar","22050","/storage/emulated/0/pp/1576657432247.mp4"}
  
  1576657500.833 20809-22043/com.practice.presto D/ffmpeg4android: /storage/emulated/0/DCIM/Camera/VID_20191218_135413.mp4 length in bytes: 15793157
  
  1576657500.834 20809-22043/com.practice.presto E/ffmpeg4android: **videokitLibPath not exits: /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so**
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: libvideokit.so load Fail: /data/app/com.practice.presto-SSicBo_Qm4UXOQAQ45Vttg==/lib/arm/libvideokit.so
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: args is not NULL
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: more then one arg
  
  1576657500.835 20809-22043/com.practice.presto I/Videokit: function symbol not found
  
  1576657500.835 20809-22043/com.practice.presto D/Videokit: Calling videokit run via loader
  
  1576657500.860 20809-22043/com.practice.presto A/libc: **Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 22043 (Thread-19), pid 20809 (practice.presto)**

• FFmpeg + iOS + lossy cellular connections

  9 novembre 2014, par Moss

  I am able to play an RTMP audio + video real-time stream on iOS with FFmpeg. Works fantastic when everything is on a solid WiFi connection.

  When I switch to a cellular connection (great signal strength and LTE/4G), av_read_frame() will intermittently block for an unacceptable amount of time. From what I can tell, it’s not that the cellular data connection just dropped, because I can reconnect immediately and start downloading more packets. In some cases, I’ve clocked 30+ seconds of hang time before it returns the next frame. When the next frame finally comes in, my real-time video stream is permanently delayed by the amount of time that av_read_frame() blocked.

  I attempted a work-around by using the AVIOInterruptCB interrupt callback to abort av_read_frame() if the function takes longer than 1 second to return. Here’s what that code looks like :

  - (void)readPackets {
  
      // Make sure FFmpeg calls our interrupt periodically
  
      _context->interrupt_callback.callback = interrupt_cb;
  
      _context->interrupt_callback.opaque = self;
  
  
  
      dispatch_async(_readPacketQueue, ^(void) {
  
          int err;
  
  
  
          while(true) {
  
              _readFrameTimeStamp = [[NSDate date] timeIntervalSince1970];
  
              err = av_read_frame(_context, &packet);
  
              _readFrameTimeStamp = 0;
  
  
  
              if(err) {
  
                  // Error - Reconnect the entire stream from scratch, taking 5-10 seconds
  
                  // And we know when av_read_frame() was aborted
  
                  // because its error code is -1414092869 ("EXIT")
  
              }
  
              else {
  
                  // Play this audio or video packet
  
              }
  
          }
  
     });
  
  }
  
  
  
  /**
  
   * Interrupt
  
   * @return 1 to abort the current operation
  
   */
  
  static int interrupt_cb(void *decoder) {
  
      if(decoder) {
  
          if(_readFrameTimeStamp != 0) {
  
              if([[NSDate date] timeIntervalSince1970] - _readFrameTimeStamp > 1) {
  
                  // Abort av_read_frame(), it's taking longer than 1 second
  
                  return 1;
  
              }
  
          }
  
      }
  
  }

  This definitely aborts av_read_frame() after 1 second, but unfortunately after I do this, future attempts to call av_read_frame() result in EIO errors (-5), which indicates that the connection has been severed.

  As a result, I am forced to fully reconnect the viewer, which takes 5-10 seconds. (avformat_open_input() takes 3-4 seconds, and then find the stream info again takes 2-3 seconds, and then start reading frames).

  The 5-10 second delay to fully reconnect is much better than waiting more than 10 seconds for av_read_frame() to unblock, and it’s much better than the real-time stream being delayed by a significant amount. But it’s much worse than being able to retry av_read_frame() immediately.

  From a cellular user’s perspective, their video locks up intermittently for 5-10 seconds while we reconnect the stream in the background from scratch, which isn’t a good user experience.

  What strategies are there to better way to manage av_read_frame() on a lossy cellular connection ?
  (Or strategies to improve the reconnect time ?)