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

[Michael Niedermayer]

On Sat, Feb 28, 2009 at 01:46:21AM +0100, Olivier Guilyardi wrote:
> Version 0.6 of the jack demuxer path is attached.
[...]
> >> +            latency = latency / self->nports;
> >> +            cycle_delay = jack_frames_since_cycle_start(self->client);
> >> +            info.pts = av_gettime() - (latency + cycle_delay) * self->frame_ms;
> > 
> > does jack not provide a timestamp for the returned audio?
> 
> Jack doesn't provide any absolute timestamp. Only some running counters. This is
> one of the reasons why I asked whether timestamps should be absolute or relative
> in an earlier post.

we need timestamps that are compareable to the "system clock/wall clock" so
audio/video sync is possible. We also need accurate timestamps and
av_gettime() is probably not accurate enough for many uses.
I assume the running counters count samples and not true time?
If so JACK has the same problem OSS has.

this needs something like

estimated_time = av_gettime() - (latency + cycle_delay) * self->frame_ms; (taken from your code)

pts= last_pts + samples_since_last_time / sample_rate
pts+= (estimated_time - pts)*0.01;
sample_rate+= (samples_since_last_time/estimated_time_since_last - sample_rate)*0.001;

also as our OSS code doesnt have something similar yet, you would possibly
make some people happy if you could implement this in a seperate file, & patch
and it could be used by both ...
(note the 0.001 / 0.01 constants are arbitary picked by me and likely poor
 choices, and above code is untested ...)


[...]
> >> +    for (i = 0; i < self->nports; i++) {
> >> +        jack_ringbuffer_read(self->data_rb, (char *) self->channel_buffer,
> >> +                             info.size * sizeof(float));
> >> +        for (j = 0; j < info.size; j++) {
> >> +            output_data[j * self->nports + i] = self->channel_buffer[j];
> >> +        }
> >> +    }
> > 
> > useless copy?
> > why not allocate a packet (or several) and read directly into them?
> 
> The data needs to be interleaved. Doing this efficiently in-place is non
> trivial, because there might be more than 2 input channels. In other terms this
> is a matrix transposition with an unknown number of rows and columns. For
> example, 

is the ringbuffer stuff doing a copy on its own? if so maybe you should
not use it but rather directly copy & interleave the data into AVPackets.


> the GNU Scientific Library offers a function for this:
> gsl_matrix_transpose()
> 
> Is it an option?

no

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090228/966c3ce4/attachment.pgp>