Opened 8 years ago
Closed 6 years ago
#5931 closed defect (fixed)
showwavespic, showspectrumpic innacurate length of resulting image
Reported by: | Jonatã Bolzan Loss | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | avfilter |
Version: | git-master | Keywords: | showwavespic |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:showwavespic, showspectrumpic innacurate length of resulting image
How to reproduce:
ffmpeg -i voice.wav -lavfi showwavespic=scale=log:s=1000x180 waveform.png
In this example, the waveform is rendered correctly (end of waveform on image1.png). But if we increase the with to 10000, the end of waveform have an extra gap (end of waveform on image2.png).
ffmpeg -i voice.wav -lavfi showwavespic=scale=log:s=10000x180 waveform.png
Attachments (10)
Change History (17)
by , 8 years ago
Attachment: | image1.png added |
---|
by , 8 years ago
Attachment: | image2.png added |
---|
by , 8 years ago
comment:1 by , 8 years ago
Keywords: | showwavespic added |
---|---|
Priority: | normal → minor |
Status: | new → open |
Afaict, there is always a right border (without waves), even for small width (at least for a width of 1000 for the given sample). I don't know if this is intended or not.
comment:2 by , 7 years ago
It appears the shorter your audio is, the bigger the gap can get. Rendering a one second WAV into a 1000px wide image leaves 20 pixels empty on the right. This is not a trivial amount of error. I'll try upload a simple test case.
by , 7 years ago
Attachment: | generate-waveform.zip added |
---|
Example of rendering a waveform with a one second audio file
comment:3 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | open → closed |
comment:4 by , 7 years ago
Cc: | added |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
Why was this set to 'wontfix'? If there are any further infos/details needed to get this fixed I'd be happy to provide. I have been running into this issue a bunch recently on the latest build (ffmpeg-20180619-a990184) and it is a pretty nasty bug, making features that are 95% complete basically useless due to unreliability/inaccuracy. PNGs end up with anywhere from 1 to 300+ empty pixels on the right and there's no way to know which empty pixels are due to the bug and which are due to actual silence in the input audio. Does anyone know any way to work around this bug, like if there is some magic number for the .png dimensions that makes ffmpeg happy, or some way to calculate how many of the blank pixels are erroneous (is it a function of the length of the audio)?
comment:5 by , 7 years ago
Cc: | removed |
---|
comment:6 by , 7 years ago
I've just attached some more explicit examples, including ffmpeg log files, input audio files, and output pngs, in the hopes that this helps:
jimi20_2560x1440.png - Attempt to render a 2560x1440 png of a 2.42 seconds mono wav file jimi20.wav (loud drum sample with no silence). The resulting png contains a 2540px wide waveform plus a 20px wide section of erroneous empty pixels. Logfile ffmpeg-20180629-204841.log
45sec_sine_stereo_test_6000x500.png - Attempt to render a 6000x500 png of a 45 seconds stereo flac file 45sec_sine_stereo_test.flac (simple sine tone, no silence). The resulting png contains a 5995px wide waveform plus a 5px wide section of erroneous empty pixels. Logfile ffmpeg-20180629-213108.log
comment:7 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
image1