[RFC] dvb-apps ported for ISDB-T

[RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

I wrote several patches those days in order to allow dvb-apps to properly
parse ISDB-T channel.conf.

On ISDB-T, there are several new parameters, so the parsing is more complex
than all the other currently supported video standards.

I've added the changes at:

http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/

I've merged there Patrick's dvb-apps-isdbt tree.

While there, I fixed a few bugs I noticed on the parser and converted it
to work with the DVB API v5 headers that are bundled together with dvb-apps.
This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
there can now be removed.

TODO:
=====

The new ISDB-T parameters are parsed, but I haven't add yet a code to make
them to be used;

There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
segment parameters. Currently, the parser will fail if those parameters are found.

gnutv is still reporting ISDB-T as "DVB-T".

needs to review the other applications.

Please review. If everything is right, I intend to commit it likely next week at
dvb-apps.

Cheers,
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
> I wrote several patches those days in order to allow dvb-apps to properly
> parse ISDB-T channel.conf.
> 
> On ISDB-T, there are several new parameters, so the parsing is more complex
> than all the other currently supported video standards.
> 
> I've added the changes at:
> 
> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
> 
> I've merged there Patrick's dvb-apps-isdbt tree.
> 
> While there, I fixed a few bugs I noticed on the parser and converted it
> to work with the DVB API v5 headers that are bundled together with dvb-apps.
> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
> there can now be removed.
> 
> TODO:
> =====
> 
> The new ISDB-T parameters are parsed, but I haven't add yet a code to make
> them to be used;
> 
> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
> segment parameters. Currently, the parser will fail if those parameters are found.
> 
> gnutv is still reporting ISDB-T as "DVB-T".
> 

I've just fixed the issues on the TODO list. The DVB v5 code is now working fine
for ISDB-T.

Pending stuff (patches are welcome):
	- Implement v5 calls for other video standards;
	- Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling
DVBv5 is now at /lib/libdvbapi/v5api.c);
	- Test/use the functions to retrieve values via DVBv5 API. The function is
already there, but I haven't tested.

With the DVBv5 API implementation, zap is now working properly with ISDB-T.
gnutv also works (although some outputs - like decoder - may need some changes, in
order to work with mpeg4/AAC video/audio codecs).

Have fun!

Cheers,
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Patrick Boettcher]

Hi Mauro,

On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote:

> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>> I wrote several patches those days in order to allow dvb-apps to properly
>> parse ISDB-T channel.conf.
>>
>> On ISDB-T, there are several new parameters, so the parsing is more complex
>> than all the other currently supported video standards.
>>
>> I've added the changes at:
>>
>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>
>> I've merged there Patrick's dvb-apps-isdbt tree.
>>
>> While there, I fixed a few bugs I noticed on the parser and converted it
>> to work with the DVB API v5 headers that are bundled together with dvb-apps.
>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
>> there can now be removed.
>>
>> TODO:
>> =====
>>
>> The new ISDB-T parameters are parsed, but I haven't add yet a code to make
>> them to be used;
>>
>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>> segment parameters. Currently, the parser will fail if those parameters are found.
>>
>> gnutv is still reporting ISDB-T as "DVB-T".
>>
>
> I've just fixed the issues on the TODO list. The DVB v5 code is now working fine
> for ISDB-T.
>
> Pending stuff (patches are welcome):
> 	- Implement v5 calls for other video standards;
> 	- Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling
> DVBv5 is now at /lib/libdvbapi/v5api.c);
> 	- Test/use the functions to retrieve values via DVBv5 API. The function is
> already there, but I haven't tested.
>
> With the DVBv5 API implementation, zap is now working properly with ISDB-T.
> gnutv also works (although some outputs - like decoder - may need some changes, in
> order to work with mpeg4/AAC video/audio codecs).

Very good job!

Have you had a look here on this one

http://www.mail-archive.com/vdr@linuxtv.org/msg11125.html

?

I had this on my list because I wanted to spent some time on DVB-S2 myself 
and it seemed to be a good step to merge it (back) into dvb-apps. Though I 
haven't yet looked at it in detail.

I will check your changes soon, but after the holidays.

So, now you should have some quiet time for yourself! ;-)

regards,

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/

Re: [RFC] dvb-apps ported for ISDB-T

[Akihiro TSUKADA]

Hi Mauro,

>> I wrote several patches those days in order to allow dvb-apps to properly
>> parse ISDB-T channel.conf.
 
