> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Marton Balint > Sent: October 31, 2017 2:06 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD > GPUs based on AMF SDK > > > On Tue, 31 Oct 2017, Mironov, Mikhail wrote: > > [...] > > >> I see some confusion. The user can call send_frame/receive_packet in > >> any order, and you can implement send_frame and receive_packet any > >> way you want, the only thing you have to guarantee is that you cannot > >> return EAGAIN for both send_frame and receive_packet. Not even > temporarily. > >> > >> If you returned EAGAIN in send_frame, you must return success or a > >> normal error in receive_packet. If you returned EAGAIN in > >> receive_packet, you must return success or a normal error in send_frame. > >> > >> By returning EAGAIN in receive_packet you make sure that the API user > >> submits as many frames as needed to fill your pipeline. > >> > >> The simplest solution really seems to me what Mark proposed: > >> > >> send_frame: > >> > >> if (have_stored_frame) > >> return EAGAIN; > >> if (amd_send_frame() == INPUT_FULL) > >> store_frame; > >> return 0; > >> > >> receive_packet: > >> > >> if (have_stored_frame) { > >> if (amd_send_frame() == OK) > >> unstore_frame; > >> block_until_have_packet > >> return packet > >> } else { > >> return EAGAIN > >> } > >> > >> I hope I did not mess it up, proper draining and error handling > >> obviously needs some minor changes. > >> > > > > The logic in receive_packet() will be slightly different but I will figure > > this > out. > > My only note is that returning EAGAIN from send_frame() will not work > > with current ffmpeg calling code. > > I was assured that this will never happen but I don’t like possibility > > of the failure. What the calling code supposed to do getting EAGAIN > > from send_frame()? Resubmit? If so it would not work with the logic > > described. > > Anyway, lets try Mark's suggestion and see if alternations are needed. > > ffmpeg.c is written in a way that it calls receive_packet repeatedly until it > gets > EAGAIN. Due to the API requirements I mentioned (send_frame and > receive_packet both cannot return EAGAIN), it is OK to not handle EAGAIN > for send_frame in ffmpeg.c code. > > Other applications might use other logic (e.g. call send_frame repeatedly, > and then call receive_packet once, or call send_frame and receive packet > alternating), in these cases the user application must be able to handle > EAGAIN for send_frame, and resubmit the frame next time. > > But if ffmpeg.c gets an EAGAIN in send_frame, that means a bug in the > encoder because the encoder is breaking the API and it needs to be fixed.
Yes, this is exactly how I understand it and hopefully implemented it. > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks, Mikhail _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
