also from what i can recall, the yuv you get from the encoder may not be valid yuv to feed to the output side.
i think it's more meant to work on the output from a software decoder (aka yv12). -tmk --- John Harvey <[EMAIL PROTECTED]> wrote: > The other probable problem (for me at least) is that > those buffer addresses > are likely to be different for PAL since a buffer is > bigger!. > > Anyway I'll see if I can start to take a look at > this later then. > > John > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:ivtv-devel- > > [EMAIL PROTECTED] On Behalf Of Chris > Kennedy > > Sent: 30 November 2004 19:06 > > To: [EMAIL PROTECTED] > > Subject: Re: [ivtv-devel] State of YUV > playback/decodeing. > > > > On Tue, Nov 30, 2004 at 06:41:46PM +0000, John > Harvey wrote: > > > So now that we seem to be able to capture YUV > does > > > anyone have any expectations that they YUV > decoding > > > should work? > > > > > > As far as i can tell it doesnt work. > > > I would expect that > > > > > > dd if=/dev/video32 of=/dev/video48 bs=xxxx > > > where xxxx is the correct block size depending > on PAL > > > or NTSC. > > > But this doesnt seem to display anything and > there is > > > a comment in ivtv-driverh where the > YUV_BUFFER_OFFSET > > > is defined saying FIXME this iw wrong > > > > Yeah, that buffer area seems to be changing with > video when > > in Passthrough mode, and when black is black YUV > it seems, > > and color bars likewise. But the firmware of > course doesn't > > tell us any valid values for the YUV memory offset > so we > > are in a bind there to figure out what to do and > exactly how > > to time it. It may be we need to do some special > way of writing > > and timing it, I have the memory map I've derived > up on... > > > > > http://205.209.168.201/~ckennedy/ivtv/itvc/memory_map.txt > > > > Which seems there's a couple possible > combinations, I have > > thought that we may have to split the Y and UV up > actually > > ourselves and use these buffers to place it for > the decoder, > > while probably following the decoder vsync > interrupt timing > > to playback frame accurate YUV right (and maybe to > do PCM > > audio we also have to place that into these > buffers). So > > maybe (if you look at the buffers offsets) the > groups of > > 3 are a Y a UV and a PCM buffer? > > > > 0x01024000-0x01026fa0 - YUV Buffer for Decoding? > > 0x01029000-0x0107d600 - YUV Buffer for Decoding? > > 0x0108e400-0x010b8700 - YUV Buffer for Decoding? > > ... > > 0x01240400-0x012949f0 - YUV Buffer for Decoding? > > 0x012a5800-0x012cfb00 - YUV Buffer for Decoding? > > 0x012d8200-0x0132c7f0 - YUV Buffer for Decoding? > > > > I think this may be the case, and there are a > couple groups, > > and from looking at other chips that YUV decode, > seems often > > you have multiple buffers so 2+ frames can be > DMA'd in a row > > to successive buffers possibly, but that may not > be so for > > this chip for all I know. > > > > I hadn't known much about YUV when looking at > these, so haven't > > done much calculations on sizes or if they are > even right amounts > > to store YUV data. So something to explore, > surely someone knowing > > alot about YUV should be able to at least validate > or theorize about > > if these are possibly right and what we need to do > with them. > > > > Actually the more I think about it, I'm not sure > YUV decoding would > > really need to give sizes or memory addresses if > we knew them already > > (and size would always be one frame, addresses > wouldn't offset really > > and just be the buffer start). So it may make > alot of sense what we > > are getting back from the firmware and one just > needs to either have > > documentation on the way to YUV decode or like we > have done derive it > > (which passthrough mode is a great opportunity to > watch the firmware > > do it and emulate that). > > > > Thanks, > > Chris > > > > > > Thanks, > > Chris > > > > > > So assuming that the code is close to working > and that > > > the most likely cause of it not displaying > anything is > > > the value defined for IVTV_YUV_BUFFER_OFFSET how > do we > > > work out what the value should be. > > > > > > The reason i was thinking of doing this is that > if we > > > can get this to work i can probably start to add > Xv > > > support to the X driver, which i have working > but at > > > the moment i'm software decoding the yuv buffer > and > > > displaying it the frame buffer which is not > > > particularly fast but is at least a start. > > > > > > John > > > > > > > > > > ------------------------------------------------------- > > > 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://productguide.itmanagersjournal.com/ > > > _______________________________________________ > > > 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://productguide.itmanagersjournal.com/ > > _______________________________________________ > > 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://productguide.itmanagersjournal.com/ > _______________________________________________ > 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://productguide.itmanagersjournal.com/ _______________________________________________ ivtv-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