I think it would be convenient if channel.conf allows
the kind of format of PROPNAME=VALUE list, for readability and extensibility
of the conf file.

there are already so many parameters in ISDB-T,
so it is a bit difficult for the users to remember and correctly specify
all the field in the right order.
besides they have to be careful in counting the delimiter character
 when some (most?) parameters can be omitted or be left to the device/region default.

and when I consider extending this lib to ISDB-S (for example),
I have to add "TS-id" parameter,
which leads to the re-definition of the data structure and requires re-building.
So, it would be convenient if I could write for example like,
DTV_FREQUENCY=1049480:DTV_ISDBS_TS_ID=1

regards,
akihiro
--------------------------------------
Get Disney character's mail address on Yahoo! Mail
http://pr.mail.yahoo.co.jp/disney/

Re: [RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

Em 25-12-2009 09:25, Patrick Boettcher escreveu:
> Hi Mauro,
> 
> On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote:
> 
>> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>>> I wrote several patches those days in order to allow dvb-apps to
>>> properly
>>> parse ISDB-T channel.conf.
>>>
>>> On ISDB-T, there are several new parameters, so the parsing is more
>>> complex
>>> than all the other currently supported video standards.
>>>
>>> I've added the changes at:
>>>
>>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>>
>>> I've merged there Patrick's dvb-apps-isdbt tree.
>>>
>>> While there, I fixed a few bugs I noticed on the parser and converted it
>>> to work with the DVB API v5 headers that are bundled together with
>>> dvb-apps.
>>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests.
>>> The ones
>>> there can now be removed.
>>>
>>> TODO:
>>> =====
>>>
>>> The new ISDB-T parameters are parsed, but I haven't add yet a code to
>>> make
>>> them to be used;
>>>
>>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>>> segment parameters. Currently, the parser will fail if those
>>> parameters are found.
>>>
>>> gnutv is still reporting ISDB-T as "DVB-T".
>>>
>>
>> I've just fixed the issues on the TODO list. The DVB v5 code is now
>> working fine
>> for ISDB-T.
>>
>> Pending stuff (patches are welcome):
>>     - Implement v5 calls for other video standards;
>>     - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code
>> for calling
>> DVBv5 is now at /lib/libdvbapi/v5api.c);
>>     - Test/use the functions to retrieve values via DVBv5 API. The
>> function is
>> already there, but I haven't tested.
>>
>> With the DVBv5 API implementation, zap is now working properly with
>> ISDB-T.
>> gnutv also works (although some outputs - like decoder - may need some
>> changes, in
>> order to work with mpeg4/AAC video/audio codecs).
> 
> Very good job!

Thanks!

> Have you had a look here on this one
> 
> http://www.mail-archive.com/vdr@linuxtv.org/msg11125.html
> 
> ?
> 
> I had this on my list because I wanted to spent some time on DVB-S2
> myself and it seemed to be a good step to merge it (back) into dvb-apps.
> Though I haven't yet looked at it in detail.
> 
> I will check your changes soon, but after the holidays.
> 
> So, now you should have some quiet time for yourself! ;-)

It shouldn't be hard to add DVB-S2 to dvb-apps, now that I've added
support for ISDB-T.

Basically, it needs to move the DVB-S code that it is inside
/util/scan/scan.c to /lib/libdvbapi/v5api.c, extend it to DVB-S2
and write the parser and the new fields for DVB-S2.

Since the dvb-apps library has an abstraction layer, the biggest
part is to add the abstraction layer bits, but this is not a hard
part, and, as DVB-S2 will share several parts with DVB-S, probably
it will require less work.

Cheers,
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

Em 25-12-2009 13:33, Akihiro TSUKADA escreveu:
> 
> Hi Mauro,
> 
>>> I wrote several patches those days in order to allow dvb-apps to properly
>>> parse ISDB-T channel.conf.
>  
> I think it would be convenient if channel.conf allows
> the kind of format of PROPNAME=VALUE list, for readability and extensibility
> of the conf file.
> 
> there are already so many parameters in ISDB-T,
> so it is a bit difficult for the users to remember and correctly specify
> all the field in the right order.
> besides they have to be careful in counting the delimiter character
>  when some (most?) parameters can be omitted or be left to the device/region default.
> 
> and when I consider extending this lib to ISDB-S (for example),
> I have to add "TS-id" parameter,
> which leads to the re-definition of the data structure and requires re-building.
> So, it would be convenient if I could write for example like,
> DTV_FREQUENCY=1049480:DTV_ISDBS_TS_ID=1

