<p><code>showwavespic</code> generates only one frame, so there's no substrate on which for overlay to take effect after that first frame. Use the tpad filter and -shortest option to clone frames till audio length.</p>

<p>Use</p>

<p><code>ffmpeg -i music.mp3 -filter_complex "[0:a]showwavespic=split_channels=0:colors=white|lightgrey,format=pix_fmts=yuv420p,fps=10,tpad=stop=-1:stop_mode=clone" -map 0:a -shortest audio.mp4</code></p>

CC BY-SA 4.0
2019-02-14T13:00:52.687Z
Thanks, but it doesn't work... or rather: doesn't work correctly. FFmpeg doesn't stop generating frames, not even when changing the stop value. It does work when I use the output of the second command from my question as input, and run a new ffmpeg command to tpad that to the desired length. Thanks for setting me on the right track.
TGV
CC BY-SA 4.0
2019-02-14T13:20:12.810Z
Share full log. Works here.
Gyan
CC BY-SA 4.0
2019-02-14T14:16:46.270Z
The full log is a bit large when setting loglevel to debug. My summary would be: it starts with the normal output, then there are about 25000 lines of this kind:
 [mp4 @ 0xbf678c0] Delay between the first packet and last packet in the muxing queue is 10007800 > 10000000: forcing output
cur_dts is invalid (...)
after which follows this:
*** 1085029 dup!
More than 1000 frames duplicated
[libx264 @ 0xbf68c80] frame=   0 QP=15.98 NAL=3 Slice:I Poc:0   I:570  P:0    SKIP:0    size=6490 bytes
The latter line runs to frame 28123 before I killed it.
TGV
CC BY-SA 4.0
2019-02-14T14:31:57.337Z
Don't need debug level. Share full log.
Gyan
CC BY-SA 4.0
2019-02-14T14:58:23.237Z
See question for log.
TGV
CC BY-SA 4.0
2019-02-14T15:27:56.050Z
Ok, ffmpeg isn't getting stuck. The showwavespic filter outputs a single image, and long story short, assigns it a weird large framerate. So, ffmpeg is cloning frames to match a constant stream at that rate. This causes a lag in ffmpeg updating its console, so it appears 'stuck'. If you wait for some time, ffmpeg will update. But added a workaround.
Gyan
CC BY-SA 4.0
2019-02-15T10:04:14.140Z
Indeed. I let it run, and after 20min user time it produced a 66MB file with a duration of 04:06:02.33, instead of 00:00:46.16 (which curiously enough looks a lot shifting the digits to the wrong position). I'll look for the workaround. Thanks!
TGV
CC BY-SA 4.0
2019-02-13T14:16:14.093Z
2019-02-14T15:22:36.360Z
2019-02-14T15:22:36.360Z
Gyan
<p>I've got an ffmpeg command that overlays a line on a video and moves it from left to right while the video plays:</p>

<pre><code>ffmpeg -i clip.mp4 -i line-with-transparent-white.png -filter_complex "[0:v][1:v]overlay=x=t/15*1280" output.mp4
</code></pre>

