[Freevo-devel] Re: VideoGroups too complicated
Rob Shortt wrote:
> Yes, I was feeling wierd about that too. How about using an object
> oriented / inheritence approach as Kans suggested? TVSettings(),
> DVBSettings(), IVTVSettings(), each with apropriate properties.
Agreed.
>
>> TV_SETTINGS['dvb0'] = TVSettings()
>> This will auto-configure the TVSettings:
>> - set mode to dvb
>> - set device to adapter0
>> So TV_SETTINGS needs to be much more than a simple dict. But the
>> interface should be like the one you propose.
>>
>>>TV_SETTINGS['tv0'].vdev = '/dev/video1'
>>># Or maybe their second tuner is on video2
>>>TV_SETTINGS['tv1'].vdev = '/dev/video2'
>> We can auto-detect this (more or less). Should we support /dev/video1
>> for tv0? Or do we also prefer /dev/videoX for tvX?
>
> How about we not use tv/ivtv/dvb and use tvX/ivtvX/dvbX. tv0 should
> start at /dev/video0, etc. Maybe we can do something like
> TVSettings('tv', 0) or ('tv0') or TVSettings(0), DVBSettings(0),
> IVTVSettings(0).
Do not add the 0 in the constructor, this looks to complicated:
TV_SETTINGS['tv0'] = TVSettings()
TV_SETTINGS is no real dict, on __set_item__ it auto sets the device
to 0 because the user adds it to 'tv0'.
Or even better, we auto detect all this and user only sets a new adev
if needed by typing
TV_SETTINGS['tv0'].adev = '/dev/dsp'
Dischi
--
According to Kentucky state law, every person must take a bath at least
once a year.
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Re: VideoGroups too complicated
Rob Shortt wrote:
> Hans Meine wrote:
>> On Sunday 08 August 2004 18:58, Rob Shortt wrote:
>>># Accept the defaults for the first regular tv card
>>>TV_SETTINGS['tv'] = TVSettings()
>> If the user may get to see this class name at some point, I would
>> suggest a name like "TVCard" instead of settings, because from a
>> user point of view, this is all about settings. This can be a class
>> within the module "config", so that it's namespaced
>> (i.e. config.TVCard from the rest of the code).
>
> Yes, they would only need to instantiate it if adding a 4th card and
> when the class is defined in config.py then it is in the same
> namespece as where they'd use it (local_conf.py / freevo_config.py).
> Also, tv0 and tv1 don't need to be on seperate cards, one could be for
> using the tuner, the other for svideo.
Is it possible to do some auto-detection here?
for X in /dev/dvb/adapter[0-9] TV_SETTINGS['dvbX'] = DVBSettings(X)
That's all. Next the CHANNELS_CONF:
c = [part of CHANNELS_CONF] = ('art.de', 'ARD', 'ARD')
if c[2] is string and there is dvb card:
c = ('art.de', 'ARD', 'dvb:ARD')
if c[2] not endswith number:
if there is card0 for dvb:
c = ('art.de', 'ARD', 'dvb0:ARD')
Dischi
--
A man generally has two reasons for doing a thing. One that sounds
good, and a real one.
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: VideoGroups too complicated
Rob Shortt wrote: oriented / inheritence approach as Kans suggested? Sorry Hans, typo! :) --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: VideoGroups too complicated
Dirk Meyer wrote:
Rob Shortt wrote:
class TVSettings:
"""
vdev:The video device, such as /dev/video.
adev:The audio device, such as /dev/dsp.
What does adev have to do with the tv settings? Aren't this normal
output settings? And what is /dev/video? I guess it is a simple
link. were is the destination?
/dev/video is a link, almost always pointing to video0. Adev matters
for audio encoding on regular tv cards, you only get video from
/dev/video0 and audio will come from /dev/dsp0 if using a loopback cable
or from dsp1 or 2 if using something like btaudio plugin for sound
directly from the card.
input_type: tuner, composite, svideo, webcam
input_num: The number of this input according to V4L
tuner_norm: NTSC, PAL, SECAM
tuner_chanlist: us-cable,
Problem here: for dvb we don't need this at all.
Right...
Or only TV_SETTINGS['dvb'].device = 0.
TV_SETTINGS['dvb'].adev = None
This is nonsense. We will never have an adev for dvb. I guess we need
some sort of intelligence here:
Yes, I was feeling wierd about that too. How about using an object
oriented / inheritence approach as Kans suggested? TVSettings(),
DVBSettings(), IVTVSettings(), each with apropriate properties.
TV_SETTINGS['dvb0'] = TVSettings()
This will auto-configure the TVSettings:
- set mode to dvb
- set device to adapter0
So TV_SETTINGS needs to be much more than a simple dict. But the
interface should be like the one you propose.
TV_SETTINGS['tv0'].vdev = '/dev/video1'
# Or maybe their second tuner is on video2
TV_SETTINGS['tv1'].vdev = '/dev/video2'
We can auto-detect this (more or less). Should we support /dev/video1
for tv0? Or do we also prefer /dev/videoX for tvX?
How about we not use tv/ivtv/dvb and use tvX/ivtvX/dvbX. tv0 should
start at /dev/video0, etc. Maybe we can do something like
TVSettings('tv', 0) or ('tv0') or TVSettings(0), DVBSettings(0),
IVTVSettings(0).
-Rob
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Re: VideoGroups too complicated
Rob Shortt wrote:
> Ok, so I've been doing some work on recordserver and ivtv_record and
> am running into some pitfalls wrt the lack of VideoGroups. Sorry to
> do this but I need to bring this up again. :)
No problem, we need to find the best working setup.
> What we talked about using:
>
> TV_[DVB|TV|IVTV]_[DEVICE|POST_CMD|PRE_CMD...] ie: TV_DVB_DEVICE =
> ['/dev/dvb']
>
> CHANNEL_LIST = [
> ('vox.de', 'VOX', ['dvb:VOX', 'tv0:1234', 'tv1:1234'])
> ]
> (Or Hans' suggestion... see below)
>
> TV_MPLAYER_URLS['tv0'] = '-tv device=/dev/video0:...'
> TV_MPLAYER_URLS['tv1'] = '-tv device=/dev/video1:input=4...'
> TV_MPLAYER_URLS['ivtv0'] = '-cache 8192 /dev/video2'
>
>
> We are still missing some fine grained configuration that came from
> video groups, most of that config we don't really need but we need to
> know more about each dvb/tv0/tv1 such as: audio device to capture
> from, are we using tuner, composite, or svideo input, what number said
> input is mapped to on the card, the norm (NTSC/PAL/SECAM), and the
> chanlist (us-cable, etc).
I only know about dvb and here it is very clean. All stuff for _one_
card is in one directory inside /dev. But from your mail I guess this
is not the case for analog audio.
> The old VIDEO_GROUPS array is very user unfriendly and the TV_*
> single variable assignment is much cleaner from that perspective.
> On the other hand if we introduce new variables for
> TV_[DVB|TV|IVTV]_[device|input|norm|adevice...] there will be too
> many variables to deal with and even then you also have to consider
> multiple devices of each kind (tv0, tv1, tv2). We had talked about
> using lists to handle that, which introduces more complexity.
>
> I've done some more thinking and come up with something in
> between. Inside config.py I would like to introduce a new class:
>
> class TVSettings:
> """
> vdev:The video device, such as /dev/video.
> adev:The audio device, such as /dev/dsp.
What does adev have to do with the tv settings? Aren't this normal
output settings? And what is /dev/video? I guess it is a simple
link. were is the destination?
> input_type: tuner, composite, svideo, webcam
> input_num: The number of this input according to V4L
> tuner_norm: NTSC, PAL, SECAM
> tuner_chanlist: us-cable,
Problem here: for dvb we don't need this at all.
> That is much smaller than VideoGroup. But still, we don't want users
> to have to instantiate this class by themselves in their config! We
> can do that behind the scenes in config.py or freevo_config.py (please
> bear with me):
>
> # Accept the defaults for the first regular tv card
> TV_SETTINGS['tv'] = TVSettings()
>
> # The user may decide to call that tv0 instead, do another for convenience
> TV_SETTINGS['tv0'] = TVSettings()
>
> TV_SETTINGS['tv1'] = TVSettings()
> TV_SETTINGS['tv1'].vdev = '/dev/video1'
> TV_SETTINGS['tv1'].adev = '/dev/dsp1'
>
> TV_SETTINGS['tv2'] = TVSettings()
> TV_SETTINGS['tv2'].vdev = '/dev/video2'
> TV_SETTINGS['tv2'].adev = '/dev/dsp2'
>
>
> # Accept the defaults for the first ivtv card
> TV_SETTINGS['ivtv'] = TVSettings()
> TV_SETTINGS['ivtv'].adev = None
> TV_SETTINGS['ivtv'].input_num = 4
>
> # The user may decide to call that ivtv0 instead, do another for convenience
> TV_SETTINGS['ivtv0'] = TVSettings()
> TV_SETTINGS['ivtv0'].adev = None
> TV_SETTINGS['ivtv0'].input_num = 4
>
> TV_SETTINGS['ivtv1'] = TVSettings()
> TV_SETTINGS['ivtv1'].vdev = '/dev/video1'
> TV_SETTINGS['ivtv1'].adev = None
> TV_SETTINGS['ivtv1'].input_num = 4
>
> TV_SETTINGS['ivtv2'] = TVSettings()
> TV_SETTINGS['ivtv2'].vdev = '/dev/video2'
> TV_SETTINGS['ivtv2'].adev = None
> TV_SETTINGS['ivtv2'].input_num = 4
>
> # Accept the defaults for the first DVB card
> TV_SETTINGS['dvb'] = TVSettings()
> TV_SETTINGS['dvb'].vdev = '/dev/dvb/adapter0/dvr0'
> # Or we could use '/dev/dvb/adapter0/' to find each device
> # in that dir.
Or only TV_SETTINGS['dvb'].device = 0.
> TV_SETTINGS['dvb'].adev = None
This is nonsense. We will never have an adev for dvb. I guess we need
some sort of intelligence here:
TV_SETTINGS['dvb0'] = TVSettings()
This will auto-configure the TVSettings:
- set mode to dvb
- set device to adapter0
So TV_SETTINGS needs to be much more than a simple dict. But the
interface should be like the one you propose.
> TV_SETTINGS['tv0'].vdev = '/dev/video1'
> # Or maybe their second tuner is on video2
> TV_SETTINGS['tv1'].vdev = '/dev/video2'
We can auto-detect this (more or less). Should we support /dev/video1
for tv0? Or do we also prefer /dev/videoX for tvX?
> Actually I'm having a hard time thinking of scenarios where the user
> might need to change something and even then it is easy. If the user
> needs more than 3 tv cards they should be able to figure out how to
> add 'tv3'.
>
> Also, I like Hans' suggestion of using DEFAULT_CHANNEL_METHOD =
> ['tv0', 'tv1'] or CHANNEL_METHOD_ALTERNATIVES = {'tv0': 'tv1'} to
> default to one type and to determin
Re: [Freevo-devel] Re: VideoGroups too complicated
Hans Meine wrote: On Sunday 08 August 2004 18:58, Rob Shortt wrote: # Accept the defaults for the first regular tv card TV_SETTINGS['tv'] = TVSettings() If the user may get to see this class name at some point, I would suggest a name like "TVCard" instead of settings, because from a user point of view, this is all about settings. This can be a class within the module "config", so that it's namespaced (i.e. config.TVCard from the rest of the code). Yes, they would only need to instantiate it if adding a 4th card and when the class is defined in config.py then it is in the same namespece as where they'd use it (local_conf.py / freevo_config.py). Also, tv0 and tv1 don't need to be on seperate cards, one could be for using the tuner, the other for svideo. And I want to point out that simple inheritance might be useful for different types of cards. I.e. TV_SETTINGS['ivtv'] = IVTVCard() or similar, since IVTV has many more (and different) options than normal v4l cards. Excelent idea. That way we can get rid of IVTV_OPTIONS and have support for different options for each card which is good because not all ivtv cards are the same. The same goes for dvb I guess. -Rob --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: VideoGroups too complicated
On Sunday 08 August 2004 18:58, Rob Shortt wrote: > (us-cable, etc). The old VIDEO_GROUPS array is very user unfriendly and > the TV_* single variable assignment is much cleaner from that > perspective. On the other hand if we introduce new variables for > TV_[DVB|TV|IVTV]_[device|input|norm|adevice...] there will be too many > variables to deal with and even then you also have to consider multiple > devices of each kind (tv0, tv1, tv2). We had talked about using lists > to handle that, which introduces more complexity. If the number of variables becomes too large, separate variables get indeed ugly IMO. And lists are fine for grouping, but have the disadvantage that they depend on the order of their entries, which is ugly both from a user's point of view and in the code (having all the unnamed indices). Of course, dicts would be better but then, you're totally right IMHO that classes are the best solution. They can fill in default values in their constructors and the config variables can be accessed with meaningful names. > # Accept the defaults for the first regular tv card > TV_SETTINGS['tv'] = TVSettings() If the user may get to see this class name at some point, I would suggest a name like "TVCard" instead of settings, because from a user point of view, this is all about settings. This can be a class within the module "config", so that it's namespaced (i.e. config.TVCard from the rest of the code). And I want to point out that simple inheritance might be useful for different types of cards. I.e. TV_SETTINGS['ivtv'] = IVTVCard() or similar, since IVTV has many more (and different) options than normal v4l cards. > Comments? *crossed fingers* I think it's fine. :-) -- Ciao, / /.o. /--/ ..o / / ANS ooo --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Re: VideoGroups too complicated
Ok, so I've been doing some work on recordserver and ivtv_record and am
running into some pitfalls wrt the lack of VideoGroups. Sorry to do
this but I need to bring this up again. :)
What we talked about using:
TV_[DVB|TV|IVTV]_[DEVICE|POST_CMD|PRE_CMD...] ie: TV_DVB_DEVICE =
['/dev/dvb']
CHANNEL_LIST = [
('vox.de', 'VOX', ['dvb:VOX', 'tv0:1234', 'tv1:1234'])
]
(Or Hans' suggestion... see below)
TV_MPLAYER_URLS['tv0'] = '-tv device=/dev/video0:...'
TV_MPLAYER_URLS['tv1'] = '-tv device=/dev/video1:input=4...'
TV_MPLAYER_URLS['ivtv0'] = '-cache 8192 /dev/video2'
We are still missing some fine grained configuration that came from
video groups, most of that config we don't really need but we need to
know more about each dvb/tv0/tv1 such as: audio device to capture from,
are we using tuner, composite, or svideo input, what number said input
is mapped to on the card, the norm (NTSC/PAL/SECAM), and the chanlist
(us-cable, etc). The old VIDEO_GROUPS array is very user unfriendly and
the TV_* single variable assignment is much cleaner from that
perspective. On the other hand if we introduce new variables for
TV_[DVB|TV|IVTV]_[device|input|norm|adevice...] there will be too many
variables to deal with and even then you also have to consider multiple
devices of each kind (tv0, tv1, tv2). We had talked about using lists
to handle that, which introduces more complexity.
I've done some more thinking and come up with something in between.
Inside config.py I would like to introduce a new class:
class TVSettings:
"""
vdev:The video device, such as /dev/video.
adev:The audio device, such as /dev/dsp.
input_type: tuner, composite, svideo, webcam
input_num: The number of this input according to V4L
tuner_norm: NTSC, PAL, SECAM
tuner_chanlist: us-cable,
"""
def __init__(self):
self.vdev = '/dev/video0'
self.adev = '/dev/dsp0'
self.input_type = 'tuner'
self.input_num = 0
self.tuner_norm = CONF.norm
self.tuner_chanlist = CONF.chanlist
That is much smaller than VideoGroup. But still, we don't want users to
have to instantiate this class by themselves in their config! We can do
that behind the scenes in config.py or freevo_config.py (please bear
with me):
# Accept the defaults for the first regular tv card
TV_SETTINGS['tv'] = TVSettings()
# The user may decide to call that tv0 instead, do another for convenience
TV_SETTINGS['tv0'] = TVSettings()
TV_SETTINGS['tv1'] = TVSettings()
TV_SETTINGS['tv1'].vdev = '/dev/video1'
TV_SETTINGS['tv1'].adev = '/dev/dsp1'
TV_SETTINGS['tv2'] = TVSettings()
TV_SETTINGS['tv2'].vdev = '/dev/video2'
TV_SETTINGS['tv2'].adev = '/dev/dsp2'
# Accept the defaults for the first ivtv card
TV_SETTINGS['ivtv'] = TVSettings()
TV_SETTINGS['ivtv'].adev = None
TV_SETTINGS['ivtv'].input_num = 4
# The user may decide to call that ivtv0 instead, do another for convenience
TV_SETTINGS['ivtv0'] = TVSettings()
TV_SETTINGS['ivtv0'].adev = None
TV_SETTINGS['ivtv0'].input_num = 4
TV_SETTINGS['ivtv1'] = TVSettings()
TV_SETTINGS['ivtv1'].vdev = '/dev/video1'
TV_SETTINGS['ivtv1'].adev = None
TV_SETTINGS['ivtv1'].input_num = 4
TV_SETTINGS['ivtv2'] = TVSettings()
TV_SETTINGS['ivtv2'].vdev = '/dev/video2'
TV_SETTINGS['ivtv2'].adev = None
TV_SETTINGS['ivtv2'].input_num = 4
# Accept the defaults for the first DVB card
TV_SETTINGS['dvb'] = TVSettings()
TV_SETTINGS['dvb'].vdev = '/dev/dvb/adapter0/dvr0'
# Or we could use '/dev/dvb/adapter0/' to find each device
# in that dir.
TV_SETTINGS['dvb'].adev = None
# The user may decide to call that dvb0 instead, do another for convenience
TV_SETTINGS['dvb0'] = TVSettings()
TV_SETTINGS['dvb0'].vdev = '/dev/dvb/adapter0/dvr0'
TV_SETTINGS['dvb0'].adev = None
TV_SETTINGS['dvb1'] = TVSettings()
TV_SETTINGS['dvb1'].vdev = '/dev/dvb/adapter1/dvr1'
TV_SETTINGS['dvb1'].adev = None
TV_SETTINGS['dvb2'] = TVSettings()
TV_SETTINGS['dvb2'].vdev = '/dev/dvb/adapter2/dvr2'
TV_SETTINGS['dvb2'].adev = None
Ok, all that behind the scenes, hidden from the user. Most people will
require no further configuration if we default TV_CHANNELS to 'tv0:'.
Using this method we'll have ell the information we'll need for each
device, even with more complicated situations (using svideo input,
external tuner..). Consider these scenarios:
1) User has a regular tv tuner but it is on video1 instead.
TV_SETTINGS['tv0'].vdev = '/dev/video1'
# Or maybe their second tuner is on video2
TV_SETTINGS['tv1'].vdev = '/dev/video2'
2) User has a regular tv tuner hooked up to a cable box recording from
svideo and using an infrared transmitter to change channels:
TV_SETTINGS['tv0'].input_type = 'svideo'
TV_SETTINGS['tv0'].input_num = 2
# and _maybe_ tuner_type but I think we can do without
TV_SETTINGS['tv0'].tuner_type = 'external'
# That was pretty easy to configure.
3) My second tuner is PAL but my conf uses NTSC (unrealistic):
TV_SETTINGS['tv1'].norm = 'PAL'
Actually I'm having a hard time t
Re: [Freevo-devel] Re: VideoGroups too complicated
On Thursday 05 August 2004 15:39, Dirk Meyer wrote:
> CHANNEL_LIST = [
> ('vox.de', 'VOX', ['dvb:VOX', 'tv0:1234', 'tv1:1234'])
> ]
Looks fine; however, if a user buys a second TV card of the same type, he/she
might like a facility to say "tv1 can do the same as tv0". That could be a
simple python two-liner which adds all entries to the CHANNEL_LIST that are
then needed.
Ideally, something like
CHANNEL_LIST = [
('vox.de', 'VOX', '1234')
]
DEFAULT_CHANNEL_METHOD = ['tv0', 'tv1']
would suffice. At least something like
CHANNEL_LIST = [
('vox.de', 'VOX', 'tv0:1234')
]
CHANNEL_METHOD_ALTERNATIVES = {'tv0': 'tv1'}
should be possible to save the user from a *lot* of typing (or from knowing
his Emacs well ;-) ).
> You have the channel VOX. If you want to play it, Freevo will ask
> every plugin about dvb.
This question should actually be about "dvb:VOX" or "dvb:band" (sorry if I'm
using the wrong terminology, only analog equipment around..) so that a plugin
might say: OK, the device is busy, but can record a second channel from the
same source" (/foo/bar/whatever, being ignorant ;-) ).
The whole thing makes sense to me, although my impression is that a
Freevo-setup utility (a separate app) might to the trick as well, since this
is mostly about complex config file structures, not really about complex
program interna.
--
Ciao, / /.o.
/--/ ..o
/ / ANS ooo
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
