On 04/09/17 17:00, Jorge Ramirez wrote: > On 09/03/2017 08:23 PM, Mark Thompson wrote: >> On 03/09/17 17:54, Jorge Ramirez wrote: >>> On 09/03/2017 02:27 AM, Mark Thompson wrote: >>>>> +/* in ffmpeg there is a single thread could be queueing/dequeuing >>>>> buffers so a >>>>> + * timeout is * required when retrieving a frame in case the driver has >>>>> not received >>>>> + * enough input * to start generating output. >>>>> + * >>>>> + * once decoding starts, the timeout should not be hit. >>>> This seems like it could introduce a significant delay on startup for no >>>> good reason. Can you instead just queue packets until either you run out >>>> of input buffers or a nonblocking dequeue succeeds? >>>> >>>> (I might need to think more about how the semantics of this work.) >>>> >>> if the decoder needs 4 blocks, the delay is 200ms, if it is 10 blocks, that >>> is 500ms which doesn't seem too significant? when I test I barely notice >>> the difference with respect to using the h264 codec (or any of the others >>> in fact) >>> >>> the best solution would be to be able to block until the capture queue has >>> frames ready but for that we would need another thread inputting >>> independently on the other queue...does ffmpeg allow for this? separate >>> threads for input and output? >> Since the API is nonblocking, you can just return EAGAIN from receive_frame >> if there are any free buffers (to request more input). You would then only >> block waiting for output if there is no more input (end of stream) or there >> aren't any free buffers (so no more input could be accepted). Ideally there >> would then be no timeouts at all except in error cases. > > sure, can do that as well, not a problem. > > the encoding API doesnt seem to allow for this though: once it retrieves a > valid frame it appears to keep on reading them without inputing others (this > causes teh capture queue to block for ever) > > is this intentional or is it a bug?
The encode API should be identical to the decode API with frames/packets swapped (see docs in avcodec.h). If you have an lavc-using program which calls receive_packet() repeatedly after it has returned EAGAIN and never calls send_packet() then that program is wrong. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
