Marton Balint (12020-04-11):
> The extra allocations and deallocations are barely measurable. So far
> uncoded_frame was used for realtime outputs. So you get, I don't know 100
> packets/frames per second? Allocating those is peanuts, and I have to stress
> that you are not allocating the data, jus
On Mon, 6 Apr 2020, Nicolas George wrote:
Marton Balint (12020-04-06):
The same goal can be achieved using the WRAPPED_AVFRAME codec with the existing
API.
These two APIs are somewhat redundant, but we need to discuss which one
we want to keep.
WRAPPED_AVFRAME is nice because it goes throu
Marton Balint (12020-04-06):
> The same goal can be achieved using the WRAPPED_AVFRAME codec with the
> existing
> API.
These two APIs are somewhat redundant, but we need to discuss which one
we want to keep.
WRAPPED_AVFRAME is nice because it goes through the normal code path,
and therefore req
The same goal can be achieved using the WRAPPED_AVFRAME codec with the existing
API.
Signed-off-by: Marton Balint
---
doc/APIchanges | 4
libavdevice/alsa_enc.c | 4
libavdevice/opengl_enc.c | 4
libavdevice/pulse_audio_enc.c| 4
li
