On 09/03/2017 02:27 AM, Mark Thompson wrote:
+
+ return 0;
+}
+
+static int v4l2m2m_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+{
+ V4L2m2mContext *s = avctx->priv_data;
+ V4L2Context *const output = &s->output;
+
+ return ff_v4l2_enqueue_frame(output, frame);
+}
+
+/* Send and receive frame happen on the same thread, hence the need for a
polling timeout */
Maybe this should only block if there isn't any space to queue more input?
as it happens on the decoding side, the issue is the same.
before being able to receive frames from the capture queue
(encoded/decoded) the user needs to push a number of buffers to the
output queue.
this number varies from IP to IP...I guess also depend on the formats.
so yeah, if we knew before hand this number then it would be easy to
make sure we have queued enough input buffers to get the pipe going and
then just block for data safely.
you proposed that this number is calibrated (ie, track the timeout);
however it makes me feel unsafe not having a fallback option (ie, if the
pipe blocks, then we are stuck)....
having said that, I will post the calibrated solution if you'd rather
have that....we can easily go back to a timeout if needed.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
