Recherche avancée

Sur d’autres sites (11306)

• three ways to achieve an H264 file

  18 mars 2016, par Kindermann

  here I have three ways to get an H264 file, like all forensic scientists, I am very curious about the differences between them :

  1.

  ffmpeg -i video.mp4 video.h264

  2.

  ffmpeg -i video.mp4 -vcodec copy -an -f h264 video.h264

  3. Using the example "demuxing_decoding.c" provided on the ffmpeg official website :
  http://ffmpeg.org/doxygen/trunk/demuxing_decoding_8c-example.html

  Obviously, the first one does the transformation, and the second one does the demuxing. They render different H264 files which however have similar file sizes(in my case, it’s about say 24 MB). Suprisingly, the third one, which is also supposed to do the demuxing job, renders an H264 file with 8.4 GB ! Why ?

  What I wondered is really, how the interiors of these three methods work ?(The third one is already in source code, therefore it’s quite easy to have an insight) What about the first two commands ? What APIs are called when executing these two commands and how those APIs are called(namely, in what kind of sequences they are called) and things like that.
  One thing that is also important to me is, i have no idea how I can trace the execution routines of ffmpeg command lines. I want to see what’s going on behind ffmpeg commands in source code version. Is it possible ?

  I appreciate any comment.

• avcodec/speexdec : Consider mode in frame size check

  26 décembre 2021, par Michael Niedermayer

  avcodec/speexdec : Consider mode in frame size check
  No speex samples with non default frame sizes are known (to me)
  
  the official speexenc seems to only generate the 3 default ones.
  
  Thus it may be that the fuzzer samples where the first non default
  
  values encountered by the decoder.
  
  Possibly the "<" should be " !="
  Fixes : out of array access
  
  Fixes : 42821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-5640695772217344
  Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/speexdec.c

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