<p>(the numbers 15 and 1280 are duration and width of the clip; they are set in a shell script from ffprobe's output).</p>

<p>That works, but only when clip.mp4 is a "normal" video; not when it has been produced by ffmpeg with the following command:</p>

<pre><code>ffmpeg -i music.mp3 -filter_complex "[0:a]showwavespic=split_channels=0:colors=white|lightgrey,format=pix_fmts=yuv420p" -map 0:a audio.mp4
</code></pre>

<p>The latter file plays fine: it shows the wave, and the music plays, but when I use it as input for the first command, the line graphic doesn't move. It's as if the variable "t" stays at 0 throughout.</p>

<p>I have the vague suspicion that it's related to the fact that the image doesn't change, and hence that there's no progress in the overlay (the mp4 file is barely larger than the mp3 file).</p>

<p>Does anyone know how to proceed: do I need to change the format of "audio.mp4", is there another trick or tool I can use, or should I file a bug perhaps?</p>

<p>Thanks in advance.</p>

<p>BTW, the first command requires the addition of <code>-max_muxing_queue_size 9999</code> when using audio.mp4 as input.</p>

<p>Output from ffmpeg:</p>

<pre><code>ffmpeg version N-48132-ga84af760b8-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.100 / 58. 47.100
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  6.101 / 58.  6.101
  libavfilter     7. 48.100 /  7. 48.100
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, mp3, from 'BayesXMas.mp3':
  Metadata:
    TSS             : Logic Pro X 10.3.3
    iTunNORM        :  000001A6 000001B0 00000FCE 0000170A 00000B53 000064B6 0000543B 00006520 00000772 00000E63
    iTunSMPB        :  00000000 00000210 000008F0 00000000001F0000 00000000 00185D01 00000000 00000000 00000000 00000000 00000000 00000000
  Duration: 00:00:46.16, start: 0.000000, bitrate: 278 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 277 kb/s
Stream mapping:
  Stream #0:0 (mp3float) -&gt; showwavespic (graph 0)
  tpad (graph 0) -&gt; Stream #0:0 (libx264)
  Stream #0:0 -&gt; #0:1 (mp3 (mp3float) -&gt; aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0xceef480] using SAR=1/1
[libx264 @ 0xceef480] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0xceef480] profile High, level 3.1, 4:2:0, 8-bit
[libx264 @ 0xceef480] 264 - core 157 r2935 545de2f - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=7 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'audio5.mp4':
  Metadata:
    TSS             : Logic Pro X 10.3.3
    iTunNORM        :  000001A6 000001B0 00000FCE 0000170A 00000B53 000064B6 0000543B 00006520 00000772 00000E63
    iTunSMPB        :  00000000 00000210 000008F0 00000000001F0000 00000000 00185D01 00000000 00000000 00000000 00000000 00000000 00000000
    encoder         : Lavf58.26.101
    Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 600x240 [SAR 1:1 DAR 5:2], q=-1--1, 73.50 fps, 18816 tbn, 73.50 tbc
    Metadata:
      encoder         : Lavc58.47.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s
    Metadata:
      encoder         : Lavc58.47.100 aac
More than 1000 frames duplicated      0kB time=00:00:24.93 bitrate=   0.0kbits/s speed=49.9x    
</code></pre>

<video><ffmpeg><audio>
Question about ffmpeg's overlay variable t
TGV
# Question about ffmpeg's overlay variable t

(Asked by: username_0 on 2019-02-13)

I've got an ffmpeg command that overlays a line on a video and moves it from left to right while the video plays:
ffmpeg -i clip.mp4 -i line-with-transparent-white.png -filter_complex "[0:v][1:v]overlay=x=t/15*1280" output.mp4

