[Freevo-users] IVTV-record bugs and problems
Hi,
I'm trying to set freevo with a pvr350 card using the IVTV record
plugin.
DEBUG=1 is set in the local_config.
I'm using the freevo and mmpython cvs version on gentoo. python 2.3.3
This is the first error I get when using the ivtv record plugin :
2004/07/06 18:25 CEST [*RecordServer*] vnorm: PAL
2004/07/06 18:25 CEST [*RecordServer*] Setting Input to 4
2004/07/06 18:25 CEST [*RecordServer*] Setting Channel to E9
2004/07/06 18:25 CEST [*RecordServer*] USING STANDARD FREQUENCY:
chan=E9, freq=203250
2004/07/06 18:25 CEST [*RecordServer*] Video Opened at /dev/video1
2004/07/06 18:25 CEST [*RecordServer*] Exception in thread Thread-1:
2004/07/06 18:25 CEST [*RecordServer*] Traceback (most recent call
last):
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/threading.py, line 436, in __bootstrap
2004/07/06 18:25 CEST [*RecordServer*] self.run()
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/plugins/ivtv_record.py,
line 197, in run
2004/07/06 18:25 CEST [*RecordServer*] if DEBUG: v.print_settings()
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/ivtv.py, line 146, in
print_settings
2004/07/06 18:25 CEST [*RecordServer*]
tv.v4l2.Videodev.print_settings(self)2004/07/06 18:25 CEST
[*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/v4l2.py, line 314, in
print_settings
2004/07/06 18:25 CEST [*RecordServer*] print 'Driver: %s' %
self.driver
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/twisted/python/log.py, line 307, in
write
2004/07/06 18:25 CEST [*RecordServer*] d = (self.buf +
data).split('\n')
2004/07/06 18:25 CEST [*RecordServer*] UnicodeDecodeError: 'ascii' codec
can't decode byte 0xc4 in position 13: ordinal not in range(128)
2004/07/06 18:25 CEST [*RecordServer*]
in v4l2.py there are some print statements and I get a Unidecode error
when setting these ptint statements in comment I can go on.
The second problem is NTSC = PAL.
I am a pal user, ivtv driver is installed correctly I can capture
without problems when I do cat /dev/video1 somefile.mpg The result is
a 720x576 mpeg file with sound.
My pvr350 card is /dev/video1, /dev/video0 is a from the dvb card that
isn't configured in freevo at the moment.
When capturing with freevo I get a 720x480 mpeg file.
This are some lines from my local_config file
--
TV_REC_SIZE = (720, 576)
TV_RECORD_DIR = '/usr/local/freevo/record'
TV_RECORDFILE_MASK = '%%m-%%d %%Hh%%M %(progname)s'
TV_SETTINGS = 'PAL 4 europe-east /dev/video1'
IVTV_OPTIONS = {
'input' : 4,
'resolution': '720x576',
'aspect': 3,
'audio_bitmask' : 233,
'bframes' : 3,
'bitrate_mode' : 1,
'bitrate' : 400,
'bitrate_peak' : 800,
'dnr_mode' : 0,
'dnr_spatial' : 0,
'dnr_temporal' : 0,
'dnr_type' : 0,
'framerate' : 0,
'framespergop' : 15,
'gop_closure' : 1,
'pulldown' : 0,
'stream_type' : 10
}
VIDEO_GROUPS = [
VideoGroup(vdev=/dev/video1,
adev=None,
input_num=4,
tuner_norm=CONF.tv,
tuner_chanlist=CONF.chanlist,
desc='Cable',
group_type=ivtv,
recordable=True),
]
-
When looking at the kernel messages I see the ivtv size changes when
recording with freevo. I added an extra print statement to see that the
vnorm the recordserver gets is PAL, here is the recordserver log file :
--
2004/07/06 18:35 CEST [*RecordServer*] vnorm: PAL
2004/07/06 18:35 CEST [*RecordServer*] Setting Input to 4
2004/07/06 18:35 CEST [*RecordServer*] Setting Channel to E9
2004/07/06 18:35 CEST [*RecordServer*] USING STANDARD FREQUENCY:
chan=E9, freq=203250
2004/07/06 18:35 CEST [*RecordServer*] Video Opened at /dev/video1
2004/07/06 18:35 CEST [*RecordServer*] Enumerating supported Standards.
2004/07/06 18:35 CEST [*RecordServer*] 0: 0x3000 NTSC
2004/07/06 18:35 CEST [*RecordServer*] 1: 0xff PAL
2004/07/06 18:35 CEST [*RecordServer*] 2: 0x7f SECAM
2004/07/06 18:35 CEST [*RecordServer*] Current Standard is: 0xff
2004/07/06 18:35 CEST [*RecordServer*] Enumerating supported Inputs.
2004/07/06 18:35 CEST [*RecordServer*] 0: Composite 0
2004/07/06 18:35 CEST [*RecordServer*] 1: Composite 1
2004/07/06 18:35 CEST [*RecordServer*] 2: Composite 2
2004/07/06 18:35 CEST [*RecordServer*] 3: Composite 3
2004/07/06 18:35 CEST [*RecordServer*] 4: Tuner 0
2004/07/06 18:35 CEST [*RecordServer*] 5: Composite 4
2004/07/06 18:35 CEST [*RecordServer*] 6: S-Video 0
2004/07/06 18:35 CEST [*RecordServer*] 7: S-Video 1
2004/07/06 18:35 CEST [*RecordServer*] 8: S-Video 2
Re: [Freevo-users] IVTV-record bugs and problems
Bart Heremans wrote:
Hi,
Hi,
I'm trying to set freevo with a pvr350 card using the IVTV record
plugin.
DEBUG=1 is set in the local_config.
I'm using the freevo and mmpython cvs version on gentoo. python 2.3.3
This is the first error I get when using the ivtv record plugin :
2004/07/06 18:25 CEST [*RecordServer*] vnorm: PAL
2004/07/06 18:25 CEST [*RecordServer*] Setting Input to 4
2004/07/06 18:25 CEST [*RecordServer*] Setting Channel to E9
2004/07/06 18:25 CEST [*RecordServer*] USING STANDARD FREQUENCY:
chan=E9, freq=203250
2004/07/06 18:25 CEST [*RecordServer*] Video Opened at /dev/video1
2004/07/06 18:25 CEST [*RecordServer*] Exception in thread Thread-1:
2004/07/06 18:25 CEST [*RecordServer*] Traceback (most recent call
last):
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/threading.py, line 436, in __bootstrap
2004/07/06 18:25 CEST [*RecordServer*] self.run()
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/plugins/ivtv_record.py,
line 197, in run
2004/07/06 18:25 CEST [*RecordServer*] if DEBUG: v.print_settings()
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/ivtv.py, line 146, in
print_settings
2004/07/06 18:25 CEST [*RecordServer*]
tv.v4l2.Videodev.print_settings(self)2004/07/06 18:25 CEST
[*RecordServer*] File
/usr/lib/python2.3/site-packages/freevo/tv/v4l2.py, line 314, in
print_settings
2004/07/06 18:25 CEST [*RecordServer*] print 'Driver: %s' %
self.driver
2004/07/06 18:25 CEST [*RecordServer*] File
/usr/lib/python2.3/site-packages/twisted/python/log.py, line 307, in
write
2004/07/06 18:25 CEST [*RecordServer*] d = (self.buf +
data).split('\n')
2004/07/06 18:25 CEST [*RecordServer*] UnicodeDecodeError: 'ascii' codec
can't decode byte 0xc4 in position 13: ordinal not in range(128)
2004/07/06 18:25 CEST [*RecordServer*]
in v4l2.py there are some print statements and I get a Unidecode error
when setting these ptint statements in comment I can go on.
I am using a PVR-250 and started having the same problem a while ago
after updating my driver. Which version of ivtv are you using? I tried
messing around with Unicode and String objects but nothing really worked
for me. I was beginning to think that the driver is returning bad data
or the interface has changed. I ultimately ended up commenting those
prints out (Driver, Card, Version).
The second problem is NTSC = PAL.
I am a pal user, ivtv driver is installed correctly I can capture
without problems when I do cat /dev/video1 somefile.mpg The result is
a 720x576 mpeg file with sound.
My pvr350 card is /dev/video1, /dev/video0 is a from the dvb card that
isn't configured in freevo at the moment.
When capturing with freevo I get a 720x480 mpeg file.
This are some lines from my local_config file
--
TV_REC_SIZE = (720, 576)
Hmm, I think TV_REC_SIZE may be ignored by the ivtv code.
IVTV_OPTIONS = {
...
'resolution': '720x576',
...
}
...
2004/07/06 18:35 CEST [*RecordServer*] Width: 720, Height: 480
--
So the video standard is correct but the resolution is incorrect. AM I
missing something ?
I don't think you're missing anything. Maybe the setCodec interface
hace changed slightly, the explicit set to '720x576' fails and it
defaults back to NTSC resolution? I should have a chance to take a
closer look a bit later.
-Rob
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freevo-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
On Tue, 2004-07-06 at 16:16 -0300, Rob Shortt wrote: I am using a PVR-250 and started having the same problem a while ago after updating my driver. Which version of ivtv are you using? I tried messing around with Unicode and String objects but nothing really worked for me. I was beginning to think that the driver is returning bad data or the interface has changed. I ultimately ended up commenting those prints out (Driver, Card, Version). I'm using one with Chris Kennedys IVTV patches http://kmos.org/~ckennedy/ivtv/ : ivtv-0.1.10-pre2-ck98p.tgz TV_REC_SIZE = (720, 576) Hmm, I think TV_REC_SIZE may be ignored by the ivtv code. I thaught so, was just to be sure I don't think you're missing anything. Maybe the setCodec interface hace changed slightly, the explicit set to '720x576' fails and it defaults back to NTSC resolution? I should have a chance to take a closer look a bit later. -Rob Thanks, maybe I will use another driver if I find one that works well with 2.6 kernel, 0.1.9 won't compile And another question, is it possible with the video groups to use more than one tuner, a searched the mailing list but don't really know how to set it up. there are three tuners in the pc 1) dvb-s haupage nexus 2) pvr350 3) bttv didn't really try more than one at the moment because I'm already stuck with the pvr350. (I got in wortking some months ago in my pc, now it is in my brothers). the bttv card was working well alone, never used the dbv-s card with freevo. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
Hi,
ck ivtv patches are outputting this info when passing a ioctl
QUERYCAP_ST on the video device.
Driver: ivtvrÎàâÒÍó¼Ä
Card: Vanilla iTVC15 card qÎâ[À
Version: 266
Capabilities: 17236019
Enumerating supported Standards.
0: 0x3000 NTSC
1: 0xff PAL
2: 0x7f SECAM
In v4l2.py QUERYCAP_ST is defined like this.
QUERYCAP_ST = 16s32s32sLL16x
QUERYCAP_NO = _IOR('V', 0, QUERYCAP_ST)
Not sure what to make of this mumbo jumbo ;-) Rob can you explain what
you are trying to do here with 16s32s32sLL16x ? Willing to help if you
got some pointers.
Bart, if you set DEBUG to 0 it doesn't try to print out the
QUERYCAP ioctl output and all should work as excpected.
/Robert
Tuesday, July 6, 2004, 6:31:21 PM, Bart wrote:
On Tue, 2004-07-06 at 16:16 -0300, Rob Shortt wrote:
I am using a PVR-250 and started having the same problem a while ago
after updating my driver. Which version of ivtv are you using? I tried
messing around with Unicode and String objects but nothing really worked
for me. I was beginning to think that the driver is returning bad data
or the interface has changed. I ultimately ended up commenting those
prints out (Driver, Card, Version).
I'm using one with Chris Kennedys IVTV patches
http://kmos.org/~ckennedy/ivtv/ : ivtv-0.1.10-pre2-ck98p.tgz
TV_REC_SIZE = (720, 576)
Hmm, I think TV_REC_SIZE may be ignored by the ivtv code.
I thaught so, was just to be sure
I don't think you're missing anything. Maybe the setCodec interface
hace changed slightly, the explicit set to '720x576' fails and it
defaults back to NTSC resolution? I should have a chance to take a
closer look a bit later.
-Rob
Thanks, maybe I will use another driver if I find one that works well
with 2.6 kernel, 0.1.9 won't compile
And another question, is it possible with the video groups to use more
than one tuner, a searched the mailing list but don't really know how to
set it up. there are three tuners in the pc
1) dvb-s haupage nexus
2) pvr350
3) bttv
didn't really try more than one at the moment because I'm already stuck
with the pvr350. (I got in wortking some months ago in my pc, now it is
in my brothers). the bttv card was working well alone, never used the
dbv-s card with freevo.
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freevo-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-users
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freevo-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
Robert Winder wrote:
Driver: ivtvrÎàâÒÍó¼Ä
Card: Vanilla iTVC15 card qÎâ[À
Yeah, that junk's causing problems.
QUERYCAP_ST = 16s32s32sLL16x
QUERYCAP_NO = _IOR('V', 0, QUERYCAP_ST)
Not sure what to make of this mumbo jumbo ;-) Rob can you explain what
you are trying to do here with 16s32s32sLL16x ? Willing to help if you
got some pointers.
Heh. Ok, start by reading:
http://www.python.org/doc/2.3.4/lib/module-struct.html
We need to turn the results of the QUERYCAP_NO (really a hex number)
driver ioctl call into something python and understands.
def querycap(self):
val = struct.pack( QUERYCAP_ST, , , , 0, 0 )
r = fcntl.ioctl(self.device, long(QUERYCAP_NO), val)
return struct.unpack( QUERYCAP_ST, r )
That function gives us a list returned by the ioctl. Also note in the
struct pack line: , , , 0, 0; a string, string, string, int, int.
Well in C these tyles are more complec, and from reading the v4l
header file you can see the struct returned has members like 16 char
array, 2 - 32 char arrays, 2 - unsigned longs, and 16 bytes of padding.
Ok, so this one probably doesn't ring a bell now because I just
remembered Thomas was the one who made this file, and I think that was
based on another project, so, perhaps the interface has changed. Maybe
someone should review the v4l or ivtv header files and compare all the
struct packing/unpacking. I will take a peek later perhaps but atm I'm
a bit busy.
-Rob
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freevo-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-users
