[MPlayer-users] rtmp stream problems - large GOP

[Karoly Horvath]

Hi,

> It's been some time, but still.
> Do you still have this issue?

yes, I still have the issue.

> I tried a few times and it seems to work fine.

Hmm.. that's weird. I just tried it with the latest SVN snapshot, and
I see the same problem. very often.

ds_fill_buffer: EOF reached (stream: video)
A:   0.5 V:   0.0 A-V:  0.472 ct: -0.000   0/  0 ??% ??% ??,?% 46787 0
ds_fill_buffer: EOF reached (stream: video)
A:   0.5 V:   0.0 A-V:  0.472 ct: -0.000   0/  0 ??% ??% ??,?% 46788 0
ds_fill_buffer: EOF reached (stream: video)
A:   0.5 V:   0.0 A-V:  0.472 ct: -0.000   0/  0 ??% ??% ??,?% 46789 0

I don't know whether it matters, I tested this now with: -vo null -ao
pcm:fast  (I'm on a text console).

What I managed to figure out, and could be a big clue:
If I set the fps to a sufficiently large value (eg: -fps 300), it
works _all_ the time.
Obviously it kills the A-V synchronisation... but... it looks like
mplayer normally gives up looking for the next key frame, but with a
large fps it waits enough to find one... or at least that's how I
interpret the results.

Again, I'm not sure how you didn't manage to reproduce the problem,
it's quite consistent (happens about once from 3 or 4 tries). Have you
checked the first link?

> Using different -cache options might make a slight difference,
> and you can set the -msglevel so the message isn't printed, but
> if MPlayer gets stuck that is probably a bug that can only
> be fixed by changing the code.

Message appears only with added verbosity, and that's fine.
I would like to fix the bug, but I'm only familiar with some parts of
the app (stream handler, little bit of demux, a/v filters, ...) and
the problem manifests some layers below and I'm not sure where (and
why) it originated.

Cheers,

-- 
Karoly