zapping-misc — General discussion

[Zapping-misc] Re: [V4L] Re: [Ffmpeg-devel] Reducing loss of quality while recoding

[Billy B. <ve...@du...>]

Zdenek Kabelac (ka...@in...):

> VirtualDub & Huffyuv - one day might be working in linux :) but right
> now I'm not sure which day it will be - but it will

  FWIW, I have a prediction-based lossless compressor (huffyuv-style) in
my (incomplete) v4l recording app 'reetpvr'.  Check out the
diffcomp.[c,h] files in CVS at www.sf.net/projects/reetpvr/ if you have
any thoughts on better compression, optimizing the code, or want to
standardize on a fourcc for it or something.

> - If I would be you - just byu a Duron and compress into MPEG4 in
> realtime it's really waste of energy and your time in my eyes...
> (well unless you plan to compress 720x520 sized image :)

  I can happily record full 720x480 using reetpvr without dropping
frames of video or audio using 'reetpvr'.  I have a P3-733 and a
bttv-compatible card.

-- 
Billy Biggs
ve...@du...

[Zapping-misc] Re: [Ffmpeg-devel] Reducing loss of quality while recoding

[Zdenek K. <ka...@in...>]

> 1) If there is a large harddisk availlable, one could bear a relatively
>    low, but sufficiently artefact/lossless encoding while recording
>    and recompress better afterwards.
>    Which tools are availlable for this? (reliable capture and
>    optimal recompression)

VirtualDub & Huffyuv - one day might be working in linux :) but right now
I'm not sure which day it will be - but it will

> 2) Could ffmpeg's encoders benefit from a postprocessing-filter 
>    between the decoder and the encoder while doing recoding?

It will be always getting worse if you will be recompressing already
compressed image - it's the same as for JPEGs

- If I would be you - just byu a Duron and compress into MPEG4 in realtime
it's really waste of energy and your time in my eyes...
(well unless you plan to compress 720x520 sized image :)


-- 
  .''`.  Which fundamental human right do you want to give up today?
 : :' :      Debian GNU/Linux maintainer - www.debian.{org,cz}
 `. `'  Zdenek Kabelac  kabi@{debian.org, users.sf.net, fi.muni.cz}
   `-         Resistance is futile. You all will be packaged

[Zapping-misc] Reducing loss of quality while recoding

[<R.O...@GD...>]

Hi, List

I'm starting to try to burn video from bt878 to CD.
1) I do the grabbing with the only tool I found that ensures
   very good sync between audio and video, which uses low CPU,
   which runs without framedrops at high resolutions at a 
   K6III-450 and which keeps sync also in case of eventual 
   framedrops:
   "mp1e"
2) Finally I want to have a File with MPEG4 and MP2/3 inside.
   So I convert the movie with ffmpeg from MPEG1 to MPEG4.
3) The resulting video quality is always worse than the MPEG1-
   source. Even with high bitrates.

I found one systematic problem:
Isn't the MPEG4-format meant to allow for better quality at low bitrates?
Of course, conversions are lossy. I'm not quite sure, but I think,
that the MPEG4-encoder suffers from the MPEG1-artefacts, and it could
give much better results at the same bitrate, if it would get a more
original-like picture for input.
Two questions come to mind:

1) If there is a large harddisk availlable, one could bear a relatively
   low, but sufficiently artefact/lossless encoding while recording
   and recompress better afterwards.
   Which tools are availlable for this? (reliable capture and
   optimal recompression)
2) Could ffmpeg's encoders benefit from a postprocessing-filter 
   between the decoder and the encoder while doing recoding?



One text I read at the internet gave theese thoughts to me:


At "http://www.math.berkeley.edu/~benrg/huffyuv.html#MJPEG", 
which describes a project for lossless video-grabbing one can
read:
> Why not use Motion JPEG?
> If you capture video in order to edit it and output it back to tape,
> then Motion JPEG is probably perfectly adequate. It's also a good 
> archival format. However, if you're producing MPEG video (or any lossy
> format), you should avoid using MJPEG (or any lossy format) in your 
> intermediate files if you can. The reason is that JPEG was designed 
> for viewing, not image processing. JPEG achieves its compression
> by exploiting known weaknesses in the human perceptual system, but 
> computers don't see images the way people do: an MJPEG clip which 
> looks fine to you may not look so good to an MPEG encoder. As
> a rule, MPEG encoders are very sensitive to noise, and MJPEG 
> is basically an avoidable source of noise. 


Regards,
        Ralf

 -----------------------------------------------------------------
|  Ralf Oehler
|  GDI - Gesellschaft fuer Digitale Informationstechnik mbH
|
|  E-Mail:      R.O...@GD...
|  Tel.:        +49 6182-9271-23 
|  Fax.:        +49 6182-25035           
|  Mail:        GDI, Bensbruchstraße 11, D-63533 Mainhausen
|  HTTP:        www.GDImbH.com
 -----------------------------------------------------------------

time is a funny concept

[Zapping-misc] VIDIOCCAPTURE failed

[Daniel K. <Tr...@we...>]

If i use zapping as normal user, i get this error if i want
to switch to preview mode, but it works if i use zapping as root
first (..start zapping as root, close zapping, open zapping as user)

Error: callbacks.c (307) [on_go_previewing2_activate]:
[tveng1.c] tveng1_set_preview (line 2207)
VIDIOCCAPTURE failed: Invalid argument

