Recherche avancée

Sur d’autres sites (8094)

• How to compile ffmpeg and x264 with thread support for android ?

  18 mai 2017, par Sureshkumar Menon

  i want to compile both x264 and ffmpeg with thread support for ANDROID .FFmpeg and x264 didn’t compile with thread support even after enabling enable-pthreads and enable-threads respectively.

  Both the config.h contains #define HAVE_THREAD 0 and #define HAVE_PTHREADS 0

  1.How to compile with thread support.
  2.Second question is that when i increase the gop size from 1 to some other value encoder returns 0 for certain subsequent frames.This causes a delay more than 3 to 5 seconds in vide playing

• fate : Fix the sub-mcc tests on Windows in eastern time zones

  11 août, par Martin Storsjö

  fate : Fix the sub-mcc tests on Windows in eastern time zones
  Previously, these tests failed when running on Windows, if the
  
  system is configured with a time zone east of Greenwich, i.e.
  
  with a positive GMT offset.
  The muxer converts the creation_date given by the user using
  
  av_parse_time to unix time, as a time_t. The creation_date is
  
  interpreted as a local time, i.e. according to the current time
  
  zone. (This time_t value is then converted back to a broken out
  
  local time form with localtime_r.)
  The given reference date/time, "1970-01-01T00:00:00", is the
  
  origin point for unix time, corresponding to time_t zero. However
  
  when interpreted as local time, this doesn't map to exactly zero.
  
  Time zones east of Greenwich reached this time a number of hours
  
  before the point of zero time_t - so the corresponding time_t
  
  value essentially is minus the GMT offset, in seconds.
  Windows mktime returns an error, returning (time_t)-1, when given
  
  such a "struct tm", while e.g. glibc mktime happily returns a
  
  negative time_t. av_parse_time doesn't check the return value of
  
  mktime for potential errors.
  This is observable with the following test snippet :
      struct tm tm =  0  ;
  
      tm.tm_year = 70 ;
  
      tm.tm_isdst = -1 ;
  
      tm.tm_mday = 1 ;
  
      tm.tm_hour = 0 ;
  
      time_t t = mktime(&tm) ;
  
      printf("%d-%02d-%02d %02d :%02d :%02d\n", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec) ;
  
      printf("t %d\n", (int)t) ;
  By varying the value of tm_hour and the system time zone, one
  
  can observe that Windows mktime returns -1 for all time_t values
  
  that would have been negative.
  This range limit is also documented by Microsoft in detail at
  
  https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64.
  To avoid the issue, pick a different, arbitrary reference time,
  
  which should have a nonnegative time_t for all time zones.
  

  • [DH] tests/fate/subtitles.mak
  • [DH] tests/ref/fate/sub-mcc-remux
  • [DH] tests/ref/fate/sub-mcc-remux-eia608
  • [DH] tests/ref/fate/sub-mcc-remux-eia608-bsf
  • [DH] tests/ref/fate/sub-mcc-remux-eia608-recode

• nomenclature #3469 (Nouveau) : Étendre la balise #URL_PAGE à tout objet éditorial

  6 juin 2015, par tetue tetue

  La balise #URL_PAGE affiche actuellement la page fabriquée par le squelette passé en paramètre : http://www.spip.net/fr_article4630.html

  Cette balise pourrait être étendue aux objets éditoriaux de SPIP, de façon à être utilisée facilement, sans paramètre, pour lier explicitement la page SPIP, ce qui est utile pour les objets possédant par ailleurs une URL qui leur est propre, tel que les sites.

  #URL_PAGE afficherait l’url de la page dédiée à l’objet, c’est-à-dire la page générée via le squelette homonyme (sans nécessiter de le passer en paramètre), si ce skel existe, sinon rien.

  Par exemple :

  - dans une boucle SITES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « site » — au lieu de l’actuel [(#ID_SYNDIC|generer_url_entitesite)] anciennement (#ID_SYNDIC, trop barbare — tandis que #URL_FORUM affiche l’url de la page où est affiché le message
  - dans une boucle DOCUMENTS, #URL_PAGE afficherait l’url de la page fabriquée par le skel « document », s’il existe, tandis que #URL_DOCUMENT affiche l’url du fichier multimédia
  - idem avec les FORUMS
  - dans une boucle SYNDIC_ARTICLES, #URL_PAGE n’afficherait rien, car le squelette « article_syndic » n’existe pas
  - dans une boucle ARTICLES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « article », comme #URL_ARTICLE
  - etc.

  Il ne s’agit pas tant qu’une évolution, puisque l’affichage de toutes ces URLs est déjà possible, que d’une homogénéisation et simplification de la nomenclature. Mieux vaut écrire #URL_PAGE que [(#ID_SYNDIC|generer_url_entitesite)], n’est-ce pas ;)