Opened 5 years ago

Last modified 5 years ago

#8132 new defect

Audio cutoff when using nobuffer flag

Reported by: paco Owned by:
Priority: normal Component: avformat
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

When converting audio and using the nobuffer flag, audio is cut off at the beginning, ~2 sec of a 4 sec audio.

Audio used in the example below is available here: http://www.wavsource.com/snds_2018-06-03_5106726768923853/music/coming_to_take.wav

How to reproduce:

% ffmpeg -y -fflags nobuffer -i ./coming_to_take.wav -f_err_detect compliant -f wav -ar 16000 -acodec pcm_s16le -ac 1 coming_to_take_converted.wav

fmpeg version: 4.1.3
built on: Apple LLVM version 10.0.1 (clang-1001.0.46.4)

ffmpeg output:

Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, wav, from './coming_to_take.wav':
  Duration: 00:00:04.33, bitrate: 88 kb/s
    Stream #0:0: Audio: pcm_u8 ([1][0][0][0] / 0x0001), 11025 Hz, mono, u8, 88 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_u8 (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to 'coming_to_take_converted.wav':
  Metadata:
    ISFT            : Lavf58.20.100
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, mono, s16, 256 kb/s
    Metadata:
      encoder         : Lavc58.35.100 pcm_s16le
size=      77kB time=00:00:04.32 bitrate= 146.3kbits/s speed= 602x    
video:0kB audio:77kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.098594%

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (3)

comment:1 by paco, 5 years ago

Component: undeterminedavformat

comment:2 by Carl Eugen Hoyos, 5 years ago

Version: unspecifiedgit-master

For future tickets: Please test current FFmpeg git head and provide the command line you tested together with the complete, uncut console output.

If the input is smaller than probesize, nobuffer leads to an empty output.

comment:3 by paco, 5 years ago

I've just tested with -probesize 1024, at first I though the cutoff was completely gone, however when I inspected the file with audacity I've observed there is still a small cutoff (~0.1sec), I don't really see why probesize would need to be any bigger here, the converted input file is a wave file of which all information needed for conversion, is available in the 44 bytes RIFF header.

Note: See TracTickets for help on using tickets.