[FFmpeg-devel] [PATCH] libavdevice: JACK demuxer
Sat Mar 7 18:05:06 CET 2009
On Sat, Mar 07, 2009 at 04:32:53PM +0100, Reimar D?ffinger wrote:
> On Sat, Mar 07, 2009 at 04:10:32PM +0100, Michael Niedermayer wrote:
> > What you didnt consider though is that we will need a similar buffer for OSS
> > and possibly others, the jack ringbuffer cant be used for these.
> > because we cant use jacks ringbuffer we need our own no matter what amount of
> > extra bugfixing that involves, using jacks ringbuffer in one piece of code
> > and our own in another is no gain it just means more code& more bugs.
> > and after rethinking the code, iam pretty sure any such buffer will need
> > memory barriers on some cpus
> Note that MPlayer already has about 3 implementations of such a ring buffer
> (admittedly it assumes atomic reads and writes to ints) e.g. in
> libao2/ao_sdl.c and libao2/ao_jack.c, a implementation in libavutil
> would be welcome thus.
> I was once thinking about just using fifo.c, but since it uses bytes
> as basic unit (instead of a e.g. 1kB block), it allocates exactly one
> additional byte, causing alignment issues after the first loop through
> the buffer.
id love to see libavutil/fifo extended to fix the 1 byte issue and
whatever else is needed.
but first i think you should read Documentation/memory-barriers.txt
from the kernel, because i think all these buffers are buggy on SMP.
More specifically the update of the pointer/index that is performed after
updating the buffer content may or may not be seen in that order by
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel