[MPlayer-dev-eng] [PATCH] af_skip to skip first audio samples

[Uoti Urpala]

On Thu, 2006-08-17 at 22:13 +0200, Reimar Döffinger wrote:
> On Thu, Aug 17, 2006 at 10:59:32PM +0300, Uoti Urpala wrote:
> > What kind of use cases would you have for this filter? The -delay one
> > you mention would IMO be better handled by a sync option to throw away
> > decoded audio if the current audio position is significantly behind
> > video.
> 
> That sounds rather difficult and fragile, not to mention that you can't
> decide then where in the filter chain to throw away the audio.

I mean doing that as part of the sync code, after the filter chain.
Currently if you play something with -delay 10 the video doesn't play
until after 10 seconds when starting, after seeks the adjustment is
gradual. Instead the sync code could throw away audio until it catches
video. 

> I think it wouldn't be too difficult to extend this approach so later
> the mplayer.c core can tell the filter "hey, throw away the next 10
> seconds of audio".

What's the advantage of doing this in a filter? The current semantics
don't make much sense as a general filter, and using the filter
interface from mplayer.c would probably require more code there than
directly implementing the "throw away the next X bytes" logic.

> Also, is there any specific part of the patch you dislike? What about

My main dislike is towards the af_skip functionality itself; IMO the
current semantics are nonsense. Related sane semantics could be
something like "remove audio with pts values between x and y, and adjust
pts values after y by x-y" (obviously implementing this would require
better pts manipulation support for the audio filter chain).

> the change to mplayer.c, it probably makes sense/is needed for any
> filter that causes a significant delay or needs a lot of data to start
> its work, like -af delay.

I see no reason to have AF_RETRY visible to mplayer.c, the audio
decoding routines should be able to handle that internally. Taking the
result of af_calc_delay() (which is currently ignored) into account is
necessary if filters can add significant delay, but your patch doesn't
do that right. I think it's necessary to always substract the filter
delay value from the result in written_audio_pts().