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

[thomas schorpp]

On 30.01.2013 18:06, Philip Langdale wrote:
> On Wed, 30 Jan 2013 00:25:14 +0100
> thomas schorpp <thomas.schorpp at gmail.com> wrote:
>
>> Hello,
>>
>> 1.
>> Are You all with vdpau now or was it the kernel crashing driver bug
>> why most crystal HD projects dropped now for about a year? Patch
>> attached. Seems to work, no more kernel crashes so far. Broadcom
>> authors and owner of crystalhd @git.linuxtv.org (latest codebase) not
>> responding, google group left, anybody out there?
>
> Hi Tom,
>
> Yes, it's a bit of a dead community. I haven't had the time to look
> seriously at CrystalHD work for a while. It's very time consuming and
> frustrating at this point - as most of what you're doing is trying to
> work around lack of information. You can't trust the driver/library to
> tell you when a frame a ready, or when a new input packet is needed, or
> whether an output frame is interlaced or not. 80%+ of crystalhd.c is
> interlaced heuristics!
>
> I had some contact with one of the Broadcom engineers back in 2011 and
> he had said he'd try and get help for all this stuff but he never got
> back to me and I had less and less time to work on it, so my efforts
> tailed off. I got the 70015 working well enough for my needs so my
> personal motivation to fix 70012, which has such different behaviour,
> was low. I know it can be made to work (see gstreamer plugin, vlc, etc)
> but it would be a lot of work to adapt the multi-threaded design to
> an ffmpeg codec.

I just have a look at and try the Broadcom gstreamer decoder plugin (on debian stable ^^ , don't know yet if it builds at all),
it's in C and using pthreads and usual multithreading event methods, if it performs better I'll try to port the mechanisms of

crystalhd/filters/gst/gst-plugin/src/gstbcmdec.c:1371 bcmdec_process_output() ,etc,

to FFmpeg.

y
tom