My source video is MPEG-2, 720x576, DAR=16:9. Using FFmpeg and the h264_nvenc encoder, I convert it to H.264. The problem: The output AR is strange/wrong/incosistent. Command line:

>ffmpeg -i "d:\in.mpg" -aspect 16:9 -c:v h264_nvenc -c:a copy -t 15 "d:\out.mp4"
ffmpeg version N-83280-gcba4f0e Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 5.4.0 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
  libavutil      55. 45.100 / 55. 45.100
  libavcodec     57. 75.100 / 57. 75.100
  libavformat    57. 65.100 / 57. 65.100
  libavdevice    57.  2.100 / 57.  2.100
  libavfilter     6. 71.100 /  6. 71.100
  libswscale      4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc    54.  2.100 / 54.  2.100
[mpeg @ 000000000223ab20] start time for stream 0 is not set in estimate_timings_from_pts
Input #0, mpeg, from 'd:\in.mpg':
  Duration: 02:59:33.92, start: 0.500000, bitrate: 3401 kb/s
    Stream #0:0[0x1bf]: Data: dvd_nav_packet
    Stream #0:1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s
    Stream #0:2[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
File 'd:\out.mp4' already exists. Overwrite ? [y/N] y
Output #0, mp4, to 'd:\out.mp4':
    encoder         : Lavf57.65.100
    Stream #0:0: Video: h264 (h264_nvenc) (Main) ([33][0][0][0] / 0x0021), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=-1--1, 2000 kb/s, 25 fps, 12800 tbn, 25 tbc
      encoder         : Lavc57.75.100 h264_nvenc
    Side data:
      cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: -1
    Stream #0:1: Audio: mp2 (i[0][0][0] / 0x0069), 48000 Hz, stereo, s16p, 192 kb/s
Stream mapping:
  Stream #0:2 -> #0:0 (mpeg2video (native) -> h264 (h264_nvenc))
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=  375 fps=0.0 q=22.0 Lsize=    4122kB time=00:00:14.97 bitrate=2254.9kbits/s dup=19 drop=0 speed=28.9x
video:3762kB audio:352kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.208697%

For the output video stream, it says "[SAR 64:45 DAR 16:9]", however, if I analyze the resulting out.mp4, it says:

Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 720x576 [SAR 16:11 DAR 20:11], 2054 kb/s, SAR 64:45 DAR 16:9, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)

The values after the square brackets are correct, but inside the brackets, I don't know why it uses these DAR/SAR values. Depending on which values are used (container or stream AR) by the player later, the result can be wrong. It doesn't matter if "-aspect 16:9" is used or not.

If I use libx264 instead of h264_nvenc, the output AR is correct, so I think it's an encoder issue. I was using the latest build, but before, I've used official releases 3.2 and 3.2.2

I'm surprised I didn't find the same issue reported anywhere yet, so before reporting this as a bug, I'd like to ask for your opinion if I'm doing something wrong. Thanks.

  • Was the behavior different with older builds (such as the release versions)? – llogan Feb 1 '17 at 17:49
  • No, that's why I've tried the latest build to see if it might have been fixed meanwhile. – user674865 Feb 1 '17 at 18:24
  • If you add -vf setdar=16:9, does that avoid the problem? – Gyan Feb 1 '17 at 19:39
  • Thanks for the hint. No, it doesn't change the result. Even if I specify "-aspect 4:3", the stream DAR is 20:11.However, if I specify "-vf setdar=4:3", the resulting stream DAR is 15:11. Probably it takes the input DAR into account, but I think if 16:9 is the explicit target DAR, there must not be a deviation from it. – user674865 Feb 1 '17 at 20:46
  • Interesting: If I prepend the scale filter, the AR set is being set correctly. But this only works if I really change the size, i.e. if I set the destination size equal to the input size 720x576, setting the DAR does not have an effect. – user674865 Feb 1 '17 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy