[FFmpeg-devel] [PATCH] libavdevice: JACK demuxer

[Olivier Guilyardi]

Luca Abeni wrote:
> Olivier Guilyardi wrote:
>> Luca Abeni wrote:
>>> Hi,
>>>
>>> I do not comment on the rest of the patch (yet :), but:
>>>
>>> Reimar D?ffinger wrote:
>>> [...]
>>>>> +            info.pts = av_gettime() - (latency + cycle_delay) * self->frame_ms;
>>>> The system time should not be stored anywhere without explicit
>>>> permission from the user, particularly not as an absolute value.
>>> This is needed for synchronising the audio with video or other media 
>>> coming from other devices. If it really is a security issue (but in this
>>> case I do not believe it is) maybe the usual "round the time to ms" can 
>>> be a solution?
>> I have a simple question here: must the pts be absolute (number of seconds since
>>  the epoch) or can it be relative (for example 0 for the first audio sample).
>> Luca you already told me it must be absolute, but I still have doubts about this.
> 
> If it is relative to the first audio sample, how do you synchronise with 
> a different stream (that does not know when this stream's first audio 
> sample is)?

First, I suspect that ffmpeg already treats pts as relative, because when you
start it, it prints "Duration: .., start: .., bitrate: .." for all of its input
streams. With an avi file as input I get start: 0.0000, while with an oss input
it prints an absolute epoch-based value (1235767507 or so).

However, when I use two inputs, one relative (a file) and the other absolute (a
jack input for example), the audio and the video are in sync. It's not as if the
audio was starting 1235767507 seconds after the video.

Second, to answer your question, some sort of syncing is just matter of
substracting the start time (the time in the first AVPacket) from the pts in the
subsequent packets. And of course adjust possible delays with -itsoffset.

I'm not saying this is a good approach. I'm just trying to understand how it's
(and must be) done in ffmpeg. So, absolute or relative?

--
  Olivier