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 , 5 years ago
Component: | undetermined → avformat |
---|
comment:2 by , 5 years ago
Version: | unspecified → git-master |
---|
comment:3 by , 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.
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.