This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding 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.
amf encoders adapted by James Almer
librav1e encoder adapted by James Almer
nvidia encoders adapted by James Almer
MediaFoundation encoders adapted by James Almer
vaapi encoders adapted by Linjie Fu
v4l2_m2m encoders adapted by Andriy Gelman
Signed-off-by: James Almer <jamrial@gmail.com>
The h264_nvenc and hevc_nvenc encoders aren't respecting the framerate in the codec context.
Instead it was using the timebase which in our use-case was 1/1000 so the encoder was behaving
as if we wanted 1000fps. This resulted in poor encoding results due to an extremely low bitrate.
Both the amf and qsv encoders already contain similar logic to first check the framerate before
falling back to the timebase.
Signed-off-by: Zachariah Brown <zachariah@renewedvision.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The old approach used some highly complex delta computation math and
output-delaying.
I do not remember what the initial reasoning behind that was, but given
that we can just offset the dts by the amount of bframes, it seems wholy
unnecessary.
This leaves open an issue with VFR content, for which some more complex
logic might be needed.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This reverts nvenc to old behaviour, which in some super rare edge cases
performs better.
The implication of this is that any potential API user who relies on
nvenc cleaning up every frames device resources after it's done using
them will have to change their usage pattern.
That should not be a problem, since pretty much every normal usage
pattern automatically implies that surfaces are reused from a common
pool, since constant re-allocation is also very expensive.
We have a pattern of wrapping CUDA calls to print errors and
normalise return values that is used in a couple of places. To
avoid duplication and increase consistency, let's put the wrapper
implementation in a shared place and use it everywhere.
Affects:
* avcodec/cuviddec
* avcodec/nvdec
* avcodec/nvenc
* avfilter/vf_scale_cuda
* avfilter/vf_scale_npp
* avfilter/vf_thumbnail_cuda
* avfilter/vf_transpose_npp
* avfilter/vf_yadif_cuda
This reverts commit 7d4e1f7cfb.
Accidentially pushed this with a batch of other patches, and it didn't
seem to break anything, so I went with it.
Except it does, so reverting it it is.
The patch enables dynamic bitrate through ReconfigureEncoder method
from nvenc API.
This is useful for live streaming in case of network congestion.
Signed-off-by: pkviet <pkv.stream@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
If there is input like DVB-T streams it can change aspect ratio
on-the-fly, so nvenc should respect this change and change aspect ratio
in encoder.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
nvenc doesn't support P016, but we have two problems today:
1) We declare support for YUV444P16 which nvenc also doesn't support.
We do this because it's the only pix_fmt we have that can
approximate nvenc's internal format that is YUV444P10 with data in
MSBs instead of LSBs. Because the declared format is a 16bit one,
it will be preferrentially chosen when encoding >10bit content,
but that content will normally be YUV420P12 or P016 which should
get mapped to P010 and not YUV444P10.
2) Transcoding P016 content with nvenc should be possible in a pure
hardware pipeline, and that can't be done if nvenc doesn't say it
accepts P016. By mapping it to P010, we can use it, albeit with
truncation. I have established that swscale doesn't know how to
dither to 10bits so we'd get truncation anyway, even if we tried
to do this 'properly'.
Currently the resource is only ever unregistered when the
registered_frames array is fully in use and an unmapped entry is re-used
and cleaned up.
I'm pretty sure the frame will have been cleaned up before that happens,
so I'm kinda surprised this never blew up.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
If some logic like vsync in ffmpeg.c duplicates frames, it might pass
the same frame twice, which will result in a crash due it being
effectively mapped and unmapped twice.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
In function process_output_surface(), the return value is 0 on the path
that av_mallocz() returns a NULL pointer. 0 indicates success, which
deviates from the fact. Return "AVERROR(ENOMEM)" instead of "0".
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Interlaced encoding profits from it, or might even need it in some
players.
No harm in enabling it unconditionally.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
