Opened 5 years ago

Last modified 12 months ago

#615 open defect

ALSA buffer xrun

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

Description

when grabbing video+audio from usb webcam, this error always appear, no matter what output muxer format is chosen: "ALSA buffer xrun"

i've tried with .avi, .ts, .flv, .mkv, and all give the similar output:

ffmpeg -y -re \
        -f video4linux2 -r 30 -s qvga -i /dev/v4l/by-id/usb-046d_0809_33A881A3-video-index0 \
        -f alsa -ar 44100 -ac 2 -i default:CARD=Intel \
        out.flv

ffmpeg version N-34519-g54a09f1, Copyright (c) 2000-2011 the FFmpeg developers
  built on Nov  6 2011 12:46:05 with gcc 4.6.1
  configuration: --enable-static --enable-shared --enable-gpl --enable-nonfree --enable-postproc --enable-libx264 --enable-libaacplus --enable-libmp3lame --enable-libv4l2 --enable-libvo-aacenc --enable-version3
  libavutil    51. 23. 0 / 51. 23. 0
  libavcodec   53. 28. 0 / 53. 28. 0
  libavformat  53. 19. 0 / 53. 19. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 47. 0 /  2. 47. 0
  libswscale    2.  1. 0 /  2.  1. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[video4linux2,v4l2 @ 0x2247980] Estimating duration from bitrate, this may be inaccurate
Input #0, video4linux2,v4l2, from '/dev/v4l/by-id/usb-046d_0809_33A881A3-video-index0':
  Duration: N/A, start: 27263.653187, bitrate: 27648 kb/s
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 320x240, 27648 kb/s, 30 tbr, 1000k tbn, 30 tbc
[alsa @ 0x2242040] Estimating duration from bitrate, this may be inaccurate
Input #1, alsa, from 'default:CARD=Intel':
  Duration: N/A, start: 1320593764.890759, bitrate: N/A
    Stream #1:0: Audio: pcm_s16le, 44100 Hz, 2 channels, s16, 1411 kb/s
[buffer @ 0x2297f20] w:320 h:240 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:
Output #0, flv, to 'out.flv':
  Metadata:
    encoder         : Lavf53.19.0
    Stream #0:0: Video: flv1 ([2][0][0][0] / 0x0002), yuv420p, 320x240, q=2-31, 200 kb/s, 1k tbn, 30 tbc
    Stream #0:1: Audio: mp3 ([2][0][0][0] / 0x0002), 44100 Hz, 2 channels, s16, 128 kb/s
Stream mapping:
  Stream #0.0 -> #0.0 (rawvideo -> flv)
  Stream #1.0 -> #0.1 (pcm_s16le -> libmp3lame)
Press [q] to stop, [?] for help
[alsa @ 0x2242040] ALSA buffer xrun.
ALSA buffer xrun. 6 q=2.6 size=      34kB time=00:00:01.48 bitrate= 185.4kbits/s
ALSA buffer xrun. 8 q=2.6 size=     103kB time=00:00:03.52 bitrate= 240.2kbits/s
frame=   78 fps=  8 q=2.8 Lsize=     252kB time=00:00:04.91 bitrate= 421.2kbits/s
video:171kB audio:77kB global headers:0kB muxing overhead 1.801323%
root@strumf:~/videos/tests/mpegts# ^C

Change History (28)

comment:1 Changed 5 years ago by cehoyos

  • Component changed from FFmpeg to undetermined

Is this also reproducible with

$ ffmpeg -f alsa -ar 44100 -ac 2 -i default:CARD=Intel out.wav

?

And is anything wrong with the resulting file?

comment:2 Changed 5 years ago by burek

There is no such error with .wav. I've ran ffmpeg for a whole minute, not a single ALSA error occured. Audio file is ok, just 2 warnings appeared at the beginning:

main debug: Decoder buffering done in 1251 ms
main warning: PTS is out of range (-9963), dropping buffer
main warning: PTS is out of range (-33131), dropping buffer

And the rest of the audio played back without any problems.

