Opened 5 years ago

Closed 4 years ago

#4119 closed defect (fixed)

glitchy reading of lagarith 1.3.27 streams

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

Description

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 lagarith-1.3.27-black-frames-and-off-by-ones.mov

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)

Change History (13)

comment:1 Changed 5 years ago by cracki

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 http://ffmpeg.zeranoe.com/builds/.

comment:2 Changed 5 years ago by cehoyos

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 out.mov

comment:3 Changed 5 years ago by cracki

ffprobe on the output: Duration: 00:00:02.04, start: 0.000000, bitrate: 133 kb/s
see attached file comment-2.mov

comment:4 Changed 5 years ago by cehoyos

  • Keywords fps added
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version changed from unspecified to git-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:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/180754/focus=180758
It probably fixes your issue but was not accepted yet.

comment:5 Changed 5 years ago by cracki

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 Changed 5 years ago by cehoyos

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 Changed 5 years ago by llogan

This was probably fixed by 9f6d48d696d679de77e8cb513d5f64cd708ed86f. Please test.

comment:8 Changed 5 years ago by cehoyos

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

comment:9 Changed 5 years ago by cehoyos

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Still reproducible after #1578 and #3052 were fixed, Michael posted a patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2014-November/165583.html

comment:10 Changed 4 years ago by cehoyos

  • Component changed from undetermined to ffmpeg
  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.