[linux-dvb] DVB API update
abraham.manu at gmail.com
Mon Sep 17 18:38:53 CEST 2007
Johannes Stezenbach wrote:
> Hi Manu,
> On Sat, Sep 15, 2007, Manu Abraham wrote:
>> While being on the V3 frontend API overhaul, i found to much dismay that
>> it would be much better to revamp V4 into a newer API version such as
>> V5, rather than scratching with V3 for ages together, resulting in just
>> unnecessary talks and discussions.
> It is beyond me why you think creating a new API would
> result in less "unnecessary" discussions that improving
> the existing API... :-)
(Oh, here comes the flame thrower from Johannes with a smiley)
With regards to improving the existing API, just see the past reactions
and too many unnecessary discussions. It is too much work to get going
with a running API. It is next to impossible with all those politics in.
To make it simpler, the existing API is a bit broken too much. :)
> Given that there already is well-discussed API enhancement
> proposal for DVB-S2, affectionately but wrongly called
> "multiproto" (MPE?), I don't know why you don't get this
> merged first instead of making that task bigger and have
> everyone wait longer for the end result?
multiproto "did not" mean Multi Protocol Encapsulation, but just meant
multiple delivery systems. The original naming carried on from the first
patch. IIRC, it was Obi who said/(corrected) that it would be incorrect
to term protocol and hence changed to delivery system, but the naming
just stuck to it, that's all.
(Confusion again) i wonder how we can get rid of all these confusion
between people. ;-)
You see why now, rather being affection ?
The problem is that, after making something experimental, throwing it
out to application authors stating here it is: the API update, again a
fix to the API will make anyone furious, nobody wants to keep tinkering
forever on the same thing. I would prefer to say mark it experimental in
a tree dedicated to it, such that it is explicitly stated that it is not
a permanent solution and in the background, the fixes required for the
relevant can be done.
Don't you think so ? If someone asked me to keep working on with changes
every now and then i wouldn't be very happy, but if i were explicitly
told, look this is what as far what it stands as of now, it is expected
to change, for further support, that i could digest it a bit. Trying to
put myself into someone else's shoes.
That said there are newer devices taking advantage of the full specs. As
we have seen as soon as there are devices, there are applications as
well. Vendors don't spend their funds on something nonsense and that too
a major chunk of it. Of course there are cases, but in this case i
highly doubt your claim.
Not making others wait longer, see down..
> IIRC my closing words in the DVB-S2 API discussion were
> along the line of "we shouldn't merge an API without users
> into mainline now, we should wait until the first driver which
> uses it is ready and merge both at the same time".
> That is because a) we generally shouldn't add APIs without
> users, b) we shouldn't add APIs which are untested and
> thus not proven to work.
IIRC, You only wrote sometime earlier, why work on something useless
such as DVB-S2. Why a change of thought ?
> Ever since, everyone's just been waiting for your
> "I'm ready with my driver, please merge" mail.
I would be going on with an experimental tree after Wednesday.
Still some more things to be polished in that CCM only case too. See the
first few posts on this DVB API update thread, The way the current API
is, well it is as good as no statistics, but just for kids play there
are some numbers scrolling up and down, ie the statistics do not hold
any value. Displaying some random numbers is not statistics.
Had a discussion with Steven too on this, since he has a driver as well.
Why this is experimental ? I guess you get all the answers from within
this mail itself.
Sometime back you were the person who was against merging the same, now
that you seem to suddenly pull in all that you said crap a few mails
back. Wow, what a contradiction in statements.
I would like to see the other features of DVB-S2 go in as well, since
there are newer devices using those features. But for that i wouldn't
prefer to work with the V3 demuxer, but prefer to go with V4 which has
the advantages of ZeroCopy at least.
>> What i find interesting with the V4 API
>> * A better demuxer
> But it's also overcomplicated and like MiHu explained not
> targeted at PCI/USB cards. IMHO It would be useful to add
> a simple version of the recording filters to the V3 demux.
Copying around, i would like to avoid. With High bitrate streams etc,
for HD streams the PC would be already saturated, i would like to cut
down whatever unnecessary overheads that do exist.
If you would like to fix that in V3, i would much appreciate. If you
would just like to keep talking only, maybe lets then not talk too much
>> * ARIB extensions
> I don't see anyone writing a driver using that, so why bother?
Someone asked me over IRC a few weeks back on a demod, moreover i have a
13 seg tuner. (You have the sources for that driver from me, currently)
> Given that we always need to stay backward compatible with
> old API versions, I believe it is much easier to improve
> the existing API in small incremental steps than to introduce
> a completely new API. (While working on V4, we were always
> thinking "hey, we can add backward compat later", but frankly
> I don't see how this could've worked out.)
Okay, suppose you have added backward compat, for the initial simpler
aspect with regards to the frontend. The demuxer almost will need to be
redone. Don't you think so at least, with regards to DVB-S2, exception CCM ?
Please do not ignore other deliveries either (just because you do not
have it), i plan to work on DMB as well very soon. There were people who
asked me about ARIB, who got fed up trying to add in a driver for 13seg
(a guy who was banned from the list)
So when you have to spent efforts again after a while again and again,
why not do it once for all ? I don't follow your argument that we have
to have flamewars every now and then. Maybe you like them so much and
blame others for it ?
> For DVB-S2 the problem was:
> - couldn't extend FE_SET_FRONTEND without breaking
> backwards compat
> - thus need new ioctl
> - to not repeat the same mistake I proposed to add
> "forward compatibility" so we could extend the
> new ioctl later for DVB-H etc. (DVB-SH, DVB-T2
> and DVB-C2 anyone?)
DVB.org has called for the papers currently for C2 and T2, basically the
idea they have put up is to use LDPC/BCH instead of Reed/Solomon.
Another year or 2 for DVB-C2 or T2.
But even before that i guess we need to work for the hardware which do
exist, rather than for devices the even the complete base specification
is not yet released. Don't you think so ? Please don't snip away all
these, i need an answer from you, why you think this way. Of course you
are free not to reply on the main things but rather what you would just
We have ACM applications and DMB-T/H chips coming up. IMHO it would be
better to go along with what the industry goes with rather than define
our ways and goals, which results in completely broken approaches of
> (V4L2 API does the same thing)
Don't care what V4L2 is doing, but ATM more concerned about what's going
on. You can't force what someone is doing on somebody else.
"Life is not Black and White. It is different shades of Black and white
causing different Gray levels" someone said that .. ;-)
> See? Keep it simple. Do just one thing at a time.
I don't see it. As i said, will you take charge in fixing the demuxer
for complete S2 as well as other protocols ?
(Since you had a larger hand in the whole mess created, what i mean here
is that you maintained DVB for a long while)
The point being: either you fix it or allow others to fix. Both you seem
to mildly dislike, don't understand why.
If so sounds fine to me. But as you said i am just doing one thing at a
Currently CCM works, need to get ACM and other things working, maybe get
DSS also going (demux support needed)
More information about the linux-dvb