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

wm4 nfxjfg at googlemail.com
Fri Jan 3 17:21:36 CET 2014


On Fri, 3 Jan 2014 06:07:24 +0100
Lukasz M <lukasz.m.luki at gmail.com> wrote:

> 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.

Oh, some players/APIs actually use wallclock for presentation times, at
least mplayer2, mpv, vdpau. I think you'll have to think about whether
a muxer API is really the right match for a audio/video playback API.


More information about the ffmpeg-devel mailing list