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

Michael Niedermayer michaelni at gmx.at
Fri Jan 3 19:02:41 CET 2014


On Fri, Jan 03, 2014 at 06:07:24AM +0100, Lukasz M 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.
> 

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

thats not practical, even 15years ago players had 3 buffers in video
memory and while loading one from the decoder, having one displayed
the third was the next to display and at the correct time display
was switched by page flip from one buffer to the other.

a write_packet() takes time and can get interrupted by other processes
so theres no way timing the presentation can happen from outside
unless that outside would be inside the kernel


[...]

more generally
there are 2 kinds of output devices
ones that can do presentation of (audio/video/...) at a time
provided by the application
and ones that cannot do that

the 2nd kind like a TV with fixed 50hz output or most audio hardware
(hopefully) can provide feedback of when actual display happened
(using av_get_output_timestamp for example) and that feedback
can then be used by a audio resampler or fps convertion filter to
stretch or squish the stream so as to get presentation to happen when
its intended

output APIs/Libs that lack their own buffers and just do "display
it now" should be wraped in their own thread that has a fifo
and does the presentation when the user provided timestamps want it
that would happen in a ffmpeg device/muxer or could use some utils
from common code

better ideas & solutions welcome of course

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/3873f109/attachment.asc>


More information about the ffmpeg-devel mailing list