There is no way to tell one over the other when parameters
seem valid for DVB-T and DVB-T2 and the adapter supports
both. Reason to go with the former here is that, from
experience, most DVB-T2 channels out there seem to use
parameters that are not valid for DVB-T, like QAM_256
https://bugzilla.gnome.org/show_bug.cgi?id=765731
DVB-T/T2 have the same number of fields so we were
wrongly assuming DVB-T for DVB-T2 broadcasts. Not
setting the delivery system here allows for dvbsrc
to make an informed guess based on the channel
parameters.
When there's no explicit delivery system information
for a channel in the channel configuration file and
the user hasn't selected one via setting the delsys
property, we *guessed* it by selecting the last
supported delsys reported by the driver. This change
provides the basis for smarter delsys auto detection
and implements a rule for DVB-T2. Rules for other
delivery systems can be added in _guess_delsys() in
a similar way.
Additionally: Store list of adapter-supported
delivery systems instead of querying the driver each
time this information is needed.
Related to:
https://bugzilla.gnome.org/show_bug.cgi?id=765731
The only mandatory frontend information for our use case
is its status. Make sure we output what we know instead
of choking at the first error getting SNR, BER or any of
the other informational parameters.
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_ARGS.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
DVB-T2 supports 5, 10 and 1.712 MHz
Order of the enum values (new values after _AUTO)
has been kept congruent with the one in the v4l
API for consistency
Previously known as DMB-T/H, this is the
terrestial DTV broadcast standard currently
used by the People's Republic of China,
Hong Kong, Laos and Macau (officially),
and by Malaysia, Iraq, Jordan, Syria and
Lebanon (experimentally).
These apply to ISDB-T, DVB-T2 and DTMB
Order of the enum values (new rates after _AUTO)
has been kept congruent with the one in the v4l
API for consistency.
According to the v4l-dvb API docs, these are only
used for DVB-T2 at the moment.
Order of the enum values (new rates after _AUTO)
has been kept congruent with the one in the v4l
API for consistency.
Valid values range from 1 to 7 as stated.
DTV_ISDBT_LAYER_ENABLED bitmask is built from
OR-ing 0x1 0x2 0x4. If all bits are set
(0x00000111 = 7) it means all layers should be
demodulated.
Change avoids attempting to convert to kHz if unneeded.
There are quite some ZAP format variants out there. Among
their subtle little differences, some store transponder
frequencies in Mhz and others in kHz. The latter been the
most common variant.
It works the same as the 'tune' property that is used only to signal
the element that it should tune, but it is more natural to be used
as a signal rather than a property.
It is also proxied at the dvbbasebin element
ISDB-T and ISDB-Tb (the Brazilian variant) are the
terrestial DTV standards used by Japan, Philippines,
Maldives, Thailand, most South American countries
and Botswana. Changeset adds the set of previously
missing (and required) ISDB-T parameters, adapter
and frontend setup logic and proxies the new
properties on dvbbasebin.
Tested to work with the live aerial broadcast by
Tv Paraíba HD in Campina Grande (Brazil).
https://bugzilla.gnome.org/show_bug.cgi?id=732875
Allows proper tuning around high/low band boundaries when using
non "standard" LNBs.
Not all LNBs (Low noise block down converters) are made equal.
This is particularly true for universal LNBFs, where, even though
there are seemingly standard values for the local oscillator
frequencies, these can vary from manufacturer to manufacturer
and LNB model. Change also proxies the new LNB properties in
dvbbasebin.
https://bugzilla.gnome.org/show_bug.cgi?id=732818
It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
Interestingly, Coverity implies that close takes an unsigned
argument, while my close(2) man page shows it taking a signed
argument. I guess it may be platforms specific.
Coverity 1214602
New approach attempts to be more accurate by measuring
the elapsed time by iteration. Also:
* Use a 10 seconds default timeout and a half a second
polling step. New values should better match the tuning
process on real-life scenarios.
* Correct elapsed_time computation.
* Add _retry_ioctl() to avoid bailing out on temporary
ioctl EINTR failures (no need to check for EAGAIN cause
we are opening the frontend on blocking mode)
* Small corrections to fail condition handling
* Drop remaining sleep() logic in favor of polling
* Use best guess delivery system if none is set
* Make tuning/locking timeout configurable
* Add signals for tuning start, done and fail
* Drop gst_dvbsrc_frontend_status(). It was used only
for signal LOCK checking. This is now part of the
tuning/locking loop
* Break up frontend configuration and tuning
on separate functions
Plus:
* Add some more useful DEBUG/TRACE messages
* Move over misplaced DVB API message
* Fix wrong comment for default DVB buffer size (http://linuxtv.org/downloads/v4l-dvb-apis/dmx_fcalls.html#DMX_SET_BUFFER_SIZE)
This patch builds up on previous work done by
Fabrizio (Misto) Milo <mistobaan@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=641204
