[FFmpeg-devel,WIP,0/4] Encoding API code restructuration

This set follows the same logic as 061a0c14bb, but for the encode API: The
new public API will no longer be a wrapper around the old deprecated one, and
the internal API used by the encoders now consists of a single receive_packet()
callback that pulls frames as required.

Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
have been adapted, and said changes squashed into it. This means librav1e, nvenc,
amfenc, v4l2_m2m, and vaapi_enc.
I have ported librav1e both to test this set and for it to work as an example
for the maintainers of the other three encoders in order to get an idea of what
they should do.

James Almer (4):
  avcodec: move avcodec_flush_buffers from decode.c to utils.c
  avcodec/encode: restructure the core encoding code
  avcodec/encode: restructure the old encode API
  avcodec/librav1e: adapt to the new internal encode API

 libavcodec/avcodec.h  |  12 +-
 libavcodec/decode.c   |  36 ---
 libavcodec/encode.c   | 497 +++++++++++++++++++++---------------------
 libavcodec/encode.h   |  39 ++++
 libavcodec/internal.h |   8 +-
 libavcodec/librav1e.c |  65 +++---
 libavcodec/utils.c    |  52 ++++-
 7 files changed, 384 insertions(+), 325 deletions(-)
 create mode 100644 libavcodec/encode.h

Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer <jamrial@gmail.com>:
>
> This set follows the same logic as 061a0c14bb, but for the encode API: The
> new public API will no longer be a wrapper around the old deprecated one, and
> the internal API used by the encoders now consists of a single receive_packet()
> callback that pulls frames as required.
>
> Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
> have been adapted, and said changes squashed into it. This means librav1e, nvenc,
> amfenc, v4l2_m2m, and vaapi_enc.
> I have ported librav1e both to test this set and for it to work as an example
> for the maintainers of the other three encoders in order to get an idea of what
> they should do.

How does performance change with these patches?

Am I correct that this changes the "new" api which so many
users complained about?

Carl Eugen

On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer <jamrial@gmail.com>:
>>
>> This set follows the same logic as 061a0c14bb, but for the encode API: The
>> new public API will no longer be a wrapper around the old deprecated one, and
>> the internal API used by the encoders now consists of a single receive_packet()
>> callback that pulls frames as required.
>>
>> Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
>> have been adapted, and said changes squashed into it. This means librav1e, nvenc,
>> amfenc, v4l2_m2m, and vaapi_enc.
>> I have ported librav1e both to test this set and for it to work as an example
>> for the maintainers of the other three encoders in order to get an idea of what
>> they should do.
> 
> How does performance change with these patches?

I didn't notice any performance hit.

> 
> Am I correct that this changes the "new" api which so many
> users complained about?

I'm not sure what users complained about, but this doesn't change the
public API as far as library users are concerned. It changes how it
works internally, removing the dependency it had on the old deprecated API.

> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer <jamrial@gmail.com>:
>
> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> > Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer <jamrial@gmail.com>:
> >>
> >> This set follows the same logic as 061a0c14bb, but for the encode API: The
> >> new public API will no longer be a wrapper around the old deprecated one, and
> >> the internal API used by the encoders now consists of a single receive_packet()
> >> callback that pulls frames as required.
> >>
> >> Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
> >> have been adapted, and said changes squashed into it. This means librav1e, nvenc,
> >> amfenc, v4l2_m2m, and vaapi_enc.
> >> I have ported librav1e both to test this set and for it to work as an example
> >> for the maintainers of the other three encoders in order to get an idea of what
> >> they should do.
> >
> > How does performance change with these patches?
>
> I didn't notice any performance hit.

I had hoped for a performance gain...

Sorry for asking: Did you test? They are rumours we once upon a time
changed something in libavcodec which had a huge speed impact that
was simply ignored here...

> > Am I correct that this changes the "new" api which so many
> > users complained about?
>
> I'm not sure what users complained about, but this doesn't change the
> public API as far as library users are concerned. It changes how it
> works internally, removing the dependency it had on the old deprecated API.

Thank you for the explanation!

Carl Eugen

On 2/27/2020 3:45 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer <jamrial@gmail.com>:
>>
>> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
>>> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer <jamrial@gmail.com>:
>>>>
>>>> This set follows the same logic as 061a0c14bb, but for the encode API: The
>>>> new public API will no longer be a wrapper around the old deprecated one, and
>>>> the internal API used by the encoders now consists of a single receive_packet()
>>>> callback that pulls frames as required.
>>>>
>>>> Because of the above, PATCH 2/4 can't be applied until all the relevant encoders
>>>> have been adapted, and said changes squashed into it. This means librav1e, nvenc,
>>>> amfenc, v4l2_m2m, and vaapi_enc.
>>>> I have ported librav1e both to test this set and for it to work as an example
>>>> for the maintainers of the other three encoders in order to get an idea of what
>>>> they should do.
>>>
>>> How does performance change with these patches?
>>
>> I didn't notice any performance hit.
> 
> I had hoped for a performance gain...
> 
> Sorry for asking: Did you test? They are rumours we once upon a time
> changed something in libavcodec which had a huge speed impact that
> was simply ignored here...

I did with librav1e which uses the new API callback internally, but i
just tried quickly again using mpeg2video which uses the old API
callback internally just to confirm:
./ffmpeg -framerate 24 -i ~/ToS/00%3d.png -pix_fmt yuv420p -benchmark
-c:v mpeg2video -f null -t 10 -

Before
frame=  240 fps= 88 q=31.0 Lsize=N/A time=00:00:09.95 bitrate=N/A
speed=3.65x
video:1822kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=9.922s stime=0.312s rtime=2.745s
bench: maxrss=97532kB

After
frame=  240 fps= 88 q=31.0 Lsize=N/A time=00:00:09.95 bitrate=N/A
speed=3.64x
video:1822kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=9.656s stime=0.453s rtime=2.761s
bench: maxrss=93892kB

> 
>>> Am I correct that this changes the "new" api which so many
>>> users complained about?
>>
>> I'm not sure what users complained about, but this doesn't change the
>> public API as far as library users are concerned. It changes how it
>> works internally, removing the dependency it had on the old deprecated API.
> 
> Thank you for the explanation!
> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>