(the numbers 15 and 1280 are duration and width of the clip; they are set in a shell script from ffprobe's output).
That works, but only when clip.mp4 is a "normal" video; not when it has been produced by ffmpeg with the following command:
ffmpeg -i music.mp3 -filter_complex "[0:a]showwavespic=split_channels=0:colors=white|lightgrey,format=pix_fmts=yuv420p" -map 0:a audio.mp4

The latter file plays fine: it shows the wave, and the music plays, but when I use it as input for the first command, the line graphic doesn't move. It's as if the variable "t" stays at 0 throughout.
I have the vague suspicion that it's related to the fact that the image doesn't change, and hence that there's no progress in the overlay (the mp4 file is barely larger than the mp3 file).
Does anyone know how to proceed: do I need to change the format of "audio.mp4", is there another trick or tool I can use, or should I file a bug perhaps?
Thanks in advance.
BTW, the first command requires the addition of -max_muxing_queue_size 9999 when using audio.mp4 as input.
Output from ffmpeg:
ffmpeg version N-48132-ga84af760b8-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.100 / 58. 47.100
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  6.101 / 58.  6.101
  libavfilter     7. 48.100 /  7. 48.100
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, mp3, from 'BayesXMas.mp3':
  Metadata:
    TSS             : Logic Pro X 10.3.3
    iTunNORM        :  000001A6 000001B0 00000FCE 0000170A 00000B53 000064B6 0000543B 00006520 00000772 00000E63
    iTunSMPB        :  00000000 00000210 000008F0 00000000001F0000 00000000 00185D01 00000000 00000000 00000000 00000000 00000000 00000000
  Duration: 00:00:46.16, start: 0.000000, bitrate: 278 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 277 kb/s
Stream mapping:
  Stream #0:0 (mp3float) -> showwavespic (graph 0)
  tpad (graph 0) -> Stream #0:0 (libx264)
  Stream #0:0 -> #0:1 (mp3 (mp3float) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0xceef480] using SAR=1/1
[libx264 @ 0xceef480] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0xceef480] profile High, level 3.1, 4:2:0, 8-bit
[libx264 @ 0xceef480] 264 - core 157 r2935 545de2f - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=7 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'audio5.mp4':
  Metadata:
    TSS             : Logic Pro X 10.3.3
    iTunNORM        :  000001A6 000001B0 00000FCE 0000170A 00000B53 000064B6 0000543B 00006520 00000772 00000E63
    iTunSMPB        :  00000000 00000210 000008F0 00000000001F0000 00000000 00185D01 00000000 00000000 00000000 00000000 00000000 00000000
    encoder         : Lavf58.26.101
    Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 600x240 [SAR 1:1 DAR 5:2], q=-1--1, 73.50 fps, 18816 tbn, 73.50 tbc
    Metadata:
      encoder         : Lavc58.47.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s
    Metadata:
      encoder         : Lavc58.47.100 aac
More than 1000 frames duplicated      0kB time=00:00:24.93 bitrate=   0.0kbits/s speed=49.9x

**Tags:** video, ffmpeg, audio


---

## 1 answers

### Answer by username_1 on 2019-02-13. Score: 0

`showwavespic` generates only one frame, so there's no substrate on which for overlay to take effect after that first frame. Use the tpad filter and -shortest option to clone frames till audio length.

Use

`ffmpeg -i music.mp3 -filter_complex "[0:a]showwavespic=split_channels=0:colors=white|lightgrey,format=pix_fmts=yuv420p,fps=10,tpad=stop=-1:stop_mode=clone" -map 0:a -shortest audio.mp4`

> **Comments:**
> **username_0**: Thanks, but it doesn't work... or rather: doesn't work correctly. FFmpeg doesn't stop generating frames, not even when changing the stop value. It does work when I use the output of the second command from my question as input, and run a new ffmpeg command to tpad that to the desired length. Thanks for setting me on the right track.  
> **username_1**: Share full log. Works here.  
> **username_0**: The full log is a bit large when setting loglevel to debug. My summary would be: it starts with the normal output, then there are about 25000 lines of this kind:  [mp4 @ 0xbf678c0] Delay between the first packet and last packet in the muxing queue is 10007800 > 10000000: forcing output cur_dts is invalid (...) after which follows this: *** 1085029 dup! More than 1000 frames duplicated [libx264 @ 0xbf68c80] frame=   0 QP=15.98 NAL=3 Slice:I Poc:0   I:570  P:0    SKIP:0    size=6490 bytes The latter line runs to frame 28123 before I killed it.  
> **username_1**: Don't need debug level. Share full log.  
> **username_0**: See question for log.  
> **username_1**: Ok, ffmpeg isn't getting stuck. The showwavespic filter outputs a single image, and long story short, assigns it a weird large framerate. So, ffmpeg is cloning frames to match a constant stream at that rate. This causes a lag in ffmpeg updating its console, so it appears 'stuck'. If you wait for some time, ffmpeg will update. But added a workaround.  
> **username_0**: Indeed. I let it run, and after 20min user time it produced a 66MB file with a duration of 04:06:02.33, instead of 00:00:46.16 (which curiously enough looks a lot shifting the digits to the wrong position). I'll look for the workaround. Thanks!  

---