System: (XFree 4.1.0, linux 2.4.7 (RH 7.2), NVIDIA GeForce2 MX (with
binary driver from NVidia))

Daniel Kenzelmann

[Zapping-misc] [ zapping-Bugs-448902 ] TV Overlay exceeds bottom of window

[<no...@so...>]

Bugs item #448902, was opened at 2001-08-07 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=448902&group_id=2599

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Green (james)
Assigned to: Iñaki García Etxebarria (garetxe)
Summary: TV Overlay exceeds bottom of window

Initial Comment:
Using a cvs build pulled today, the image of the
televison picture overflows the bottom of the zapping
window.

The bottom border of the window is rougly five-ten
pixels too high. This occurs in all aspect ratio modes.

Using XF4.1. I guess I'm using XVideo since zapping
eats my cpu while in normal mode.

I'd call this is a pretty serious bug.


----------------------------------------------------------------------

>Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-10-22 10:18

Message:
Logged In: YES 
user_id=7928

The patch should fix the driver, I'm pretty convinced the
rouding comes from there.

----------------------------------------------------------------------

Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-08-09 14:39

Message:
Logged In: YES 
user_id=7928

Are you really using XVideo? I can see this effect, but only
when doing overlay with the bttv2 driver (it rounds the
given size to the nearest safe size). A workaround in Z for
this would involve a lot of ugly code i don't really want to
write, it's better to fix the driver.
Download latest bttv2 from CVS and apply this patch:
Index: bttv-driver.c
===================================================================
RCS file: /cvsroot/bttv-v4l2/bttv2/bttv-driver.c,v
retrieving revision 1.29
diff -u -u -r1.29 bttv-driver.c
--- bttv-driver.c       2001/07/02 07:51:36     1.29
+++ bttv-driver.c       2001/08/09 21:33:43
@@ -1445,7 +1445,17 @@
        i = find_format(btv->fb.fmt.pixelformat);
        if(!formats[i].packed) {
                btv->win.height &= ~3;
-               btv->win.width &= ~15;
+               switch (formats[i].pixelformat) {
+               case V4L2_PIX_FMT_RGB555:
+               case V4L2_PIX_FMT_RGB565:
+               case V4L2_PIX_FMT_BGR24:
+               case V4L2_PIX_FMT_BGR32:
+                       btv->win.width &= ~3;
+                       break;
+               default:
+                       btv->win.width &= ~15;
+                       break;
+               }
        } else {
                btv->win.width *= formats[i].bpp;
                btv->win.width >>= 5;

Regards,
Iñaki

PD: James, are you still having the freezes with bttv2?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=448902&group_id=2599

[Zapping-misc] [ zapping-Bugs-423785 ] Improve Aspect Ratio Support

[<no...@so...>]

Bugs item #423785, was opened at 2001-05-13 13:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=423785&group_id=2599

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Green (james)
Assigned to: Iñaki García Etxebarria (garetxe)
Summary: Improve Aspect Ratio Support

Initial Comment:
Here in the UK, various parties are hopping about
trying to get everyone to accept digital television one
way or another. We have had Cable installed which gives
us digital signals.

These digital signals are very often carrying both
traditional 4:3 and widescreen 16:9 aspect ratios.
Indeed, almost all our channels now broadcast
significant widescreen programming on digital - some
channels are broadcasting a widescreen 16:9 format over
analog.

This places more importance on television reception
devices being able to tell whether it is receiving
widescreen or traditional ratios, and adjust the
picture to be correct. Zapping is unable to do this.

What is needed is a much simpler and faster method for
changing aspect ratio. I see two possible ways of doing
this:

1. If the user can get a widescreen signal, they should
adjust zapping's window size to be able to contain the
image in widescreen mode. When the broadcast is in
widescreen, the full area is used; when the broadcast
is in 4:3 mode, black borders shall appear on the left
and right of the picture, and the tv image be re-sized
to reduce it's X axis, thus restoring the 4:3 ratio.

2. The user shall have a menu option, very quick to
access, that chooses the aspect ratio. On change, the
window resizes to that ratio.


Problems:

With 1. zapping would need to detect the lack of
widescreen input and perform the image scaling itself.
I know widescreen television sets do this, but whether
software can do it, I do not know. This setting
detection would need to be in a 'loose' loop since the
broadcast may change between a 4:3 tv program then a
16:3 tv advert, then back to the 4:3 prgram (it happens
frequently here), I say loose because you don't want to
hang the cpu on this matter.

With 2. the entire window shifts and cause cause
annoying flicker.


This probably warrants some discussion, particularly
from a technical standpoint.


----------------------------------------------------------------------

>Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-10-22 10:17

Message:
Logged In: YES 
user_id=7928

ok, closing.

----------------------------------------------------------------------

Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-09-29 08:01

Message:
Logged In: YES 
user_id=7928

We've aspect ratio autodetection in 0.6.1, should I close
this one?
Please keep in mind that sawfish (at least 0.3x) doesn't
support constant aspect ratio, so better test the feature
with Windowmaker, E, or any other window manager that
supports constant aspect ratio.

----------------------------------------------------------------------

Comment By: Michael H. Schimek (mschimek)
Date: 2001-05-31 12:50

Message:
Logged In: YES 
user_id=46861

Comment By: James Green (james)
> If you are on analog, you can see as many as three modes:
> 1) full 4:3 picture
> 2) full 16:9 picture (large black bars top and bottom)
> 3) an in-between mode in which the black bars are 1/4th
the
>    size they would be in 16:9 mode.

