my information was based on the fact that it's just sending it to the digitizer. If it's doing conversion on its own, anything is possible.
-tmk --- John Harvey <[EMAIL PROTECTED]> wrote: > 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 > === message truncated === ------------------------------------------------------- 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
