[FFmpeg-user] Piped processes result in glitches/dropouts

[Anders Bjerkén]

Thanks Moritz for the quick response!

Here's my command in its full context:

ffmpeg -hide_banner -f s16le -ac 2 -ar 44100 -channel_layout stereo -f alsa
-i hw:2 -filter:a "volume=1.5" -ab 192k -acodec mp3 -f mp3 - | ffmpeg
-hide_banner -f mp3 -i - -c copy -f mpegts udp://<ip>:1685 -c copy -f mp3
udp://0.0.0.0:1685

Input #0, alsa, from 'hw:2':

  Duration: N/A, start: 1726316588.273876, bitrate: 1411 kb/s

    Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s

Stream mapping:

  Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp3 (libmp3lame))

Press [q] to stop, [?] for help

Output #0, mp3, to 'pipe:':

  Metadata:

    TSSE            : Lavf58.45.100

    Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, fltp, 192 kb/s

    Metadata:

      encoder         : Lavc58.91.100 libmp3lame

Input #0, mp3, from 'pipe:':0.91 bitrate= 197.4kbits/s speed=0.912x

  Metadata:

    encoder         : Lavf58.45.100

  Duration: N/A, start: 0.000000, bitrate: 192 kb/s

    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s

Output #0, mpegts, to 'udp://<ip>:1685':

  Metadata:

    encoder         : Lavf58.45.100

    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s

Output #1, mp3, to 'udp://0.0.0.0:1685':

  Metadata:

    TSSE            : Lavf58.45.100

    Stream #1:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s

Stream mapping:

  Stream #0:0 -> #0:0 (copy)

  Stream #0:0 -> #1:0 (copy)

size=    1346kB time=00:00:57.39 bitrate= 192.1kbits/s speed=0.999x


No, it doesn't glitch if I stream directly from the first ffmpeg process to
any of the outputs.


Thanks for the tip regarding the complete, uncut console output, which I
didn't study in detail before. I suddenly realized that there are
corresponding entries with "ALSA buffer xrun." in the log for every glitch.
I reckon this may be fixed by setting "-thread_queue_size" for the input in
my second ffmpeg. I will try different values and come back here if I don't
get it right...


Thanks again

Anders



Den lör 14 sep. 2024 kl 13:50 skrev Moritz Barsnick via ffmpeg-user <
ffmpeg-user at ffmpeg.org>:

> Hej Anders,
>
> On Sat, Sep 14, 2024 at 13:32:01 +0200, Anders Bjerkén wrote:
> > ffmpeg -f alsa -i hw:2 -filter:a "volume=1.5" -ab 192k -acodec mp3 -f
> mp3 -
> > | ffmpeg -f mp3 -i - -c copy -f mpegts udp://<external_ip>:1685 -c copy
> -f
> > mp3 udp://0.0.0.0:1685
>
> It's usually expected to also post the complete, uncut console
> output(s) here.
>
> > Conceptually, it works. However, every now and then I get synchronized
> 1-2
> > second long glitches in the outcoming data stream for both outputs.
>
> This sounds like a buffering issue.
>
> What happens if you stream directly from the first ffmpeg process to
> one of the outputs? Does it also glitch?
>
> You could consider using one ffmpeg process and the "tee" muxer. I'm
> not sure it will solve your problem, but could be an alternative and a
> more lightweight command line.
>
> > have used all suggested versions of this command mentioned
> > on https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs, but with
> the
> > same result in the end.
>
> Ah, I forgot that the "tee" muxer is mentioned there as well.
>
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>