GNOME Bugzilla – Bug 152403
[mpeg/DVB] Integrating externaly developped DVB source element
Last modified: 2007-03-07 11:07:43 UTC
at the end of june, first days of jully, on the devel ML, there has been a post about adding support for DVB as a source : http://sourceforge.net/mailarchive/message.php?msg_id=8873625 it seems that Martin Eikermann wrote such an element and posted the source on his website : (sources from 07/03/2004) http://eikermann.afraid.org/dvbsrc.tar.bz2 http://eikermann.afraid.org/ts-tools.tar.bz2 (see the second message) his mail is : eikermann@gmx.net/meiker@upb.de, i'll put it on CC better contact him, he might have newer code that those snapshots zaheer has 2 != DVB cards, i have one, perhaps we would be able to help integrating those elements there has been 3 threads on devel ML on this subject : (found via gmane) "DVB Source Plugin" : 15/04/2003 "New Plugin: gstdvbsrc" : 14/07/2003 (by Martin, the plug-in author) "DVB Filter : 30/06/2004" perhaps it's time to integrate it, before it fail into oblivon for one more year. a DVB related bug from him : http://bugzilla.gnome.org/show_bug.cgi?id=119376 (a bug he had when he was already using his plug-in to capture mpeg PES, more than one year ago)
in case the plugin author can't be reached at any of the 2 above mail, here is a third one : meiker (at) uni-paderborn.de the one in the AUTHORS file of his dvbsrc plug-in tarball
Hi Stephane, I just put the current version of my stuff at eikermann.afraid.org. There's also a patch for the mpegdemuxer in addition to the dvbsrc element and the ts-tools. The patch is necessary to calulate the muxrate on the fly from PCRs, otherwise video and audio are not synchronized correctly between two PCRs. (IIRC xine and mplayer do the same to handle mpegs with incorrect muxrates) Changes from prev. version: * dvbsrc: take a list of pids instead of apid and vpid * tsparse: gerneral section parsing parsing of standart MPEG-TS section such as PAT, PMT
patch for bug #119376 applied (mpegstream.patch)
got a few issues while testing those plugins : running 'gst-inspect dvbsrc', i got : pol : Polarity Unknown type 16 "guchar" pidlist : Pointer to a guint16[MAX_FILTERS] (For Apps) Unknown type 68 "gpointer" Write only tune : Atomically tune to channel. (For Apps) Unknown type 68 "gpointer" Write only trying to use any of those parameters on a pipeline would trigger an error like : ERROR (0x80509b8 - 304195:53:44.738930000) GST_PIPELINE(29971) ./grammar.y(276):gst_parse_element_set: could not set property "pol" in element "dvbsrc0" to "h" --------- in dvbsrc README, the gst-launch example is outdated (uses apid, vpid) xvideosink is 0.6, now is x[v]imagesink --------- gstdvbtv : (process:29991): GLib-GObject-WARNING **: g_object_set_valist: object class `GstFileSrc' has no property named `freq' (process:29991): GLib-GObject-CRITICAL **: file gobject.c: line 1207 (g_object_set): assertion `G_IS_OBJECT (object)' failed --------- gst-inspect tsparse /usr/bin/gst-inspect-0.8: symbol lookup error: /usr/lib/gstreamer-0.8/libgsttsparse.so: undefined symbol: gst_tsparse_init_section_filter (this one could me my fault as i installed those plugins manually)
On the properties of dvbsrc: * pol: Is of type gchar. I had a patch for the core to accept g(u)char properties on elements. However, with the introduction of gstvalue it was rendered obsolete. The clean solution now is to add g[u]char support to gstvalue. I'll file a bug. * pidlist: Is another way to set the pids. It was intended that apps use this instead of construction a string of pids. I'd agree if someone says it's redundant , leads to confusion and should be removed. * tune: From the command line u can't change the channel. For an app I figured several ways to tune: 1. Everytime a property is changed. (Everytime u tune, ~1-2sec pass by until the signal is locked, so this is impractical) 2. A separate pointer property "tune-channel" which is used to hand a struct containing channel properties from app to dvbsrc (Would render all other properties useless) 3. Set all properties and finally set the special dvbsrc property tune (value will be ignored) to tune. Maybe there is a more coherent way which i haven't thought about. -------- README, fixed in current version, thx. -------- gstdvbtv: this is merely an example program. However it should work. There was something left from my debugging. The issue i was debugging on is still not resolved. If I build the pipeline which works from the command line in gstdvbtv something goes horribly wrong with the clocking. I disabled my left overs from debugging, so if u start gstdvbtv u should see it too, unless it was fixed in a very recent version of gstreamer. -------- It's my fault. I tried on consistend naming of functions, and failed.... (fixed now) I updated both packages on my server. Thx for your comments.
i just downloaded new versions (sep 14 00:40 GMT+2) --- as long as pol would use a non-supported gstvalue type, no one would be able to set this property. i don't mind if you choose a string or a boolean for it. what is the default value for polarity ? H or V ? --- we should keep in my that DVB is not only DVB-S. afaik, polarity is DVB-S only. so, we should perhaps add a property which says which DVB type is in use (or is it possible to auto-detect it ??) i don't know if adding DISEQC functions into this module makes sense but this is secondary. (however, i'll need DISEQC one day as i have a dual-head : hotbird 13°E/astra 19.2°E) --- launching the gst-launch line or gstdvbtv, i always have : WARNING **: Unable to set voltage on dvb frontend device my modules are loaded : firmware_class 10240 1 dvb_ttpci ttpci_eeprom 2816 1 dvb_ttpci stv0299 13000 0 dvb_core 87336 2 dvb_ttpci,stv0299 crc32 4352 2 dvb_ttpci,dvb_core saa7146_vv 49536 1 dvb_ttpci video_buf 21636 1 saa7146_vv v4l1_compat 13828 1 saa7146_vv v4l2_common 6208 1 saa7146_vv videodev 9920 1 saa7146_vv saa7146 18788 2 dvb_ttpci,saa7146_vv as you see, i have a TechnoTrend DVB-S v1.3 --- my first head is directed to hotbird 13°E, so i'll have to find frequency/symbol rate/pids for a Free To Air channel on it to really test it further. --- perhaps in the future, it would be good if dvbsrc could generate events like "PID list changed" as depending on the program, there could be several audio streams (stereo/ac3, french/english/deustch), a subtitle stream or not, EPG, ... how do you plan to handle this ? --- it seems that your plugins live in a CVS repository somewhere (saw .cvsignore fimes). is this a public CVS server or is that inside your university (closed to non-students) ?
depending on how we would clean it enought/make it work fully, your plugins would go somewhere in gstreamer CVS. if fully working : gst-plugins under sys/ for dvbsrc and under gst/ for tsparse/ts2ps if not : in gst-sandbox/dvb i have CVS access for gstreamer but the decision to put it in one or the other would not be mine.
last thing for tonight : it should be better to detect and use system installed DVB headers (linux/dvb/*) instead of local copies in dvb-api i'll try provide you a patch for that tomorrow if you want (for a clean detection in configure.ac)
on #6: - I changed the pol property to be of type string and removed the pidlist property as it was not even implemented. - DVB-S, DVB-T and DVB-C all need a different set of parameters. I just have a TT Budget DVB-S Card so I didn't worked on terrestial or cable. A use case for a DVB-[SCT] app might be: 1. Set adapter property. 2. Wait for element to signal the type of this adapter (through a signal or property) 3. Choose a proper channels.conf based on 2. 4. Set properties on dvbsrc. - It'd be nice to have DISEQC support. > WARNING **: Unable to set voltage on dvb frontend device - Does it work with mplayer or xine? If not, is the firmware loaded? - For a list of frequencies have a look at http://www1.digitalfernsehen.de/frequenzen/hotbird13.html - Plan is to subclass tsparse for a dvbsi plugin. dvbsi would parse all service information defined in the dvb standart (e.g. EIT (EPG), Service Descr. Table (SDT), Time Desrc. Table (TDT), ...) The SDT/PMT provide all necessary data to learn which pids are associated with a particular service (program). With a additional dvbtxt, dvbsubt u can then get hold of the Teletext/Subtitles. There is a mpeg2subt element. It decodes dvd subtitles and merges them with a video stream. It may also be able decode DVB subtitles. On different audio streams: Maybe we should change ts2ps to take not just vpid and apid but at least one vpid and many apids. Mpegdemux would then demux all streams in the program stream and u can just use the switch element to make a choise between them. - it's just my local repository ------ on #7: That'd be great. This would expose the plugins to some more users and one or the other might even have a dvb-c or dvb-t card. ------ on 8# I ever wanted to add this too. It's just that my distrubution (FC2), and supposedly most other distributions, do not install the dvb api headers. I had expected them in /usr/include/linux/dvb/... . And afaik the API hasn't changed since long and there is no intention to change it. Look here for more info: http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0372.html
The links to the code on your website seems to be dead. Are they still online somewhere?
Stephane put everything into gst-sandbox. The dvb-elements directory. There is the most recent version of the dvb elements. I still have a patch locally for the dvb-elements. I'll attach it here so someone with cvs access can apply it.
Created attachment 33436 [details] [review] Enhancement patch for dvb elements * use poll for reading from DVBs dvr device * new-media events from dvbsrc on tuning * command line channel tuning in gstdvbtv * new-media event in ts2ps/tsparse will initiate some cleanup * prepared for dvbsi plugin * gstdvbtv now reads channel.conf files from recent vdr version However there's still one bug in gst-core and another in mpegdemux which prevents the small sample app gstdvbtv from working as a charm. mpegdemux creates pads based on stream ids. So when the stream id changes, cause dvbsrc is tuned to another channel, some pads will not be used anymore. There's no way to figure out which pads to use.
hi Martin, i just commited your patch from comment #12 about the 2 bugs you mention in this comment, what are their bug number in bugzilla ? (if they're not in, please create them)
Hi Stephane First bug was #148787 which is fixed. For the second issue I just submitted #160730 (http://bugzilla.gnome.org/show_bug.cgi?id=160730).
Created attachment 35025 [details] [review] further enhancement Added features: * finally supports recent vdr channels.conf format * added missing properties for DVB-T * changed mime type from video/mpeg to video/mpeg-ts * sample channels.conf for DVB-T, -S, -C (from vdr) * autogen.sh for dvbsrc and ts-tools directory
this bug depends on #161929. Can someone add this dependency. I can't (why?).
Convergence is bankrupt, so the GPL routines copyrighted by them need to be replaced with something LGPL. The files which is only copyrighted by Marcus Metzler we can probably have relicenced. Let me know if that is of interest or if that partial relicense doesn't really save any work.
Created attachment 38726 [details] DVB-T Demo This program successfully uses dvbsrc for watching ProSieben via DVB-T in Berlin/Germany. Hardware is some passive Terratec CinergyT2 USB box. So DVB-T appears to be working. At least with that hardware. Just wondering why it is that incredibly slow: Via Xine and Mplayer my good old P3/733 has "only" 40 to 50 percent CPU load. Via gstreamer this machine is far too slow for watching DVB-T.
Hmm... Forgot to ask: Why develop ts-tools, if ffmpeg also supports MPEG2TS? Ok, ffdemux_mpegts of gst-plugins-0.8.4 fails to connect with dvbsrc - but accordingly to my experiments with the ffmpeg commandline tool, ffmpeg is able to demultiplex the MPEG2TS stream sent via DVB-T in Berlin.
I may have mixed up mimetypes. I've done most of ffmpeg, and honestly, I don't know what some of those mediatypes are. Also, note that I don't have a DVB card so I cannot test this... If you believe it's wrong, change the mimetype in gstffmpegcodecmap.c (in gst-ffmpeg/ext/ffmpeg/) and submit a patch.
#20: Hmmm... Fixing the mime-type allowed the filter to connect. Nevertheless ffdemux_mpegts failes to create PADs. Could be, that ffdemux_mpegts has problems to detect the video and audio streams? The combination of ts2ps and mpegdemuc also stays silent, until I tell ts2ps which program ids to filter out. Regarding the MIME type of MPEG2 transport streams: Three suggestions ("video/mpeg-ts" in dvbsrc, "video/mpegts" in gst-ffmpeg and "video/x-mpegts" in ffmpeg), but all where wrong. Accordingly to RFC 3555 "video/MP2T" is the proper MIME type. Wondering now, which MIME type to put into the patches: "video/MP2T" or "video/mp2t"? Asking, because in violation to RFC 2045 gstreamer handles MIME types case-sensitive (instead of handling them case-insensitive).
#18: Thanx for the feedback. I have a DVB-S card only. Did you try the sample program (gstdvbtv) as well? I wonder why you experience high cpu load. ts parsing is not cpu intensive so so that the whole dvb pipeline should be having similar load as a mpeg pipeline. Or is it a timing issue? Ronald fixed a DVD issue in the mpegparse.c (http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/mpegstream/gstmpegparse.c?r1=1.64&r2=1.65). Revert that patch and see if it works better. I haven't had the time to think of a decent fix that would hold for DVD and DVB :(. #19: When I wrote this, I wasn't aware of gst-ffmpeg handling ts streams. So you have the choice now. I like the ts-tools because it is a good place to add dvb si (system information) parsing. Don't know how to do that in ffmpeg (never really tried to understand Ronald's gst-ffmpeg magic). #21: ts2ps in its current state does not attempt to figure out the right apid/vpid. I'd prefer video/x-mpeg-ts. However, I don't see that we should stick to RRFC 3555 as it applies only for RTP payloads. See gstreamer/docs/random/mimetypes for mimetypes gstreamer knows about.
Regarding gstdvbtv: It fails to parse "channels.conf.terr". As the program also doesn't make any attempts to set DVB-T parameters when tuning, I decided to quickly write my own test program, instead of trying to fix gstdvbtv. Regarding performance: Reverted gstmpegparse.c to version 1.64. It didn't solve the performance problem. As you consider dvbsrc to be fast on your machine: Did your compare CPU load of dvbsrc and mplayer or xine? Regarding gst-ffmpeg: Saw your preparations for extracting program information out of the transport stream, so I admit now, that ts-tools makes sense: Much easier to catch them via tsparse, than to get them out of ffmpeg. Wondering if you know dvbsnoop (http://dvbsnoop.sf.net/). It's something like tcpdump. Might be useful for finishing dvbsi, even if I was not able to fetch usefull program information with it yet. Regarding mime-type: Yup "video/x-mpeg-ts" looks better, but "video/mp2t" feels more official...
We call them media-types. They're not mime-types and not intended to be perfectly compatible with official mimetypes. All media-types are lower-case only. Martin, ask me privately (IRC/mail) for questions about gst-ffmpeg, I'll happily explain bits you don't understand. It's a lot of crap, I know, but if I'm the only one understanding it, we have a serious maintainership nightmare.
Created attachment 38786 [details] [review] some changes for gstdvbtv Here is an update for the sample dvb program. It now reads channels.conf.[terr|sat|cable] depending in detected adapter-type.
just compared gstreamers (recent BRANCH-GSTREAMER-0_8 checkout) and mplayers cpu load with top. gst-launch filesrc location=test1-v101a102.ts ! ts2ps apid=102 vpid=101 ! mpegdemux name=demux { demux.video_04 ! queue ! mpeg2dec ! xvimagesink } demux.audio_00 ! { queue ! mad ! alsasink } -> ~8.5 cpu usage mplayer test1-v101a102.ts -> ~6.9 cpu usage So gstreamer is not as slick as mplayer but no big difference here.
ping, any news here? it would be cool to have dvb support :)
Yes it would be nice to have a port to 0.10 :-)
There's a dvb input plugin written for the kaffeine player. Are we able to hackin this input plugin and create a gstreamer element ? http://websvn.kde.org/trunk/extragear/multimedia/kaffeine/src/input/dvb/ http://websvn.kde.org/trunk/extragear/multimedia/kaffeine/README.dvb?rev=522104
Kaffeine is be a front-end only, there's even a gstreamer element written for kaffeine, but it's outdated and does not support the dvb input plugin. http://websvn.kde.org/trunk/extragear/multimedia/kaffeine/src/player-parts/gstreamer-part/ I am looking for a dvb support for gLiveSupport. http://code.campware.org/projects/livesupport/ticket/1376
Bug 344987 has more recent stuff about this. I guess this bug could be closed as duplicated.
Closing this as fixed, with Zaheer's DVB plugin in CVS I guess this is taken care of.