[FFmpeg-devel] [RFC] FFmpeg libavcodec/crystalhd.c: Optimize for reduced latency

[thomas schorpp]

On 03.02.2013 02:59, Philip Langdale wrote:
> On Sat, 02 Feb 2013 16:18:22 +0100
> thomas schorpp <thomas.schorpp at gmail.com> wrote:
>>
>> I've got it sync'd to the driver and a stable pipeline control loop,
>> the TX/RX- ringbuffers balanced with faster and more precise sync
>> locking for now with patch #03:
>>
>> <SNIP>
>>
>> Why is a pixel format converter called "scaler" in FFmpeg?
>>
>> But I don't see the cause from the stream input in the stereo3d
>> filter source code hitting this switch() case: [stereo3d] stereo
>> format of input is not supported I try to excplicitely specify pixel
>> format and scaler params.
>>
>> Comments on this crystalhd.c development patch?
>
> The pixel format conversion is done by the scaler because it has to
> support that anyway, so even when doing a 1:1 conversion it gets used;
> that's just an ffmpeg implementation detail.
>
> So, yeah - it certainly seems functional - with the big caveat that if
> you try and seek in the video with mplayer, it will overflow the input
> buffer and grind to a halt. The old code doesn't do that. It's fine
> for a transcode run, but not good for interactive playback.

Yes, first optimization target is transcoding, noted the mplayer seek break, too, and
does not even work as good as your design for transcoding,
every random minutes distorted picture and audio out of sync after 20min, fsck.

I've trimmed some more and added an extra wait sleep to stop buffer overruns,
but I think next I should try a real timer() with autocalibration on capture startup,
but timers need multithreading as I know... pthread_cond_wait() etc

So I've got a growing feeling that I'll end up porting the stereo3d filter to
a gstreamer plugin, too, if the crystalhd plugin performs better, but 15fps maybe
the maximum performance for 1080p with this filter already on my cpus.

Thanks again for Your feedback, please say if You don't want to be CC'd anymore.

Version 0.4 and my new broadcom driver bugfix attached, without, Transmageddon
will crash Your kernel on matroska demux probing (and maybe yet again ^^),
I've no more motivation fixing Broadcom's stuff under LGPL, wether they send one
looking after it from time to time or better GPL it, best way if they don't care anyway.

y
tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crystalhd-latencyopt-experimental.04.schorpp.patch
Type: text/x-diff
Size: 13480 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130203/fa717a40/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crystalhd-paging-bugfix.schorpp.01.patch
Type: text/x-diff
Size: 15897 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130203/fa717a40/attachment-0001.bin>