Just another quick update. It looks like 0x011a8600 - 0x01240400 contains a YUV buffer that is displayed. It also appears that this is in the mangled format that we receive from the card.
Writing to the device's memory having mapped it into user space I have a program that writes 1 frame at a time from a yuv file captured from /dev/video32 and most of the time it plays back. Some of the time this works and sometimes it doesn't (almost as if it's double buffering the yuv output and I'm writing to the wrong one). However I haven't figured out where the second buffer is if that's the case yet. Since Kevin believes that the card is supposed to use proper YV12 I wonder if the cards dma api's take a buffer in from one location and convert them from normal YV12 to Hauppage YUV and place it in one of 2 buffers? Anyway I'll experiment a bit more over the next few evenings. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ivtv-devel- > [EMAIL PROTECTED] On Behalf Of John Harvey > Sent: 30 November 2004 22:14 > To: [EMAIL PROTECTED] > Subject: RE: [ivtv-devel] State of YUV playback/decodeing. > > Just a quick summary since I have to stop now. > Part of the problem is that the decoding doesn't understand YUV frames > properly. > So if I read a buffer in of 622080 bytes and write this as a single write > we > don't dma the complete data but at least the data on the card at the > address > we select in the header file is correct. > However if I write the same data a second time then instead of the start > of > the Y data appearing I have something from the middle of the buffer > appearing at that point. > > I hope this makes some sense. I'll work on this tomorrow since if we cant > get the correct data into the place in memory that we want we don't stand > any chance of working out where that place should be. > > John > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:ivtv-devel- > > [EMAIL PROTECTED] On Behalf Of John Harvey > > Sent: 30 November 2004 21:41 > > To: [EMAIL PROTECTED] > > Subject: RE: [ivtv-devel] State of YUV playback/decodeing. > > > > That would be even better if its true since its easier to feed that from > > XV > > rather than the strange muddled up stuff from the encoder. I'll create > > some > > test yv12 data to try it with as well since I can easily dump that out > > from > > the xv code I have at the moment. > > > > John > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:ivtv-devel- > > > [EMAIL PROTECTED] On Behalf Of kevin thayer > > > Sent: 30 November 2004 21:26 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ivtv-devel] State of YUV playback/decodeing. > > > > > > 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 > > > > > > > > ------------------------------------------------------- > > 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
