Before the patch, the method to generate DTS only works with
timebase equal to 1/fps. With timebase like 1/1000
./ffmpeg -i foo.mp4 -an -c:v h264_nvenc -enc_time_base 1/1000 bar.mp4
pts 0 dts -3
pts 160 dts 37
pts 80 dts 77
pts 40 dts 117 <-- invalid
pts 120 dts 157
pts 320 dts 197
pts 240 dts 237
pts 200 dts 277 <-- invalid
pts 280 dts 317 <-- invalid
The generated DTS can be larger than PTS, since it only reorder the
input PTS and minus the number of frame delay, which doesn't take
timebase into account. It should minus the "time" of frame delay.
9a245bd trying to fix the issue, but the implementation is incomplete,
which only use time_base.num. Then it got reverted by ac7c265b33.
After this patch:
pts 0 dts -120
pts 160 dts -80
pts 80 dts -40
pts 40 dts 0
pts 120 dts 40
pts 320 dts 80
pts 240 dts 120
pts 200 dts 160
pts 280 dts 200
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces.
Together with using the wrong size on deallocation of the
frame_data_array, this lead to a crash.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Adding 10-bit encoding support for HEVC if the input is 8-bit. In
case of 8-bit input content, NVENC performs an internal CUDA 8 to
10-bit conversion of the input prior to encoding. Currently, only
AV1 supports encoding 8-bit content as 10-bit.
Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
When Split frame encoding is enabled, each input frame is partitioned into
horizontal strips which are encoded independently and simultaneously by
separate NVENCs, usually resulting in increased encoding speed compared to
single NVENC encoding.
Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Instead, use forward declarations; and in order not to affect
any user include these headers for them, but not internally.
This has the advantage of removing implicit inclusions of these
headers from almost all files providing codecs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() accepts const uint8_t* const * as source;
lots of user have uint8_t* const * and therefore either
cast (the majority) or copy the array of pointers.
This commit changes this by adding a static inline wrapper
for av_image_copy() that casts between the two types
so that we do not need to add casts everywhere else.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
nvenc_store_frame_data() is always called with frame != NULL
(checked at the beginning of nvenc_send_frame());
in fact, frame is dereferenced unconditionally after the block
guarded by the check for frame. Therefore Coverity complains
about this in issue #1538295.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When intra_refresh is enabled, gopLength is equal to
NVENC_INFINITE_GOPLENGTH. gopLength should be 1 at least.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Default GOP size is now set by preset and tuning info. This GOP size is only overwriten if -g value is provided.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The implementation is flawed in that the frame opaque data is not in
fact correctly reordered along with the packets, but is being output in
packet input order, just like the dts are.
This reverts commit 3553809703.
This reverts commit 9a245bdf5d.
This commit basically broke all samples with fractional framerates,
rather than fixing them.
I at this point do not understand the original issue anymore, and I'm
not sure how this slipped my initial testing.
All my test samples must have happened to have a simple timebase.
The actual dts values pretty much always are just a simple chain of
1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means
an advance in time by one unit of the timebase.
So a fractional framerate/timebase is already not an issue.
So with this patch applied, the calculation might end up substracting
huge values (1001 is a common one) from the dts, which would be an
offset of that many frames, not of that many fractions of a second.
This broke at least muxing into mp4, if the sample happened to have a
fractional framerate.
I do not thing the original issue this patch tried to fix existed in the
first place, so it can be reverted without further consequences.
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
When using fractional framerates (or any fraction with a numerator != 1),
DTS values for packets would be calculated incorrectly.
Signed-off-by: Kyle Manning <tt2468@irltoolkit.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
dts != pts is actually a spec violation for AV1, given it has no
reordering in the classical sense.
We don't really need the whole timestamp queue in this case and can just
pass through the timestamp as is for both dts and pts.
The encoder seems to be trading blows with hevc_nvenc.
In terms of quality at low bitrate cbr settings, it seems to
outperform it even. It produces fewer artifacts and the ones it
does produce are less jarring to my perception.
At higher bitrates I had a hard time finding differences between
the two encoders in terms of subjective visual quality.
Using the 'slow' preset, av1_nvenc outperformed hevc_nvenc in terms
of encoding speed by 75% to 100% while performing above tests.
Needless to say, it always massively outperformed h264_nvenc in terms
of quality for a given bitrate, while also being slightly faster.
nvenc does not appear to use these values as inputs for its built in RGB
to YUV conversion, but instead sets them on the output as-is.
Testing indicates the input is expected to be sRGB, with the output
ending up as limited range bt.470.
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
