Second last frame duplicated on MPEG decoding

[stefan_heinzmann@…]

The ffmpeg application duplicates the second last frame when reading some mpeg
files (example attached). For example, the following output from an ffmpeg run
shows that 394 frames have been extracted from the attached file which only
holds 393 frames (see timecode visible in the pictures).

ffmpeg output from the following command: ffmpeg -i 393.mpg -f image2 'img%03d.jpg'
========================================================
FFmpeg version SVN-r5991, Copyright (c) 2000-2004 Fabrice Bellard

configuration: --disable-strip --disable-opts --disable-mmx
libavutil version: 49.0.0
libavcodec version: 51.11.0
libavformat version: 50.5.0
built on Aug 13 2006 17:58:38, gcc: 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)

Input #0, mpeg, from '393.mpg':

Duration: 00:00:14.8, start: 0.220000, bitrate: 2065 kb/s
Stream #0.0[0x1e0]: Video: mpeg1video, yuv420p, 720x576, 1700 kb/s, 25.00 fps(r)
Stream #0.1[0x1c0]: Audio: mp2, 44100 Hz, stereo, 224 kb/s

Output #0, image2, to 'img%03d.jpg':

Stream #0.0: Video: mjpeg, yuvj420p, 720x576, q=2-31, 200 kb/s, 25.00 fps(c)

Stream mapping:

Stream #0.0 -> #0.0

[mjpeg @ 0x83c7978]removing common factors from framerate
Press [q] to stop encoding
frame= 394 q=24.8 Lsize= 0kB time=15.8 bitrate= 0.0kbits/s
video:5968kB audio:0kB global headers:0kB muxing overhead -100.000000%
===============================================================

The problem is reproducible also on Windows/MinGW, and it is in the libraries,
not the ffmpeg application.

[stefan_heinzmann@…]

Zipped MPEG file with 393 frames and visible timecode, part 1

[stefan_heinzmann@…]

Zipped MPEG file with 393 frames and visible timecode, part 2

[stefan_heinzmann@…]

Zipped MPEG file with 393 frames and visible timecode, part 3

[stefan_heinzmann@…]

Zipped MPEG file with 393 frames and visible timecode, part 4

[mans@…]

Is this still a problem?

[stefan_heinzmann@…]

I can't say at the moment because we've frozen ffmpeg in our project at svn
revision 5992 in order to avoid further trouble right now. We will eventually
catch up again and retest, and also possibly contribute a couple of patches
unless the situation has rectified itself in the meantime.

[diego@…]

Is this still a problem? Otherwise we should close it.

[compn]

closing all ffmpeg bugs
please use ffmpeg roundup tracker for ffmpeg bugs now