[MPlayer-dev-eng] Strange behavior with audio delayed video files

[Reimar Döffinger]

On Fri, Feb 21, 2014 at 11:47:35AM +0100, Ingo Brückl wrote:
> Reimar Döffinger wrote on Fri, 21 Feb 2014 08:38:10 +0100:
> 
> > On 21 February 2014 00:19:25 CET, "Ingo Brückl" <ib at wupperonline.de>
> > wrote:
> >>Reimar Döffinger wrote on Thu, 20 Feb 2014 21:21:49 +0100:
> >>
> >>> On Thu, Feb 20, 2014 at 07:29:50PM +0100, Ingo Brückl wrote:
> >>>> When I use FFmpeg (ffmpeg -i file.mkv -itsoffset 60 -i file.mkv
> >>-codec copy
> >>>> -map 0:v -map 1:a sync.mkv) to adjust an audio delay (60 seconds in
> >>this
> >>>> example) I'm experiencing a strange behavior with MPlayer playback.
> >>The audio
> >>>> firstly starts at the very beginning as if no delay had been set.
> >>When I jump
> >>>> back to the beginning, it runs silent until 60 seconds have been
> >>played, and
> >>>> every seeking is OK, i.e. the audio is in sync now.
> >>>>
> >>>> So, is the first playback with immediate audio a MPlayer bug?
> >>
> >>> MPlayer always plays audio right from the start.
> >>> I guess you could call that a bug, [...]
> >>
> >>I would do so, if audio timestamps say that it should play only later.
> 
> > That is a feature that is rarely used, and in general rarely useful, [...]
> 
> Well, I won't insist,

I have nothing against it, at least optional.
I just don't expect that you will find a solution that I don't see
issues with - not enough to be against it, but enough to not have
much enthusiasm about it.
But my lack of enthusiasm should not hinder you if it's something you
care about.

> but I what I don't understand: While audio starts at
> the beginning when playback starts, it is immediately silent after pressing
> "skip back", i.e. MPlayer does know about and does follow the delayed audio
> information, but only after (the first) seeking. Why is that?

MPlayer know about it all the time, as you should see from the A-V
printout.
Since the audio playback is already started however the only way to
fix it is playing the video faster.
This might fail due to video decoding not being fast enough.
However mostly it is limited intentionally. That intentional
limit is adjustable with the -mc option.
Oh, and concerning ways to fix it: one very simple way is to just pause
the ao when A-V becomes too large.
Pro: It also helps with other issues, e.g. when video decoding is
much too slow or on seeking in badly interleaved files
Contra: It won't work that well for this case, since it will
start playing a short bit and then stop, and it also will
have to read the audio from the file first, thus causing
the buffering issue.