Actually I suspect for YUV input, we won't be able to input fast enough without buffering, I've actually tried an ioctl before with YUV frames, and it would miss a frame once in awhile until I used buffering. I am wondering about how the PCM will feed in and sync up, but possibly the whole timestamp stuff, somehow, with the vsync, would that be used? Just my thoughts though, good thing to try and I would be interested in that, maybe what I did to input with an ioctl was flawed, we'll just have to explore and see what works. Also changing the registers to point at the buffer, it won't work from what I can tell, I tried changing it and seems things are unstable switching them alot, I think? Although I see what your saying and I suspected that, that those 4 registers point to the buffers to show, or buffer, I think one is the top field and other the bottom, just my suspicions, but maybe wrong there (so in theory could buffer top/bottom field separately?). I just couldn't get them to ever actually work that way, but do have to program them first to get it to work consistently. I guess we could fill each buffer, of the 4, and show them and use the hardware as 4 buffers actually, maybe that would work. I was thinking in mpeg decoding, it fills buffers and shows them, so would need buffers, but for our YUV direct output, we maybe don't need more than one, unless we used the hardware for buffering instead of software ones. Does PCM decoding work, I haven't even looked to see, I am wondering about how the PCM frames correspond to YUV ones, how that works, and how an mplayer plugin would be able to input YUV (and convert AVI to YUV frames) and PCM together in a way we could properly time them together.
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 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
