GNOME Bugzilla – Bug 654479
Support DVB-S2
Last modified: 2013-05-08 16:29:29 UTC
Created attachment 191817 [details] [review] dvb s2api patch against current git Please add support for DVB-S2. The good news is that I've done it myself and I am attaching patches. This uses s2api for all other types of card too, but I've only tested it with DVB-T and DVB-S(2) because I don't have cable or ATSC. I've added properties "roll-off", "gen2" and "dvb-s2" to dvbsrc and dvbbasebin. Additionally "satellite" delivery descriptor structures contain "roll-off" and "dvb-s2" members.
Created attachment 191818 [details] [review] DVB s2api patch against 0.10.22 for Debian unstable
Please attach the patch in "git format-patch" style. It makes applying it easier and will include your name, mail address and commit message.
Created attachment 191903 [details] [review] Adds DVB-S2 and s2api support to the DVB subsystem and MPEG parsers. Replaces earlier patch. Now generated with git format-patch.
Are there any plans to accept this patch?
It should probably be updated to support DVB-T2 too. At the moment the only extra parameter supported by the kernel is plp-id.
Review of attachment 191903 [details] [review]: There are too many things put together here Make different patches for the dvb part, and the various other elements. Make a separate patch for adding DVB_API_VERSION == 5 support (Essentially S2API) Then finally a patch adding the support for the DVB-S2 FE parts. Don't you also need to expose control of DTV_PILOT ?
Tony, are you planning on updating these patches ?
To be honest, I wasn't planning to. In the end I decided my needs were better served by writing my own code to handle tuning and parsing SI data (via linux API section filters) and only using gstreamer for handling the stream. One of the factors in my decision was that there seemed to be no progress in getting this patch accepted and I want my application ultimately to work with standard gstreamer without having to patch it. If there is now some interest in it and nobody else is available I'm willing to have a go at updating it.
(In reply to comment #8) > To be honest, I wasn't planning to. In the end I decided my needs were better > served by writing my own code to handle tuning and parsing SI data (via linux > API section filters) and only using gstreamer for handling the stream. > > One of the factors in my decision was that there seemed to be no progress in > getting this patch accepted and I want my application ultimately to work with > standard gstreamer without having to patch it. Sad to hear, but understandable. There are only so many reviewers :( > If there is now some interest in > it and nobody else is available I'm willing to have a go at updating it. That would be great ! All development effort is going right now in the master branch (i.e. 1.0). It brings many performance improvements, and new demuxers. Don't hesitate to ask for assistance here or on the #gstreamer IRC channel
Yes, it definitely makes sense to target 0.11/1.0. One thought I've had is that S2API is a closer fit to gstreamer's API because set_property/get_property could be mapped directly to the FE_SET_PROPERTY and FE_GET_PROPERTY ioctls instead of storing a struct in the object but I didn't do it that way before because it was simpler to keep the struct when retaining backwards compatibility with the old DVB API. Would it be OK to assume that S2API will always be available with gstreamer 1.0 and drop support for the old API? That would simplify the new version of dvbsrc which I think is a better goal than minimising the changes made by the patch.
(In reply to comment #10) > Would it be OK to assume that S2API will always be available with gstreamer 1.0 > and drop support for the old API? That would simplify the new version of dvbsrc > which I think is a better goal than minimising the changes made by the patch. Considering S2API has been available for 4 years, I'm fine with that.
I'm having trouble doing this because I can't get the python DVB application I was developing to work with gstreamer 0.11/1.0. See Bug 679856. Should I add that the bug blocks this one? The program is also aborting after that with EINVAL from pthread_mutex_lock() but I wouldn't have thought the structure parsing errors should cause that because they're handled entirely within the message callbacks with try/except.
Created attachment 227376 [details] [review] Use DVB API v5 The attached patch exclusively uses the newer v5 API and no longer v3 API. Support for DVB-S2 is not yet included.
(In reply to comment #13) > Created an attachment (id=227376) [details] [review] > Use DVB API v5 > > The attached patch exclusively uses the newer v5 API and no longer v3 API. > Support for DVB-S2 is not yet included. nice patch. I cannot see the handling of multi-standard frontends. With ioctl FE_GET_PROPERTY, cmd=DTV_ENUM_DELSYS you can ask all delsys, which the frontend can. A few delsys I missed.
This looks quite nice indeed. Will try to try it later. I think the handling of multiple delivery system should be added as a separate patch since we don't have that feature in current dvbsrc. I'm actually wondering if it wouldn't make more sense to add that feature in dvbbasebin. The reasoning is that it's dvbbasebin that figures out for a given channel name which settings to put on dvbsrc. Right now it just forwards the adapter/frontend properties, but it could scan all available adapters/frontends to figure out which one can handle T/C/S/S2/.... and set that accordingly.
commit 5d406192c3301bd4751c55f94e667c77ebed3577 Author: Sebastian Pölsterl <sebp@k-d-w.org> Date: Fri Oct 26 18:00:02 2012 +0200 Use DVB API v5 aka S2API instead of obsolete v3 API Patch is based on work of Tony Houghton <h@realh.co.uk> https://bugzilla.gnome.org/show_bug.cgi?id=654479