It shouldn't be hard to add it, by writing a new parser file and a new dump file.
Currently, there are two parser files and two dump files: one for vdr and one for
zap format.

I opted to not do it to avoid breaking compatibility with those two applications.

Cheers,
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Manu Abraham]

Hello Mauro,


On Fri, Dec 25, 2009 at 7:09 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>> I wrote several patches those days in order to allow dvb-apps to properly
>> parse ISDB-T channel.conf.
>>
>> On ISDB-T, there are several new parameters, so the parsing is more complex
>> than all the other currently supported video standards.
>>
>> I've added the changes at:
>>
>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>
>> I've merged there Patrick's dvb-apps-isdbt tree.
>>
>> While there, I fixed a few bugs I noticed on the parser and converted it
>> to work with the DVB API v5 headers that are bundled together with dvb-apps.
>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
>> there can now be removed.
>>
>> TODO:
>> =====
>>
>> The new ISDB-T parameters are parsed, but I haven't add yet a code to make
>> them to be used;
>>
>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>> segment parameters. Currently, the parser will fail if those parameters are found.
>>
>> gnutv is still reporting ISDB-T as "DVB-T".
>>
>
> I've just fixed the issues on the TODO list. The DVB v5 code is now working fine
> for ISDB-T.
>
> Pending stuff (patches are welcome):
>        - Implement v5 calls for other video standards;
>        - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling
> DVBv5 is now at /lib/libdvbapi/v5api.c);
>        - Test/use the functions to retrieve values via DVBv5 API. The function is
> already there, but I haven't tested.
>
> With the DVBv5 API implementation, zap is now working properly with ISDB-T.
> gnutv also works (although some outputs - like decoder - may need some changes, in
> order to work with mpeg4/AAC video/audio codecs).


Few comments on your changes (that came up on a first glance):

- dvb-apps don't need a DCO (S-O-B) as for kernel related code (though
not an issue, whether it is there or not)

- changeset 1334 is a regression:

dvb-apps look at libraries that are shipped with the distribution
alone. The headers in there are a copy for szap2 alone for test cases
and szap2 is not a generic application such as zap and hence doesn't
need to be ported.

- get_v5_frontend keeps on malloc with no free .....

- the basic design we have in the libraries is that we don't allow the
library to do the allocation but allocation is done by the user
(application)

- the library is not meant to handle the basic in-kernel API alone,
there are others that's the whole intention for the library.

- changeset 1341 is broken

Regards,
Manu

Re: [RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

Manu Abraham wrote:
> Hello Mauro,
> 
> 
> On Fri, Dec 25, 2009 at 7:09 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>>> I wrote several patches those days in order to allow dvb-apps to properly
>>> parse ISDB-T channel.conf.
>>>
>>> On ISDB-T, there are several new parameters, so the parsing is more complex
>>> than all the other currently supported video standards.
>>>
>>> I've added the changes at:
>>>
>>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>>
>>> I've merged there Patrick's dvb-apps-isdbt tree.
>>>
>>> While there, I fixed a few bugs I noticed on the parser and converted it
>>> to work with the DVB API v5 headers that are bundled together with dvb-apps.
>>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
>>> there can now be removed.
>>>
>>> TODO:
>>> =====
>>>
>>> The new ISDB-T parameters are parsed, but I haven't add yet a code to make
>>> them to be used;
>>>
>>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>>> segment parameters. Currently, the parser will fail if those parameters are found.
>>>
>>> gnutv is still reporting ISDB-T as "DVB-T".
>>>
>> I've just fixed the issues on the TODO list. The DVB v5 code is now working fine
>> for ISDB-T.
>>
>> Pending stuff (patches are welcome):
>>        - Implement v5 calls for other video standards;
>>        - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling
>> DVBv5 is now at /lib/libdvbapi/v5api.c);
>>        - Test/use the functions to retrieve values via DVBv5 API. The function is
>> already there, but I haven't tested.
>>
>> With the DVBv5 API implementation, zap is now working properly with ISDB-T.
>> gnutv also works (although some outputs - like decoder - may need some changes, in
>> order to work with mpeg4/AAC video/audio codecs).
> 
> 
> Few comments on your changes (that came up on a first glance):

