Recherche avancée

Sur d’autres sites (6468)

• Ffmpeg inaccurate cutting with ts and m3u8 files despite resamping audio filter

  31 juillet 2020, par Lemon Sky

  I need to accurately seek and cut a video. Some online sources say put -ss in front or after the source. The result is the same for me. In the examples below, the start time is accurate but the duration is not accurate.

  


  ffmpeg -y -ss 00:00:05 -t 00:00:05 -i output.ts 5s.wav
ffprobe 5s.wav

Duration: 00:00:04.74

ffmpeg -y -i output.ts -ss 00:00:05 -t 00:00:05 5s.wav
ffprobe 5s.wav

Duration: 00:00:04.74


  


  Sometimes the starting point is not accurate but the duration is. This is clearly audible by cutting the ts file and cutting an uncompressed wav file, and listening to both.

  


  ffmpeg -y -i output.ts -ss 00:00:15 -t 00:00:05 5s.wav

ffmpeg -y -i output.wav -ss 00:00:15 -t 00:00:05 5s-reference.wav


  


  What fixes the starting time is if I use an m3u8 file that contains the byte offset for every keyframe AND I put the -ss option in front of the source file (if I put it after the source, the start time is inaccurate but the duration is accurate) :

  


  ffmpeg -y -ss 00:00:15 -t 00:00:05 -i output.m3u8 5s.wav


  


  This fixes the start time but the duration is at the location that I would get had I used no m3u8 file (duration is just 4.47s).

  


  It seems different timestamps are involved, and sometimes one or the other gets used.

  


  The ts file was generated by capturing a UDP stream and storing it with ffmpeg and -codec:v copy.

  


  Is ffmpeg broken, or the ts file ? How do I work around this issue or fix the ts file ? What I realize is that the video starts later than the audio, probably because the video does not start with a keyframe. Can I get ffmpeg to start the -codec:v copy after the first keyframe ? What I also notice is that using ffprobe reports "start : 1.400000". Can I force it to start at 0 ?

  


  Any hints would be appreciated.

  


  I tried both ffmpeg 4.3.1 and ffmpeg git-2020-07-24-21442a8.

  


  The output.* files were generated as follows. The statement "af aresample=async=1" should fill missing audio according to Duration of source video and subtracted audio are different. Adding this statement makes no difference in terms of accuracy or duration. The question is not a duplicate.

  


  ffmpeg -i udp://example:port ^
-af aresample=async=1 ^
-codec:v copy ^
-codec:a aac -ac 2 -ar 44100 -b:a 160k ^
-hls_time 4 -hls_flags single_file -hls_list_size 0 -hls_segment_filename output.ts -hls_segment_type mpegts output.m3u8 ^
-codec:a pcm_s16le -bitexact -ar 11025 -ac 1 output.wav


  


