On Fri, Feb 16, 2018 at 9:15 PM, Luca Barbato <lu_z...@gentoo.org> wrote:
> 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. >>> >> Would be nice that the commit message is expanded, explaining what is currently broken and how this fixes it. > --- >>> 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.) >> > -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
