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

[Olivier Guilyardi]

Attached:
- jack demuxer patch version 0.7
- time filter patch version 0.1

The later provides DLL time filtering as a libavformat patch (I'm not sure about
the Makefile changes).

Michael Niedermayer wrote:

>> http://www.kokkinizita.net/papers/usingdll.pdf
> 
> this pretty much describes what i suggested (from looking at the equations, i
> didnt read through the text) and i would have called it alpha/beta filter but
> maybe there are some differences ive not checked the equations for being
> strictly equivalent.
> 
>>> 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 ...)
>> You are in a lucky day, I implemented DLL filtering as a small standalone 
>> library, libpendule, a few weeks ago:
>>
>> http://svn.samalyse.com/pendule/trunk/
>>
>> We've done quite a lot of measuring on various hardware (see the README about 
>> ./measure and ./graph), and the results are very good in regard to jitter reduction.
>>
>> libpendule actually consists into two very small files, pendule.h and pendule.c, 
>> with no dependency. It could be used in the oss demuxer, and possibly others. 
>> Plus, I'll make you a good price ;) Do you buy?
> 
> 1. i dont know what "CeCILL-B Free Software License Agreement version 1.0"
> is or if this is GPL&LGPL compatible or not

It's a "BSD-like" license that's compatible with french law. Anyway, both my
patches are under LGPL.

> 2. it seems limited to constant sized packets, my example above is not

Sorry, I can't (nor have time for) investigate this. I don't have sufficient
mathematical knowledge to see whether variable sized packets are possible or not
using a DLL. All I can tell you is that the timefilter patch, is based on
libpendule, which has been tested and benchmarked. In other terms: it works. I
don't know what the constants you are talking about may or may not be, and am
not willing to investigate this.

> 3. i dont like the code, its too large for what it does, the variables
>    are poorly named, half of them being 1 or 2 letters,
>    spagethi code like:
>     double device_rate_error;
>     stats->filter_time = self->filter_time;
>     stats->next_filter_time = self->t1;
>     stats->system_time = self->system_time;
>     stats->device_time = self->device_time;
>     stats->filter_drift = self->filter_time - self->system_time;
>     stats->device_drift = stats->device_time - self->system_time;
>     device_rate_error = self->ncycles ? stats->device_drift / self->ncycles : 0;
>     stats->filter_jitter = self->filter_period_error - device_rate_error;
>     stats->system_jitter = self->system_period_error - device_rate_error;
> 
>     can anyone read this without reformating it first?

Reformated

> the 2 parameters that control the filter are locked together using a
> formular using sqrt() PI and others, while iam sure this can be proofen
> to be optimal in a idealized case its certainly not in all practical
> cases, the user should have the chance to set both independantly, and
> as a sideeffect the dependancy on math.h can then be droped

The parameters of the filter are a complex topic, which users shouldn't play
with IMO. Please fully read the pdf document mentionned earlier.

> anyway if you want to submit that code as patch for libavformat
> under LGPL and dont mind my mercyless critique then it is very
> welcome but i would surely insist on some cleanup

It's attached, and hopefully clean ;)

>> There is an important point to consider: the process_callback function is 
>> running in a thread with realtime priority, and mustn't do anything that could 
>> block. In particular, allocating memory (and thus packets) in there isn't an 
>> option at all.
> 
> no need for that at all
> 
> read_packet(){
>     while(no packet available) ;
>     n= (n+1) % ring_size
>     packet= ring[n];
>     ring[n]= allocate new packet;
>     
>     return packet;
> }
> 
> realtime_proc(){
>     if(n!=m){
>         packet= ring[m];
>         copy&interleave data from hw into packet
>         m= (m+1) % ring_size;
>     }
> }
> 

Okay, I've done this. I'm not sure how safe it is. It's not been heavily tested
as the jack ringbuffer on various archs (weak memory ordering smp, etc..), but
it looks apparently okay, and works on my quad core.

--
  Olivier

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-r17730-jack-0.7.patch
Type: text/x-patch
Size: 11330 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090302/e4a4c65e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-r17730-timefilter-0.1.patch
Type: text/x-patch
Size: 9671 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090302/e4a4c65e/attachment-0001.bin>