Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer <jamr...@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 <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
