Opened 2 years ago

Closed 2 years ago

#2315 closed defect (fixed)

mplayer doesn't respect duration of the last frame

Reported by: hxuanyu Owned by: beastd
Priority: normal Component: undetermined
Version: unspecified Severity: blocker
Keywords: Cc: reimar
Blocked By: Blocking:
Reproduced by developer: yes Analyzed by developer: yes

Description

This issue is reproducible on mplayer, version sherpya-r37905+g1f5630a-6.2.1 on Win10 64bit.

This is the video file to be played ​​https://dl.dropboxusercontent.com/u/89678527/testsmall_video.mp4

It has a duration of 4:30, it's variable frame rate, having a frame at 3:00, duration 30 seconds, last frame at 3:30, duration 60 seconds.

This file plays correctly in MPV, staying at 3:00 for 30 seconds, and then stays at 3:30 for 60 seconds, then player exits.

But when played in mplayer, it stays at 3:00 for 30 seconds, then shows frame at 3:30 and finishes playing immediately. The last frames does't stay on the screen for 60 seconds.

Attachments (4)

test-long-frames.mp4 (13.6 KB) - added by beastd 2 years ago.
test-long-frames.mkv (13.5 KB) - added by beastd 2 years ago.
test-long-frames.nut (13.1 KB) - added by beastd 2 years ago.
test-long-frames.avi (18.5 KB) - added by beastd 2 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 2 years ago by hxuanyu

Actually it's not only a problem for vfr video. I have a constant frame rate MP4 here:
https://dl.dropboxusercontent.com/u/89678527/cfr.mp4

Every frame is 4 seconds long, but once the last frame is shown, player immediately stops playback (instead of showing it for 4 seconds).

Changed 2 years ago by beastd

Changed 2 years ago by beastd

Changed 2 years ago by beastd

Changed 2 years ago by beastd

comment:2 Changed 2 years ago by beastd

  • Reproduced by developer set
  • Status changed from new to open

I have attached a bunch of small samples generated with ffmpeg.

I used below command line for different container formats.

ffmpeg -filter_complex 'testsrc,fps=1/5:round=up' -frames 2 -q 3 -c mpeg4 -pix_fmt yuv420p /home/beastd/unsorted/test-long-frames.mp4

Except for the .mkv mpv plays all samples with the expected timing.

comment:3 Changed 2 years ago by beastd

  • Summary changed from can't play last frame on a VFR MP4 file to mplayer doesn't respect duration of the last frame

comment:4 Changed 2 years ago by beastd

When playing the attached samples with mplayer using different VOs (gl, xv, vdpau, sdl, x11) the frames shown are different, but the last frame duration is never respected.

comment:5 follow-up: Changed 2 years ago by reimar

I'm sorry, but this ticket has become completely confused.
I just sent a patch that as far as I can tell fixes all your nice simple examples (including cfr.mp4).
I don't think it does anything (or at least not the right thing) for the original sample, so I think all the samples you created are for something else...
Also I can't match the problem description quite up with how the first sample plays for me.
As far as I can tell, the frame that should display at 3:30 is displayed instead at 3:00, but for 90 seconds (thus the overall timing is ok).
But as I don't know for sure what it SHOULD look like, can't even say for certain what is wrong.

comment:6 in reply to: ↑ 5 Changed 2 years ago by beastd

Replying to reimar:

I'm sorry, but this ticket has become completely confused.

I am not sure about that yet. Though the first sample seems two have different issues even if the symptoms were similar. I think we agree on that.

I just sent a patch that as far as I can tell fixes all your nice simple examples (including cfr.mp4).

I can confirm that. For all except the first sample the timing is good with your patch. Though some VOs still do not display the first frame for me.

I don't think it does anything (or at least not the right thing) for the original sample, so I think all the samples you created are for something else...
Also I can't match the problem description quite up with how the first sample plays for me.
As far as I can tell, the frame that should display at 3:30 is displayed instead at 3:00, but for 90 seconds (thus the overall timing is ok).
But as I don't know for sure what it SHOULD look like, can't even say for certain what is wrong.

Well I guess the symptoms might materialize in different ways under different circumstances. At least I can confirm that the wrong frame is displayed for a long time first. In my case though it was for 30s (IIRC) and that only after applying your patch.

Without your patch it shows the correct frame for 30s but the following one only for a really really short time, thus matching the description of the bug reporter.

comment:7 Changed 2 years ago by beastd

  • Cc reimar added

comment:8 Changed 2 years ago by beastd

After testing with your v2 patch set:

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2017-March/thread.html#73572

[PATCH 1/2] mplayer.c: Fix timing of first frame.
[PATCH 2/2] timing: pass through endpts and time

Things look quite good!

One thing that still is strange and may not be be related to the timing problem:

When I test here with vo gl, vdpau, sdl, xv, and x11 only vdpau actually shows the first frame. Can be seen here easily with the samples I uploaded or the cfr.mp4 from the bug reporter.

comment:9 Changed 2 years ago by beastd

  • Analyzed by developer set
  • Resolution set to fixed
  • Status changed from open to closed

Should be fixed in MPlayer SVN with revisions r37935 and r37936 .

If there are still problems with the samples you posted (for me they are OK now), please re-open this bug.

Thank you for the reporting these timing issues.

Note: See TracTickets for help on using tickets.