#2335 closed defect (fixed)

skipping forward or reading next file fails with infinite loop

Reported by: quackslikea 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 quackslikea 19 months ago.
backtraces of when mplayer hangs
20171029-2-mplayer.log (14.1 KB) - added by quackslikea 19 months ago.
second gdb backtrace

Download all attachments as: .zip

Change History (11)

Changed 19 months ago by quackslikea

backtraces of when mplayer hangs

comment:1 Changed 19 months ago by quackslikea

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

comment:2 Changed 19 months ago by quackslikea

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

Changed 19 months ago by quackslikea

second gdb backtrace

comment:3 Changed 19 months ago by quackslikea

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 Changed 19 months ago by beastd

  • Status changed from new to open

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 Changed 19 months ago by quackslikea

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 Changed 19 months ago by 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 .

comment:7 Changed 19 months ago by beastd

  • Reproduced by developer set

comment:8 Changed 19 months ago by beastd

  • Analyzed by developer set
  • Component changed from undetermined to demuxer

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 Changed 18 months ago by beastd

  • Resolution set to fixed
  • Status changed from open to closed

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.