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

[Matthew Delco]

On Thu, 15 Nov 2001, Lloyd Lim wrote:

> On Thursday 15 November 2001 07:25 am, Bob Riddle wrote:
> >
> >[...]  Also, it starts vic with a user
> >script file "-u /tmp/vic-startup.0" which doesn't seem to hang around
> >long enough for me to peek at it.  Anybody know what this script looks
> >like?
>
> This would explain why someone was asking for this option.  Can an AG
> person explain what this is used for?
>
> Even if we added this capability, you'd probably have to rewrite the
> startup script because Mash internals are not identical to UCL
> internals.  It's probably better to let us know what you want so we
> could implement it as one or more command-line options.
>
> >Anyway, Matthew indicates in his mjpeg pages that vic can be built
> > using the lml33 mjpeg drive.  In fact, Larry Rowe had sent a note
> > some time ago indicating this might be included in future openmash
> > "releases".  So my current thought is to try and get a linux version
> > of the openmash vic slide in place on the AG linux video capture
> > machine and see if it resolves the startup issue by using more
> > "normal" AG video capture software.
>
> I'm not sure if Matt was talking about encoding or decoding in that
> reference.  Matt is really the only person that would/could add this
> capability to Mash.
>
> I'd love to see LML33 hardware decoding in vic.
>
> Lloyd
>

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