On Mon, May 16, 2016 at 4:29 AM, Anton Khirnov <[email protected]> wrote: > From: Philip Langdale <[email protected]> > > For reasons we are not privy to, nvidia decided that the nvenc encoder > should apply aspect ratio compensation to 'DVD like' content, assuming that > the content is not bt.601 compliant, but needs to be bt.601 compliant. In
nit: capital BT > this context, that means that they make the following, questionable, > assumptions: > > 1) If the input dimensions are 720x480 or 720x576, assume the content has > an active area of 704x480 or 704x576. > > 2) Assume that whatever the input sample aspect ratio is, it does not account > for the difference between 'physical' and 'active' dimensions. > > From, these assumptions, they then conclude that they can 'help', by adjusting extra , > the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to > display only the 704 wide active area with the same aspect ratio as the full > 720 wide image - this would be the correct adjustment factor, but what if you > don't? And more importantly, what if you're used to ffmpeg not making this > kind "ffmpeg or avconv" > of adjustment at encode time - because none of the other encoders do this! > > And, what if you had already accounted for bt.601 and your input had the nit: capital BT > correct attributes? Well, it's going to apply the compensation anyway! > So, if you take some content, and feed it through nvenc repeatedly, it > will keep scaling the aspect ratio every time, stretching your video out > more and more and more. > > So, clearly, regardless of whether you want to apply bt.601 aspect ratio ditto > adjustments or not, this is not the way to do it. With any other ffmpeg s/ffmpeg/libavcodec/ > encoder, you would do it as part of defining your input paramters or parameters > do the adjustment at playback time, and there's no reason by nvenc > should be any different. > > This change adds some logic to undo the compensation that nvenc would > otherwise do. > > nvidia engineers have told us that they will work to make this > compensation mechanism optional in a future release of the nvenc > SDK. At that point, we can adapt accordingly. > > Signed-off-by: Philip Langdale <[email protected]> > Reviewed-by: Timo Rothenpieler <[email protected]> > Signed-off-by: Anton Khirnov <[email protected]> > --- > libavcodec/nvenc.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index 21b8f25..327d1f0 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > @@ -744,6 +744,15 @@ static int nvenc_setup_encoder(AVCodecContext *avctx) > ctx->params.darWidth = avctx->width; > } > > + // De-compensate for hardware, dubiously, trying to compensate for > + // playback at 704 pixel width. > + if (avctx->width == 720 && (avctx->height == 480 || avctx->height == > 576)) { > + av_reduce(&ctx->params.darWidth, &ctx->params.darHeight, > + ctx->params.darWidth * 44, > + ctx->params.darHeight * 45, > + 1024 * 1024); > + } > + > ctx->params.frameRateNum = avctx->time_base.den; > ctx->params.frameRateDen = avctx->time_base.num * avctx->ticks_per_frame; > > -- -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
