headers
Jim Bauer | 1 Jan 2004 04:26
Picon

slow video


I have a Hauppauge PVR350 in a rather old and slow box.  I can

	dd if=/dev/video0 of=/dev/video16 bs=64k

and it looks just fine on a TV.  But if I run mplayer the video is very slow
but the audio is ok.  When I run mythTV both the video are slow
(about 1 frame per sec).  The CPU is 0% idle.

I am working on getting a faster system so I have just been playing with an 
old 200MHz K6 that was otherwise sitting idle.  I didn't really expect it to
be great till I got a new CPU/motherboard, but considering the 'dd' looked 
great I was wonder if perhaps I am missing something else.

ivtv driver from CVS from last week
recent gentoo build
linux 2.4.20-gentoo-r9

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 2 comments |
headers
Isaac Richards | 1 Jan 2004 04:50
Picon

Re: slow video

On Wednesday 31 December 2003 10:26 pm, Jim Bauer wrote:
> I have a Hauppauge PVR350 in a rather old and slow box.  I can
> 
> 	dd if=/dev/video0 of=/dev/video16 bs=64k
> 
> and it looks just fine on a TV.  But if I run mplayer the video is very
> slow
 but the audio is ok.  When I run mythTV both the video are slow
> (about 1 frame per sec).  The CPU is 0% idle.
> 
> I am working on getting a faster system so I have just been playing with an
> 
 old 200MHz K6 that was otherwise sitting idle.  I didn't really expect it
> to be great till I got a new CPU/motherboard, but considering the 'dd'
> looked great I was wonder if perhaps I am missing something else.

You probably want the ivtv list (ivtv-devel <at> lists.sf.net), but, enable the 
pvr-350 output in the mythtv settings (setup -> tv settings -> playback -> 
3rd page of the wizard) so that it will use the pvr-350's decoder.  No other 
app (ie, mplayer) supports the hardware decoder on the pvr-350 yet, really.

Isaac

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
Robert W. Fuller | 1 Jan 2004 07:33
Picon

Re: capture card recomendations

I'm confused.  I thought that if you de-interlaced you would get a frame 
that is twice the size of each field with half the "field rate."  That 
is if you capture interlaced material and de-interlace it you should get 
full frame at 30 fps.

Tuukka Toivonen wrote:

>On Mon, 22 Dec 2003, Jindrich Makovicka wrote:
>
>  
>
>>the left and right. I usually capture at 720x576 and deinterlace &
>>rescale to 512x384, which is IMO enough for most of TV material.
>>    
>>
>
>I guess it depends on material. I can see clearly resolution & quality drop
>when capturing at 768x576 and scaling down to 640x480. But this is for
>non-interlaced movies; for interlaced material the vertical resolution is
>practically half of the original after deinterlacing, so I encode those at
>512x384.
>
>Actually broadcast TV resolution is very good, the real trouble is noise on
>weak stations and sometimes on bad weather horizontal "echos" or "shadows".
>VHS tape horizontal resolution is very poor though, and the noise just
>awful.
>
>
>--
>video4linux-list mailing list
(Continue reading)

Permalink | Reply | 7 comments |
headers
Erik Slagter | 1 Jan 2004 12:01

Re: capture card recomendations

> I'm confused.  I thought that if you de-interlaced you would get a frame 
> that is twice the size of each field with half the "field rate."  That 
> is if you capture interlaced material and de-interlace it you should get 
> full frame at 30 fps.

This is not a result of the deinterlacing.

TV capture cards generally capture full size frames at "frame rate",
that's 25 or 29.9.. Hz. These frames consist of two fields, the odd and
even fields, already integrated into each other. So all lines are there
0-576 or 480 (simplistic). These two fields (even and odd lines) are not
from the same moment in time though. As long as there is little motion,
you will not see any problem. As soon as there is motion between the
recording time of the odd frame and the recording time of even frame,
you will see a comb effect. On a normal television set, you don't have
this problem, as it does not use full frames at all, it only displays
the fields one at a time, at the right interval.

You can try to minimize these comb effects which is in fact
de-interlacing. It takes a full frame at frame rate and produces full
frames at full rate. Several algorithms exist, generally they try to
smooth out the differences between the even and odd lines.
De-interlacing is effective against comb filters but also yields
unwanted artefacts. This is inherent to the process. You cannot
de-interlace frames without loss of information. The only way you can
view an interlaced video source properly, is on a television set at the
proper field (!) rate, fully synced etc. A computer monitor won't do.

IMHO the best way to deal with interlacing is: if you can keep the
material interlaced, keep it that way, e.g. if the destination is mpeg
(Continue reading)

Permalink | Reply | 5 comments |
headers
Erik Slagter | 1 Jan 2004 12:04

Re: capture card recomendations

> I'm confused.  I thought that if you de-interlaced you would get a frame 
> that is twice the size of each field with half the "field rate."  That 
> is if you capture interlaced material and de-interlace it you should get 
> full frame at 30 fps.

BTW, what you describe is actually ONE possible way of deinterlacing,
although not often used. You split the frames into fields and use the
field rate and field size. Mpeg should be able to encode this, but I am
not shure whether your standalone DVD player will play it correctly.
There is a possibility it can't handle the double frame rate and also it
has to take into account the offset of the odd field (start at line 1
not 0).

Anyway, at least mpeg does a poor job encoding this way, so it is not
recommended.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
surya | 1 Jan 2004 13:24

Re: Vertical synchronization

Hi Erik,
  From your comments what I observe is that the BT8x8 cards drop data
directly on to the framebuffer only when requested through V4l2 APIs.
What my doubt is whether BT8x8 cards drop data directly on to the
framebuffer by default with its hardware features. If I know the
starting address (physical address) of the framebuffer can I able to
read the video data without using V4l2 APIs ?

On Tue, 2003-12-30 at 16:03, Erik Slagter wrote:
> > Hi Michael and all,
> >   I have been asking the question whether BT8x8 cards write video data
> > directly on to the framebuffer many times. But I got the answer from
> > your mail. If BT8x8 cards write video data directly on to the
> > framebuffer, how can we read the video data from "/dev/fb0" instead of
> > "/dev/video0" ? I am using Microwindows (www.microwindows.org) to
> > develop a tv viewer application like "Xawtv" which uses "/dev/video0" to
> > read video streams. I have planned to develop a tv viewer application
> > which reads the data from "/dev/fb0".
> 
> And while it's soo simple ;-)
> 
> There are roughly two modes of operation for both v4l2 (with v4l2 it's a
> bit more subtile btw), capturing to "memory" and capturing to "screen".
> 
> If you request capturing to "memory" your application can fetch the
> frames from there, it hasn't been on your display at all. You can even
> use to read() system call to fetch the data (although not recommended).
> 
> You can also request capturing to "screen" which will place the frame
> date directly into frame buffer memory, where you can see it. That's why
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Jones | 1 Jan 2004 14:21

CC only works occasionally w/zapping-0.6.7-fr1, zvbi-0.2.4-fr2, rte-0.5.1-fr2

I have a (few years old) Hauppauge WinTV card, using Fedora Core 1.  
Using xawtv and ntsc-cc -c I can reliably see the CC text, but whether 
CC works with zapping is a coin toss (if the coin's biased, that is).

zapping -d, on a run where CC doesn't work, shows the following in the 
output:

I/O error #0 in decoding thread:
V4L/V4L2 VBI interface timeout

Searching for those messages (or rather, pieces thereof) on Google 
turned up two messages in French. One suggested a possible permission 
problem...and interestingly, when I run zapping as root, I appear
to always be able to view CC when I wish. Sure enough, I look at 
/dev/vbi* and see that /dev/vbi[0123] are only readable and writable by 
root, so I chmod 666 them... to no avail. (And the above messages  
appear even when CC works.)

So... it's probably a matter of permission, but on what? Any help would 
be greatly appreciated; the ultimate goal is to get a deaf friend 
running with Linux.

    James Jones

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert W. Fuller | 1 Jan 2004 16:37
Picon

Re: capture card recomendations

Yes, this is clear.  Thank you.

I have the man pages for the tools and the book DVD Demystified, but I 
didn't find all this information.  Where did you learn all this?

Also, how does this relate to the bttv's poor algorithm for downsampling 
to 4:2:0?  If I capture in yuv4mpeg format with streamer, am I losing 
chroma data that should be interpolated?  If so, what would be a better 
capture format, and what tool should I use to downsample for mjpegtools 
MPEG-2 encoding?  Alternatively, is there a tool more suited to the bttv 
for MPEG-2 encoding than mjpegtools?

Erik Slagter wrote:

>You can try to minimize these comb effects which is in fact
>de-interlacing. It takes a full frame at frame rate and produces full
>frames at full rate. Several algorithms exist, generally they try to
>smooth out the differences between the even and odd lines.
>De-interlacing is effective against comb filters but also yields
>unwanted artefacts. This is inherent to the process. You cannot
>de-interlace frames without loss of information. The only way you can
>view an interlaced video source properly, is on a television set at the
>proper field (!) rate, fully synced etc. A computer monitor won't do.
>
>IMHO the best way to deal with interlacing is: if you can keep the
>material interlaced, keep it that way, e.g. if the destination is mpeg
>on a dvd-standalone player. If your destination encoder cannot handle
>interlaced material you'll have to deinterlace it. In other cases, e.g.
>encoding for display on a computer monitor, you can choose whether you
>want to de-interlace it before encoding or at viewing time, depending on
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Slagter | 1 Jan 2004 17:59

Re: Vertical synchronization

>   From your comments what I observe is that the BT8x8 cards drop data
> directly on to the framebuffer only when requested through V4l2 APIs.
> What my doubt is whether BT8x8 cards drop data directly on to the
> framebuffer by default with its hardware features. If I know the
> starting address (physical address) of the framebuffer can I able to
> read the video data without using V4l2 APIs ?

If you know how to program the bt878, you can have it put the frame data
everywhere you'd like to.

I doubt that's what you want though. Why not use the V4l2 api?

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 2 comments |
headers
Erik Slagter | 1 Jan 2004 18:10

Re: capture card recomendations

> I have the man pages for the tools and the book DVD Demystified, but I 
> didn't find all this information.  Where did you learn all this?

Following several mailing lists and writing my own v4l2 import module
for transcode. Also on the web there really is information about this.

> Also, how does this relate to the bttv's poor algorithm for downsampling 
> to 4:2:0?

I do not know whether the bttv driver still only samples field for
chroma, maybe Gerd can enlighten us? I know the SAA7134 at least can
take samples from both fields and I assume the driver supports this.

If you want to be shure, capture in 4:2:2 and downsample in software. My
v4l2 import module for transcode can do that. I did not see any
difference though. Don't forget chroma is already pretty mangled using
one of the infamous colour standards.

> If I capture in yuv4mpeg format with streamer, am I losing 
> chroma data that should be interpolated?

Maybe. See above notes.

> If so, what would be a better 
> capture format, and what tool should I use to downsample for mjpegtools 
> MPEG-2 encoding?  Alternatively, is there a tool more suited to the bttv 
> for MPEG-2 encoding than mjpegtools?

BTW current mpeg2 implementations for linux all encode in YUV420, so
there is little sense in capturing in YUV422, apart from a possible flaw
(Continue reading)

Permalink | Reply | 0 comments |

Gmane