You're sure about 1/4 (2 x 18 lines), not 1/2 (2 x 36)?
Never mind. It's probably close enough if Zapping supports
four or five of the most usual ratios. When the exact
numbers aren't transmitted we can't reliable detect anyway.

> Now, when in analog, our main TV (widescreen) detects the
> black bars in 16:9 mode and zooms in on the picture (which
> is blown up somewhat. In digital, more often than not the
> picture is crystal-clear widescreen, i.e. there's no
blowing
> up (scaling) of the image.

Makes perfect sense. They broadcast anamorphic on digital
which all boxes can handle, lbx on analog to get a normal
picture on old 4:3 TVs.

> On our digital boxes we have a menu to select which mode
to
> use: 
> 1) 4:3
> 2) 16:9 letterbox
> 3) 16:9 widescreen
>
> >From what I can tell, 2) is pretty much identical to 3).
Not
> sure what the difference is, really.

I guess 2) scales anamorphic to lbx for 4:3 TVs and 3)
leaves anamorphic unchanged for 16:9. Your widescreen zooms
into 2), so it resembles stretched 3). Wonder what 1) is,
maybe pan & scan,
seems redundant otherwise.

Michael


----------------------------------------------------------------------

Comment By: James Green (james)
Date: 2001-05-30 06:57

Message:
Logged In: YES 
user_id=1174

I see several things going on here.

If you are on analog, you can see as many as three modes:

1) full 4:3 picture
2) full 16:9 picture (large black bars top and bottom)
3) an in-between mode in which the black bars are 1/4th the
   size they would be in 16:9 mode.

When I switch to digital:

1) Full 4:3 picture
2) full 16:9 picture (in 4:3 windowed mode the picture is
   horizontally compressed, widen the window to get it to
   normal) (what you call anamorphic?)
3) the same in-between mode as per analog (although this
   rarely happens)

Now, when in analog, our main TV (widescreen) detects the
black bars in 16:9 mode and zooms in on the picture (which
is blown up somewhat. In digital, more often than not the
picture is crystal-clear widescreen, i.e. there's no blowing
up (scaling) of the image.

So clearly there are various modes and half-way-houses
depending on whether you're a digital customer or not.

On our digital boxes we have a menu to select which mode to use:

1) 4:3
2) 16:9 letterbox
3) 16:9 widescreen

From what I can tell, 2) is pretty much identical to 3). Not
sure what the difference is, really.

Also, on our widescreen TV, we have the option of 14:9 mode.
This is apparently never used...

Quite what software techniques are being used here I do not
know. I might phone up our cable provider and see.


----------------------------------------------------------------------

Comment By: Michael H. Schimek (mschimek)
Date: 2001-05-30 02:29

Message:
Logged In: YES 
user_id=46861

Hi James and Iñaki,

Let me clarify: We're talking about the legacy 4:3 format,
letterboxed 16:9 (or 2:1 or another aspect ratio) with black
bars on top and bottom, and anamorphic 16:9 which is
squeezed horizontally to fit standard PAL/NTSC resolution.
Moreover there's an analog transmission system PALPlus,
hiding information in the letterbox bars a PALPlus decoder
can use to increase the vertical resolution cf. anamorphic.

A 4:3 anamorphic aware TV will shrink the picture
vertically, that is by modifying the electron beam
deflection, creating a letterboxed picture but with greater
vertical resolution. A 16:9 TV displays 4:3 with black bars
to the left and right. Letterboxed programs (and possibly
also 4:3) will be magnified to fill the screen, cutting off
the black bars. Anamorphic programs (and possibly also 4:3)
are stretched in horizontal direction, probably by means of
beam magic as well.

Apart of TVs with buttons to switch between display modes,
there are two systems encoding the correct aspect ratio I
know. First, this information is an integral part of every
MPEG-2 stream on DVD or DVB. Second, there's the analog Wide
Screen Signalling (WSS) which is encoded on a scanning line
similar to Teletext, however at a lower bit rate to be
recorded on standard VHS. It was originally devised and
mandatory for PALPlus, including hints for the decoder,
audio and subtitle flags, but it has been recommended for
general use as well.

MPEG (eg. a digital VCR) can very well record WSS. If the
stations transmit analog WSS or it's inserted at the analog
cable feed (same as Teletext) I don't know. Anyway, one
specific property makes WSS decoding a little difficult for
Zapping: It's encoded in the VBI, on the first half of line
23. Active video starts exactly on line 23.5. Sounds odd but
is a logical consequence of the constant vertical velocity
of the electron beam.

Now a PAL image really consists of 574 + 2/2 active lines.
When the video driver captures 576 lines and is correctly
adjusted, it should capture all of line 23, and our libvbi
could decode WSS from the RGB or YUV picture. You can verify
yourself, WSS is a funny Morse pattern in the top left
corner. (Side note: Maybe we should blank 23.0/623.5, it's
ugly.) Of course scaling by the driver may harm the signal
beyond recognition (352x288, first field only, would still
work FX).

Another option is to decode from VBI, provided the driver
volunteers line 23 as part of the VBI image (the v4l2 and
v4l/2.4 API allow to request any VBI lines). That depends if
the driver can overlap the VBI and video capture window, or
shift the video window down, yet another difficulty to write
a book about. A third, more theoretical option exists in
form of hardware with built-in WSS (TTX, VPS, CC, ...)
decoder, but to this date no sliced VBI API matured and to
my knowledge, aside of parport TTX devices no such drivers
exist.

