Recherche avancée

Sur d’autres sites (6905)

• Problem compiling ffmpeg with nvenc using visual studio 2015 community edition

  23 février 2020, par Uri Raz

  I’m trying to build ffmpeg w/ nvenc on Windows 10 64 bit and visual studio 2015 community edition. The command from step 10 in the Using FFmpeg with NVIDIA GPU Hardware Acceleration doc :

  ./configure —enable-nonfree —enable-cuda-sdk —enable-libnpp –-toolchain=msvc —extra-cflags=-I../nv_sdk —extraldflags=-libpath :../nv_sdk

  Gives me the error ’Unknown option "–-toolchain=msvc"’

  Background : I’ve executed the commands (changed the path in the first, I’m not sure its right) :

  export PATH="/C/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/" :$PATH
  export PATH="/c/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.0/bin/" :$PATH

  And ../nv_sdk has the subdirectories include & bin, copied from the NVIDIA GPU Computing Toolkit directory.

• 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

• AVCodecContext::channel_layout 0 for WAV files

  30 décembre 2013, par cmannett85

  I have been successfully loading compressed audio files using FFmpeg and querying their channel_layouts using some code I've written :

  AVFormatContext* fmtCxt = nullptr;
  
  avformat_open_input( &fmtCxt, "###/440_sine.wav", nullptr, nullptr );
  
  avformat_find_stream_info( fmtCxt, nullptr );
  
  av_find_best_stream( fmtCxt, AVMEDIA_TYPE_AUDIO, -1, -1, nullptr, 0 );
  
  
  
  AVCodecContext* codecCxt = fmtCxt->streams[ret]->codec;
  
  AVCodec* codec = avcodec_find_decoder( codecCxt->codec_id );
  
  avcodec_open2( codecCxt, codec, nullptr );
  
  
  
  std::cout << "Channel Layout: " << codecCxt->channel_layout << std::endl;
  
  av_dump_format( fmtCxt, 0, "###/440_sine.wav", 0 );

  I've removed all error checking for brevity. However for Microsoft WAV files (mono or stereo) the AVCodecContext::channel_layout member is always 0 - despite ffprobe and av_dump_format(..) both returning valid information :

  Input #0, wav, from '###/440_sine.wav':
  
  Duration: 00:00:00.01, bitrate: 740 kb/s
  
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 1 channels, s16, 705 kb/s

  Also codecCxt->channels returns the correct value. Using a flac file (with exactly the same audio data generated from the same application), gives a channel_layout of 0x4 (AV_CH_FRONT_CENTER).