> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Marton Balint > Sent: October 30, 2017 9:26 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 Mon, 30 Oct 2017, Mironov, Mikhail wrote: > > [...] > > >>>> I still think this would be much better off using the > >>>> send_frame()/receive_packet() API. Even if your API doesn't expose > >>>> any information about the queue length, you only need to hold a > >>>> single input frame transiently to get around that (the user is not > >>>> allowed to call > >>>> send_frame() twice in a row without calling receive_packet()). > >>>> > >>> > >>> So to implement this I would have to: > >>> - in the send_frame() if AMF_INPUT_FULL is returned - store input > >>> frame (or copy?) > >>> - In the next receive_frame() check if frame is stored > >>> - Wait till some output is produced > >>> - resubmit stored frame > >> > >> Sounds about right. > >> > >>> Issues I see: > >>> - Isn't this logic defeat the purpose of independent send()/receive()? > >>> - How can I report a error if receive() produced a compressed frame > >>> but > >> the delayed submission failed? > >> > >> Since this is asynchronous anyway, just report it at the next > >> available opportunity. > >> > >>> - This logic depends on the particular logic in the calling code. > >> > >> The API requires this behaviour of the caller. See the documentation > >> in avcodec.h. > >> > >>> - This logic depends on the particular HW behaviour. > >> > >> How so? > >> > >>> - In the future, we would like to output individual slices of a > >>> compressed > >> frame. > >>> When this added receive_frame() must be called several times to > >>> clear > >> space in the HW queue. > >>> Granted, current implementation also does not cover this case but > >>> truly independent send/receive implementation would. > >> > >> Note that the user is required to call receive_packet() repeatedly > >> until it returns EAGAIN, and only then are they allowed to call > send_frame() again. > > > > The implementation will be cumbersome at least. Note that calling > > Drain() may also return AMF_INPUT_FULL and therefore will have to be > > remembered and called again in receive(). But I will implement as you > suggests. It is not a huge change. > > > > 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. > 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