Conclusion: Automatic aspect ratio correction, letterbox
cutting (on screen or eg. for recording), selection of the
proper stereo mux (eg. correctly recording
mono/stereo/bilingual) is possible, albeit tricky.
Fullscreen mode needs further consideration (16:9 monitors,
XF86 Modelines anyone?). I'm awaiting Iñaki's opinion on the
matter.

Michael


----------------------------------------------------------------------

Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-05-13 15:27

Message:
Logged In: YES 
user_id=7928

Hi James,

you raise some really interesting points, thanks a lot for
bringing this into my attention.
Btw, feel free to reply by usual mail
(ga...@us...), that's easier for me too,
and this is going to be a long reply :-)

There are many things here, let's start from easier to harder:
- Flicker: If you have a reasonably new XFree (4.0.2 at
least), loading the v4l driver can make wonders (i.e., no
flicker at all). For it to work, your video driver (mga,
ati, whatever) must include a couple of calls, it's pretty
straightforward to do (i wrote a 15-line patch to the ati
driver a couple of weeks ago that did this, just a
20-minutes work if you know what you are doing, it will be
included in the next Xfree version). If you tell me the
driver you use, I could cook up a patch for Xfree CVS and
send it to the maintainer, so next Xfree won't flicker :-)
And flicker can be disabled temporarily by Z if it knows
that geometry is going to change (TTX subtitles OSD does
this, for example, to avoid flicker).

- Now that flicker isn't an issue ;-), (2) seems a good
(temporary) solution. Some key combo could be used to switch
between 16:9 and 4:3, but that's still annoying. A better
solution would be, as you suggest, to autodetect which ratio
is being used, but I must admit that I don't know how to
autodetect 16:9 vs 4:3. I suppose it's explained somewhere
in the Web, do you know of any place/doc/spec? Hopefully
it's transmitted in VBI, and we can filter that.

- Scaling: If we finally decide that (2) is the way to go,
then the following must be taken into account:
a) With XVideo backend scaler, scaling is a completely
trivial task, everything done in HW. Actually, you always
are scaling.
b) Without XVideo, you would need a powerful box, and
efficient MMX code to get 25fps in realtime if you really
want to scale the full frame, at, say 640x480. But probably
you don't really want to scale :-) Using interlacing
properly and smartly placed clips can achieve the same
effect without extra CPU usage (it's late at night, but i'm
comfident that this is feasible).

Thoughts?

I hope hitting send works now, this has taken a long time to
write, and the first time I tried it didn't work ;-)

Regards,
Iñaki

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=423785&group_id=2599

[Zapping-misc] [ zapping-Bugs-459849 ] lockup on close

[<no...@so...>]

Bugs item #459849, was opened at 2001-09-08 12:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=459849&group_id=2599

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matt Adam (sylphid)
Assigned to: Nobody/Anonymous (nobody)
Summary: lockup on close

Initial Comment:
i'm in canada, so i need to change the default input
standard to NTSC.  whenever i do so, and quit zapping,
it locks up on exit (if i DON'T change anything, just
start it up and quit, it's ok).

the problem of course is that it locks up before
writing out the config file, so i have to reconfigure
all my stations and inputs every time (canada has a
wierd station table, so this makes zapping all but
unusable for me).

here's the last few lines from strace, it just locks at
the end.  let me know if there's anything else i can do:

munmap(0x40017000, 4096)                = 0
write(3, "+\20\1\0", 4)                 = 4
read(3, 0xbffff75c, 32)                 = -1 EAGAIN
(Resource temporarily unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\1\2\32#\0\0\0\0\23\0
\1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
munmap(0x406b4000, 10304)               = 0
munmap(0x406a7000, 23168)               = 0
munmap(0x406ad000, 25260)               = 0
ioctl(10, 0x80287610, 0xbffff3a4)       = 0
ioctl(10, 0x40287611, 0xbffff3a4)       = 0
ioctl(10, 0x80287610, 0xbffff234)       = 0
ioctl(10, 0x800e7606, 0xbffff25c)       = 0
munmap(0x40712000, 495616)              = 0
munmap(0x4078b000, 495616)              = 0
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]


----------------------------------------------------------------------

>Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-10-22 10:11

Message:
Logged In: YES 
user_id=7928

uops, forgot to remove this bug. I fixed it a couple of
weeks ago in CVS.
Thanks for reporting.

----------------------------------------------------------------------

Comment By: Matt Adam (sylphid)
Date: 2001-09-29 18:25

Message:
Logged In: YES 
user_id=284245

aha. disabling vbi indeed fixes it (but... no vbi!)

thanks for the tip

very nice program, by the way :) keep up the good work

----------------------------------------------------------------------

Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-09-29 08:12

Message:
Logged In: YES 
user_id=7928

Appears to be a bug in libvbi, perhaps running with --no-vbi
works around it before we fix the bug.

----------------------------------------------------------------------

Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-09-12 16:28

Message:
Logged In: YES 
user_id=7928

zapping -d makes Z print out what is it doing on close,
could you please send the output of that?
If it isn't a hard freeze, a good way to know where does it
hang is to run it under gdb:

gdb ./zapping
(gdb) run
... {do things, close, hangs, now in another console:}
killall zapping
{back to the gdb console}
(gdb) bt

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=459849&group_id=2599

[Zapping-misc] [ zapping-Bugs-473614 ] Missing LIBGLADE_CFLAGS

[<no...@so...>]

Bugs item #473614, was opened at 2001-10-22 02:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=473614&group_id=2599

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing LIBGLADE_CFLAGS

