[AG-TECH] Re: AG video node using berkley mjpeg work

[José María González]

There are two places where we could insert lml33's 
jpeg hardware processing, the encoding and the decoding 
side. 

On the encoding side, current codecs do both encoding 
and packetizing of the resulting data. We could create 
an alternative version of the MJPEG encoder so that it 
accepts jpeg-encoded frames (as they are produced from 
the lml33 card) and just does the packetizing (call it 
"p-jpeg"). To make it work with vic, we would need 
setting the VideoPipeline object so that the only codec 
acceptable for the lml33 card in JPEG mode is "p-jpeg". 

This solution would probably work, but in terms of 
software architecture would be really dirty. The reason 
is that the object that is passed from the capture 
device to the codec, VideoCapture::frame_, is just a 
generic byte pointer (u_char* actually). It is always 
a component, 3-planar, YUV frame (chroma subsampling 
depending on the codec). Using it on the "p-mjpeg" codec 
as a a component, 3-planar, jpeg-encoded frame would 
be at least disconcerting. 

A cleaner, long-term solution would imply major changes 
in vic's architecture, so that different frame types 
(raw, MJPEG encoded, etc.) can be passed to the codec. 

Including hardware decoding is a harder task. 

-Chema 


Matthew Delco wrote:
> I'd have to rea-read my sentence to see what I said.  vic can't currently
> take advantage of the lml33's hardware jpeg capability.  Prof. Rowe was
> the last/only person to work on this, and I think we all got a bit puzzled
> (at that time) by the video abstractions.
> 
> I could write a mash driver that provides a hardware encoded image to
> mash, but beyond that I wouldn't know how to plug it into mash properly.
> FOr decoding, mash would have to hand the driver a complete jpeg (or some
> well-defined subset of one) that I could then kludge into a format that
> the lml33 would like.  However, only certain video sizes would work, and
> on prior occasions I've foudn that the lml33 doesn't like the jpegs that
> are produced by vic.  As far as I can tell, the lml33 is very picky about
> where the EOI marker is placed, and most vic images are a one or more
> bytes too large or small.  The IJPEG library makes a similar complaint,
> but proceeds without failing in a fatal manner.
> 
> MD