Re: Studio-grade hardware support?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Brian J. Murrell (v4l@xxxxxxxxxxxxxxx):

> >   I mean that you record at like 352x240
> @ 59.94 (both fields) or 29.97 (lose a field)?

  Well I'm assuming 29.97.  Since I don't know of a format that can
record 352x240 @ 59.94 and keep track of the dominance of each field, I
don't consider that an option.

  Consider MPEG2.  You could do 352x480 frames, interlaced, put in the
dominance, and you get exactly what you describe later in your email.

> > In order to record TV for compression to interlaced MPEG2, I need to
> > grab frames in 4:2:2 mode and downsample the chroma myself.
> 
> OK.  Note that mp1e says this:
> 
> Filter 'YUYV 4:2:2 w/vertical interpolation' Image format 'YUYV' 640 x
> 480 granted
> 
> When I record at 640x480.

  I looked though the code and sort of figured out what it was doing,
then I found that the mp1e man page explains it nicely:

  You're using:

  5 - Vertical interpolation
      Averages every current and next line, has a blurring effect.

  So that means that instead of seeing the raw data you get a blur
between both fields, so motion just looks sort of blurry instead of
harsh artifacts from looking at two frames at once.  I wouldn't think
that would look too good, but it's definitely one (highly lossy)
'deinterlacing' option.  The author notes how MPEG1 is a progressive
format and offers a bunch of filters.  One that I find kinda funny is:

  7 - Field progressive with interpolation
      One problem with filter mode #6 is that fields are shifted against
      each other by half a line height, which causes flicker.  This
      filter additionally averages two adjacent fields of the same or
      successive pictures, eliminating the flicker. At the moment this
      is as close to a real TV as you can get.

  Which is basically recording to 59.94 @ 720x480 for each frame.  Lots
of bandwidth.  I'd rather fix up mpeg2enc and use that on prerecorded
stuff using a lossless codec, but that should be obvious from the code
I've written so far (and useless for what you want to do, that is,
realtime PVR!).

  Oh, but since these go from 4:2:2 (like they should), and since it's
to MPEG1 not MPEG2, you won't have the 'bug' I noted earlier.

> > Well the drivers aren't good enough to allow you to watch interlaced
> > video on the G400 TV output.
> 
> Meaning there is no way to output fields, alternately, interlaced
> @59.94Hz with the current G400 drivers?

  Well you can send it frames that are interlaced, but you have no
control over the dominance (which field is shown first), nor do you get
an interrupt to tell you when to blit the next frame.

> > Yes, I use Xv for scaling.  But I'm sending 720x480 @ 59.94fps @
> > 16bpp (that's 4:2:2, so the same colour quality as a TV natively).
> 
> Why 480 lines @59.94?  I would have thought it would be 240 lines at
> 59.94 or 480 at 29.97.

  Because I'm a deinterlacer.  Each field I have to show as a frame.  I
want to watch TV at full framerate.  So I interpolate each field to
frame height and send it.  Is there something that isn't clear?

> But using your numbers, I calculate 331,444,224 (316M) bps, or 39MB/s
> to the video card?  Is that right?  I can see why it might judder
> then.  :-)

  Yes that's correct.

> > The judder problem is something else that needs to be fixed.  For
> > playback of 59.94fps video without judder I need to basically
> > software-genlock the monitor to either 59.94hz or 119.88hz
> 
> Right.  The G400 does/can do this.

  Are you sure?  The G400 docs say that if you have the TV input version
of the card (I didn't know there was one) or some sort of TV input thing
onboard, then it can use the refresh of that to drive the monitor.  Is
that what you're talking about?  It can't genlock from software as far
as I can tell, nor can it genlock from another video capture card.


> > it would be nice to get at least 720x480, and maybe even 720x486.
> 
> Let me play with 720x480.  What difference do you think I should see
> between 720 and 640 considering my TV out is 800x600?  My bttv card
> does not support 486 as a height though.

  I know that most TV graphics are generated for 720x480, and most DVDs
store video as 720x480 images.  However it is analog, so the scanlines
read from your capture card might not match up.  I found that running
tvtime with 720/scanline gives alot more horizontal detail than
640/scanline, and if you go to like 960 which the bttv samples at itself
you can see even more detail.  I think it would be neat to record at
960x480 on the bttv and then do a really slow interpolator and see if
you can't get a better reproduction of the original source that way.

  But again, I want to write a high quality VCR app before I write my
PVR, so this is how I approach this stuff. :)


> > Sure you need it.  You want it if you're recording anything from
> > film source to convert it from 59.94fps to 23.976fps.
> 
> 59.94fps at M x N to 23.976fps at M x N*2?

  Yeah.

> > It makes watching films much smoother and MUCH better quality,
> 
> I guess I am a philistine.  I have never noticed watching films on TV
> any worse (other that picture size and clarity) than watching real
> film or DVD.  :-)

  I have some nice examples I show people.  One is of a scene from a
special features film roll on the 'Lawrence of Arabia' DVD.  As
movietime starts it takes a few seconds to lock onto the 3:2 pulldown
sequence, but the image goes from kinda poor to ultra-clear and people
go 'cooool'.

  You should go to OLS.  There will be some video types there and I'll
try and show off some demos and stuff.  http://ottawalinuxsymposium.org

> How do I know when recording something from cable that it would need
> telecining?  If some stuff is sourced from video tape and some from
> film, by the time it gets to me, how do I know?

  That's part of the problem.  You need to do image heuristics to detect
the sequence (except on well-mastered NTSC DVDs, which store the
progressive 24fps stream and have flags to tell the player to perform
the process).  I have code to do this and so do others, but since it's
heuristics based, off-line versions can do a better job.

  There are telecine detectors in higher end TVs.  For a neat (GPL'ed)
Windows deinterlacer that does 59.94fps output and can detect pulldown,
see http://deinterlace.sf.net/

> > You need to record it as an interlaced stream and remember the field
> > dominance (are your recorded frames top-field-first or
> > bottom-field-first).  Then, when you output to your G400, you need
> > to make sure it plays the fields back in the right order.
> 
> So you are saying pretty much what I was then?  Record in the format
> it was broadcast and play it back from the recording in the format it
> was broadcast.  No conversions between to turn fields into frames and
> all that crappola.

  Yep.

> > I keep meaning to do it, but I've been busy with school.  But now
> > that I'm almost done, I'm considering buying a more modern video
> > card and getting it to work instead...
> 
> What are you considering buying that will support all you want to do?

  Um, well any video card with TV output that has some drivers started,
I guess. :)  There is some code for TV out on some Radeons in cvs at
gatos.sf.net, so that's a possibility, and for nVidia cards there is
some code here: http://sourceforge.net/projects/nv-tv-out  but I'm not
sure how to make sure I get a supported card.

-- 
Billy Biggs
vektor@xxxxxxxxxxxx





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux