[MPlayer-users] rtmp stream problems - large GOP

[Reimar Döffinger]

On Mon, Aug 12, 2013 at 04:44:52PM +0100, Karoly Horvath wrote:
> 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).

Yes it matter, since the hang bug could only happen with -ao pcm.
Since I didn't know you were using -ao pcm I of course couldn't
reproduce.

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

That's more or less because it messes up A-V sync.
The issue was with -ao pcm's code that tried to keep sync.
A simpler solution would probably have been to use -novideo though...

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

Actually the issue was a few layers above, in the A-V sync code
(well, depending on how you see it you could also say that ao_pcm
isn't exactly robust, though I also admit I am not 100% sure it
couldn't cause issues even without ao_pcm).