* RFC: dvbzap application based on DVBv5 API
@ 2011-12-29 20:12 Mauro Carvalho Chehab
2011-12-30 6:46 ` Akihiro TSUKADA
0 siblings, 1 reply; 3+ messages in thread
From: Mauro Carvalho Chehab @ 2011-12-29 20:12 UTC (permalink / raw)
To: Linux Media Mailing List
In order to test the large chunk of patches I've made those days, I wrote
a dvbzap application using DVBv5 API, based on tzap.
It is at my experimental v4l-utils tree, at branch dvb-utils:
http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils
in order to test, please use:
git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git
While I tested it only with ISDB-T, it will likely work with DVB-T, ATSC and DVB-C,
if CA is not needed.
TODO:
- Add proper support for Satellite delivery systems. It will likely
recognize a DVB-S zap file, but it won't work, as polarization setting were not
implemented, nor any DISEqC commands;
- Add support for CA;
- Be more flexible with regards to the channels.conf files.
One of the changes I'm experimenting with this tool is to define a new format to
show DVBv5 channels/transponders.
As you likely know, the current formats on the existing DVBv3 tools are
standard-dependent. Even the existing DVBv5 applications I'm aware of currently
write the channels file on a DVBv3, due to compatibility issues.
So, a new format for channels is needed.
The current code has one function to write on a new format. I lacks a parser for it
(it shouldn't be hard to write one - a few hours should be enough for doing that).
The format I'm thinking is to use:
[channel name]
property = value
...
property = value
This allows the same format to be used by any DVBv5 supported delivery system.
It will even allow to mix channels from different delivery systems on the same file.
This could be useful for devices like DRX-K, that supports multiple delivery
systems with different parameters.
As an example, this is what it produces from a DVB-T zap file:
[TV Brasil SD]
VIDEO_PID = 769
AUDIO_PID = 513
SERVICE_ID = 16161
DELIVERY_SYSTEM = DVBT
FREQUENCY = 479142857
INVERSION = AUTO
BANDWIDTH_HZ = 6000000
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
MODULATION = QAM/AUTO
TRANSMISSION_MODE = AUTO
GUARD_INTERVAL = AUTO
HIERARCHY = NONE
The same entry without audio/video/service ID's (like the ones used
by scan) would look like:
[CHANNEL]
DELIVERY_SYSTEM = DVBT
FREQUENCY = 479142857
INVERSION = AUTO
BANDWIDTH_HZ = 6000000
CODE_RATE_HP = AUTO
CODE_RATE_LP = AUTO
MODULATION = QAM/AUTO
TRANSMISSION_MODE = AUTO
GUARD_INTERVAL = AUTO
HIERARCHY = NONE
My next steps with regards to this tool are to:
1) convert a scan tool to use the same libraries as dvbzap is
using, in order to generate an output file for scan with the same format;
2) to implement a parser for the new format (this should be easy, so maybe
I'll start with this).
Comments, ideas, patches, etc are welcome.
Regards,
Mauro
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: dvbzap application based on DVBv5 API
2011-12-29 20:12 RFC: dvbzap application based on DVBv5 API Mauro Carvalho Chehab
@ 2011-12-30 6:46 ` Akihiro TSUKADA
2012-01-04 16:13 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 3+ messages in thread
From: Akihiro TSUKADA @ 2011-12-30 6:46 UTC (permalink / raw)
To: Linux Media Mailing List
> [channel name]
> property = value
> ...
> property = value
Currently, at least gstreamer's dvbbasebin and mplayer assumue that
the channel configuration file has the format of one line per channel.
So when I personally patched them to use v5 parameters,
I chose the one-line-per-channel format of
<channel name>:propname=val|...|propname=val:<service id>, for example,
NHKBS1:DTV_DELIVERY_SYSTEM=SYS_ISDBS|DTV_VOLTAGE=1|DTV_FREQUENCY=1318000|DTV_ISDBS_TS_ID=0x40f2:103
, to minimize modification (hopefully).
I understand that it is not that difficult nor complicated
to adapt applications to use the ini file style format,
but the old one line style format seems slightly easier.
and I wish that the channel configuration can allow nicknames/aliases,
as the canonical channel name can be long to type in or difficult to remember correctly.
If I remember right, MythTV has its own database,
and it would be convenient if we could share the database,
because applications currently have their own channel configuration separately,
and the configuration change like new service or parameter changes must be
propagated manually.
regards,
Akihiro
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: dvbzap application based on DVBv5 API
2011-12-30 6:46 ` Akihiro TSUKADA
@ 2012-01-04 16:13 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 3+ messages in thread
From: Mauro Carvalho Chehab @ 2012-01-04 16:13 UTC (permalink / raw)
To: Akihiro TSUKADA; +Cc: Linux Media Mailing List
Hi Akihiro,
On 30-12-2011 04:46, Akihiro TSUKADA wrote:
>> [channel name]
>> property = value
>> ...
>> property = value
>
> Currently, at least gstreamer's dvbbasebin and mplayer assumue that
> the channel configuration file has the format of one line per channel.
> So when I personally patched them to use v5 parameters,
> I chose the one-line-per-channel format of
> <channel name>:propname=val|...|propname=val:<service id>, for example,
> NHKBS1:DTV_DELIVERY_SYSTEM=SYS_ISDBS|DTV_VOLTAGE=1|DTV_FREQUENCY=1318000|DTV_ISDBS_TS_ID=0x40f2:103
> , to minimize modification (hopefully).
> I understand that it is not that difficult nor complicated
> to adapt applications to use the ini file style format,
> but the old one line style format seems slightly easier.
It is not that harder to parse a multiple lines file, but using something like above
makes harder for humans to read. Also, the format I've proposed is already handled
by several existing tools. So, there are several parsers for it already
written.
> and I wish that the channel configuration can allow nicknames/aliases,
> as the canonical channel name can be long to type in or difficult to remember correctly.
> If I remember right, MythTV has its own database,
> and it would be convenient if we could share the database,
> because applications currently have their own channel configuration separately,
> and the configuration change like new service or parameter changes must be
> propagated manually.
Yes, this is an interesting feature. Some carriers broadcast nicks/aliases via
the emphasis encoding. It shouldn't be hard to add support for it.
Btw, I finished writing a dvbv5-scan application. It reads (currently) the
legacy channels/transponders format found on dvb-apps, and outputs channel
scans on the new format.
I decided to write the scan tool from scratch, instead of importing the code from
w_scan or dvb-apps/scan, as it allowed me to avoid importing DVBv3 legacy stuff
on it, and to separate the scan code into a few function calls.
Due to that, only a subset of the features found on the other scan tools are there
(the ones that are needed for ISDB-T - and - likely DVB-T). I'm currently without
DVB-C signal, but, as soon as I return back to my hometown, I'll add the missing
bits for it.
I also wrote a small utility to convert from the legacy zap and channels.conf
formats into the new one. It is at:
http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils
Of course, patches, help, etc are welcome!
Regards,
Mauro
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-01-04 16:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-29 20:12 RFC: dvbzap application based on DVBv5 API Mauro Carvalho Chehab
2011-12-30 6:46 ` Akihiro TSUKADA
2012-01-04 16:13 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).