On 17/02/2018 00:57, wm4 wrote:
On Fri, 16 Feb 2018 18:02:05 +0100
Luca Barbato <lu_z...@gentoo.org> wrote:
Unbreaks the rate-control behaviour.
---
libavcodec/libx265.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index fd5452193b..73aff2caef 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -116,8 +116,8 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
ctx->params->frameNumThreads = avctx->thread_count;
- ctx->params->fpsNum = avctx->time_base.den;
- ctx->params->fpsDenom = avctx->time_base.num *
avctx->ticks_per_frame;
+ ctx->params->fpsNum = avctx->framerate.num;
+ ctx->params->fpsDenom = avctx->framerate.den *
avctx->ticks_per_frame;
ctx->params->sourceWidth = avctx->width;
ctx->params->sourceHeight = avctx->height;
ctx->params->bEnablePsnr = !!(avctx->flags & AV_CODEC_FLAG_PSNR);
Doesn't this use a potentially broken demuxer reported framerate?
(Not uncommon with mkv files at least.)
It is better than a definitely broken timebase.
Before you usually feed 1000 fps or worse, now it has at least a chance
to have a correct framerate by default.
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