Initial Comment:
Missing LIBGLADE_CFLAGS in COMMON_INCLUDES. In some
enviroments (like in my) it's required to get all
libglade includes in gcc include path. Attached patch
fixes that.

----------------------------------------------------------------------

>Comment By: Iñaki García Etxebarria (garetxe)
Date: 2001-10-22 10:09

Message:
Logged In: YES 
user_id=7928

Thanks a lot for the patch, applied to CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=473614&group_id=2599

[Zapping-misc] [ zapping-Bugs-473614 ] Missing LIBGLADE_CFLAGS

[<no...@so...>]

Bugs item #473614, was opened at 2001-10-22 02:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=473614&group_id=2599

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing LIBGLADE_CFLAGS

Initial Comment:
Missing LIBGLADE_CFLAGS in COMMON_INCLUDES. In some
enviroments (like in my) it's required to get all
libglade includes in gcc include path. Attached patch
fixes that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=102599&aid=473614&group_id=2599

Re: [Zapping-misc] mp1e hangs

[Michael H. S. <msc...@us...>]

R.O...@GD... wrote:
> 
> What am I doing wrong, and what about this videodevX, with which I cannot
> compile bttv-0.8.29 ?

Sorry 'bout the misleading videodevX tip, apparently already in Gerd's
patch collection. Must be the 4th incarnation floating around. Dunno why
sound does/does not work, maybe another bt8x8 owner knows.

Michael

Re: [Zapping-misc] mp1e hangs

[<R.O...@GD...>]

Hello, Michael

> R.O...@GD... wrote:
>> I just installed a SuSE-73 with kernel 2.4.10 and XFree4. I want to
>> change to the new v4l2.
> 
> You need to replace the kernel videodev module with videodevX from
> <http://www.thedirks.org/v4l2/>, and the videodriver with a v4l2 aware
> version. I suppose you have a bt8x8 card and want bttv 0.8.x from
> <http://bytesex.org/bttv/>. You need not patch the kernel AFAIK.
> 

Yes. bt8x8.
I read these pages and tried to upgrade my system to v4l2 yesterday.
It succeeded a little bit, but not completely. 
On http://bytesex.org/bttv/ Gerd Knorr says:
        [...] version 0.8.29 [...] Major rewrite of the bttv core
        code. Requires kernel 2.4 + afew patches.
So I guess I do have to patch the kernel...
This is what I did:

1)  untarred linux-2.4.12
2)  patched with the patches in http://bytesex.org/patches/2.4.12/
3)  configured, compiled, booted the new kernel 2.4.12pci64
4)  untarred videodevX-20011005.tgz form http://www.thedirks.org/v4l2/
    into a directory outside the kernel
5)  "make"d it, "make installed" it
6)  untarred bttv-0.8.29.tar.gz
7)  tried to "make" it, but it complained about redefined symbols
    and missing definitions in "videodev.h". Did not compile.
8)  "make uninstalle"d videodevX (fortunately it has a uninstaller)
9)  tried to "make" bttv, now it compiled. "make installe"d it.
10) started xawtv: I got video, I could change channels, but no audio.

After this, I repeated the procedure (without videodevX now) and renamed
the bttv from step 3) to bttv1, after installing bttv-0.8.29, I renamed
this one to bttv2. depmod -ae.

Now I typed "modprobe bttv1;xawtv". I got video and sound.
modprobe -r ....
"modprobe bttv2;xawtv". I got video but no sound.

What am I doing wrong, and what about this videodevX, with which I cannot
compile bttv-0.8.29 ?

Regards,
        Ralf

 -----------------------------------------------------------------
|  Ralf Oehler
|  GDI - Gesellschaft fuer Digitale Informationstechnik mbH
|
|  E-Mail:      R.O...@GD...
|  Tel.:        +49 6182-9271-23 
|  Fax.:        +49 6182-25035           
|  Mail:        GDI, Bensbruchstraße 11, D-63533 Mainhausen
|  HTTP:        www.GDImbH.com
 -----------------------------------------------------------------

time is a funny concept

Re: [Zapping-misc] What happens in preview mode?

[Heiko B. <Hei...@In...>]

Hi!

On 17 Oct 2001, I=F1aki Garc=EDa Etxebarria wrote:
> As promised, I've commited to CVS the changes needed to start writing
> the mga_vid video backend (but you will still have to write that code
> :-)), see x11stuff.[ch] for the API video backends should conform to and
> video_xv.c for an example using XVideo.

Ok, thank you.  But I can't check that before the end of next week.
Most important exam in my whole little life next wednesday :-O I'm
finishing my study and this is all what counts these days :)

Btw, that cpu time consumption mentioned earlier must be a problem with
window exposures. I noticed 0% cpu usage with clean desktops.


See ya,
Heiko.



--=20
[ Mail ....................... hei...@in...  ]
[ Homepage ...................... http://www-user.tu-chemnitz.de/~heba/  ]
[ Second hand CD list .... http://www.tu-chemnitz.de/~heba/cd-list.html  ]
[ B&W photography ................................ http://www.septem.de  ]

Re: [Zapping-misc] What happens in preview mode?

[E. <ga...@eu...>]

Hi everyone,

> >for common window sizes. I'm interested displaying the images via
> >MPlayer's mga_vid device, it improves frame rates dramatically.
> >Has anyone alredy checked that possibility?  I don't know nothing
> >about it's API but I would give it a try, if I can handle the code ;-))
> >
> I also have a Matrox card, and use mplayer with the mga driver.
> I spoke to I=F1aki about it, and I would be really interested in=20
> partisipating to develop a mga driver for zapping (also fullscreen)
As promised, I've commited to CVS the changes needed to start writing
the mga_vid video backend (but you will still have to write that code
:-)), see x11stuff.[ch] for the API video backends should conform to and
video_xv.c for an example using XVideo.
If you have any questions, please don't hesitate to ask, i'm willing to
help with this.

Kind regards,
I=F1aki

Re: [Zapping-misc] RTE

[Michael H. S. <msc...@us...>]

Federico Omoto wrote:
> 
> I was unable to compile RTE (cvs version) with the latest ALSA drivers
> (0.9.0beta8).

Slowly I'm losing all my credibility. :-)

Is corrected, but rte in cvs still doesn't work.

Michael

[Zapping-misc] RTE

[Federico O. <fed...@sp...>]

Hi!

I was unable to compile RTE (cvs version) with the latest ALSA drivers 
(0.9.0beta8).

Here's the errors I have:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_GNU_SOURCE -D_REENTRANT -DFLOAT=float 
-Wall -O2 -fomit-frame-pointer -Wp,-MD,.deps/alsa.pp -c alsa.c  -fPIC -DPIC 
-o .libs/alsa.lo
alsa.c:63: `SND_PCM_SFMT_S16_LE' undeclared here (not in a function)
alsa.c:63: initializer element is not constant
alsa.c:63: (near initialization for `alsa_format_preference[0][0]')
alsa.c:64: `SND_PCM_SFMT_U16_LE' undeclared here (not in a function)
alsa.c:64: initializer element is not constant
alsa.c:64: (near initialization for `alsa_format_preference[1][0]')
alsa.c:65: `SND_PCM_SFMT_U8' undeclared here (not in a function)
alsa.c:65: initializer element is not constant
alsa.c:65: (near initialization for `alsa_format_preference[2][0]')
alsa.c:66: `SND_PCM_SFMT_S8' undeclared here (not in a function)
alsa.c:66: initializer element is not constant
alsa.c:66: (near initialization for `alsa_format_preference[3][0]')
alsa.c: In function `wait_full':
alsa.c:646: `now' undeclared (first use in this function)
alsa.c:646: (Each undeclared identifier is reported only once
alsa.c:646: for each function it appears in.)
alsa.c:648: structure has no member named `time'
alsa.c:649: structure has no member named `time'
alsa.c:654: structure has no member named `time'
alsa.c:654: structure has no member named `start'
alsa.c:655: structure has no member named `time'
alsa.c:657: structure has no member named `start'
make[4]: *** [alsa.lo] Error 1
make[4]: Leaving directory `/root/temp/rte/mp1e/audio'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/root/temp/rte/mp1e'
make[2]: *** [all-recursive-am] Error 2
make[2]: Leaving directory `/root/temp/rte/mp1e'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/temp/rte'
make: *** [all-recursive-am] Error 2

I have to use ALSA 0.5.11 or 0.5.9 to let RTE compile?

Thank you in advance.

Federico

Re: [Zapping-misc] mp1e hangs

[Michael H. S. <msc...@us...>]

Hi Ralf,

R.O...@GD... wrote:
> 
> 1) When I try to capture a movie with mp1e then mp1e runs some seconds during
>    which the CPU load is 100%(ca. 40% user) without framedops. After a while
>    (2-60 Seconds, depending on output bitrate) the CPU-user-load slowly (within
>    about 5 sec.) drops to nearly zero while framedrops occure and raise up to
>    100%. After this mp1e completely ceases writing to stdout. It still reacts on
>    Ctrl-C by printing a line, but it does not abort.
>    Mplayer plays the resulting file.
>    One more thing: The hang does not occure when I capture video-only or
>    audio-only

Sounds like a sync problem. You're probably using v4l(1), the
time stamping code turned out unreliable, should be fixed now in CVS. I
found another off-by-one bug incorrectly initializing frame_rate_code in
the new option_set, although I'm not sure this ever left my HD and it
shouldn't affect sync anyway. If the problem persists, please send me a
copy of the "mp1e -vvvv ..." stderr output.

> 2) mp1e seems to write audio data, at least ffmpeg reports to find an audio
>    channel when I preprocess the stream, but I did not manage to get any sound
>    out of mplayer. Neither with the mp1e-stream nor with any stream produced by
>    ffmpeg. Neither with OSS nor with ALSA. Xmms and Xawtv both let me hear
>    sound.

If you're talking about mp1e a+v, this can be a side effect of said bug.
When it happens always I'd check the audio mixer device, volume and
recording source. The mp1e defaults may not suite your sound card. Or
maybe it opens the wrong device. Some encoding bug is always possible
but somewhat unlikely, and other recording apps should work normal. When
encoding didn't abort or otherwise misbehave, and mp2 to wav conversion
shows no unexpected sample patterns (such as waves or a DC offset) this
rather points to one of the former causes. Maybe the driver isn't well
configured or bugged, cabling isn't correct or the sound card is broken.

Michael

Re: [Zapping-misc] autogen.sh doesn't work

[E. <ga...@eu...>]

> Hi !
Hi,

> After download latest version from cvs ./autogen.sh fails:
Could be an autoconf issue, i'll try upgrading to 2.52 this week to see
whether sth fails.

