Opened 13 years ago
Last modified 19 months ago
#615 open defect
ALSA buffer xrun
Reported by: | burek | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | |
Cc: | unknow, Brad Isbell | 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 (29)
comment:1 by , 13 years ago
Component: | FFmpeg → undetermined |
---|
comment:2 by , 13 years ago
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:5 by , 13 years ago
@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 by , 13 years ago
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.
follow-up: 8 comment:7 by , 13 years ago
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 by , 13 years ago
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?
follow-ups: 10 13 comment:9 by , 13 years ago
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 by , 13 years ago
follow-up: 12 comment:11 by , 13 years ago
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 by , 13 years ago
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
follow-ups: 20 27 comment:13 by , 13 years ago
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:15 by , 13 years ago
I just tried changing it from 65536 to 524288 but the problem still exists :(
Edit: Wait, it works.. Let me do some more tests..
comment:16 by , 13 years ago
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 by , 13 years ago
Please test which size works and which not if its the buffer size, so i can change the value in git master.
comment:18 by , 13 years ago
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 by , 13 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → 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 by , 12 years ago
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 by , 12 years ago
Resolution: | needs_more_info |
---|---|
Status: | closed → reopened |
follow-up: 24 comment:22 by , 12 years ago
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 by , 12 years ago
Cc: | added |
---|---|
Keywords: | unknow removed |
comment:24 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
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 by , 10 years ago
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 by , 9 years ago
Owner: | removed |
---|---|
Status: | reopened → open |
comment:29 by , 19 months ago
Cc: | added |
---|
Is this also reproducible with
?
And is anything wrong with the resulting file?