Recherche avancée

Sur d’autres sites (6269)

• AVCodecContext::channel_layout 0 for WAV files

  25 novembre 2020, 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).

  


• 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).

• 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