[FFmpeg-devel] [PATCH 2/2] lavd/pulse_audio_enc: allow non monotonic streams

[Lukasz M]

W dniu piątek, 3 stycznia 2014 użytkownik Michael Niedermayer napisał:

> On Thu, Jan 02, 2014 at 11:50:48PM +0100, Lukasz M wrote:
> > On 2 January 2014 22:26, Michael Niedermayer <michaelni at gmx.at<javascript:;>>
> wrote:
> >
> > > On Tue, Dec 31, 2013 at 10:24:34PM +0100, Lukasz Marek wrote:
> > > > Signed-off-by: Lukasz Marek <lukasz.m.luki at gmail.com <javascript:;>>
> > > > ---
> > > >  libavdevice/pulse_audio_enc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavdevice/pulse_audio_enc.c
> > > b/libavdevice/pulse_audio_enc.c
> > > > index e047299..1a416b5 100644
> > > > --- a/libavdevice/pulse_audio_enc.c
> > > > +++ b/libavdevice/pulse_audio_enc.c
> > > > @@ -179,6 +179,6 @@ AVOutputFormat ff_pulse_muxer = {
> > > >      .write_packet   = pulse_write_packet,
> > > >      .write_trailer  = pulse_write_trailer,
> > > >      .get_output_timestamp = pulse_get_output_timestamp,
> > > > -    .flags          = AVFMT_NOFILE | AVFMT_ALLOW_FLUSH,
> > > > +    .flags          = AVFMT_NOFILE | AVFMT_ALLOW_FLUSH |
> AVFMT_TS_ANY,
> > > >      .priv_class     = &pulse_muxer_class,
> > >
> > > this looks wrong
> > >
> > > the device would need a time machine to change the past sound that
> > > was potentially already played
> > >
> >
> > This is for players, not tools like ffmpeg.
> > The scenario I have in mind is for example:
> >
> > You write to device packets with pts: 0, 1, 2, 3, 4, 5... then you seek
> > back to 2 and play again 2, 3, 4, 5 etc...
> > So in fact you play again that was already played. The code in mux.c
> > changed in previous patch didn't allow that.
> > And if you don't write packets with real pts/dts (repeated values), but
> > keep increasing them then av_get_output_timestamp() will return useless
> > values.
> >
> > If you still found it wrong then I would be glad to get some hint how to
> > solve this.
>
> when a player sends a video out device a frame with timestamp
> 2014-jan-05 13:01:31.98754 (or 1234567.89123 seconds since bootup)
> and duration 1ms
>
> thats when the device should display it
> the next frame comes after that even if the user did a seek in the
> input.


timestap is not a date + time you may check on calendar/clock on the wall,
but its a time since beginning of a stream in stream's base_time units.
current position in other words.

Currently video devices doesn't use packet pts/dts at all and display frame
right now. it is up to code that uses video device to call write_packet
function at  appropriate moment.

Audio devices also put all samples to the device's buffer (by device i
means library like libpulse for example, not device in ffmpeg meaning), but
packet's pts is used to determine current position when user wants by
calling av_get_output_timestamp.
This is calculated by adding duration of last packet to the timestamp of
last packet (its pts) and substracting latency. latency is equal to the
packet duration right after call and it decreases toward 0 with time
passing.

So again, when you seek backward you get pts that is lower than previous
one and libavformat complains about that. when you dont provide real pts
then device cant return proper position in a stream.