[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-development
Subject:    [haiku-development] Re: GSoC EHCI
From:       François_Revol <revol () free ! fr>
Date:       2011-08-04 23:34:22
Message-ID: 4E3B2C7E.7020706 () free ! fr
[Download RAW message or body]

Hi,

Le 03/08/2011 01:01, Gabriel Hartmann a écrit :
>> I've been looking at the Sonix GetFrameBitmap and FillFrameBuffer
>> code.  Could you give me a little more detail about how deFramers
>> work.  It looks like a CamDeframer makes reference to a Blist of
>> Frames.  How is this list populated?  Otherwise the two methods which
>> need implementing look pretty straight forward.
>
>
> I think this approach is a good idea, so that if in the future ehci is
> fixed at least the payload data can be interpretted easily.  In any
> case, my questions about deframers still stands.  I believe I should
> be creating a UVCDeframer class which extends CamDeframer.  This
> should then implement the virtual functions defined in CamDeframer.
> Is there any documentation about what exactly these functions are
> supposed to do?  Then I implement FillFrameBuffer or GetFrameBitmap
> using the Deframer and we should be pretty close to showing pictures
> on screen...at least for 20 seconds right?

Basically CamDeframer is a BDataIO that is written to with every chunk 
of received data, and needs to detect where a frame starts and ends, 
then create a new frame to copy the data to, adds it to the list and 
releases the semaphore to unblock WaitFrame().

See CamBufferingDeframer.cpp & CamStreamingDeframer.cpp
One of those is buggy though (the one that's not currently used, 
hopefully), I was likely asleep when I wrote this and it's likely 
suboptimal.

At least for the Sonix it needs to detect specific Start Of Frame 
markers, since it can't rely on a fixed chunk size (frames can be 
compressed, and packets can get lost).

> I'm trying to figure this out on my own, but I just keep climbing up
> the inheritance tree into less and less familiar territory.  I guess
> the key questions are what are the overridden functions in the

If you only need to detect specific markers in the streams you can just 
clone the Sonix code and change the SOF/EOF markers.

> Deframer supposed to do, and who populates the BList of frames
> (fFrames)?

the Write() hook does it, when a full frame is detected, in 
Cam[Streaming|Buffering]Deframer. Should likely go into a 
CamDeframer::PushFrame() or something.

François.

[prev in list] [next in list] [prev in thread] [next in thread]