Maybe mmap would make sense but I was thinking that an ioctl pointing to the Y & UV similar to the PREP_FRAME would probably work. Let me have a play I can add an ioctl and see how it looks.
BTW the current yuv interface is broken for PAL. The choice of when to switch between Y & UV is done on a buffer boundary only and the buffer size is chosen to work with NTSC not PAL sized buffers. Ideally I thinjk for YUV the write calls (if we stick with that interface) should accumulate buffers into frames and only add them to the q for a complete frame and then the decode thread should handle that frame as a single lump. Also (at least with 3.3.3k, your producing too many versions for me to keep up with again :) ) the buffers aren't flushed on close/open of /dev/video48 so you don't start with an empty buffer. I switched the buffer size to match PAL wrote 2 yuv frames to /dev/video48 which added some data to the decode q but didn't trigger the decode thread. Closed /dev/video48 re-opened it and wrote the same 2 frames which added them to the data from the previous write and then kicked the decode q. I haven't looked into why and the machine is in use recording something at the moment so I can't look into why for another half an hour or so. I think we can ignore audio until everything else is out of the way. Thanks John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ivtv-devel- > [EMAIL PROTECTED] On Behalf Of Chris Kennedy > Sent: 26 April 2005 20:27 > To: [email protected] > Subject: Re: [ivtv-devel] YUV decoding works, some caveats still > > I'm wondering if we would want to mmap the buffer, possibly 2, out to > userspace, and have an ioctl to switch which buffer we display. This > would be simple and basically we could write it to emulate or exactly > like normal video card output buffers. Not sure how this would be done, > but should be able to add that and still keep our current YUV decoding > but also have an OSD like interface, or something video cards would > be able to utilize or an X server, possibly add into the ivtv-fb module. > I am beginning to doubt audio will be easy, or possible even, because I > don't see any easy way to do audio PCM to the chip, we have no information > on this even being possible like we did YUV. I suspect input of PCM is > hard, we have no real interrupt or anything to follow there, and wouldn't > have a clue how to fill and play buffers, so possibly a dead end getting > that to ever work (although who knows, I'm hoping someone figures out > more). > > Thanks, > Chris > On Sun, Apr 24, 2005 at 10:19:46PM +0100, John Harvey wrote: > > 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 > > -- > --- > Chris Kennedy / [EMAIL PROTECTED] > Engineer KMOS-TV/KTBG-FM > Broadcasting Services Department > Central Missouri State University > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
