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

thomas schorpp thomas.schorpp at gmail.com
Mon Feb 4 16:37:32 CET 2013


On 03.02.2013 03:54, thomas schorpp wrote:
> 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>
>>
>> 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,

As expectable, the (unhandled?) false returns from the NULL pointer "fixes" may lead to
kernel deadlock freezes and crashes in the ISRs.
Reproducing scenario: ctrl-c at capture startup, e.g.
Broadcom driver patch attached, but don't expect that to be really a fix.

y
tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crystalhd-isr-deadlock-bugfix.schorpp.01.patch
Type: text/x-diff
Size: 18356 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130204/03e5f8b5/attachment.bin>


More information about the ffmpeg-devel mailing list