Chris
        I've now got this working intermittently so it's close but I think
we need to think about YUV should work.
        I think this should be much more like the OSD in it's behaviour
rather than a stream like mpeg and I even wonder whether there should just
be an ioctl interface to this as well. 

        The behaviour that seems to make sense to me is

User code opens /dev/video48
                Driver inits everything
User code writes YUV buffer or does ioctl with point to Y & pointer to UV
data.
                Driver copies to first buffer
                        Waits for vsync
                        Sets reg 82c, 830, 834, 838 to point to this data
                        Enables video output (0x108080 to reg 2898)
                Returns
User code writes next YUV buffer
                Driver copies to 2nd buffer
                        Waits for vsync
                        Sets reg 82c, 830, 834, 838 to point to this data

This then repeats except we don't need to enable video out other than the
first time. I don't think we want or can afford to have the delay of all the
buffering that's in the mpeg stream decoder otherwise it is going to be
almost impossible to synchronise the audio.

What do you think? Can you do this or shall I try to find some time and send
a patch?  I don't know how much time I'll have this week and you often end
up getting things done just as I start to look at things.

John

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:ivtv-devel-
> [EMAIL PROTECTED] On Behalf Of Chris Kennedy
> Sent: 24 April 2005 00:40
> To: [email protected]
> Subject: Re: [ivtv-devel] YUV decoding works, some caveats still
> 
> Yes, I've seen this too, it doesn't always work, I tried some things to
> kick
> it into action more often, but is stubborn sometimes, hard to predict, but
> when it works it is quite cool.
> 
> Thanks,
> Chris
> On Sat, Apr 23, 2005 at 10:23:59PM +0100, John Harvey wrote:
> > I can't make the yuv stuff work. Not sure what is going on but I'm using
> PAL
> > not NTSC which might make a difference though as far as I can see what
> you
> > have should work. I'll look into it a bit more tomorrow too see if I can
> see
> > what is happening.
> >
> > John
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:ivtv-devel-
> > > [EMAIL PROTECTED] On Behalf Of Chris Kennedy
> > > Sent: 23 April 2005 21:08
> > > To: [email protected]
> > > Subject: [ivtv-devel] YUV decoding works, some caveats still
> > >
> > >
> > > This allows YUV decoding to work, you can now do things like cat
> > > /dev/video32 > /dev/video48 on your pvr350.  It takes the odd format
> of
> > > YUV of course, hm12 rawvideo in mplayer.  There are still some
> oddities,
> > > you must decode mpeg at least once upon module load before it will
> decode
> > > YUV.  This seems like something we are missing in initializing the
> > > decoder.
> > > The YUV input needs a timing source, you have to send it in basically
> at
> > > a rate of playback.  So when you do the cat > above, it times it for
> you
> > > because the /dev/video32 interface won't output YUV any faster than it
> > > is played back normally.  It still needs work of course, but this is
> > > actually
> > > showing sane output of YUV on the decoder display.
> > >
> > > #0.3.3i: http://www.ivtv.tv/releases/ivtv-0.3/
> > >
> > >
> > > Thanks,
> > > Chris
> > > --
> > > ---
> > >  Chris Kennedy / [EMAIL PROTECTED]
> > >   Engineer KMOS-TV/KTBG-FM
> > >   Broadcasting Services Department
> > >   Central Missouri State University
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real
> users.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > > _______________________________________________
> > > ivtv-devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/ivtv-devel
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > ivtv-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ivtv-devel
> 
> --
> ---
>  Chris Kennedy / [EMAIL PROTECTED]
>   Engineer KMOS-TV/KTBG-FM
>   Broadcasting Services Department
>   Central Missouri State University
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ivtv-devel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Reply via email to