Thank you for your review!

> - dvb-apps don't need a DCO (S-O-B) as for kernel related code (though
> not an issue, whether it is there or not)

I know. It is just easier for me to keep the SOB than to modify my .hgrc just for
dvb-apps. If this really bothers you, I'm fine to drop it before merging it.

> - changeset 1334 is a regression:
> 
> dvb-apps look at libraries that are shipped with the distribution
> alone. The headers in there are a copy for szap2 alone for test cases
> and szap2 is not a generic application such as zap and hence doesn't
> need to be ported.

It is very confusing to have a copy of the headers there that it is used
by just one application. So, the dvb headers should be either dropped or used
by all compilation.

By using the random header that is found at /usr/include means that
dvb-apps cannot be built with all their capabilities with the stable distros, 
but only with the latest -rc kernels. 

Just for example, in my case, I was running a distro that it was launched
last month (Fedora 12). It was built and running a 2.6.31 kernel, but ISDB-T
API appeared only on 2.6.32. It seems really doubtful that building dvb-apps 
with any current non-alpha distros would enable ISDB-T, since I doubt you'll
find may users with ISDB-T headers on their /usr/include.

On the other hand, if dvb-apps is newer than the driver, there's no problem, since
it will fall-back to v3 API calls.

The practical effect of not using the latest headers is that people using 
the latest -hg kernel drivers won't benefit from the API changes, since 
there's no target at the out-of-tree system to update the headers at /usr/include.

So, except for kernel developers that know how to update the headers from the latest
linus tree, ISDB-T wouldn't work for users currently.

> - get_v5_frontend keeps on malloc with no free .....

It is feed at the end by:

+exit:
+       if (dtv_prop_arg)
+               free (dtv_prop_arg);
+       free_props(&prop);

Anyway, you're right: there are some cases that it is not freeing. I'll fix it.

> 
> - the basic design we have in the libraries is that we don't allow the
> library to do the allocation but allocation is done by the user
> (application)

In this case, it is just a temporary allocation, just like several other libc
routines do. The temporary memory should be freed before returning back to
the caller.

It is used to create a temporary list of data to be sent to the device, and
it is standard-dependent. The current code has only ISDB-T, but I wrote it
thinking on being extended to other standards as well.

The alternative of not using such data struct is very ugly.

The library might provide a callback method to allocate/free such temporary memory,
but I see no point on doing it.

> - the library is not meant to handle the basic in-kernel API alone,
> there are others that's the whole intention for the library.

Sorry, but I didn't get what you meant here: the ISDB-T data structs need to be
handled by the scan and the parsers.

All the applications needed to know is that now ISDB-T is supported. All ISDB-T
complexity were let to the API. If you see the diffstat for the series:
	hg diff -r 1325|lsdiff -p1 

you'll see that the changes were minimal at the applications (on most cases, just
a few lines at the switch() that handles the DTV types, in order to report that
the device all the DVB FE types, like this one:

$ hg diff -r 1325 util/gnutv/gnutv_dvb.c
diff --git a/util/gnutv/gnutv_dvb.c b/util/gnutv/gnutv_dvb.c
--- a/util/gnutv/gnutv_dvb.c
+++ b/util/gnutv/gnutv_dvb.c
@@ -124,8 +124,12 @@ static void *dvbthread_func(void* arg)
                                types = "DVB-T";
                                break;
                        case DVBFE_TYPE_ATSC:
+                       case DVBFE_TYPE_ATSCC:
                                types = "ATSC";
                                break;
+                       case DVBFE_TYPE_ISDBT:
+                               types = "ISDB-T";
+                               break;
                        default:
                                types = "Unknown";
                        }

> - changeset 1341 is broken

What's broken there? I tested it with both DVB-T and ISDB-T and it worked fine.
I don'think that the changes broke for the other standards.

Cheers,
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Mauro Carvalho Chehab]

