On Fri, 30 Sep 2016 11:29:07 +0200 Marton Balint <c...@passwd.hu> wrote:
> Signed-off-by: Marton Balint <c...@passwd.hu> > --- > libavdevice/openal-dec.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavdevice/openal-dec.c b/libavdevice/openal-dec.c > index 0647952..8773944 100644 > --- a/libavdevice/openal-dec.c > +++ b/libavdevice/openal-dec.c > @@ -191,6 +191,9 @@ static int read_packet(AVFormatContext* ctx, AVPacket > *pkt) > alcGetIntegerv(ad->device, ALC_CAPTURE_SAMPLES, (ALCsizei) > sizeof(ALCint), &nb_samples); > if (error = al_get_error(ad->device, &error_msg)) goto fail; > > + if (nb_samples == 0) > + return AVERROR(EAGAIN); > + > /* Create a packet of appropriate size */ > if ((error = av_new_packet(pkt, nb_samples*ad->sample_step)) < 0) > goto fail; Kind of questionable. The libavformat machine is a state machine, so it should either return a packet, EOF, some sort of timeout error, of block until new data is available. It does not really have a concept of having the API user wait for input (without blocking). But I suspect this is a deeper issue with libavdevice and even some network protocols in libavformat (I think ffmpeg.c and ffplay.c have hacks for those), so go ahead. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
