Opened 8 years ago

Closed 7 years ago

#4119 closed defect (fixed)

glitchy reading of lagarith 1.3.27 streams

Reported by: Christoph Rackwitz Owned by:
Priority: normal Component: ffmpeg
Version: git-master Keywords: lagarith fps
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no


Summary of the bug: appears to decode the wrong I-frames of most recent lagarith video. also produces black frames where there were none. generally glitchy. output completely blank when choosing -c:v libx264 for this input.

How to reproduce:

% ffmpeg -i lagarith-1.3.27-black-frames-and-off-by-ones.avi -an -c:v qtrle

ffmpeg version N-66352-g33c752b Copyright (c) 2000-2014 the FFmpeg developers
  built on Sep 19 2014 23:23:41 with gcc 4.9.1 (GCC)

Attachments (3)

lagarith-1.3.27-black-frames-and-off-by-ones.avi (6.0 KB ) - added by Christoph Rackwitz 8 years ago. (585 bytes ) - added by Christoph Rackwitz 8 years ago.
lagarith-1.3.27-black-frames-and-off-by-ones.txt (2.4 KB ) - added by Christoph Rackwitz 8 years ago.

Download all attachments as: .zip

Change History (13)

by Christoph Rackwitz, 8 years ago

by Christoph Rackwitz, 8 years ago

by Christoph Rackwitz, 8 years ago

comment:1 by Christoph Rackwitz, 8 years ago

I've attached a generating python script that requests a codec picker, where Lagarith (video for windows) should be chosen.

the attached .avi file is 25fps 3.0 seconds and should be black, "frame 1", then "frame2".

the attached qtrle .mov file is the output. I see the black frame briefly. the video isn't 3.0 seconds long anymore.

the attached .txt file is a copy of the console output.

I've used the most recent nightly build from

comment:2 by Carl Eugen Hoyos, 8 years ago

Could you test the following command line? I believe the issue is not lagarith-related, FFplay also works correctly for the sample afaict.

$ ffmpeg -i lagarith-1.3.27-black-frames-and-off-by-ones.avi​ -vf fps=25 -vcodec mpeg4

comment:3 by Christoph Rackwitz, 8 years ago

ffprobe on the output: Duration: 00:00:02.04, start: 0.000000, bitrate: 133 kb/s
see attached file

comment:4 by Carl Eugen Hoyos, 8 years ago

Keywords: fps added
Resolution: duplicate
Status: newclosed
Version: unspecifiedgit-master

Your input video has three frames, all three are decoded correctly, you can test for example with:

$ ffmpeg -vsync 0 -i lagarith-1.3.27-black-frames-and-off-by-ones.avi​ out%1d.png

FFmpeg does not work very well for first / last frames of vfr video, this is covered by several other tickets, among them #1578, (more similar to this problem) #2674 and #3052. You can basically choose if you want to have a "short" first frame with -r 25 or a "short" last frame with -vf fps=25.
A patch for fps exists:
It probably fixes your issue but was not accepted yet.

comment:5 by Christoph Rackwitz, 8 years ago

I understand the problem is variable frame rate. I'd really like to have this reproduced faithfully. I can't choose between losing frames at either end. Thanks for taking a look and linking related tickets. I'll have to wait for a fix then.

comment:6 by Carl Eugen Hoyos, 8 years ago

It is possible that concatenating your input video with a single black frame works fine, I am sure it is not difficult to find a workaround.

comment:7 by llogan, 8 years ago

This was probably fixed by 9f6d48d696d679de77e8cb513d5f64cd708ed86f. Please test.

comment:8 by Carl Eugen Hoyos, 8 years ago

The duration of the last frame is still wrong with both -r and -vf fps, see tickets #2674 and #3052.

comment:9 by Carl Eugen Hoyos, 8 years ago

Resolution: duplicate
Status: closedreopened

Still reproducible after #1578 and #3052 were fixed, Michael posted a patch:

comment:10 by Carl Eugen Hoyos, 7 years ago

Component: undeterminedffmpeg
Reproduced by developer: set
Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.