Patrick Boettcher wrote:
> Hi Mauro,
> 
> On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote:
> 
>> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>>> I wrote several patches those days in order to allow dvb-apps to
>>> properly
>>> parse ISDB-T channel.conf.
>>>
>>> On ISDB-T, there are several new parameters, so the parsing is more
>>> complex
>>> than all the other currently supported video standards.
>>>
>>> I've added the changes at:
>>>
>>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>>
>>> I've merged there Patrick's dvb-apps-isdbt tree.
>>>
>>> While there, I fixed a few bugs I noticed on the parser and converted it
>>> to work with the DVB API v5 headers that are bundled together with
>>> dvb-apps.
>>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests.
>>> The ones
>>> there can now be removed.
>>>
>>> TODO:
>>> =====
>>>
>>> The new ISDB-T parameters are parsed, but I haven't add yet a code to
>>> make
>>> them to be used;
>>>
>>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>>> segment parameters. Currently, the parser will fail if those
>>> parameters are found.
>>>
>>> gnutv is still reporting ISDB-T as "DVB-T".
>>>
>>
>> I've just fixed the issues on the TODO list. The DVB v5 code is now
>> working fine
>> for ISDB-T.
>>
>> Pending stuff (patches are welcome):
>>     - Implement v5 calls for other video standards;
>>     - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code
>> for calling
>> DVBv5 is now at /lib/libdvbapi/v5api.c);
>>     - Test/use the functions to retrieve values via DVBv5 API. The
>> function is
>> already there, but I haven't tested.
>>
>> With the DVBv5 API implementation, zap is now working properly with
>> ISDB-T.
>> gnutv also works (although some outputs - like decoder - may need some
>> changes, in
>> order to work with mpeg4/AAC video/audio codecs).
> 
> Very good job!
> 
> Have you had a look here on this one
> 
> http://www.mail-archive.com/vdr@linuxtv.org/msg11125.html
> 
> ?
> 
> I had this on my list because I wanted to spent some time on DVB-S2
> myself and it seemed to be a good step to merge it (back) into dvb-apps.
> Though I haven't yet looked at it in detail.
> 
> I will check your changes soon, but after the holidays.
> 
> So, now you should have some quiet time for yourself! ;-)

Ok, I've added a version 2 of the isdbt-aware dvb-apps scan tools. 

Basically, this version:
	- checks if v5 API is available on a driver. If not, it falls back to 
	  v3 API;
	- v5api.c is now fully internal to libdvbfe. For library clients, it
is fully transparent if it is using v5 or v3 calls;
	- scan now uses libdvbfe, instead of directly implementing the
ioctls for v3 and v5. The code were simplified by the removal of lots of if's
for v5 API;
	- scan now supports a few parameters present on DVB-S2, but there
are still a few missing bits to fully support DVB-S2;
	- as my previous tree, dvb-apps has a copy of the dvb headers, since
the headers are stable enough to work with older drivers and since the API
version check is done by an ioctl call;
	- it addresses the pertinent issues that Manu pointed.

The big advantage of using libvbfe for scan is that we can remove all v5 
(and v3) calls from scan, having a cleaner code. Also, applications like kaffeine
that have their own scan codes can benefit on using libdvbfe.

Probably, it makes sense to move some code from scan to libdvbfe or to create
a libdvbscan, in order to easy the usage of the libdvb for applications that
want to have the scan code integrated.

I started to validate the delivery system descriptors against the EN 300 468
v 1.9.1, but I haven't finished yet. Due to that, a few new parameters were
added, making easier to add DVB-S2 support.

I intend later to finish the validation against ETSI for DVB standards and do
some review on ARIB and ABNT specs to be sure that it is able to get all 
parameters reported by the NIT tables for ISDB-T.

Yet, this version is not properly tested, but, as I intend to be on vacations
next week, I wanted to post what I have, even without all tests, to avoid the 
risk of someone to be working on DVB-S2 or other improvements to do a similar 
work.

So, the new tree is at:

http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/

it was tested only with ISDB-T and may not work yet with other DTV standards.

Enjoy!

Happy New Year!
Mauro.

Re: [RFC] dvb-apps ported for ISDB-T

[Manu Abraham]

