As this is an AV_CODEC_CAP_OTHER_THREADS decoder, threading is handled by the
underlying library. In this case, the frame delay is calculated by libdav1d
based on the values from avctx->thread_count and the private max_frame_delay
option.
Export said delay reported by the library in AVCodecContext.delay
Reviewed-by: Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When using low-latency mode, it eliminates frame reordering
and follows a one-in-one-out encoding mode
Signed-off-by: xufuji456 <839789740@qq.com>
Signed-off-by: Rick Kern <kernrj@gmail.com>
Use the next I/P/B or start code as the end of current frame.
Before the patch, extension start code, user data start code,
sequence end code and so on are treated as the start of next
frame.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The demuxer exports rawvideo, so there's no reason for the muxer to only
work with wrapped_avframe.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Not only this is information that relies on the concept of a sequence of
frames, which is completely out of place as a field in AVFrame, but there are
no known or intended uses of this field.
Signed-off-by: James Almer <jamrial@gmail.com>
Accept it and pass it through unchanged.
The standard requires that decoders ignore unknown metadata, and indeed
this is tested by some of the Argon coverage streams.
* take num_ticks_per_picture_minus_1 into account, since that is a part
of the framerate computation
* stop exporting num_ticks_per_picture_minus_1 into
AVCodecContext.ticks_per_frame, as that field is used for other
purposes (in conjunction with repeat_pict, which is not used at all by
av1)
It does no initialization anymore, except for setting
transcode_init_done - the bulk of the function is printing the
input/output maps. It also cannot fail anymore, so remove the useless
return value.
Export the corresponding flag in InputFile instead. This will allow
making the demuxer AVFormatContext private in future commits, similarly
to what was previously done for muxers.
There is no point in having a per-stream wallclock start time, since
they are all computed at the same instant. Keep a per-file start time
instead, initialized when the demuxer thread starts.