[MPlayer-dev-eng] [PATCH]libmpdemux: Increase MAX_PACK_BYTES

[Reimar Döffinger]

On Wed, Mar 09, 2016 at 04:08:25PM +0000, Carl Eugen Hoyos wrote:
> Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > Ok, I probably found the cause for it, it looks like
> > FFmpeg and MPlayer disagree on when audio and video
> > are in sync and thus (from MPlayer's point of view)
> > not only interleaves rarely but actually interleaves
> > wrongly.
> > The file plays fine for me if I use
> > -speed 0.5 -delay -1
> 
> I can reproduce this but I suspect -delay -1 has 
> very bad effects, so there has to be a bug somewhere, 
> or am I wrong?

Maybe. It is very suspicious that a lot of the initial
audio packets all have a timestamp of 0, so maybe something
is wrong in the timestamps FFmpeg picks for them.
But if not, the file is simply horribly interleaved, with
video stored ahead of audio, causing the need to buffer
massive amount of video.
It could be worked around if the FFmpeg demuxer could be
force to return a audio packet next, but at these bit-rates
that probably would just lead to issues with I/O unless the
computer has several 100MB of RAM available to cache it all
(and maybe even then).
I have not checked if in the case of uncompressed audio
we maybe also read a bit too far ahead in the audio stream.
As a band-aid I would suggest expanding the meaning of
the -ni option to also cover this case, as in attached
patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: more_ni.diff
Type: text/x-diff
Size: 3273 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20160309/ec36eb1c/attachment.diff>