[FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: October 31, 2017 2:06 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks, Mikhail