Opened 14 years ago

Closed 13 years ago

#554 closed defect (remind)

Second last frame duplicated on MPEG decoding

Reported by: stefan_heinzmann@… Owned by: mans@…
Priority: normal Component: libavformat
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

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.

Attachments (4)

video393.z01 (950.0 KB) - added by stefan_heinzmann@… 14 years ago.
Zipped MPEG file with 393 frames and visible timecode, part 1
video393.z02 (950.0 KB) - added by stefan_heinzmann@… 14 years ago.
Zipped MPEG file with 393 frames and visible timecode, part 2
video393.z03 (950.0 KB) - added by stefan_heinzmann@… 14 years ago.
Zipped MPEG file with 393 frames and visible timecode, part 3
video393.zip (701.3 KB) - added by stefan_heinzmann@… 14 years ago.
Zipped MPEG file with 393 frames and visible timecode, part 4

Change History (12)

Changed 14 years ago by stefan_heinzmann@…

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

comment:1 Changed 14 years ago by stefan_heinzmann@…

Changed 14 years ago by stefan_heinzmann@…

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

comment:2 Changed 14 years ago by stefan_heinzmann@…

Changed 14 years ago by stefan_heinzmann@…

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

comment:3 Changed 14 years ago by stefan_heinzmann@…

Changed 14 years ago by stefan_heinzmann@…

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

comment:4 Changed 14 years ago by stefan_heinzmann@…

comment:5 Changed 14 years ago by mans@…

Is this still a problem?

comment:6 Changed 14 years ago by 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.

comment:7 Changed 13 years ago by diego@…

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

comment:8 Changed 13 years ago by compn

  • Resolution set to remind
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.