comment:3 Changed 5 years ago by cehoyos

Which option makes the original problem appear?

comment:4 Changed 5 years ago by michael

also try to increase ALSA_BUFFER_SIZE_MAX

comment:5 Changed 5 years ago by burek

@cehoyos I'm not sure, but I think it has got something to do with syncing video and audio..

@michael Is it an ffmpeg param or the constant in the source code?

comment:6 Changed 5 years ago by cehoyos

I meant that I provided a (short) command line that you say does not show any warnings, you provided a (longer) command line that did show warnings.
Which of the options of your command line have to be added to my command line to show the same warnings?

ALSA_BUFFER_SIZE_MAX is a constant in libavdevice/alsa-audio.h.

comment:7 follow-up: Changed 5 years ago by burek

cehoyos, I'm not sure I understand what are you asking, because the original command has got different codec, different muxer and even has an extra input stream (video), so im not sure is it even comparable with your cmd line..?

comment:8 in reply to: ↑ 7 Changed 5 years ago by cehoyos

Replying to burek:

cehoyos, I'm not sure I understand what are you asking, because the original command has got different codec, different muxer and even has an extra input stream (video)

Yes.
Which of them is necessary to trigger the warning you see?

comment:9 follow-ups: Changed 5 years ago by burek

During a series of tests, I figured this has got something to do with capturing video and audio together, not only audio. That's why I didn't think it was a good idea to start from wav output.

I'm also starting to believe it might be an ALSA bug actually. Because, every time I try to capture video from my usb webcam and audio (either from webcam or pci sound card), these errors are kinda normal thing to happen.

I'll try to capture webcam's a/v to an uncompressed a/v stream, to avoid possible encoders' bugs. Do you have any suggestion how to do this, without killing my hdd? Can I somehow stream it all using udp to some localhost udp port or to a /dev/null or something?

comment:10 in reply to: ↑ 9 Changed 5 years ago by cehoyos

Replying to burek:

Can I somehow stream it [...] to [...] /dev/null [...]?

Did you try?

comment:11 follow-up: Changed 5 years ago by burek

I would if I knew how.. How can I mux uncompressed a/v at first place? And I guess, I should just use something like this as an output: -f ... /dev/null ?

comment:12 in reply to: ↑ 11 Changed 5 years ago by cehoyos

Replying to burek:

I would if I knew how.. How can I mux uncompressed a/v at first place?

Many muxers (not mpegts and flv) will accept -vcodec rawvideo -acodec pcm_*, but in your specific case, -vcodec copy -acodec copy is sufficient.

And I guess, I should just use something like this as an output: -f ... /dev/null ?

... /dev/null will be sufficient, you may want to use ... -y /dev/null

comment:13 in reply to: ↑ 9 ; follow-ups: Changed 5 years ago by reimar

Replying to burek:

I'm also starting to believe it might be an ALSA bug actually. Because, every time I try to capture video from my usb webcam and audio (either from webcam or pci sound card), these errors are kinda normal thing to happen.

Did you try capturing audio and video at the same time bug from different FFmpeg processes?
I would have guessed that due to the overhead of video processing FFmpeg might not get data often enough from the audio device.
Even if that is not the case, clocks and thus timestamps for audio and video running apart might cause FFmpeg to read audio data not often enough.
For both cases creating a separate thread that can buffer far more data than ALSA on its own (similar to what is done in libavformat/udp.c) should help.

comment:14 Changed 5 years ago by michael

Did you try to increase ALSA_BUFFER_SIZE_MAX ?

comment:15 Changed 5 years ago by burek

