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

[Michael Niedermayer]

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

similarly for audio, this is also a requirement for exact AV sync
when there are multiple devices.
I mean the API should be able to get AV or AA sync right down to a
single audio sample or better when the hardware has such very precisse
capabilities ...

now if timestamps reset on seeks, how would a device know when to
display frames and still end up with exact sync to another
device?
Maybe iam missing something here, but if the timestamps reset on seeks
that seem to complicate and not simplify things ...
(and there could be multiple seeks before or during the display of a
frame)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140103/81ed928e/attachment.asc>