On 2/27/2020 3:45 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer :
>>
>> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
>>> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
This set follows the same logic as 061a0c14bb, but for the encode API:
Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer :
>
> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> > Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
> >>
> >> This set follows the same logic as 061a0c14bb, but for the encode API: The
> >> new public API will no longer be a
On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote:
> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
>>
>> 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
Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer :
>
> 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
>
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,
