mplayer doesn't respect duration of the last frame

[hxuanyu]

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.

[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).

[beastd]

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.

[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.

[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.

[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.

[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.

[beastd]

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.