On Fri, Jan 1, 2010 at 2:23 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Patrick Boettcher wrote:
>> Hi Mauro,
>>
>> On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote:
>>
>>> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
>>>> I wrote several patches those days in order to allow dvb-apps to
>>>> properly
>>>> parse ISDB-T channel.conf.
>>>>
>>>> On ISDB-T, there are several new parameters, so the parsing is more
>>>> complex
>>>> than all the other currently supported video standards.
>>>>
>>>> I've added the changes at:
>>>>
>>>> http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/
>>>>
>>>> I've merged there Patrick's dvb-apps-isdbt tree.
>>>>
>>>> While there, I fixed a few bugs I noticed on the parser and converted it
>>>> to work with the DVB API v5 headers that are bundled together with
>>>> dvb-apps.
>>>> This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests.
>>>> The ones
>>>> there can now be removed.
>>>>
>>>> TODO:
>>>> =====
>>>>
>>>> The new ISDB-T parameters are parsed, but I haven't add yet a code to
>>>> make
>>>> them to be used;
>>>>
>>>> There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
>>>> segment parameters. Currently, the parser will fail if those
>>>> parameters are found.
>>>>
>>>> gnutv is still reporting ISDB-T as "DVB-T".
>>>>
>>>
>>> I've just fixed the issues on the TODO list. The DVB v5 code is now
>>> working fine
>>> for ISDB-T.
>>>
>>> Pending stuff (patches are welcome):
>>>     - Implement v5 calls for other video standards;
>>>     - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code
>>> for calling
>>> DVBv5 is now at /lib/libdvbapi/v5api.c);
>>>     - Test/use the functions to retrieve values via DVBv5 API. The
>>> function is
>>> already there, but I haven't tested.
>>>
>>> With the DVBv5 API implementation, zap is now working properly with
>>> ISDB-T.
>>> gnutv also works (although some outputs - like decoder - may need some
>>> changes, in
>>> order to work with mpeg4/AAC video/audio codecs).
>>
>> Very good job!
>>
>> Have you had a look here on this one
>>
>> http://www.mail-archive.com/vdr@linuxtv.org/msg11125.html
>>
>> ?
>>
>> I had this on my list because I wanted to spent some time on DVB-S2
>> myself and it seemed to be a good step to merge it (back) into dvb-apps.
>> Though I haven't yet looked at it in detail.
>>
>> I will check your changes soon, but after the holidays.
>>
>> So, now you should have some quiet time for yourself! ;-)
>
> Ok, I've added a version 2 of the isdbt-aware dvb-apps scan tools.
>
> Basically, this version:
>        - checks if v5 API is available on a driver. If not, it falls back to
>          v3 API;
>        - v5api.c is now fully internal to libdvbfe. For library clients, it
> is fully transparent if it is using v5 or v3 calls;
>        - scan now uses libdvbfe, instead of directly implementing the
> ioctls for v3 and v5. The code were simplified by the removal of lots of if's
> for v5 API;
>        - scan now supports a few parameters present on DVB-S2, but there
> are still a few missing bits to fully support DVB-S2;
>        - as my previous tree, dvb-apps has a copy of the dvb headers, since
> the headers are stable enough to work with older drivers and since the API
> version check is done by an ioctl call;
>        - it addresses the pertinent issues that Manu pointed.


It still remains the same, however.

I had a quick look at it again:

- dvb-apps/libs stopped using a separate copy of the kernel headers;
ie  kernel headers are expected to be at the default system locations,
ie the kernel headers package. Because you added it in again, a test
app szap2 had to be disabled for compilation. Changesets: 1332, 1334,
1348, 1357

- the library is falling on an expected operation for V5. This can
fail if the API is V3 or something else. It should check the header
version and if it is known to be greater than V3, then only it should
issue the new V5 ioctl to test for version. This frees from an
unnecessary test in the case of the V3 API. Changeset 1336

- Please do not apply partial features. Either apply it, or don't.
Changeset 1341

- ATSC Cable is not DVB-C, even though it has some similiarities.
Let's not get things mixed up. Changeset 1344

- Let the application send the number of properties, not the library
to do memory allocation and deallocation. I mentioned about this one
in my previous reply to your post. fill_sys_v5_params() -->
count_props()
Changeset: 1350, 1359, 1360
sizeof applies to a data structure, not the pointer, Changeset 1360

- maintain Backward compatibility with V3. Changeset 1351


> Yet, this version is not properly tested, but, as I intend to be on vacations
> next week, I wanted to post what I have, even without all tests, to avoid the
> risk of someone to be working on DVB-S2 or other improvements to do a similar
> work.


- Memory management needs string.h

v5api.c:512: warning: implicit declaration of function ‘memset’
v5api.c:512: warning: incompatible implicit declaration of built-in
function ‘memset
v5api.c:567: warning: incompatible implicit declaration of built-in
function ‘memset’


Maybe, it would simplify things, if I would pull in the changes till
where it looks mostly right, the others which you could possibly
rework. Or maybe you would like me to apply things as a whole
together. But I guess things would be simpler in the former case.


Regards,
Manu