r17863 - trunk/libavdevice/alsa-audio-common.c
Author: lucabe Date: Sat Mar 7 19:17:13 2009 New Revision: 17863 Log: Fix AVFMT_FLAG_NONBLOCK in alsa Modified: trunk/libavdevice/alsa-audio-common.c Modified: trunk/libavdevice/alsa-audio-common.c ============================================================================== --- trunk/libavdevice/alsa-audio-common.c Sat Mar 7 16:20:55 2009 (r17862) +++ trunk/libavdevice/alsa-audio-common.c Sat Mar 7 19:17:13 2009 (r17863) @@ -68,7 +68,7 @@ av_cold int ff_alsa_open(AVFormatContext s->frame_size = av_get_bits_per_sample(*codec_id) / 8 * channels; if (ctx->flags & AVFMT_FLAG_NONBLOCK) { - flags = O_NONBLOCK; + flags = SND_PCM_NONBLOCK; } res = snd_pcm_open(&h, audio_device, mode, flags); if (res < 0) {
On Saturday 07 March 2009, 19:17:13, lucabe wrote:
if (ctx->flags & AVFMT_FLAG_NONBLOCK) { - flags = O_NONBLOCK; + flags = SND_PCM_NONBLOCK; } res = snd_pcm_open(&h, audio_device, mode, flags);
This broke alsa playback. Fix: diff --git a/libavdevice/alsa-audio-common.c b/libavdevice/alsa-audio-common.c index f1d78b0..1c31d10 100644 --- a/libavdevice/alsa-audio-common.c +++ b/libavdevice/alsa-audio-common.c @@ -67,7 +67,7 @@ av_cold int ff_alsa_open(AVFormatContext *ctx, snd_pcm_stream_ } s->frame_size = av_get_bits_per_sample(*codec_id) / 8 * channels; - if (ctx->flags & AVFMT_FLAG_NONBLOCK) { + if (ctx->flags & AVFMT_FLAG_NONBLOCK && mode == SND_PCM_STREAM_CAPTURE) { flags = SND_PCM_NONBLOCK; } res = snd_pcm_open(&h, audio_device, mode, flags); Regards, --Ivo
Hi, Ivo wrote:
On Saturday 07 March 2009, 19:17:13, lucabe wrote:
if (ctx->flags & AVFMT_FLAG_NONBLOCK) { - flags = O_NONBLOCK; + flags = SND_PCM_NONBLOCK; } res = snd_pcm_open(&h, audio_device, mode, flags);
This broke alsa playback. Fix: [...]
What's the particular problem? Has alsa some problems with non-blocking output, is libavformat broken in this regard, or is it an application issue? Maybe it is a problem with a particular driver? I am using alsa playback right now, and it seems to work correctly: ffmpeg -re -i file.mp3 -f alsa hw Luca
Hi, On Thursday 19 November 2009, 08:20:07, Luca Abeni wrote:
Ivo wrote:
On Saturday 07 March 2009, 19:17:13, lucabe wrote:
if (ctx->flags & AVFMT_FLAG_NONBLOCK) { - flags = O_NONBLOCK; + flags = SND_PCM_NONBLOCK; } res = snd_pcm_open(&h, audio_device, mode, flags);
This broke alsa playback. Fix:
[...]
What's the particular problem? Has alsa some problems with non-blocking output, is libavformat broken in this regard, or is it an application issue?
Maybe it is a problem with a particular driver? I am using alsa playback right now, and it seems to work correctly: ffmpeg -re -i file.mp3 -f alsa hw
I forgot the -re option. With that, it works correctly. Well, at least I got to use git-bisect for the first time :) Nevertheless, my fix might be the correct behaviour anyway, because the documentation says: #define AVFMT_FLAG_NONBLOCK 0x0004 ///< Do not block when reading packets from input. So it's an input-only flag, not an output flag. Regards, --Ivo
Ivo wrote: [...]
What's the particular problem? Has alsa some problems with non-blocking output, is libavformat broken in this regard, or is it an application issue?
Maybe it is a problem with a particular driver? I am using alsa playback right now, and it seems to work correctly: ffmpeg -re -i file.mp3 -f alsa hw
I forgot the -re option. With that, it works correctly. Well, at least I got to use git-bisect for the first time :)
;-)
Nevertheless, my fix might be the correct behaviour anyway, because the documentation says:
#define AVFMT_FLAG_NONBLOCK 0x0004 ///< Do not block when reading packets from input.
So it's an input-only flag, not an output flag.
You are right; there is an inconsistency between behaviour and documentation. However, I do not know if the error is in the documentation or in the current behaviour; maybe Michael can comment on this (he is the one who asked for the nonblocking behaviour). Once the expected behaviour of the flag is clarified, I'll commit the correct patch. Thanks, Luca
On Fri, Nov 20, 2009 at 09:35:16AM +0100, Luca Abeni wrote:
Ivo wrote: [...]
What's the particular problem? Has alsa some problems with non-blocking output, is libavformat broken in this regard, or is it an application issue?
Maybe it is a problem with a particular driver? I am using alsa playback right now, and it seems to work correctly: ffmpeg -re -i file.mp3 -f alsa hw I forgot the -re option. With that, it works correctly. Well, at least I got to use git-bisect for the first time :)
;-)
Nevertheless, my fix might be the correct behaviour anyway, because the documentation says: #define AVFMT_FLAG_NONBLOCK 0x0004 ///< Do not block when reading packets from input. So it's an input-only flag, not an output flag.
You are right; there is an inconsistency between behaviour and documentation. However, I do not know if the error is in the documentation or in the current behaviour; maybe Michael can comment on this (he is the one who asked for the nonblocking behaviour).
id say setting AVFMT_FLAG_NONBLOCK for output has undefined behaviour we could change that and define it in some sane way of course ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
Hi Michael, Michael Niedermayer wrote: [...]
Nevertheless, my fix might be the correct behaviour anyway, because the documentation says: #define AVFMT_FLAG_NONBLOCK 0x0004 ///< Do not block when reading packets from input. So it's an input-only flag, not an output flag. You are right; there is an inconsistency between behaviour and documentation. However, I do not know if the error is in the documentation or in the current behaviour; maybe Michael can comment on this (he is the one who asked for the nonblocking behaviour).
id say setting AVFMT_FLAG_NONBLOCK for output has undefined behaviour we could change that and define it in some sane way of course ...
Ok... So, what's the behaviour we want for output? I just verified that the "file" protocol is blocking for output, even if AVFMT_FLAG_NONBLOCK is defined... So, maybe Ivo's patch is the best solution (making the alsa output device consistent with the file protocol). The other solution would be to update the documentation, changing it in "Do not block when reading packets from input or writhing them to output". Which one do you prefer? Thanks, Luca
On Fri, Nov 20, 2009 at 03:18:26PM +0100, Luca Abeni wrote:
Hi Michael,
Michael Niedermayer wrote: [...]
Nevertheless, my fix might be the correct behaviour anyway, because the documentation says: #define AVFMT_FLAG_NONBLOCK 0x0004 ///< Do not block when reading packets from input. So it's an input-only flag, not an output flag. You are right; there is an inconsistency between behaviour and documentation. However, I do not know if the error is in the documentation or in the current behaviour; maybe Michael can comment on this (he is the one who asked for the nonblocking behaviour). id say setting AVFMT_FLAG_NONBLOCK for output has undefined behaviour we could change that and define it in some sane way of course ...
Ok... So, what's the behaviour we want for output?
maybe you should post this to ffmpeg-dev [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
Michael Niedermayer wrote: [...]
id say setting AVFMT_FLAG_NONBLOCK for output has undefined behaviour we could change that and define it in some sane way of course ... Ok... So, what's the behaviour we want for output?
maybe you should post this to ffmpeg-dev
[...]
You are right... Sorry, I pressed reply without remembering that the mail was going to ffmpeg-cvslog. Anyway, I see that Ivo already sent an email to ffmpeg-devel. Luca
participants (4)
-
ivop＠euronet.nl -
lucabe72＠email.it -
michaelni＠gmx.at -
subversion＠mplayerhq.hu