I just tried changing it from 65536 to 524288 but the problem still exists :(

Version 0, edited 5 years ago by burek (next)

comment:16 Changed 5 years ago by burek

I think it works now. I couldn't reproduce the bug anymore, so I can conclude that this really works. I'll maybe try to return to the previous buffer size, just to see if the error will reappear.

comment:17 Changed 5 years ago by michael

Please test which size works and which not if its the buffer size, so i can change the value in git master.

comment:18 Changed 5 years ago by burek

The problem is I can't reproduce the issue now.. I don't know what changed since the last time I've got that error message, but it seems I just can't reproduce it anymore on my testing machine. I'll see if I can reproduce this on a production machines, but I need to do this tomorrow, because I cannot access them right now :/

comment:19 Changed 4 years ago by michael

  • Resolution set to needs_more_info
  • Status changed from new to closed

no reply for 6 month and the issue is probably fixed, so closing it.
Please reopen if teh issue is still reproduceable

comment:20 in reply to: ↑ 13 Changed 3 years ago by unknow

i encounter the same problem.

it apear only when i record from alsa & x11grab

increasing ALSA_BUFFER_SIZE_MAX didn't seem to change anything

$ ffmpeg  -f x11grab -r 25 -s 1152x864 -i 0:0+1,20 -f alsa -i default -acodec libfaac -vcodec libx264 -preset ultrafast -y rec.mkv

or

$ ffmpeg  -f x11grab -r 25 -s 1152x864 -i 0:0+1,20 -f alsa -i default -acodec libfaac -vcodec libx264 -preset ultrafast -f null -y /dev/null

with 65535 or 6553500 i got xrun every ~30sec

the fun thing is changing audio option don't change anything but:

$ ffmpeg -f alsa -i default -f x11grab -r 10 -s 320x240  -i :0.0+1,20 -acodec libfaac -vcodec libx264 -preset ultrafast rec.mkv

works with a lot of

[libfaac @ 0xdf2a00] Queue input is backward in time
[matroska @ 0xdf1160] Non-monotonous DTS in output stream 0:1; previous: 281, current: 276; changing to 281. This may result in incorrect timestamps in the output file.

but 0 xrun, sound and video is in sync

so
Replying to reimar:

Did you try capturing audio and video at the same time bug from different FFmpeg processes?
I would have guessed that due to the overhead of video processing FFmpeg might not get data often enough from the audio device.
Even if that is not the case, clocks and thus timestamps for audio and video running apart might cause FFmpeg to read audio data not often enough.
For both cases creating a separate thread that can buffer far more data than ALSA on its own (similar to what is done in libavformat/udp.c) should help.

should be right

launching separatly

$ ffmpeg -f alsa -i default -acodec libfaac rec_va.mkv
$ ffmpeg  -f x11grab -r 25 -s 1152x864 -i 0:0+1,20 -vcodec libx264 -preset ultrafast rec_vo.mkv

got no xrun

comment:21 Changed 3 years ago by unknow

  • Resolution needs_more_info deleted
  • Status changed from closed to reopened

comment:22 follow-up: Changed 3 years ago by cehoyos

  • Keywords unknow added

Are external libraries (libx264 and libfaac) necessary to reproduce the problem or is it also reproducible with -strict -2 -acodec aac -vcodec mpeg4 ?

Please provide the command line that triggers the warnings together with the complete, uncut console output.

comment:23 Changed 3 years ago by cehoyos

  • Cc unknow added
  • Keywords unknow removed

comment:24 in reply to: ↑ 22 Changed 3 years ago by unknow

Replying to cehoyos:

Are external libraries (libx264 and libfaac) necessary to reproduce the problem or is it also reproducible with -strict -2 -acodec aac -vcodec mpeg4 ?

Please provide the command line that triggers the warnings together with the complete, uncut console output.

seem less frequent

$ ffmpeg  -f x11grab -r 25 -s 1152x864 -i 0:0+1,20 -f alsa -i default -strict -2 -acodec aac -vcodec mpeg4 -y rec.mkv
ffmpeg version git-2013-05-19-a3264b4 Copyright (c) 2000-2013 the FFmpeg developers
  built on May 19 2013 18:10:31 with gcc 4.7 (Debian 4.7.2-5)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-shared --enable-gnutls --enable-fontconfig --enable-libmp3lame --enable-libfreetype --enable-libfaac --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libtheora --enable-libvo-aacenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-openssl --enable-x11grab --enable-avresample
  libavutil      52. 33.100 / 52. 33.100
  libavcodec     55. 10.101 / 55. 10.101
  libavformat    55.  7.100 / 55.  7.100
  libavdevice    55.  0.100 / 55.  0.100
  libavfilter     3. 68.101 /  3. 68.101
  libavresample   1.  1.  0 /  1.  1.  0
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
[x11grab @ 0xe82620] device: 0:0+1,20 -> display: 0:0 x: 1 y: 20 width: 1152 height: 864
[x11grab @ 0xe82620] shared memory extension found
Input #0, x11grab, from '0:0+1,20':
  Duration: N/A, start: 1369068172.539050, bitrate: 796262 kb/s
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1152x864, 796262 kb/s, 25 tbr, 1000k tbn, 25 tbc
Guessed Channel Layout for  Input Stream #1.0 : stereo
Input #1, alsa, from 'default':
  Duration: N/A, start: 1369068172.398661, bitrate: 1536 kb/s
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Output #0, matroska, to 'rec.mkv':
  Metadata:
    encoder         : Lavf55.7.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1152x864, q=2-31, 200 kb/s, 1k tbn, 25 tbc
    Stream #0:1: Audio: aac ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, fltp, 128 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> mpeg4)
  Stream #1:0 -> #0:1 (pcm_s16le -> aac)
Press [q] to stop, [?] for help
ALSA buffer xrun.23 q=31.0 size=   11098kB time=00:00:42.83 bitrate=2122.7kbits/s    
Queue input is backward in time=   18295kB time=00:01:17.78 bitrate=1926.7kbits/s    
Queue input is backward in time=   24558kB time=00:01:52.64 bitrate=1786.0kbits/s    
[aac @ 0xebe900] Queue input is backward in time
    Last message repeated 2 times
[matroska @ 0xeb1360] Non-monotonous DTS in output stream 0:1; previous: 113171, current: 113163; changing to 113171. This may result in incorrect timestamps in the output file.
[matroska @ 0xeb1360] Non-monotonous DTS in output stream 0:1; previous: 113171, current: 113159; changing to 113171. This may result in incorrect timestamps in the output file.
[matroska @ 0xeb1360] Non-monotonous DTS in output stream 0:1; previous: 113171, current: 113158; changing to 113171. This may result in incorrect timestamps in the output file.
[matroska @ 0xeb1360] Non-monotonous DTS in output stream 0:1; previous: 113171, current: 113164; changing to 113171. This may result in incorrect timestamps in the output file.
frame= 3356 fps= 24 q=24.8 Lsize=   30006kB time=00:02:20.03 bitrate=1755.4kbits/s    
video:27740kB audio:2189kB subtitle:0 global headers:0kB muxing overhead 0.259974%
Received signal 2: terminating.

comment:25 Changed 3 years ago by cehoyos

Does the problem disappear completely if you reduce the resolution (or the frame rate)?
$ ffmpeg -f x11grab -r 25 -s 288x216 -i 0:0+1,20 -f alsa -i default -strict -2 -acodec aac -vcodec mpeg4 -y rec.mkv

comment:26 Changed 3 years ago by unknow

yep totaly works
only these warning as usual:

Queue input is backward in time=    8283kB time=00:03:20.48 bitrate= 338.4kbits/s    
Queue input is backward in time=    8341kB time=00:03:21.88 bitrate= 338.5kbits/s    
[aac @ 0x133bb60] Queue input is backward in time
Non-monotonous DTS in output stream 0:1; previous: 202519, current: 202515; changing to 202519. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 202519, current: 202512; changing to 202519. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 202519, current: 202513; changing to 202519. This may result in incorrect timestamps in the output file.
Queue input is backward in time=    8585kB time=00:03:27.98 bitrate= 338.1kbits/s    
[aac @ 0x133bb60] Queue input is backward in time
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 208509, current: 208504; changing to 208509. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 208509, current: 208503; changing to 208509. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 208509, current: 208505; changing to 208509. This may result in incorrect timestamps in the output file.
Queue input is backward in time=    8905kB time=00:03:36.05 bitrate= 337.7kbits/s    
Queue input is backward in time=    9796kB time=00:03:58.22 bitrate= 336.9kbits/s    
Queue input is backward in time=   10118kB time=00:04:06.38 bitrate= 336.4kbits/s    
[aac @ 0x133bb60] Queue input is backward in time
    Last message repeated 1 times
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 246523, current: 246518; changing to 246523. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 246523, current: 246514; changing to 246523. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 246523, current: 246513; changing to 246523. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 246523, current: 246516; changing to 246523. This may result in incorrect timestamps in the output file.
Queue input is backward in time=   10281kB time=00:04:10.53 bitrate= 336.2kbits/s    
[aac @ 0x133bb60] Queue input is backward in time
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 250524, current: 250518; changing to 250524. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 250524, current: 250516; changing to 250524. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 250524, current: 250517; changing to 250524. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 250524, current: 250520; changing to 250524. This may result in incorrect timestamps in the output file.
Queue input is backward in time=   10502kB time=00:04:15.94 bitrate= 336.1kbits/s    
[aac @ 0x133bb60] Queue input is backward in time
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 256518, current: 256514; changing to 256518. This may result in incorrect timestamps in the output file.
[matroska @ 0x133c240] Non-monotonous DTS in output stream 0:1; previous: 256518, current: 256511; changing to 256518. This may result in incorrect timestamps in the output file.
Non-monotonous DTS in output stream 0:1; previous: 256518, current: 256512; changing to 256518. This may result in incorrect timestamps in the output file.
frame= 7829 fps= 25 q=7.8 Lsize=   12987kB time=00:05:13.30 bitrate= 339.6kbits/s    
video:7991kB audio:4822kB subtitle:0 global headers:0kB muxing overhead 1.353864%
Received signal 2: terminating.

but no desync

comment:27 in reply to: ↑ 13 Changed 19 months ago by peterbecich

Replying to reimar:

Replying to burek:

I'm also starting to believe it might be an ALSA bug actually. Because, every time I try to capture video from my usb webcam and audio (either from webcam or pci sound card), these errors are kinda normal thing to happen.

Did you try capturing audio and video at the same time bug from different FFmpeg processes?
I would have guessed that due to the overhead of video processing FFmpeg might not get data often enough from the audio device.
Even if that is not the case, clocks and thus timestamps for audio and video running apart might cause FFmpeg to read audio data not often enough.
For both cases creating a separate thread that can buffer far more data than ALSA on its own (similar to what is done in libavformat/udp.c) should help.

Thanks for this. Using two separate ffmpeg processes has solved my problem, written up here: http://stackoverflow.com/questions/28359855/alsa-buffer-xrun-induced-by-low-quality-source-in-ffmpeg-capture

I am transferring video tape. The "ALSA buffer xrun" was triggered by any noisy/garbage parts of the tape, like the beginning of it. The "xruns" then persist into quality parts of the tape, leading me to think this is a chain reaction. The video is fine, though.

.
.
[alsa @ 0x22038a0] ALSA buffer xrun.8980kB time=00:00:21.84 bitrate=7118.8kbits/s    
[alsa @ 0x22038a0] ALSA buffer xrun.2032kB time=00:00:24.55 bitrate=7349.3kbits/s    
[alsa @ 0x22038a0] ALSA buffer xrun.4612kB time=00:00:27.27 bitrate=7391.1kbits/s    
.
.

A notable feature is that after the "xruns" begin, the bitrate of the encoding shoots up higher than normal.

I haven't figured out how to increase the ALSA buffer size in Ubuntu (question here: http://askubuntu.com/questions/564033/increasing-alsas-buffer-size), and also have not figured out how to increase the ALSA thread queue size to fix this error message:

[alsa @ 0x31ab8a0] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)

If I'm reading this correctly, the option to change the ALSA thread queue size is coming soon: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2015-February/169292.html

comment:28 Changed 12 months ago by michael

  • Owner michael deleted
  • Status changed from reopened to open
Note: See TracTickets for help on using tickets.