John,
Here's a patch (attached) to YUV decoding which will make the YUV buffers fit
the data perfectly now, resized so as to have 5 of 0x00019500 size
buffers for NTSC and 6 for PAL. This should apply to 0.2.0-pre3 and 0.3.1
fine, or with little work, I've not had time to get it into both yet.
Thanks,
Chris
On Thu, Dec 02, 2004 at 10:28:52PM -0000, John Harvey 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
> > > > > 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
--
---
Chris Kennedy / [EMAIL PROTECTED]
Engineer KMOS-TV/KTBG-FM
Broadcasting Services Department
Central Missouri State University
diff -BurN ivtv-0.3.1y-yuv/driver/ivtv-driver.c ivtv-0.3.1y/driver/ivtv-driver.c
--- ivtv-0.3.1y-yuv/driver/ivtv-driver.c 2004-11-28 00:40:40.000000000
-0600
+++ ivtv-0.3.1y/driver/ivtv-driver.c 2004-12-01 09:42:38.000000000 -0600
@@ -114,7 +114,7 @@
static int radio_c = 1;
#endif
#ifdef YUV_FIXUP
-static int yuv_fixup;
+static int yuv_fixup = 1;
#endif
#ifdef MODULE
static unsigned int autoload = 1;
@@ -501,6 +501,7 @@
itv->dma_cfg.enc_yuv_buf_size = IVTV_DMA_ENC_YUV_BUF_SIZE;
itv->dma_cfg.enc_pcm_buf_size = IVTV_DMA_ENC_PCM_BUF_SIZE;
itv->dma_cfg.dec_buf_size = IVTV_DMA_DEC_BUF_SIZE;
+ itv->dma_cfg.dec_yuv_buf_size = IVTV_DMA_DEC_YUV_BUF_SIZE;
itv->dma_cfg.vbi_buf_size = IVTV_DMA_VBI_BUF_SIZE;
itv->dma_cfg.dec_vbi_buf_size = IVTV_DMA_DEC_VBI_BUF_SIZE;
itv->dma_cfg.max_yuv_buf = IVTV_MAX_YUV_BUFFERS;
diff -BurN ivtv-0.3.1y-yuv/driver/ivtv-driver.h ivtv-0.3.1y/driver/ivtv-driver.h
--- ivtv-0.3.1y-yuv/driver/ivtv-driver.h 2004-11-27 23:24:36.000000000
-0600
+++ ivtv-0.3.1y/driver/ivtv-driver.h 2004-12-01 09:41:49.000000000 -0600
@@ -117,7 +117,10 @@
#define IVTV_IOREMAP_SIZE (IVTV_REG_OFFSET + IVTV_REG_SIZE)
/* Buffers on hardware offsets */
-#define IVTV_YUV_BUFFER_OFFSET 0x00240400 /* FIXME this is wrong, where is it?
*/
+#define IVTV_YUV_BUFFER_OFFSET 0x00029000 /* FIXME this needs work */
+#define IVTV_YUV_BUFFER_OFFSET_2 0x00240400 /* second buffer? */
+#define IVTV_YUV_BUFFER_OFFSET_3 0x002d8200 /* third buffer? */
+#define IVTV_YUV_BUFFER_UV_OFFSET 0x10e00 /* only NTSC? */
/* General */
#define IVTV_DRIVER_NAME "ivtv"
@@ -199,9 +202,10 @@
/* DMA Buffers Sizes */
#define IVTV_DMA_ENC_BUF_SIZE 0x00004000
-#define IVTV_DMA_ENC_YUV_BUF_SIZE 0x00020000
-#define IVTV_DMA_ENC_PCM_BUF_SIZE 0x00001200
+#define IVTV_DMA_ENC_YUV_BUF_SIZE 0x00019500
+#define IVTV_DMA_ENC_PCM_BUF_SIZE 0x00001200
#define IVTV_DMA_DEC_BUF_SIZE 0x00010000
+#define IVTV_DMA_DEC_YUV_BUF_SIZE 0x00019500
#define IVTV_DMA_OSD_BUF_SIZE 0x00010000
/* These two values should not be changed. VBI data does not currently
@@ -237,7 +241,7 @@
#define IVTV_DEFAULT_VBI_BUFFERS (int)(2 * ((1024 * 1024)))
#define IVTV_DEFAULT_PCM_BUFFERS (int)(2 * ((1024 * 1024)))
#define IVTV_DEFAULT_DEC_MPG_BUFFERS (int)(1 * ((1024 * 1024)))
-#define IVTV_DEFAULT_DEC_YUV_BUFFERS (int)(1 * ((1024 * 1024)))
+#define IVTV_DEFAULT_DEC_YUV_BUFFERS 0
#define IVTV_DEFAULT_DEC_VBI_BUFFERS (int)(256 * (1024))
#define IVTV_DEFAULT_DEC_OSD_BUFFERS (int)(2*(1024*1024))
@@ -247,7 +251,7 @@
#define IVTV_MAX_VBI_BUFFERS (int)(2 * ((1024 * 1024)))
#define IVTV_MAX_PCM_BUFFERS (int)(2 * ((1024 * 1024)))
#define IVTV_MAX_DEC_MPG_BUFFERS (int)(1 * ((1024 * 1024)))
-#define IVTV_MAX_DEC_YUV_BUFFERS (int)(1 * ((1024 * 1024)))
+#define IVTV_MAX_DEC_YUV_BUFFERS (int)(3 * ((1024 * 1024)))
#define IVTV_MAX_DEC_VBI_BUFFERS (int)(1 * ((1024 * 1024)))
#define IVTV_MAX_DEC_OSD_BUFFERS (int)(2*(1024*1024))
@@ -270,6 +274,7 @@
int enc_yuv_buf_size;
int enc_pcm_buf_size;
int dec_buf_size;
+ int dec_yuv_buf_size;
int vbi_buf_size;
int dec_vbi_buf_size;
diff -BurN ivtv-0.3.1y-yuv/driver/ivtv-kthreads.c
ivtv-0.3.1y/driver/ivtv-kthreads.c
--- ivtv-0.3.1y-yuv/driver/ivtv-kthreads.c 2004-11-28 00:35:30.000000000
-0600
+++ ivtv-0.3.1y/driver/ivtv-kthreads.c 2004-12-01 10:32:54.000000000 -0600
@@ -628,10 +628,18 @@
goto clear_dmap;
}
} else {
- offset += IVTV_YUV_BUFFER_OFFSET;
- mem_offset = IVTV_YUV_BUFFER_OFFSET;
+ if (itv->dec_dma_stat.wq_runs == 0 ||
!(itv->dec_dma_stat.wq_runs%2)) {
+ offset = IVTV_DECODER_OFFSET +
IVTV_YUV_BUFFER_OFFSET_2;
+ mem_offset = IVTV_YUV_BUFFER_OFFSET_2;
+ } else {
+ offset = IVTV_DECODER_OFFSET +
IVTV_YUV_BUFFER_OFFSET_2;
+ mem_offset = IVTV_YUV_BUFFER_OFFSET_2;
+ }
/* YUV can xfer as much as needed */
max_xfer = mem_size;
+
+ IVTV_DEBUG(IVTV_DEBUG_ERR, "YUV Decoding [%d] 0x%08x
bytes to 0x%08x\n",
+ itv->dec_dma_stat.wq_runs, mem_size,
mem_offset);
}
/* Gather enough buffers */
diff -BurN ivtv-0.3.1y-yuv/driver/ivtv-streams.c
ivtv-0.3.1y/driver/ivtv-streams.c
--- ivtv-0.3.1y-yuv/driver/ivtv-streams.c 2004-11-28 00:47:39.000000000
-0600
+++ ivtv-0.3.1y/driver/ivtv-streams.c 2004-12-02 09:04:26.843316224 -0600
@@ -361,7 +361,8 @@
&ivtv_v4l2_dec_fops;
x |= ivtv_stream_init(itv, IVTV_DEC_STREAM_TYPE_YUV,
- itv->options.dec_yuv_buffers, itv->dma_cfg.dec_buf_size,
+ itv->options.dec_yuv_buffers,
+ itv->dma_cfg.dec_yuv_buf_size,
itv->num + IVTV_V4L2_DEC_YUV_OFFSET,
VFL_TYPE_GRABBER, PCI_DMA_TODEVICE);
if (x == 0)
