Opened 7 years ago

Closed 7 years ago

#2335 closed defect (fixed)

skipping forward or reading next file fails with infinite loop

Reported by: Arthur Marsh Owned by: beastd
Priority: normal Component: demuxer
Version: unspecified Severity: blocker
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: yes Analyzed by developer: yes

Description

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.

Attachments (2)

20171029-mplayer.log (13.1 KB ) - added by Arthur Marsh 7 years ago.
backtraces of when mplayer hangs
20171029-2-mplayer.log (14.1 KB ) - added by Arthur Marsh 7 years ago.
second gdb backtrace

Download all attachments as: .zip

Change History (11)

by Arthur Marsh, 7 years ago

Attachment: 20171029-mplayer.log added

backtraces of when mplayer hangs

comment:1 by Arthur Marsh, 7 years ago

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

comment:2 by Arthur Marsh, 7 years ago

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

by Arthur Marsh, 7 years ago

Attachment: 20171029-2-mplayer.log added

second gdb backtrace

comment:3 by Arthur Marsh, 7 years ago

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

comment:4 by beastd, 7 years ago

Status: newopen

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?

comment:5 by Arthur Marsh, 7 years ago

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.

comment:6 by beastd, 7 years ago

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 .

comment:7 by beastd, 7 years ago

Reproduced by developer: set

comment:8 by beastd, 7 years ago

Analyzed by developer: set
Component: undetermineddemuxer

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

comment:9 by beastd, 7 years ago

Resolution: fixed
Status: openclosed

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!

Note: See TracTickets for help on using tickets.