[MPlayer-users] help needed, mplayer repeats audio frames at the end of video

[David Bolen]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> Your patch only works for any looping after the AO uninit was called, which
> seems to happen with very few drivers only as nobody has reported that
> yet (which drivers do you use?).

Not sure if by drivers you mean mplayer or Windows.  On the mplayer
side, for me, it's only ever shown up with ao_dsound.  I first ran into
it in 2009 (when I did report and try patching it but misunderstood how
the DirectSound API worked), and fell back to working with ao_win32
instead.

As for system sound drivers, I believe I've had it happen with both
Intel and Realtek, on both XP and Windows 7.  Always onboard video.  I
also have some Conexant systems but not sure I ever tested on them.
It's a while back, but the problem files if played through Windows Media
Player were fine on the same systems.

I will say that my problem files are just a tiny portion of my media, so
the vast majority has no problem.  The ones I do have are locally
generated animations and/or special effects.  So maybe the problem
source files just aren't that common overall.

> The issue here is that it will loop for as much time as the video is
> longer than audio, which in theory could be hours.

Hmm, I don't think it should, at least not once uninit is called.  I'm
only looping long enough to exhaust the playable portion of the ring
buffer (through write_offset).  It's just that there's no way to
explicitly trigger or wait for that exact point (that I found), so I
fell back to the polling loop.  The silence was then because polling was
inherently imprecise.

> As for your patch, calling IDirectSoundBuffer_GetStatus is pointless
> after your changes as you always use DSBPLAY_LOOPING flag, so it
> should always report as playing.

But playing is stopped (IDirectSoundBuffer_stop) once the wait loop
exits.  The original final GetStatus loop to then to exhaust any last
bit of audio.  If I recall, without it the audio was sometimes truncated,
probably due to buffering within the system or audio driver itself.

> Also a easier "solution" might be to just not loop at all but use
> a fixed "usec_sleep(get_delay() * 1000 * 1000);" instead, possibly
> with a tiny bit of 0 padding.

I thought so too initially, but it's hard to get the timing right, or at
least it was for me.  I would still end up with artifacts right at the
end (hard to remember, but I don't think full loops but still very
audible glitches) or truncation if the timing is cut too tight.

So then the tricky part is padding away the glitch - but you could have
a completely full ring buffer when you start, in which case it's not
safe to pad anything up front until some of it has been processed.
Which then leads you to needing to wait for at least some room to free
up, which leads back to a polling loop again, or at least special case
handling of the full or nearly full buffer case.

BTW, I wasn't necessarily suggesting that this needs to be accepted as a
mainline patch (its crudeness is one of the reasons I hadn't submitted
it at the time), but was just offering it as a possible workaround for
the OP while awaiting a better solution.

-- David