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

[Olivier Guilyardi]

Michael Niedermayer wrote:
> On Sun, Mar 08, 2009 at 12:26:33AM +0100, Olivier Guilyardi wrote:
>> Michael Niedermayer a ?crit :
>>
>>> 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.
>> Okay, so, now please tell me why the hell do you want to use a ringbuffer in the 
>> oss or other (de)muxers ?
> 
> a single threaded application like ffmpeg
> that captures video and audio, encodes, muxes and stores this to disk is
> not able to read data from the demuxers as regular as it might want.
> That is even more true if the system is busy with other work.

Very true

> I dont know straight of my head how much buffering is guranteed by OSS itself
> so maybe iam underestimating the amount ...
> 
> And with some things like V4L there is the addiional issue that you have
> neither a timestamp nor a way to find how much is in the buffer.
> meassuring times by gettimeofday() from a seperate thread is likely more
> accurate than the main thread that happens sometimes to be 100ms late
> every few frames

Indeed. I didn't know you wanted to go through such a refactoring of
libavdevice. At least, jack's callback mechanism forces to follow that sort of
design, that's one of its strength.

> also, it seems libavutil/fifo.c/h could be used now (as ive fixed a
> alignment bug) so you dont have to implement anything, just call the
> code from fifo.*
> (and by that i of course mean storing AVPackets in there not the
> floats themselfs)

Okay, no problem. It's your api. However, I need a way to know how many bytes
can be written/read, before I actually write/read into this fifo buffer.
Otherwise that will result in broken packets.

I'd really like not to play directly with the members of AVFifoBuffer for this
purpose. Handling these always require some sort of atomicity, it's a bit risky.
It would break the encapsulation rule I mentioned earlier.

--
  Olivier