But before I go through all the trouble, did anyone in the list manage
to autogen.sh/configure/make with autoconf 2.52 or can point to another
source of the problem?

I=F1aki

Re: [Zapping-misc] unable to go full screen?

[E. <ga...@eu...>]

> The docs are slowly getting there, at present, got a lot of stuff with
> regards to the servers at work and perl and sql, so they are still
> coming on, but a bit slower as ive got a little less time on my hands
> these days...But they will be finished...Soooooooooon..
Excellent, looking forward to them.

Thanks,
I=F1aki

[Zapping-misc] autogen.sh doesn't work

[<DVo...@t-...>]

Hi !

After download latest version from cvs ./autogen.sh fails:

root@PCNEU /privat/tv/zapping > ./autogen.sh
**Warning**: I am going to run `configure' with no arguments.
If you wish to pass any to it, please specify them on the
`./autogen.sh' command line.

processing .
Creating ./aclocal.m4 ...
Running gettextize...  Ignore non-fatal messages.
Wiping out intl/ subdirectory
Copying file ABOUT-NLS
Copying file intl/ChangeLog
Copying file intl/Makefile.in
Copying file intl/VERSION
Copying file intl/bindtextdom.c
Copying file intl/config.charset
Copying file intl/dcgettext.c
Copying file intl/dcigettext.c
Copying file intl/dcngettext.c
Copying file intl/dgettext.c
Copying file intl/dngettext.c
Copying file intl/explodename.c
Copying file intl/finddomain.c
Copying file intl/gettext.c
Copying file intl/gettext.h
Copying file intl/gettextP.h
Copying file intl/hash-string.h
Copying file intl/intl-compat.c
Copying file intl/l10nflist.c
Copying file intl/libgettext.h
Copying file intl/libgnuintl.h
Copying file intl/loadinfo.h
Copying file intl/loadmsgcat.c
Copying file intl/localcharset.c
Copying file intl/locale.alias
Copying file intl/localealias.c
Copying file intl/ngettext.c
Copying file intl/plural.y
Copying file intl/ref-add.sin
Copying file intl/ref-del.sin
Copying file intl/textdomain.c
Copying file po/Makefile.in.in
Adding an entry to po/ChangeLog (backup is in po/ChangeLog~)

Please add the files
  codeset.m4 gettext.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

