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?

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to