skipping forward or reading next file fails with infinite loop

[Arthur Marsh]

I built mplayer on Linux using:

current FFMPEG git head and mplayer svn revision 37999

./configure --cc=gcc-8 --host-cc=gcc-8 --disable-ossaudio --disable-libopenjpeg --enable-debug=3;time make -j5

(I have also had the same result with gcc-7).

Attempting to play multiple flac files e.g.

mplayer -msglevel seek=9 file1.flac file2.flac

results in the first file being played but hitting an infinite loop, running gdb -p <pid> or from within gdb and hitting control-c results in backtraces like that attached.

Running

strace mplayer -msglevel seek=9 file1.flac file2.flac

results in an infinitely repeating line:

read(4, "", 4096) = 0

when the reaching the end of the first file being played.

I am not a C programmer but am happy to apply patches, test different builds and test cases.

[Arthur Marsh]

backtraces of when mplayer hangs

[Arthur Marsh]

I've also confirmed that this behaviour occurs when playing a single flac file.

[Arthur Marsh]

tried again with gcc-7 and downgraded gcc related libraries, see second attachment.

[Arthur Marsh]

second gdb backtrace

[Arthur Marsh]

after upgrading gcc-8 and associated libraries to 20171023 version and git head of FFMPEG and rebuilding, mplayer works, but when doing skips forward or simply playing a flac file to the end, I still see the error message:

Invalid return value 0 for stream protocol

[beastd]

Hi,

I am unable to reproduce the hang.

Could you try to compile latest MPlayer SVN (with FFmpeg git) and confirm that the problem still exists?

[Arthur Marsh]

latest mplayer svn built with gcc-8:

gcc-8 (Debian 8-20171102-1) 8.0.0 20171102 (experimental) [trunk revision 254334]

plays multiple flac files alright, but I see the message:

Invalid return value 0 for stream protocol

a few times at the end of playing each file.

[beastd]

I think I got this now. I had some faint memories about some related changes in FFmpeg.

The relevant commits are

1. FFmpeg commit 858db4b01f (libavformat: not treat 0 as EOF)
2. FFmpeg commit a606f27f4c (lavf/avio: temporarily accept 0 as EOF.)

AFAICT the first commit is responsible for uncovering the behavior you saw. The second mitigated it. Though it is a time bomb if I read the 2nd commit correctly.

Therefore I think we shouldn't close this bug yet and try to fix the handling inside MPlayer, so that the hangs will not reappear with the next major bumps of FFmpeg.

See also FFmpeg trac ticket 6767 .

[beastd]

The problem can be summarized as libavformat will not accept a zero return to mean eof anymore, because zero length packets can happen in datagram protocols like e.g. UDP.

This bug was at least triggered in formats that (a) use demuxer lavf and (b) use binary search for seeking. FFmpeg would try to find the last time stamp, which will usually hit EOF and our callback will not propagate AVERROR_EOF but a read length of zero which would cause lavf to go on and on.

The previous FFmpeg behavior was restored for non-datagram protocols in FFmpeg commit a606f27f4c , but that will probably disappear with the next API bump. This is why you see the "Invalid return value 0 for stream protocol" messages now.

I posted a patch to mplayer-dev-eng ML that should fix the described problem:

​http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2017-November/073661.html

[beastd]

I committed the above mentioned patch.

This issue should be fixed starting with MPlayer SVN r38006 .

The "Invalid return value 0 for stream protocol" messages should not appear anymore. Should the problem not be solved on your hand, feel free to re-open this ticket.

Thank you for reporting the issue!