Making ./aclocal.m4 writable ...
Running libtoolize...
You should add the contents of `/usr/share/aclocal/libtool.m4' to 
`aclocal.m4'.
Running aclocal  -I macros ...
aclocal: configure.in: 280: macro `AM_PATH_LIBGLADE' not found in library
Running autoheader...
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
Running automake --gnu  ...
Use of uninitialized value in pattern match (m//) at /usr/bin/automake line 
3460.
configure.in: 6: required file `./config.h.in' not found
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
macros/Makefile.am:32: INSIDE_GNOME_COMMON does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
automake: src/Makefile.am: Assembler source seen but `AS' not defined in 
`configure.in'
automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not defined in 
`configure.in'/usr/share/automake/am/depend2.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
Running autoconf ...
configure.in:5: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:6: error: possibly undefined macro: AM_CONFIG_HEADER
configure.in:11: error: possibly undefined macro: AM_ACLOCAL_INCLUDE
configure.in:13: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.in:53: error: possibly undefined macro: AM_PROG_CC_STDC
configure.in:139: error: possibly undefined macro: AM_CONDITIONAL
configure.in:280: error: possibly undefined macro: AM_PATH_LIBGLADE
configure.in:286: error: possibly undefined macro: AM_GNU_GETTEXT
Running ./configure --enable-maintainer-mode --enable-compile-warnings ...
./configure: line 938: syntax error near unexpected token 
`AM_INIT_AUTOMAKE(zapping,'
./configure: line 938: `AM_INIT_AUTOMAKE(zapping, 0.6.2cvs)'

Compile of 0.6.1final works without any problem.

I use autoconf 2.52 !

Dirk

[Zapping-misc] mp1e hangs

[<R.O...@GD...>]

Hi, List

I'm new to this project and need some advice. Maybe I found a bug, or maybe I
just configured something wrong.

1) When I try to capture a movie with mp1e then mp1e runs some seconds during
   which the CPU load is 100%(ca. 40% user) without framedops. After a while
   (2-60 Seconds, depending on output bitrate) the CPU-user-load slowly (within
   about 5 sec.) drops to nearly zero while framedrops occure and raise up to
   100%. After this mp1e completely ceases writing to stdout. It still reacts on
   Ctrl-C by printing a line, but it does not abort.
   Mplayer plays the resulting file.
   One more thing: The hang does not occure when I capture video-only or
   audio-only

2) mp1e seems to write audio data, at least ffmpeg reports to find an audio
   channel when I preprocess the stream, but I did not manage to get any sound
   out of mplayer. Neither with the mp1e-stream nor with any stream produced by
   ffmpeg. Neither with OSS nor with ALSA. Xmms and Xawtv both let me hear
   sound.

What could be the problem?

My System:

        K6-3, 450MHz, 512MB
        Linux SuSE-73
        zapping-CVS as of 2001-10-12

Regards,
        Ralf


 -----------------------------------------------------------------
|  Ralf Oehler
|  GDI - Gesellschaft fuer Digitale Informationstechnik mbH
|
|  E-Mail:      R.O...@GD...
|  Tel.:        +49 6182-9271-23 
|  Fax.:        +49 6182-25035           
|  Mail:        GDI, Bensbruchstraße 11, D-63533 Mainhausen
|  HTTP:        www.GDImbH.com
 -----------------------------------------------------------------

time is a funny concept

Re: [Zapping-misc] unable to go full screen?

[mark <ma...@ex...>]

Hi I=F1aki and All,

The docs are slowly getting there, at present, got a lot of stuff with
regards to the servers at work and perl and sql, so they are still
coming on, but a bit slower as ive got a little less time on my hands
these days...But they will be finished...Soooooooooon..

Anyway ive tried running:

/usr/sbin/zapping_setup_fb --verbose --verbose --device /dev/video0

and the output is one of the attached txt file


this seemed to work, so i then ran zapping -d at full screen about 6
times and it now seems fine. (again output on attached txt file).

As with reference to the pam problem, iam running nis+ and nfs,so that
may be a problem, but i was getting the same errors as root, but not as
much..

Regards

Mark


On Sun, 2001-10-14 at 13:35, I=F1aki Garc=EDa Etxebarria wrote:
> Hi,
>=20
> > Error: fullscreen.c (241) [fullscreen_start]:
> > Sorry, but cannot go fullscreen:
> > [tveng1.c] tveng1_set_preview (line 2207)
> > VIDIOCCAPTURE failed: Invalid argument
> Could be an error with pam that shows at times.
> Please try after running the following as root:
>=20
> "zapping_setup_fb --verbose --verbose --device /dev/video0"
>=20
> "/usr/bin/zapping_setup_fb --verbose --verbose --device /dev/video0"
>=20
> "/usr/sbin/zapping_setup_fb --verbose --verbose --device /dev/video0"
>=20
> You might need to replace "/dev/video0" with the name of the real video
> device.
> If it doesn't work, the output of those commands will still be useful,
> please send that to the list (and the output of "zapping -d" can help
> too).
>=20
> Regards,
> I=F1aki
>=20
> PD: How are the docs going?
>=20
>=20
> _______________________________________________
> Zapping-misc mailing list
> Zap...@li...
> https://lists.sourceforge.net/lists/listinfo/zapping-misc
>=20
--=20
=20
----
        A penguin a day keeps the fatal exceptions away...
       =20
                              Registered Linux User: 208939
                             	Licq: 119422259

Re: [Zapping-misc] What happens in preview mode?

[Magnus S. <ma...@sa...>]

Heiko Bachmann wrote:

>Hi folks,
>
>I recently got a V4L device and found Zapping the most useful TV app
>for me :)
>
>Anyway, there are some questions:
>
>What happens inside Zapping if switched to preview mode? There's a
>notible CPU usage of around 10..20 percent (slow system, K6-3/400).
>VBI decoding is already disabled.
>
>Because of my slower system interlaced capture mode is not usable
>for common window sizes. I'm interested displaying the images via
>MPlayer's mga_vid device, it improves frame rates dramatically.
>Has anyone alredy checked that possibility?  I don't know nothing
>about it's API but I would give it a try, if I can handle the code ;-))
>
I also have a Matrox card, and use mplayer with the mga driver.
I spoke to I=F1aki about it, and I would be really interested in=20
partisipating to develop a mga driver for zapping (also fullscreen)

Regards
// Magnus

Re: [Zapping-misc] Bug?

[E. <ga...@eu...>]

> Hi!
>=20
> I'm capturing the image with the ksnapshop program, and it seems to don't=
=20
> capture very well. The image that I want to show you has garbage at the t=
op=20
> of the image (1/8 of the total screen, the rest is blue!).
> I tried with kwintv and it works fine :(
I'll take a look, but I can't promise anything.

>=20
> Thank you very much for taking in consideration my suggest about arts! I=20
> think that it would be great for all the KDE users!
True. I've just commited an arts backend to CVS, it will be released
with 0.6.2

Regards,
I=F1aki

Re: [Zapping-misc] What happens in preview mode?

[E. <ga...@eu...>]

Hi,

> What happens inside Zapping if switched to preview mode?
Nothing (well, almost :-)) The slowdown might come from the X server if
you are using XVideo, does running "zapping -v" help?

>=20
> Because of my slower system interlaced capture mode is not usable
> for common window sizes. I'm interested displaying the images via
> MPlayer's mga_vid device, it improves frame rates dramatically.
> Has anyone alredy checked that possibility?  I don't know nothing
> about it's API but I would give it a try, if I can handle the code ;-))
That would be much appreciated. The relevant code in Zapping is in
src/capture.c and src/x11stuff.c, i don't think it's crystal clear. But
I will help you if you write the mga_vid related code (I cannot write
that since I don't own such a device).

Regards,
I=F1aki

Re: [Zapping-misc] unable to go full screen?

[E. <ga...@eu...>]

Hi,

> Error: fullscreen.c (241) [fullscreen_start]:
> Sorry, but cannot go fullscreen:
> [tveng1.c] tveng1_set_preview (line 2207)
> VIDIOCCAPTURE failed: Invalid argument
Could be an error with pam that shows at times.
Please try after running the following as root:

"zapping_setup_fb --verbose --verbose --device /dev/video0"

"/usr/bin/zapping_setup_fb --verbose --verbose --device /dev/video0"

"/usr/sbin/zapping_setup_fb --verbose --verbose --device /dev/video0"

You might need to replace "/dev/video0" with the name of the real video
device.
If it doesn't work, the output of those commands will still be useful,
please send that to the list (and the output of "zapping -d" can help
too).

Regards,
I=F1aki

PD: How are the docs going?