From: Hans de Goede <hdegoede@redhat.com>
To: Chicken Shack <chicken.shack@gmx.de>
Cc: linux-media@vger.kernel.org,
Devin Heitmueller <dheitmueller@kernellabs.com>,
Douglas Schilling Landgraf <dougsland@gmail.com>,
hermann pitton <hermann-pitton@arcor.de>,
Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: v4l-utils, dvb-utils, xawtv and alevt
Date: Sat, 13 Mar 2010 07:51:16 +0100 [thread overview]
Message-ID: <4B9B35E4.7070702@redhat.com> (raw)
In-Reply-To: <1268421039.1971.46.camel@brian.bconsult.de>
Hi,
On 03/12/2010 08:10 PM, Chicken Shack wrote:
> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> self-contained videotext application consisting of three parts:
> a. alevt, b. alevt-date c. alevt-cap
>
> While the packed size of alevt is 78770 the complete size of the
> dvb-apps as a whole ranges around 350000.
>
> I am not against hosting this program at linuxtv.org, but if this
> decision is made the decision should be an intelligent one: alevt is a
> separate tree, and any other choice is simply a dumb one.
> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> only need the libc6.
>
Seems we agree here, becoming a new upstream for alevt is good, merging
it into another package is not good :)
> 2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
> whole. And that's exactly why you cannot discuss it as a whole!
>
Actually when I was talking about doing a tree to collect distro packages
and serve as a new upstream for xawtv I was talking about xawtv version
3.95, is that the same as which you call xawtv-4.0 pre ?
> The usable parts are:
>
> a. mtt: a slave videotext application which is running independently
> from the master application tuning the channels.
> Its packed size amounts to 107744.
>
> b. dvbrowse: a slave EPG application which is running independently from
> the master application tuning the channels.
> Packed Size: 101267.
>
> c. dvbradio: a fast and rather stable running application for watching
> DVB radio streams.
> Packed Size: 119957.
> Problem: dvbradio would need investigation to understand channel lists
> in vdr channels.conf format.
> As long as this is not the case, the insane slow homebrew scanner called
> alexplore is necessary to produce a channels list.
> Gerd implied some vdr modules into thew package, but they are
> ca. unfinished work
> cb. for debug purposes only
>
>
> The unusable parts are:
>
> a. xawtv itself, the main program.
> It never ran stable and it is unfinished work.
> Its graphical capabilities are pure rubbish compared to todays
> standards.
>
??
Its UI is not a brilliant piece of work but it is usable and certainly
is stable. Actually it still is my preffered app for tvcard testing / usage.
> b. Lots of aged tools like scantv or radio who just have survived
> somehow but weren't modified.
>
If these are really useless we could certainly drop them, as we could
drop say v4l-ctl once we've got rid of the last v4l1 drivers.
Regards,
Hans
next prev parent reply other threads:[~2010-03-13 6:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-09 7:48 v4l-utils: i2c-id.h and alevt Hans Verkuil
2010-03-10 5:04 ` hermann pitton
2010-03-11 14:14 ` Douglas Schilling Landgraf
2010-03-11 14:31 ` Devin Heitmueller
2010-03-12 7:27 ` Hans Verkuil
2010-03-12 15:21 ` Devin Heitmueller
2010-03-12 15:38 ` Hans de Goede
2010-03-12 15:40 ` Hans de Goede
2010-03-12 16:20 ` Manu Abraham
2010-03-12 19:10 ` v4l-utils, dvb-utils, xawtv and alevt (was: v4l-utils: i2c-id.h and alevt) Chicken Shack
2010-03-13 6:51 ` Hans de Goede [this message]
2010-03-13 10:15 ` v4l-utils, dvb-utils, xawtv and alevt Chicken Shack
2010-03-13 12:34 ` Hans de Goede
2010-03-13 13:43 ` Chicken Shack
2010-03-14 5:39 ` hermann pitton
2010-03-14 11:13 ` Chicken Shack
2010-03-14 14:38 ` Aw: " hermann-pitton
2010-03-12 15:55 ` v4l-utils: i2c-id.h " Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B9B35E4.7070702@redhat.com \
--to=hdegoede@redhat.com \
--cc=chicken.shack@gmx.de \
--cc=dheitmueller@kernellabs.com \
--cc=dougsland@gmail.com \
--cc=hermann-pitton@arcor.de \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.