• libffmpeg.so in not building

  22 mai 2015, par Sargam Modak

  my build_ffmpeg_for_android.sh is like this

  #!/usr/bin/env bash
  
  
  
  NDK=/home/samo/Downloads/android-ndk-r10e
  
  SYSROOT=$NDK/platforms/android-9/arch-arm/
  
  TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64
  
  PLATFORM=$NDK/platforms/android-19/arch-arm/
  
  PREBUILT=$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64
  
  
  
  function build_one
  
  {
  
  ./configure \
  
      --prefix=$PREFIX \
  
      --enable-shared \
  
      --disable-static \
  
      --disable-doc \
  
      --disable-ffmpeg \
  
      --disable-ffplay \
  
      --disable-ffprobe \
  
      --disable-ffserver \
  
      --disable-avdevice \
  
      --disable-doc \
  
      --disable-symver \
  
      --cross-prefix=$TOOLCHAIN/bin/arm-linux-androideabi- \
  
      --target-os=linux \
  
      --arch=arm \
  
      --enable-cross-compile \
  
      --sysroot=$SYSROOT \
  
      --extra-cflags="-Os -fpic $ADDI_CFLAGS" \
  
      --extra-ldflags="$ADDI_LDFLAGS" \
  
      $ADDITIONAL_CONFIGURE_FLAG
  
  make clean
  
  make -j4
  
  make install
  
  $PREBUILT/bin/arm-linux-androideabi-ar d libavcodec/libavcodec.a inverse.o
  
  $PREBUILT/bin/arm-linux-androideabi-ld -rpath-link=$PLATFORM/usr/lib -L$PLATFORM/usr/lib  -soname libffmpeg.so -shared -nostdlib  -z,noexecstack -Bsymbolic --whole-archive --no-undefined -o $PREFIX/libffmpeg.so libavcodec/libavcodec.a libavformat/libavformat.a libavutil/libavutil.a libswscale/libswscale.a -lc -lm -lz -ldl -llog  --warn-once  --dynamic-linker=/system/bin/linker $PREBUILT/lib/gcc/arm-linux-androideabi/4.8/libgcc.a
  
  }
  
  
  
  CPU=arm
  
  PREFIX=/home/samo/ffmpeg/android/$CPU
  
  ADDI_CFLAGS="-marm"
  
  
  
  build_one

  when i am running this code libffmpeg.so is not building.
  secondly error is coming : /home/samo/Downloads/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld : ,noexecstack : unknown -z option

  Can someone explain me the two lines after ’make install’. What are those two lines doing. I dont know the scripting so pls elaborate what d and -z terms doing. Thanx

• libswresample : swr_convert() not producing enough samples

  20 septembre 2016, par Tsherr

  I’m trying to use ffmpeg/libswresample to resample streaming audio in my c++ application. Changing the sample width works well and the result sounds as one would expect ; however, when changing the sample rate the result is somewhat crackly. I am unsure if it is due to incorrect usage of the libswresample library, or if I’m misunderstanding the resampling theory.

  Here is my resampling process, simplified for demonstration’s sake :

  //Externally supplied data
  
  const uint8_t* in_samples //contains the audio data to be resampled
  
  int in_num_samples = 256
  
  
  
  //Set up resampling context
  
  SwrContext *swr = swr_alloc();
  
  av_opt_set_channel_layout(swr, "in_channel_layout", AV_CH_LAYOUT_STEREO, 0);
  
  av_opt_set_channel_layout(swr, "out_channel_layout", AV_CH_LAYOUT_STEREO, 0);
  
  av_opt_set_int(swr, "in_sample_rate", 44100, 0);
  
  av_opt_set_int(swr, "out_sample_rate", 22050, 0);
  
  av_opt_set_sample_fmt(swr, "in_sample_fmt", AV_SAMPLE_FMT_FLT, 0);
  
  av_opt_set_sample_fmt(swr, "out_sample_fmt", AV_SAMPLE_FMT_FLT, 0);
  
  swr_init(swr);
  
  
  
  //Perform the resampe
  
  uint8_t* out_samples;
  
  int out_num_samples = av_rescale_rnd(swr_get_delay(swr, in_samplerate) + in_num_samples, out_samplerate, in_samplerate, AV_ROUND_UP);
  
  av_samples_alloc(&out_samples, NULL, out_num_channels, out_num_samples, AV_SAMPLE_FMT_FLT, 0);
  
  out_num_samples = swr_convert(swr, &out_samples, out_num_samples, &in_samples, in_num_samples);
  
  av_freep(&out_samples);
  
  swr_free(&swr);

  I suspect that the reason the resampled audio does not sound right is because swr_convert() returns 112, where I expect it to return 128 (the number of samples of the resampled audio) :
  Downsampling 256 samples from a samplerate of 44100 to a samplerate of 22050 should yield 128 samples, yet swr_convert() is producing 112 samples. When expressed in terms of audio duration this is also puzzling. 256 samples at 44100 = 5.8 ms, but 112 samples at 22050 = 5.07 ms. Shouldn’t the downsampling process not alter the duration of the resampled audio ?

  I have also stepped through an example provided with ffmpeg, in which swr_convert() also returns a smaller number than I would expect. So, I suspect that the problem is not due to a bug in libswresample but rather my own lack of understanding.