ah, seems like a decoding bug too then, we aren't clearing those buffers for either I suspect. Yes, we need to just adjust buffersize if in PAL mode upon module startup, that should be easy actually.
Thanks, Chris On Tue, Apr 26, 2005 at 08:43:36PM +0100, John Harvey wrote: > 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 -- --- 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
