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

[Marton Balint]

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.

Regards,
Marton