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. > > 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-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ 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".
