[FFmpeg-trac] #7922(avcodec:new): Encoding with h264_amf, muxing in MP4, missing reference frame when seeking within 2nd and 3rd GOP

[FFmpeg]

#7922: Encoding with h264_amf, muxing in MP4, missing reference frame when seeking
within 2nd and 3rd GOP
-----------------------------------+----------------------------------
             Reporter:  lveilleux  |                     Type:  defect
               Status:  new        |                 Priority:  normal
            Component:  avcodec    |                  Version:  4.1
             Keywords:             |               Blocked By:
             Blocking:             |  Reproduced by developer:  0
Analyzed by developer:  0          |
-----------------------------------+----------------------------------
 Summary of the bug:
 I created a directshow filter that calls FFMPEG APIs to encode  using
 h264_nvenc, h264_amf, h264_qsv and Xvid, then mux in MP4. It tries opening
 the encoders in that order, if it fails it moves on to the next one. I
 also tested with libx264, but did not include it in release build since I
 have not procured a commercial license for x264.

 When running on a computer with compatible AMD card, it encodes using
 H264_AMF, but the resulting MP4 has problems seeking. If I seek within the
 2nd or 3rd GOP, a reference frame is missing on some media players. Latest
 VLC and WMP work fine, some older versions of WMP shows the problem, and
 all directshow splitters I tried (LAV Splitter, GDCL MPEG4 Demuxer, Haali
 Media Splitter) have this problem. The same code shows no seeking problem
 when using H264_NVENC, H264_QSV or LIBX264 codecs.

 This is the code that initializes the codec (for h264_amf, with some hard-
 coded parameters). Although I initialize at 30fps, it uses variable frame
 rate with timestmps coming from directshow IMediaSample.

 AVCodec *videoCodec = avcodec_find_encoder_by_name("h264_amf");

 m_c = avcodec_alloc_context3(videoCodec);
 if (!(m_c)) return -1;

 m_c->width = 1920;
 m_c->height = 1080;
 m_c->gop_size = 100;
 m_c->bit_rate = 8M;
 m_c->time_base.den = 90000;
 m_c->time_base.num = 3000;
 m_c->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
 m_c->pix_fmt = AV_PIX_FMT_YUV420P;

 av_opt_set(m_c->priv_data, "rc", "cqp", 0);
 av_opt_set_int(m_c->priv_data, "qp_i", 30, 0);
 av_opt_set_int(m_c->priv_data, "qp_p", 30, 0);
 av_opt_set_int(m_c->priv_data, "qp_b", 30, 0);
 ret = avcodec_open2(m_c, videoCodec, NULL);

 ffmpeg version: Windows x64, nightly build from 12 March 2019

 I tried different settings/options, and the only way I am able to avoid
 this seeking problem is to force only 1 reference frame (m_c->refs = 1).
 But that results in bitrate/file size 3-4 times larger than if I leave
 m_c->refs to default. This is a little overkill to avoid seeking problem
 that only appear in 2nd and 3rd GOPs.

 I attached a short desktop capture video that shows this (remember, some
 latest media players read it fine but none of the "popular" directshow MP4
 demuxers). Average framerate is ~20.6fps and GOP is 100, so the 2nd and
 3rd GOPs are ~5 to 14 seconds into the video.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7922>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker