gatos-devel Mailing List for GATOS
Status: Beta
Brought to you by:
volodya
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(229) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(744) |
Feb
(481) |
Mar
(400) |
Apr
(309) |
May
(290) |
Jun
(266) |
Jul
(403) |
Aug
(434) |
Sep
(546) |
Oct
(392) |
Nov
(309) |
Dec
(350) |
| 2003 |
Jan
(318) |
Feb
(339) |
Mar
(436) |
Apr
(269) |
May
(326) |
Jun
(293) |
Jul
(332) |
Aug
(131) |
Sep
(126) |
Oct
(216) |
Nov
(140) |
Dec
(167) |
| 2004 |
Jan
(367) |
Feb
(141) |
Mar
(77) |
Apr
(85) |
May
(100) |
Jun
(98) |
Jul
(79) |
Aug
(87) |
Sep
(96) |
Oct
(185) |
Nov
(105) |
Dec
(112) |
| 2005 |
Jan
(156) |
Feb
(60) |
Mar
(35) |
Apr
(57) |
May
(43) |
Jun
(49) |
Jul
(30) |
Aug
(60) |
Sep
(24) |
Oct
(55) |
Nov
(13) |
Dec
(35) |
| 2006 |
Jan
(50) |
Feb
(22) |
Mar
(24) |
Apr
(35) |
May
(44) |
Jun
(20) |
Jul
(21) |
Aug
(15) |
Sep
(9) |
Oct
(21) |
Nov
(31) |
Dec
(32) |
| 2007 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(9) |
May
(15) |
Jun
(15) |
Jul
(14) |
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
(4) |
Dec
(1) |
| 2008 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(9) |
|
2
(12) |
3
(21) |
4
(17) |
5
(11) |
6
(9) |
7
(11) |
8
(10) |
|
9
(6) |
10
(7) |
11
(6) |
12
(7) |
13
(5) |
14
(17) |
15
(15) |
|
16
(4) |
17
(14) |
18
(12) |
19
(15) |
20
(7) |
21
(2) |
22
(2) |
|
23
(3) |
24
(9) |
25
(8) |
26
|
27
(3) |
28
(2) |
29
(11) |
|
30
(11) |
|
|
|
|
|
|
|
From: Matt Z. <md...@cs...> - 2002-06-30 23:35:57
|
On Sun, Jun 30, 2002 at 04:27:59PM -0700, Fred wrote: > I'm curious what the performance benefits/penalties of using FIFO's vs. threads for video capture. > > Currently, I do the following: > > mkfifo the_video > dd if=/dev/video bs=307200 of=the_video & > # 307200 is 640x240 at 16 bpp > ffmpeg -f rawvideo -i the_video -s 640x240 -r 60 ... Why not just enhance ffmpeg to accept video on stdin, and: dd if=/dev/video bs=300k | ffmpeg -f rawvideo -i - ... No messing about with creating fifos, and it's easy to add and remove other processing from the pipeline. > BTW, I've hacked ffmpeg to recognize rawvideo input as YUY2 packed (instead of YV12). > > Do FIFO's really buffer the frames? If so, at what point would they drop them (how deeply buffered)? The FIFO itself will not drop data, but dd will block on write when the buffer is full. Presumably, the capture device will then discard data. > If the penalties of FIFO's aren't huge, why add threads? The processes > can be nice'd, too, if dd or ffmpeg need a little more time. Adding sound > capture is just another mkfifo wth a sox(OSS)/arecord(ALSA) process. For > mmap-based capture, could you create a small program for the dd-like > stuff? Threads will, in general, provide faster context switches than processes. This is very important when processing in real-time. It would be nice to have the ability to optionally use processes, though, in order to do custom processing in the pipeline. -- - mdz |
|
From: Fred <fo...@sh...> - 2002-06-30 23:21:44
|
I'm curious what the performance benefits/penalties of using FIFO's vs. threads for video capture. Currently, I do the following: mkfifo the_video dd if=/dev/video bs=307200 of=the_video & # 307200 is 640x240 at 16 bpp ffmpeg -f rawvideo -i the_video -s 640x240 -r 60 ... BTW, I've hacked ffmpeg to recognize rawvideo input as YUY2 packed (instead of YV12). Do FIFO's really buffer the frames? If so, at what point would they drop them (how deeply buffered)? If the penalties of FIFO's aren't huge, why add threads? The processes can be nice'd, too, if dd or ffmpeg need a little more time. Adding sound capture is just another mkfifo wth a sox(OSS)/arecord(ALSA) process. For mmap-based capture, could you create a small program for the dd-like stuff? I suppose, for A/V sync purposes, ffmpeg could add two separate programs to capture data to "stdout": ffmpeg_audio_cap and ffmpeg_video_cap, which would add time stamps to the data that they receive. Then ffmpeg could multiplex the "stdin"'s with correct sync? Fred |
|
From: Vladimir D. <vo...@mi...> - 2002-06-30 16:53:39
|
On Sun, 30 Jun 2002, Matt Zimmerman wrote: > On Sun, Jun 30, 2002 at 12:36:28AM -0400, Vladimir Dergachev wrote: > > > On Sat, 29 Jun 2002, Matt Zimmerman wrote: > > > > > I have not yet been able to get v4l capture to work at all. Once I got > > > all of the versions right (to avoid the 'Radeon memory controller is > > > misconfigured' message), I still couldn't get any data from the video > > > device. I am considering getting a separate capture card, since the CPU > > > that I have available for this project will probably be too slow for > > > real-time software encoding. Does anyone have experience which might > > > demonstrate the minimum CPU requirements for full-size capture with this > > > card? > > > > Try using avview. Also, I do not know of any (standalone or otherwise) > > capture card that is inexpensive and is able to output a full-size NTSC > > mpeg stream. I.e. bt848 cards will only produce uncompressed video. > > I looked at avview briefly, but I don't understand much Tcl, and couldn't > quickly figure out how to control it without using a mouse. I suppose I > could use something like x2x for testing, but I need the ability to > automatically start a capture from the command line. That is not entirely implemented, but take a look at Tcl/Tk manpages (it is rather similar to bash in syntax) and try this: ./avview_shell source avview.scp You will then get a prompt that will allow you to enter commands.. Also, you *need* X and some Xv app (avview or xawtv) to be running in order to capture anything. > > Which leaves me back with the AIW card and ffmpeg. Can you give me any > figures from your experience for the CPU requirements of this method? > See http://gatos.sf.net/km.php > > > Though the screen was somewhat scrambled, it was internally consistent, > > > and I was able to get a TV overlay window, though it was distorted and > > > only used part of the screen. > > > > > > So, how can I help? > > > > If you have some hardware experience try to figure out how to access i2c > > bus on this card. One way, for example, would be to take a careful look at > > windows register and drivers for any kind of hints as to what it might be. > > For example and *.inf files that come with drivers might refer to some i2c > > mode.. We looked, but another pair of eyes might find something new. > > > > Also, you can try hooking up a scope or multimeter to i2c pins of the > > tuner and try tinkering with registers (carefully..) using hw_script. It > > is possible that Radeon 7500 is using bit-banging interface like older > > Rage128 and mach64 cards. > > I have a little bit of hardware experience, but this kind of thing is a > little beyond by comfort level. I don't even know which pins are the i2c > pins. There is a datasheet for the tuner publicly available from Philips. > > There is a kernel i2c driver for bit-banging interfaces; would it be > possible to discover something using a software approach? Possibly.. but not necessarily. And it is more dangerous then hardware approach. The reason to suggest using scope or multimeter is that then you can detect whether individual i2c lines (clock or data) has been toggled. With software you will only know it works when you figured out both clock and data - this requires far more bit-banging different registers. > > > Also, you can try merging main and devel branches of CVS to get TV-out > > working on your computer and then try to figure out how to setup it > > without using BIOS - this would be of great help. An important detail to > > keep in mind is that the source code files are essentially all the > > documentation ATI provides - the other pdf files simply go over the source > > code mentioning saying that you need these or that lines, so a person with > > official documentation has the same chances as anyone else. > > It sounds like Rick Scott has done something in the way of bringing the BIOS > TV-out stuff from devel to main. I am going to try out his patch and see if > I can make any progress with it. > > Where is the source code and documentation from ATI? Or can this not be > disclosed? The Rage Theatre source is in main CVS (a little cleaned up), see theatre* files. The documentation I got under NDA.. > > On the topic of not using the BIOS...the way that others seem to have done > it for Matrox cards is to add TV-out support to the kernel framebuffer > driver, and use that interface to talk to the card. Would this be a viable > approach for the ATI cards as well? > > http://linux.sarang.net/ftp/mirror/multimedia/video/mplayer/DOCS/video.html#2.3.1.A > Let me put it this way: if I knew how to program Rage Theatre chip to enable TV-out _some_ C source for doing this would already be in CVS, working or not. The only known way to turn TV-out on is by using BIOS calls. Which means not only that non-PC or dualcard users cannot use it, but also that we do not know how to behave nicely to the card in TV-out mode. In particular, you can have lockups in TV-out mode because the existing code programs the card as if TV-out was not enabled. best Vladimir Dergachev > -- > - mdz > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gatos-devel mailing list > Gat...@li... > https://lists.sourceforge.net/lists/listinfo/gatos-devel > |
|
From: Rick S. <rw...@al...> - 2002-06-30 16:05:15
|
Like I said, it works for my AIW R128 Pro Ultra, 5446, not the radeon. Nothing in there should affect a radeon. On 30-Jun-02 at 11:26, Matt Zimmerman (md...@cs...) wrote: > On Sun, Jun 30, 2002 at 11:15:24AM -0400, Matt Zimmerman wrote: > > > On Sun, Jun 30, 2002 at 08:36:06AM -0400, Rick Scott wrote: > > > > > I maintain a patch against the HEAD branch of the ati.2 CVS that I use > > > for TV out with my AIW R128 Pro Ultra, 5446. It still uses the BIOS > > > calls, but at least it's against the HEAD. You can get it from > > > http://members.rogers.com/r.w.scott/patches/XFree86/ati.2/vesa.diff > > > > I applied this patch to CVS HEAD, and with it, my X server segfaults. I > > tried with both the 1.2.0 release of the DRM module, as well as with > > current CVS, with the same results. Log attached. I don't currently > > have an X server with debugging symbols, so I can't do much more yet. > > This only seems to happen in some (most, but not all) video modes. It > segfaults at 1024x768x16bpp, but not at 800x600x16bpp, for example. > > Even when it does not segfault, the TV output is still scrambled. What > does this indicate? Is it just a matter of using the wrong video mode > settings, or are the TV features of the card not properly initialized? > > -- > - mdz > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gatos-devel mailing list > Gat...@li... > https://lists.sourceforge.net/lists/listinfo/gatos-devel |
|
From: Matt Z. <md...@cs...> - 2002-06-30 15:24:21
|
On Sun, Jun 30, 2002 at 11:15:24AM -0400, Matt Zimmerman wrote: > On Sun, Jun 30, 2002 at 08:36:06AM -0400, Rick Scott wrote: > > > I maintain a patch against the HEAD branch of the ati.2 CVS that I use for TV > > out with my AIW R128 Pro Ultra, 5446. It still uses the BIOS calls, but at > > least it's against the HEAD. You can get it from > > http://members.rogers.com/r.w.scott/patches/XFree86/ati.2/vesa.diff > > I applied this patch to CVS HEAD, and with it, my X server segfaults. I > tried with both the 1.2.0 release of the DRM module, as well as with current > CVS, with the same results. Log attached. I don't currently have an X > server with debugging symbols, so I can't do much more yet. This only seems to happen in some (most, but not all) video modes. It segfaults at 1024x768x16bpp, but not at 800x600x16bpp, for example. Even when it does not segfault, the TV output is still scrambled. What does this indicate? Is it just a matter of using the wrong video mode settings, or are the TV features of the card not properly initialized? -- - mdz |
|
From: Matt Z. <md...@cs...> - 2002-06-30 15:16:57
|
On Sun, Jun 30, 2002 at 08:36:06AM -0400, Rick Scott wrote: > I maintain a patch against the HEAD branch of the ati.2 CVS that I use for TV > out with my AIW R128 Pro Ultra, 5446. It still uses the BIOS calls, but at > least it's against the HEAD. You can get it from > http://members.rogers.com/r.w.scott/patches/XFree86/ati.2/vesa.diff I applied this patch to CVS HEAD, and with it, my X server segfaults. I tried with both the 1.2.0 release of the DRM module, as well as with current CVS, with the same results. Log attached. I don't currently have an X server with debugging symbols, so I can't do much more yet. -- - mdz |
|
From: Matt Z. <md...@cs...> - 2002-06-30 14:27:31
|
On Sun, Jun 30, 2002 at 12:36:28AM -0400, Vladimir Dergachev wrote: > On Sat, 29 Jun 2002, Matt Zimmerman wrote: > > > I have not yet been able to get v4l capture to work at all. Once I got > > all of the versions right (to avoid the 'Radeon memory controller is > > misconfigured' message), I still couldn't get any data from the video > > device. I am considering getting a separate capture card, since the CPU > > that I have available for this project will probably be too slow for > > real-time software encoding. Does anyone have experience which might > > demonstrate the minimum CPU requirements for full-size capture with this > > card? > > Try using avview. Also, I do not know of any (standalone or otherwise) > capture card that is inexpensive and is able to output a full-size NTSC > mpeg stream. I.e. bt848 cards will only produce uncompressed video. I looked at avview briefly, but I don't understand much Tcl, and couldn't quickly figure out how to control it without using a mouse. I suppose I could use something like x2x for testing, but I need the ability to automatically start a capture from the command line. I was looking at the Hauppauge WinTV-PVR: http://www.hauppauge.com/html/wintvpvr_datasheet.htm http://tangentsoft.net/video/mpeg/reviews/pvr.html which includes a hardware MPEG encoder (a Kfir chip), and is not much more expensive than the Radeon AIW 7500. It implies that it can encode in real-time (TV-pause) with only a Pentium II/450MHz CPU, which would be perfect in my application, since that is the class of CPU that I currently have available. There is a sourceforge project here: http://pvr.sourceforge.net/ which seems to have made some progress in creating a driver, but has been inactive for some time. It does not seem that it is able to drive the card to produce compressed video. Which leaves me back with the AIW card and ffmpeg. Can you give me any figures from your experience for the CPU requirements of this method? > > Though the screen was somewhat scrambled, it was internally consistent, > > and I was able to get a TV overlay window, though it was distorted and > > only used part of the screen. > > > > So, how can I help? > > If you have some hardware experience try to figure out how to access i2c > bus on this card. One way, for example, would be to take a careful look at > windows register and drivers for any kind of hints as to what it might be. > For example and *.inf files that come with drivers might refer to some i2c > mode.. We looked, but another pair of eyes might find something new. > > Also, you can try hooking up a scope or multimeter to i2c pins of the > tuner and try tinkering with registers (carefully..) using hw_script. It > is possible that Radeon 7500 is using bit-banging interface like older > Rage128 and mach64 cards. I have a little bit of hardware experience, but this kind of thing is a little beyond by comfort level. I don't even know which pins are the i2c pins. There is a kernel i2c driver for bit-banging interfaces; would it be possible to discover something using a software approach? > Also, you can try merging main and devel branches of CVS to get TV-out > working on your computer and then try to figure out how to setup it > without using BIOS - this would be of great help. An important detail to > keep in mind is that the source code files are essentially all the > documentation ATI provides - the other pdf files simply go over the source > code mentioning saying that you need these or that lines, so a person with > official documentation has the same chances as anyone else. It sounds like Rick Scott has done something in the way of bringing the BIOS TV-out stuff from devel to main. I am going to try out his patch and see if I can make any progress with it. Where is the source code and documentation from ATI? Or can this not be disclosed? On the topic of not using the BIOS...the way that others seem to have done it for Matrox cards is to add TV-out support to the kernel framebuffer driver, and use that interface to talk to the card. Would this be a viable approach for the ATI cards as well? http://linux.sarang.net/ftp/mirror/multimedia/video/mplayer/DOCS/video.html#2.3.1.A -- - mdz |
|
From: Rick S. <rw...@al...> - 2002-06-30 12:36:29
|
I maintain a patch against the HEAD branch of the ati.2 CVS that I use for TV out with my AIW R128 Pro Ultra, 5446. It still uses the BIOS calls, but at least it's against the HEAD. You can get it from http://members.rogers.com/r.w.scott/patches/XFree86/ati.2/vesa.diff |
|
From: Vladimir D. <vo...@mi...> - 2002-06-30 04:34:39
|
On Sat, 29 Jun 2002, Matt Zimmerman wrote:
> I recently purchased a Radeon All-in-Wonder 7500 card for use in a
> Linux-based digital video unit, with TV output. I understand that not all
> of the features of this card are supported yet, and I am willing to
> volunteer time and resources to help improve the situation.
>
> Here is what I have been able to achieve with the current drivers:
>
> With the stock XFree86 4.2.0 'radeon' driver, things basically work with a
> CRT. I didn't check whether acceleration worked.
>
> With the ati.2 driver from CVS, acceleration work, and DVD playback on a CRT
> works very nicely (<50% CPU utilization with 0 drops on a minimal CPU).
>
> I do not have the hardware arrangement to test TV overlay on a CRT, so I
> have not tried that. It seems like it should work, according to the
> information on the gatos website.
>
> I have not yet been able to get v4l capture to work at all. Once I got all
> of the versions right (to avoid the 'Radeon memory controller is
> misconfigured' message), I still couldn't get any data from the video
> device. I am considering getting a separate capture card, since the CPU
> that I have available for this project will probably be too slow for
> real-time software encoding. Does anyone have experience which might
> demonstrate the minimum CPU requirements for full-size capture with this
> card?
Try using avview. Also, I do not know of any (standalone or otherwise)
capture card that is inexpensive and is able to output a full-size NTSC
mpeg stream. I.e. bt848 cards will only produce uncompressed video.
>
> TV output works great with the XFree86 VESA driver, though without
> acceleration, DVD playback is too jittery to be watchable.
>
> With the 'devel' ati.2 driver, the TV output is scrambled. I tried many
> different modes without success.
The devel version has not been updated in a while.. I still have to
integrate the patch to bring it in sync with main CVS.
>
> Though the screen was somewhat scrambled, it was internally consistent, and
> I was able to get a TV overlay window, though it was distorted and only used
> part of the screen.
>
> So, how can I help?
If you have some hardware experience try to figure out how to access i2c
bus on this card. One way, for example, would be to take a careful look at
windows register and drivers for any kind of hints as to what it might be.
For example and *.inf files that come with drivers might refer to some i2c
mode.. We looked, but another pair of eyes might find something new.
Also, you can try hooking up a scope or multimeter to i2c pins of the
tuner and try tinkering with registers (carefully..) using hw_script. It
is possible that Radeon 7500 is using bit-banging interface like older
Rage128 and mach64 cards.
Also, you can try merging main and devel branches of CVS to get TV-out
working on your computer and then try to figure out how to setup it
without using BIOS - this would be of great help. An important detail to
keep in mind is that the source code files are essentially all the
documentation ATI provides - the other pdf files simply go over the source
code mentioning saying that you need these or that lines, so a person with
official documentation has the same chances as anyone else.
best
Vladimir Dergachev
>
> --
> - mdz
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
|
|
From: Matt Z. <md...@cs...> - 2002-06-30 01:11:29
|
I forgot to mention one other thing. While I am able to get (garbled, probably due to TV-out problems) TV overlay using drm-kernel 1.2.0, the current CVS drm-kernel locks up my machine, requiring a hard reset. Has anyone else seen a similar problem, or have any ideas about it? -- - mdz |
|
From: Matt Z. <md...@cs...> - 2002-06-30 00:27:15
|
I recently purchased a Radeon All-in-Wonder 7500 card for use in a Linux-based digital video unit, with TV output. I understand that not all of the features of this card are supported yet, and I am willing to volunteer time and resources to help improve the situation. Here is what I have been able to achieve with the current drivers: With the stock XFree86 4.2.0 'radeon' driver, things basically work with a CRT. I didn't check whether acceleration worked. With the ati.2 driver from CVS, acceleration work, and DVD playback on a CRT works very nicely (<50% CPU utilization with 0 drops on a minimal CPU). I do not have the hardware arrangement to test TV overlay on a CRT, so I have not tried that. It seems like it should work, according to the information on the gatos website. I have not yet been able to get v4l capture to work at all. Once I got all of the versions right (to avoid the 'Radeon memory controller is misconfigured' message), I still couldn't get any data from the video device. I am considering getting a separate capture card, since the CPU that I have available for this project will probably be too slow for real-time software encoding. Does anyone have experience which might demonstrate the minimum CPU requirements for full-size capture with this card? TV output works great with the XFree86 VESA driver, though without acceleration, DVD playback is too jittery to be watchable. With the 'devel' ati.2 driver, the TV output is scrambled. I tried many different modes without success. Though the screen was somewhat scrambled, it was internally consistent, and I was able to get a TV overlay window, though it was distorted and only used part of the screen. So, how can I help? -- - mdz |
|
From: Vladimir D. <vo...@mi...> - 2002-06-29 19:14:45
|
On 29 Jun 2002, Benjamin Mesing wrote:
> Take my apologies, I should have really looked closer at the configure
> output, forgot to specify the ffmpeg path :-(
This implies that the program has problems when ffmpeg has not been
compiled in. I'll take a look.
Vladimir Dergachev
>
> Sorry Ben
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
|
|
From: Benjamin M. <ben...@gm...> - 2002-06-29 18:31:54
|
Take my apologies, I should have really looked closer at the configure output, forgot to specify the ffmpeg path :-( Sorry Ben |
|
From: Benjamin M. <ben...@gm...> - 2002-06-29 18:17:43
|
> Try deleting (or moving to a different file) your ~/.avview_state file. No success. > Also check that all files were updated.. perhaps something is missing. I've tried a completly new checkout. Greetings Ben |
|
From: Vladimir D. <vo...@mi...> - 2002-06-29 17:52:12
|
Try deleting (or moving to a different file) your ~/.avview_state file.
Also check that all files were updated.. perhaps something is missing.
Vladimir Dergachev
On 29 Jun 2002, Benjamin Mesing wrote:
> Hello,
>
> today I've updated my avview version (CVS), but while the old one worked
> the new one has some errors with me. The recording interface is
> incomplete now, only the
> "V4L device:
> Recording mode:
> Window:"
> lines are there, the rest (like the record button) is missing.
> When trying to close the program I get the following error message, in a
> message box:
> Title: "Error in Tcl Script"
> Text: "Error: can't read "ffmpeg_video_codec": no such variable"
> Buttons: "Ok" "Skip Messages" "Stack Trace"
> (Independent of what button I press, the program doesn't end.)
>
> Clicking Stack Trace gives this:
> ------------------
> can't read "ffmpeg_video_codec": no such variable
> while executing
> "puts $fileid "set ffmpeg_video_codec \"$ffmpeg_video_codec\"""
> (procedure "save_v4l_capture" line 30)
> invoked from within
> "save_v4l_capture $fileid"
> (procedure "save_settings" line 47)
> invoked from within
> "save_settings"
> invoked from within
> ".video_menu invoke active"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 [list $w invoke active]"
> (procedure "tkMenuInvoke" line 47)
> invoked from within
> "tkMenuInvoke .video_menu 1
> "
> (command bound to event)
> ------------------
>
> After this all config files seems to be destroyed :-(
> Any ideas?
>
> Greetings Ben
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
|
|
From: Martyn R. <ran...@li...> - 2002-06-29 17:34:21
|
Thanks again for your reply Vladimir. On Saturday 29 June 2002 18:11, Vladimir Dergachev wrote: > I was under impression that pal and secam resolutions coincide, isn't it > so ? This may be my lack of knowledge - pal is 352x288 rather than 360x240, which I was under the impression was ntsc and secam, but I guess it must just be ntsc. Thanks for correcting me. > Try using "double-deinterlace" mode - this should work better for you. This will make the file /nearer/ the correct ratio but not quite the correct ratio. 1.5 just doesn't look quite right if the actual ratio (from the video) is 1.2 recurring. For now, until I can actually stretch, rather than scale, it will have to do. > Perhaps.. One thing that you should also keep in mind is that I do not > know how to get ffmpeg to encode interlaced stream. I do not think it can > do it. (Note: not ffmpeg binary which has deinterlacing algorithm but the > library with the aim of producing interlaced mpeg file). I don't think what I'm asking for is interlacing the mpeg file, just getting ffmpeg to write the correct value for ratio in the header of the mpeg file. AFAIK in the mpeg standard, it doesn't matter what res you exists, the player should play at the correct ratio. e.g. DVDs are always encoded at a res that is 4:5, but played back at 4:3 or 16:9 depending on the mpeg file's header. (I know dvds are Mpeg-2, but that's just an example, AFAIK mpeg-1 is the same.) > Vladimir Dergachev Martyn Ranyard |
|
From: Benjamin M. <ben...@gm...> - 2002-06-29 17:23:13
|
Hello,
today I've updated my avview version (CVS), but while the old one worked
the new one has some errors with me. The recording interface is
incomplete now, only the
"V4L device:
Recording mode:
Window:"
lines are there, the rest (like the record button) is missing.
When trying to close the program I get the following error message, in a
message box:
Title: "Error in Tcl Script"
Text: "Error: can't read "ffmpeg_video_codec": no such variable"
Buttons: "Ok" "Skip Messages" "Stack Trace"
(Independent of what button I press, the program doesn't end.)
Clicking Stack Trace gives this:
------------------
can't read "ffmpeg_video_codec": no such variable
while executing
"puts $fileid "set ffmpeg_video_codec \"$ffmpeg_video_codec\"""
(procedure "save_v4l_capture" line 30)
invoked from within
"save_v4l_capture $fileid"
(procedure "save_settings" line 47)
invoked from within
"save_settings"
invoked from within
".video_menu invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tkMenuInvoke" line 47)
invoked from within
"tkMenuInvoke .video_menu 1
"
(command bound to event)
------------------
After this all config files seems to be destroyed :-(
Any ideas?
Greetings Ben
|
|
From: Vladimir D. <vo...@mi...> - 2002-06-29 17:04:17
|
On Sat, 29 Jun 2002, Torsten Howard wrote: > Hello, > > I've read the archive notes for the 8500DV. I'm considering > a purchase, and I'm wondering if someone could vouch for > functionality. I'll most likely be using xfree 4.2. > > I'm curious about the following: > Well, I have 8500 DV installed and I am writing message using it.. > 1) 2D accelerated works > 2) 3D accelerated There is a driver, but it is binary only, apparently created to support big ATI customers (i.e. IBM). Tungsten Graphics is working on open source driver. > 3) Accelerated DVD/TV playbak (Xv) Works great here. > 4) Fullscreen TV viewing (PAL and NTSC) (TV-in) Works. Will work better once I fix avview to *always* maximize the window in KDE. Note: I have NTSC only. PAL/SECAM tuning might (should ?) require some tinkering with the code. > 5) TV tuning (PAL and NTSC) > 6) TV encoding (mjpeg?) mpeg2/mpeg4 - use avview. you need fast cpu and hard disk for that. > 7) TV-out (PAL, NTSC) Nope. I do not not think that the experimental code will work with this card, it was written before it was supported. TV-out is a murky area anyway. > 8) Firewire Seems to work. Linux recognizes it, but I do not have any devices to test. > 9) Wireless Remote control Works fine. Note: for now use the CVS code which supports all the 16 channels of the remote. > > Webpage says 3d is not accelerated yet, but Nathan Smith posted that > it is working with firegl drivers. > > Also, there was some posts about sound output. Is it necessary to > boot into windows before linux to make the TV stuff work? I unfortunately > don't have windows at all. This is about AIW 7500, which has some problems because we do not know how to access i2c bus which controls tuner and audio chips. > > I've read no mention about capturing the video, I assume this is possible? > Hardware will be (2.4G P4, 2GB RAM). Likely this will do fine. see http://gatos.sf.net/km.php for more info. > > Finally, I will need to tune both PAL and NTSC videos. I have some videos > from home (PAL) that I want to digitize, is this feasible? That might have problems. First of all you need to have a VCR that can read them (i.e. a multisystem VCR). Secondly, I was having problems with my VCR with tapes that I made myself. It seems newer (and cheaper) VCRs turn on Macrovision always which causes decoder to lose sync. Vladimir Dergachev > > Thanks for the help, > Torsten > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > Gatos-devel mailing list > Gat...@li... > https://lists.sourceforge.net/lists/listinfo/gatos-devel > |
|
From: Torsten H. <to...@in...> - 2002-06-29 16:34:22
|
Hello, I've read the archive notes for the 8500DV. I'm considering a purchase, and I'm wondering if someone could vouch for functionality. I'll most likely be using xfree 4.2. I'm curious about the following: 1) 2D accelerated 2) 3D accelerated 3) Accelerated DVD/TV playbak (Xv) 4) Fullscreen TV viewing (PAL and NTSC) (TV-in) 5) TV tuning (PAL and NTSC) 6) TV encoding (mjpeg?) 7) TV-out (PAL, NTSC) 8) Firewire 9) Wireless Remote control Webpage says 3d is not accelerated yet, but Nathan Smith posted that it is working with firegl drivers. Also, there was some posts about sound output. Is it necessary to boot into windows before linux to make the TV stuff work? I unfortunately don't have windows at all. I've read no mention about capturing the video, I assume this is possible? Hardware will be (2.4G P4, 2GB RAM). Finally, I will need to tune both PAL and NTSC videos. I have some videos from home (PAL) that I want to digitize, is this feasible? Thanks for the help, Torsten |
|
From: Martyn R. <ran...@li...> - 2002-06-29 11:53:12
|
I seem to be getting one of these whenever I post to the list! ---------- Forwarded Message ---------- Subject: Date: Fri, 28 Jun 2002 15:44:08 -0400 From: ga...@ca... To: ran...@li... Sorry, freelabs.com is either Moved or Temporarily Disconnected Management Skyport Network ------------------------------------------------------- |
|
From: Vladimir D. <vo...@mi...> - 2002-06-28 20:27:05
|
Martyn, here is how it works:
The hardware decoder outputs (for PAL/SECAM) 720x240 (or 768x240 depending
on your card) fields 60 times per second. Two consecutive fields make an
interlaced _frame_.
Now the problem is that PC monitors display progressive video and not
interlaced. Thus deinterlacing is required.
Also, hardware decoder outputs data in YUV422 format, but MPEG files
consume YUV420.
Thus there are three good ways AVview can transform incoming video stream
into something MPEG encoder can consume:
1) average each horizontal line (half-width) mode and discard every other
color line. This results in 360x240 or 388x240 video
2) retain original size and discard every other color line. This results
in 720x240 or 768x240 video.
3) create new horizontal brightness lines by interpolating neighbouring
brightness lines and use color lines alternative for lines of different
parity. (double-interpolate). This results in 720x480 or 768x480 video and
retains most of the original information.
In all of the cases above you should capture at "half-rate" or smaller to
process fields of the same parity.
There are other deinteralacing algorithms (like weave) but they are not as
good with motion video. There is also known so called "adaptive"
deinterlacing that switches between being closer to double-interpolate or
weave depending on the picture, but it is not implemented in avview,
because a) I do not know how it works (and how well it works) and b)
whatever deinterlacing avview does must be done realtime.
Now, to your problem of creating video stream in a format you like. First
you need to compare the actual aspect ratios of incoming and outgoing
streams. Are they both 4:3 ? Or is one 4:3 and the other 16:9 ?
If they match you need to simply scale the image - check options in
whatever program you use to do that. Otherwise you are best painting part
of the image black to preserve the original aspect ration.
Lastly, to produce mpeg files AVview uses ffmpeg library. Thus if there is
any issue you should check it first. It is possible that avview is not
setting some parameter - if you find out which one I'll be glad to change
avview to do it properly.
Vladimir Dergachev
PS And, if you have not done so already, try avview from CVS - it is much
improved.
On Fri, 28 Jun 2002, Martyn Ranyard wrote:
>
> Hi Vladimir, Everyone,
>
> I am trying to post-process some captured files and I came across something
> I did not know about MPEG formats. They have a viewing aspect ratio.
>
> I captured at pal full-frame mode (720x240), thinking that any later resize
> would be better quality than half-width (360x240). What a mistake! the
> full-frame mode has an aspect ratio of 3:1 - I don't know what the aspect
> field says, but when I transcode to svcd (480x576), I get a nice long strip
> in the middle, because it's enforcing the aspect ratio! I don't wan't to
> have to mess around too much with post-processing, so does anyone know of a
> program to edit this field after recording, and could someone look into
> altering the field when recording starts.
>
> I still would like to see a way of getting to resize directly to a
> vcd/svcd/xsvcd res, but my programming powers don't work on anything but
> pascal! PAL .*vcd is 352x288, wheras NTSC .*vcd is 360x240 I believe. Is
> the fact that ATI capture is only 240 high an assumption of NTSC by ATI? If
> not, could when someone selects a PAL tuner, capture be done at 704x288?
>
> I cannot understand ffmpeg enough to tell me the answer to my final
> question - If the input is a file, then specifying a res before is fine, but
> I cannot specify an input res if the input is from v4l. Maybe I am just
> missing something. Also, for vcd capture, how do I tell ffmpeg to do fixed
> bit rate - I guess it must be possible as avview now has it!
>
> Thanks for everyone's patience and by the way, have downloaded the source
> to cinelerra, so will report back soon!
>
> Martyn
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
|
|
From: Martyn R. <ran...@li...> - 2002-06-28 19:42:46
|
Hi Vladimir, Everyone, I am trying to post-process some captured files and I came across something I did not know about MPEG formats. They have a viewing aspect ratio. I captured at pal full-frame mode (720x240), thinking that any later resize would be better quality than half-width (360x240). What a mistake! the full-frame mode has an aspect ratio of 3:1 - I don't know what the aspect field says, but when I transcode to svcd (480x576), I get a nice long strip in the middle, because it's enforcing the aspect ratio! I don't wan't to have to mess around too much with post-processing, so does anyone know of a program to edit this field after recording, and could someone look into altering the field when recording starts. I still would like to see a way of getting to resize directly to a vcd/svcd/xsvcd res, but my programming powers don't work on anything but pascal! PAL .*vcd is 352x288, wheras NTSC .*vcd is 360x240 I believe. Is the fact that ATI capture is only 240 high an assumption of NTSC by ATI? If not, could when someone selects a PAL tuner, capture be done at 704x288? I cannot understand ffmpeg enough to tell me the answer to my final question - If the input is a file, then specifying a res before is fine, but I cannot specify an input res if the input is from v4l. Maybe I am just missing something. Also, for vcd capture, how do I tell ffmpeg to do fixed bit rate - I guess it must be possible as avview now has it! Thanks for everyone's patience and by the way, have downloaded the source to cinelerra, so will report back soon! Martyn |
|
From: David S. <si...@da...> - 2002-06-27 23:15:01
|
The behavior was the same with or without the TV-out.
It turns out the problem was that Red Hat's version of libGL.so.1
was being loaded instead of my recently compiled version from
the "pure" XFree86 4.2 source. Apparantly Red Hat applies massive
patches to the XFree86 source (as they do to the kernel), and I
guess some of these modifications were not compatible with the
GATOS drm-kernel stuff. Now, I have TV-out and DRI working well
together.
I'm still seeing the text-mode screen mangling when I exit X,
but this is less of a problem. Even the attempts of "SVGATextMode -o"
to restore sane video timings doesn't restore the text-mode display.
I'm guessing that some code somewhere in drm-kernel or ati.2 is
setting an odd register on the card that is not getting properly
reset when X exits.
David
On Mon, 24 Jun 2002, Vladimir Dergachev wrote:
>
> Try checking whether DRI works fine without TV-out. If yes, there might be
> some interference.. Also, TV-out devel branch is quite old, perhaps trying
> out an older drm-kernel code will work better.
>
> Vladimir Dergachev
>
> On Mon, 24 Jun 2002, David Simmons wrote:
>
> >
> > I've been experimenting with the gatos drivers recently for my
> > ATI Radeon 7500 All-In-Wonder card. I seem to have everything
> > working (including TV-out), except for DRI. When I try to run
> > an application that uses DRI (glxgears, specifically), the
> > screen and keyboard freeze up. The mouse pointer can still be
> > moved around, but mouse events are not processed, and keyboard
> > functions like CTRL-ALT-Backspace and CTRL-ALT-F1 do not work.
> >
> > I am able to log into the box remotely to reboot. When I do
> > this, the machine appears to shut down most of the way (it
> > cannot be pinged), but it doesn't actually reboot and I have
> > to hit the reset button.
> >
> > Here's the specifics about my setup:
> >
> > Red Hat Linux 7.3
> > Custom 2.4.18 kernel build (without Red Hat mods)
> > Custom build of XFree86 4.2.0 source
> > ati.2 from the CVS "devel" branch, 6-19-2002
> > - installed modules into /usr/X11R6/lib/modules/{drivers,multimedia}
> > drm-kernel from Gatos CVS, 6-18-2002
> > - installed radeon.o into /lib/modules/2.4.18/kernel/drivers/char/drm/
> > modprobe agpgart
> > modprobe radeon
> > Start X in 640x480x16 with output to monitor and TV
> >
> > Also, when I start X, do not run a DRI application, and exit,
> > the text mode video is mangled.
> >
> > Does anyone have any pointers on what I might be doing wrong?
> >
> > Thanks,
> >
> > David
> >
> > --
> > David Simmons
> > "Today is a fine day for science!" -- Dexter
> >
|
|
From: Vladimir D. <vo...@mi...> - 2002-06-27 20:59:20
|
Shaw, could you try the new remote code from CVS (module ati_remote
in gatos CVS) ? Turns out that the remote can be configured to 16
different channels and old code supported only 1. New code should work
fine with all 16.
thanks
Vladimir Dergachev
On Wed, 27 Mar 2002, Shaw Riddell wrote:
> ok I have gotten the card and all working with Xfree and everything but I
> can't seem to get the remote nore the TV Sound output to work. I have
> tried to plug it in directly it is as if nothing is coming out of the
> audio port of the AIW card. Anybody have an ideas how to help me with
> those two??
>
> Shaw Riddell
>
>
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
|
|
From: David D S. <ult...@ul...> - 2002-06-27 08:34:36
|
>>>>> "Martyn" == Martyn Ranyard <ran...@li...> writes:
Martyn> Does anyone know of a premier-like editor for linux
Martyn> (ideally GPL) - and also has anyone seen a plugin for
Martyn> such, or premier, that will remove roll from the top of
Martyn> VHS recorded files - my TV manages it, so there's gotta be
Martyn> a standard formula for removing it.
I last used it when it was called broadcast 2000, but it was
wonderful. Far more powerful then premier and fully GPL'd. The author
removed it from cirulation (although mirrors are still available, such
as at tux.org) but has since been working quietly on an even better
replacement called Cinelerra which has just recently entered beta
(meaning its actually being promoted with a web page, rather then the
curious reader finding it in sourceforge CVS). I haven't tried it yet
so I can't say if its good for production use. If you do try it, would
you reply to me with how well it worked for you? See
http://heroinewarrior.com/cinelerra.php3 .
--
david
1024D/E6511C7E :: CE01 474D B8C6 CDE5 FA32 6DC9 1091 8EB9 E651 1C7E
Welcome to the best software in the world today cafe!
<http://ultrasoul.com/best_stuff.ogg>
|