mpeg2 decoder always output some redundant dummy frames for interlace videos

[Zhong,Li]

Summary of the bug:
If a mpeg2 video is a field video, ffmpeg will always insert a dummy frame when decoding the first key filed picture. And the dummy frame will be output later.
Take the attachment file (tcela-8-fp-dp.bits.mpeg2) as example, this clip has 4 frames (8 fields), but 5 frames will be output after decoding, the first output frame is a redundant dummy frame.

How to reproduce:

ffmpeg -i /root/Videos/yami_mpeg2/tcela-8-fp-dp.bits.mpeg2 -pix_fmt yuv420p /root/Videos/tcela-8-fp-dp.bits.mpeg_sw_720x480.yuv
ffmpeg version N-87349-g0426e77108 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Ubuntu 6.3.0-12ubuntu2) 20170406
  configuration: --prefix=/opt/X11R7/ --enable-vaapi --enable-libx264 --enable-libx265 --enable-gpl --disable-optimizations --enable-debug=3
  libavutil      55. 75.100 / 55. 75.100
  libavcodec     57.106.101 / 57.106.101
  libavformat    57. 82.101 / 57. 82.101
  libavdevice    57.  8.101 / 57.  8.101
  libavfilter     6.105.100 /  6.105.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpegvideo @ 0x557bd94c37e0] Estimating duration from bitrate, this may be inaccurate
Input #0, mpegvideo, from '/root/Videos/yami_mpeg2/tcela-8-fp-dp.bits.mpeg2':
  Duration: 00:00:00.15, bitrate: 15000 kb/s
    Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, bottom first), 720x480 [SAR 8:9 DAR 4:3], 15000 kb/s, 30 fps, 30 tbr, 1200k tbn, 60 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> rawvideo (native))
Press [q] to stop, [?] for help
Output #0, rawvideo, to '/root/Videos/tcela-8-fp-dp.bits.mpeg_sw_720x480.yuv':
  Metadata:
    encoder         : Lavf57.82.101
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 124416 kb/s, 30 fps, 30 tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.106.101 rawvideo
frame=    5 fps=0.0 q=-0.0 Lsize=    2531kB time=00:00:00.16 bitrate=124415.8kbits/s speed=18.1x
video:2531kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

[Carl Eugen Hoyos]

Regression since 99e07a4453732058df90885f80b3db3b4f37cb3c, I wonder if there is a relation with #3690 (which shows another commit but also grey frames).

[Carl Eugen Hoyos]

Original thread:
​http://ffmpeg.org/pipermail/ffmpeg-devel/2011-February/104559.html

[Zhong,Li]

Yes, it is a regression. I am plan to revert the commit of 99e07a4453732058df90885f80b3db3b4f37cb3c, but I can't get the clip of issue #2367 this commit try to fix.

[Carl Eugen Hoyos]

Ticket 2367 != issue 2367
​http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue2367/

[Zhong,Li]

I prefer to revert 99e07a4453732058df90885f80b3db3b4f37cb3c directly, since the sample clip ofinterlaced_mpeg2.bin is detected as wrong input and doesn't make ffmpeg crash right now.

[Carl Eugen Hoyos]

I can confirm that reverting 99e07a4 the crash with the given sample was fixed in 23daee0dcc57b647b9d62d4c905e94acf0c6b8e0

[Zhong,Li]

Patch has been sent to review.

[Carl Eugen Hoyos]

Fixed in fd7cb86468cc63b5bda203d74964584281318cda - thank you for the report and the fix!