Recherche avancée

Sur d’autres sites (8323)

• 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

• 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