Re: [vdr] [ANNOUNCE] New VDR plugin: epgfixer
2012/3/17 Matti Lehtimäki : > Hi > > I made a new plugin to remove parental rating from the end of title in EPG > when separated by parentheses, for example "Program title (12)". The > obtained parental rating is then placed into correct EPG field. The feature > can be activated/disabled from plugin setup. > > Requirements: > VDR-1.7.26 or later > > If there are other features related to handling of EPG data you would like > to add please let me know. I'll be happy to integrate them to this plugin. > > -- > Matti > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > Nice idea for a plugin. How about adding the capability to define regular expressions to alter the epg data? I think it would allow a great deal of flexibility as practically anything can be done with regexes :) You'd need to work hard on the UI to make it user friendly though. Best regards, -- Antti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [solved] [iptv] [input_vdr] No data in 8 seconds, queuing no signal image
2009/5/7 Paul Menzel : > I just wanted to confirm that you were right all the way. I get video > with VDR 1.7.7 (although I will have to tweak my system to get it > fluent). > Thanks. Great news! Once you are all set up would you be so kind to post iptv -channels from your channels.conf to the German wiki page (http://www.vdr-wiki.de/wiki/index.php/Iptv-plugin) along with few notes about what was required to get it working? I think such information would be very helpful to other users from Germany who are thinking about trying the plugin. -- Antti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [iptv] [input_vdr] No data in 8 seconds, queuing no signal image
Paul Menzel wrote: > Am Samstag, den 02.05.2009, 21:24 +0300 schrieb Antti Seppälä: >> Do you know what encoding format your provider uses for the streams? >> Play it with mplayer -v rtp://233.51.128.19:1234 to see the information. > > TRIED UP TO POSITION 321104, FOUND 47, packet_size= 188, SEEMS A TS? 1 Mplayer detects that your stream is transport stream, which is what vdr requires. > PARSE_PMT(28106 INDEX 0), STREAM: 0, FOUND pid=0x30 (48), type=0x1005, > ES_DESCR_LENGTH: 0, bytes left: 28 > ...descr id: 0xa, len=4 > Language Descriptor: deu > PARSE_PMT(28106 INDEX 1), STREAM: 1, FOUND pid=0x31 (49), type=0x50, > ES_DESCR_LENGTH: 6, bytes left: 17 > ...descr id: 0x56, len=10 > PARSE_PMT(28106 INDEX 2), STREAM: 2, FOUND pid=0x34 (52), type=0x, > ES_DESCR_LENGTH: 12, bytes left: 0 This is the pid information vdr also requires in the channels.conf entry. > Searching for picture parameter set... H264: 0x128 > OK! This means that the stream is using h264 encoding. > > > I tried it with S0P0 and there was only a black screen shown and I could > see the VDR menu on top of it. I also noticed the the following line was > added to channels.conf. I do not know how it got there. > > Das > Erste;ARD:10:IPTV|S0P0|UDP|233.51.128.19|1234:P:0:0:49=deu:52:0:28106:1:1019:0 > The line was added by vdr when it detected that the stream is in the format it supports. (Though I wonder if it shouldn't happen when disabling sid scanning with S0.) It also means that iptv plugin is working and the stream in rtp format is really supported. The entry contains 0 as the video pid which means that the channel is treated like a radio channel. > Changing to this channel with the up key, I could hear the audio, but > instead of the video some kind of animation was shown. Those you can set > up in your media players and which move to the audio. > This is what xineliboutput does when viewing a radio channel. It's called the goom plugin. I think you are only missing h264 support from vdr core which could be the reason why the video pid of the channel is set to zero. A patch for adding h264 support to vdr 1.6 -series is included in this mailing list post: http://www.linuxtv.org/pipermail/vdr/2008-March/016227.html It's the vdr-1.5.18-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2 and it works for 1.6 even though the name suggests 1.5 version. Vdr 1.7.x includes h264 support by default. -- Antti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [iptv] [input_vdr] No data in 8 seconds, queuing no signal image
Paul Menzel wrote: > Dear list, > > > I am trying to set up IPTV for German public stations. They provide > the multicast addresses [1]. I have to use the Hansenet ones. They > also provide playlists for VLC and MPlayer [2]. I used VLC to watch > some channels and that worked quite OK, if the modem has synced > correctly(?), i. e. has a good connection. With VLC it stuttered > every 5 seconds with some channels. > The plugin *should* actually have native support for rtp wrapped udp multicast data such as your streams seem to be. It is not well tested but I'd love to hear rtp being successfully used somewhere :) Do you know what encoding format your provider uses for the streams? Play it with mplayer -v rtp://233.51.128.19:1234 to see the information. If it is in one of the formats supported by vdr (MPEG2/TS or h264 with vdr patches) you could try the plugin native methods for inputting the data to vdr. So instead of doing complicated and error prone EXT|vlc2iptv -stream conversion your channels.conf entry could look something like this (for Hansenet): Das Erste;IPTV:10:IPTV|S1P0|UDP|233.51.128.19|1234:P:0:2:3:0:0:1:0:0:0 In the best case you'd get working epg, automatic pid updates and all the other goodies from the stream when using native udp input methods. -- Antti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
2008/12/2 Alex Betis <[EMAIL PROTECTED]>: > Hmmm... 2 minutes after I wrote my previous message my HTPC stuck without > any way to control it beside the hardware reset. > Don't know what killed it, but I have a feeling its the HUD display since > when its used, VDR can't stop, it always segfaults. > Without HUD its able to stop normally. > Will try to find out later where it crashes. > > Anyone else seen that problem as well? Do you run vdr-sxfe as your display frontend or have you configured xineliboutput to use the local frontend? I've never noticed hud to cause such problems with vdr-sxfe... If you can reproduce this by running vdr with only xineliboutput plugin then more information about the crash (some logs or gdb backtrace) would help in debugging. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
2008/12/2 Gerald Dachs <[EMAIL PROTECTED]>: > It sounds as if xcompmgr is no drop in replacement for compiz, I need > a windows manager too? Yes, xcompmgr is not a window manager, you'll need one as well (I believe :). I run evilwm + xcompmgr, very light weight and suitable for HTPCs. > And this together will need less resources than > compiz without anything else? I think there's not much of a difference in your case but I suppose you can go and give it a try. Regards, -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
2008/12/2 Gerald Dachs <[EMAIL PROTECTED]>: > > After reading your mail I have tried yesterday again to use xcompmgr instead > of compiz for the hud osd without success. The osd doesn't show up. I think > my configuration can't be that wrong, as the hud osd is shown with compiz. Any > hints what I have to look for? > Do you start the xcompmgr with the -n switch? Does it start correctly? If I start xcompmgr without client side compositing then I'm unable to get hud to work properly. Which window manager you are using together with xcompmgr? Try to make sure that you have the Ubuntu desktop effects disabled as they will probably interfere with the operation of xcompmgr. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
2008/12/1 Alex Betis <[EMAIL PROTECTED]>: > Hi, > > Please advice how to configure xineliboutput in the best way... > I have 1.7.1 + ext64 patches, xineliboutput 1.0.3, nVidia card with latest > drivers. > > After many tests I have the following: > Using --hud gives best OSD I ever seen, but it shows only the OSD when the > output window is in focus and no playback. When I select another window > (loose focus), I see the playback, but this way I can't control it... > Reports about this pop-up occasionally so I'll try to clarify: You need a compositing window manager to see both the hud osd and video at the same time. I recommend xcompmgr because it can run in parallel to your normal window manager and serve the necessary compositing extensions as an addition. Of the compositing managers I've tried it also seems to be the fastest / least cpu intensive. So install xcompmgr and run: xcompmgr -n& prior to starting vdr-sxfe --hud You'll need to setup xorg.conf so that compositing is enabled. IOW you should have lines similar to following in you xorg.conf: Section "Extensions" Option "Composite" "Enable" EndSection Concerning your other display issues (opengl osd etc.) I'd recommend trying without patched vdr and maybe latest version of xine-lib. Regards, -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] iptv plugin+CAM support
2008/8/25 Придворов Андрей <[EMAIL PROTECTED]>: > Hi > I use iptv, but my iptv provider is planning to encode the signal, > and distribute the access card. > This plugin does not see the availability of encryption, and can not work > with CAM. > Any plan about integrate CAM support in iptv? > Any suggestions? > Hi. Support for CAM seems to be nowadays one of the top requested features for the iptv plugin. I guess that encrypted streams are becoming more popular in the iptv world altogether. It turns out that implementing CAM support to iptv is quite tricky. One option would be to implement support for external CAM module such as the Hauppauge WinTV-CI USB. These devices seem to be unsupported in linux so a driver would have to be written first. I've also thought about using the CAM of an existing DVB card to do the decryption of iptv streams, but to the best of my current knowledge it is impossible to use a CAM of a certain device to decrypt streams that are not received by the same device. (Someone correct me if I'm mistaken). Can anyone think of any other alternatives? -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr-xine OSD question
2008/7/12 Lucian Muresan <[EMAIL PROTECTED]>: > Antti Seppälä wrote: >> 2008/7/11 Todd Luliak <[EMAIL PROTECTED]>: >>> I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to >>> an HDTV as the only display. Is there a simple way to lock the OSD to the >>> resolution of the output device such that the OSD is not rescaled when >>> switching between SD and HD sources? I played with X-overlay, but that was >>> not what I was after. If not, could it be done in the source somewhere or is >>> the OSD anti-aliased and overlayed on the video before being sent to the >>> output device (xine, in my case)? I've looked around quite a bit on the net >>> but I guess my google-foo is failing me on this one. I just miss the >>> rock-solid OSD of the FF card setup... >>> Thanks! >>> >> >> In an effort to create something to solve such issues with >> xineliboutput plugin I came up with an idea of this HUD type OSD. >> Basically it means that OSD is rendered to a separate transparent >> surface on top of video and then these are blended together by the >> display hardware. This way the size of the OSD is bound to the size of >> the used window rather than the size of the video stream. In other >> words no OSD scaling will be necessary even though the video size >> changes. >> >> The HUD implementation has been integrated into the CVS of >> xineliboutput plugin. To operate it requires support for xorg render >> extension and presence of composite display manager such as xcompmgr. >> It also requires powerful display adapter and drivers with support for >> these modern extensions. Maybe you can try it to see if it produces >> results that you are hoping for? > > This sounds very good for HDTV setups which apparently all imply xorg, > but what about DirectFB, does this HUD implementation also work there? > Even if I still have a plain old PAL TV at the moment, when I switch to > some "SD" channels having only 544x576 (which are then stretched to > 720x576), the OSD suffers from the same problem, it's ugly stretched > horizontally, and when the channel is 16:9, even worse, compressed > vertically. > Unfortunately HUD is very dependent on xorg and will not work with DirectFB. I'm not even sure whether DirectFB contains support for similar operations without resorting to CPU intensive software blending of the OSD. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr-xine OSD question
2008/7/11 Todd Luliak <[EMAIL PROTECTED]>: > I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to > an HDTV as the only display. Is there a simple way to lock the OSD to the > resolution of the output device such that the OSD is not rescaled when > switching between SD and HD sources? I played with X-overlay, but that was > not what I was after. If not, could it be done in the source somewhere or is > the OSD anti-aliased and overlayed on the video before being sent to the > output device (xine, in my case)? I've looked around quite a bit on the net > but I guess my google-foo is failing me on this one. I just miss the > rock-solid OSD of the FF card setup... > Thanks! > In an effort to create something to solve such issues with xineliboutput plugin I came up with an idea of this HUD type OSD. Basically it means that OSD is rendered to a separate transparent surface on top of video and then these are blended together by the display hardware. This way the size of the OSD is bound to the size of the used window rather than the size of the video stream. In other words no OSD scaling will be necessary even though the video size changes. The HUD implementation has been integrated into the CVS of xineliboutput plugin. To operate it requires support for xorg render extension and presence of composite display manager such as xcompmgr. It also requires powerful display adapter and drivers with support for these modern extensions. Maybe you can try it to see if it produces results that you are hoping for? Regards, -- Antti Seppälä <[EMAIL PROTECTED]> ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] iptv FILE .ts stalling & not switching streams
Simon Baxter wrote: > Is this a more generic channels.conf problem?? > Hi Simon. We'll look into this once we get a chance. It may very well be that file input of iptv plugin is currently broken. File input was implemented only as a testing/debugging feature of iptv plugin and thus it is not as thoroughly tested. Could you possibly send us (privately) a sample of the file that is causing you problems? That way we could better investigate the issues you are experiencing. I'd also like to know what is the use case that requires you to input a static .ts file into vdr via iptv plugin? -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] iptv EXT channels.conf format
Rene Hertell wrote: > Simon Baxter wrote: >> Thanks - sound is working since I changed the audio bitrate from >> 320 to 190. >> >> Thanks too for the mms stream - works, kind of. I think the >> bandwidth to NZ is affecting it though :) > > Thanks Simon for that tip :-) Now I managed to get some sound too, > but i had to reduce it to 96 for getting a reasonablesound @ nasatv > (i just got clipping and crap sound). > > Are you using the iptvstream.sh script, or are you using the > debian-way with the config-files for each channel in > /etc/vdr/plugins/iptv/vlcinput/ ? > > I don't know where the problem is, but jumping to an other channel > leaves the vlc-process running, and on each iptv-channel-swap I get > two new vlc-processes (pgrep vlc). So before changing to an other > stream, i have to do a "killall vlc". > Are you using iptvstream.sh or some other way of controlling vlc? Handling of vlc shutdown was changed in iptvstream.sh in plugin version 0.0.6. I wonder if your iptvstream.sh uses the new approach which was supposed to be more reliable. > This fiddling with this plugin starts to drive me nuts ;-) It looks > that it's time for me to look for a wig > Heh. Sorry for all the premature hair loss. :) The configuration of the plugin is indeed not as simple as I'd like. However we are already pushing the capability boundaries of channels.conf to the limit which means that channel configuration is not straightforward. Also interaction with vlc brings its own level of complexity to the process. -- Antti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.0.7
Hi all. We are pleased to announce a new release of vdr-iptv plugin. Iptv plugin is an attempt to add various IPTV reception capabilities to VDR. This version incorporates support for VDR version 1.5.15. Another new feature is configurable scanning of PIDs for streams where the full section information is not available. This version eliminates global sid scanning configuration option and instead provides per-channel settings for toggling sid and pid scanning. These settings are accessible from iptv plugin channel editor and are stored to channels.conf accordingly. For a sample of the new channels.conf format as well as full changelog and plugin download please see plugin homepage: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ Note: After new stable VDR version (1.6.0) is available support for VDR versions below 1.5.xx is likely to be dropped from future iptv plugin releases. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Jouni Karvo wrote: > I really have no idea of which settings to try next. Configuring > xine-ui is not really an easy thing. > Few people have reported audio problems in xine-lib version 1.1.9. The setting audio.synchronization.slow_fast_audio (discussed here http://www.linuxtv.org/pipermail/vdr/2008-January/015210.html) might help. Also changing audio.synchronization.av_sync_method and/or audio.synchronization.resample_mode may have an effect on your audio problems. Other than that I have no idea. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Jouni Karvo wrote: > Antti Seppälä kirjoitti: > >> Try lowering the value of ABITRATE found in iptvstream.sh from 320 to >> e.g. 192. After such a modification the stream worked fine for me. >> >> > > Hi, > > this does not seem to help. > > I have three test channels now, all of which give the video: > > - The Albanian Rrokum TV - which gives also audio. > - Bahn TV - only video. Even with ab=192 > - BBC One premier (via http://www.global-itv.com/). Only video > > My xine has w32 (from xine's output: > load_plugins: plugin > /usr/local/lib/xine/plugins/1.1.9/xineplug_decode_w32dll.so found > ) > Since you have at least one channel which works it leads me to believe that iptv plugin is working and the problem could still be in the transcoding or playback process. Here's how you can try to investigate a bit more: Set up a vlc for transcoding in a similar fashion as to how iptv plugin uses it. For example the following command will do just that for Bahn TV: vlc mms://atkon-atkbtvolive-wmv-high.wm.llnwd.net/atkon_atkbtvolive_wmv_high --sout "#transcode{vcodec=mp2v,acodec=mpga,vb=2400,ab=192}:standard{access=udp,mux=ts{pid-video=1,pid-audio=2,tsid=3},dst=127.0.0.1:4321}" --intf dummy Now open another instance of vlc to play back the transcoded stream: vlc udp://@:4321 If the stream works perfectly, you can close the playback vlc and try to play with xine: xine udp://127.0.0.1:4321 Notice how my examples hardcode the udp port to 4321. If you want to change it, remember to do so to every command. If there's no audio on either of the players you are likely to have something wrong with your vlc installation. If vlc works but xine doesn't then xine cannot for some reason decode the audio stream. > The script sets VPID=parameter+1, APID=parameter+2, SPID=parameter+3 > (I wonder why, since if you want to receive simultaneously two > consecutive parameter things, they overlap anyway). > We try to use pids to make the channels separable from each other. Overlapping should not be a problem because multiple streams are sent to different udp ports (and different iptv devices as well). You can of course modify the script and use different pids if you like. > When looking at the stream info, they show PIDs like 3,4,66. 4,5,66. > I wonder what this 66 is and why... > I think it is the default PMT pid of vlc. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Jouni Karvo wrote: > Segers,Jan J.K.T. kirjoitti: >> have a look here: >> http://www.global-itv.com/ > > thanks. I found a couple of channels. > > It seems that vlc is able to play the stream correctly, with both audio > and video by itself. But when I try to use it together with iptv > plugin, it seems that for some reason audio is lost. > > I use vdr-xine for output. > > Xine output seems like it gets the audio, but it does not get any > synchronization info correctly, as it just reports skipping audio: > > excerpt from the xine logging: > > plugin mad will be used for audio streamtype 01. > audio_alsa_out:open pause_resume=1 > output sample rate 48000 > audio jump, diff=-2160 > set_speed 100 > ao_flush (loop running: 1) > video discontinuity #25, type is 0, disc_off 0 > waiting for audio discontinuity #25 > ao_close > audio_out: no streams left, closing driver > audio discontinuity #25, type is 0, disc_off 0 > waiting for in_discontinuity update #25 > vpts adjusted with prebuffer to 3418578 > ao_flush (loop running: 1) > video discontinuity #26, type is 0, disc_off 0 > waiting for audio discontinuity #26 > audio discontinuity #26, type is 0, disc_off 0 > waiting for in_discontinuity update #26 > vpts adjusted with prebuffer to 3418610 > > > This is the corresponding stream entry for channels.conf: > > Bahn TV;IPTV:3:IPTV|EXT|iptvstream.sh|3:P:0:4+3:5:0:0:1:0:0:0 > > What should I try? > Hi Jouni I decided to give Bahn TV a try and could also reproduce symptoms of missing audio. It seems that the transcoding engine of vlc gets confused by the audio bitrate setting iptv plugin uses by default. So far I haven't found other channels than Bahn TV that are affected by this. Try lowering the value of ABITRATE found in iptvstream.sh from 320 to e.g. 192. After such a modification the stream worked fine for me. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.0.3
Segers,Jan J.K.T. wrote: > thanks! i just re-read the instructions on your website but i still > dont get how to use the EXT format... whats the content of the > iptvstream.sh? something like "vlc -vvv > mms://livemedia.omroep.nl/vprohollanddoc-bb" ? > Our README says that "The external script is responsible for supplying IPTV plugin with MPEG2 TS data in UDP/RTP format to the listening port." So the external script must use VLC to: 1) Receive the stream 2) Transcode it to format understood by vdr (for example mpeg2 ts) 3) Feed the data to the port which iptv plugin is listening To achieve these tasks you could use for example this script: #!/bin/sh exec vlc "mms://livemedia.omroep.nl/vprohollanddoc-bb" --sout "#transcode{vcodec=mp2v,acodec=mpga,vb=2400,ab=320}:standard{access=udp,mux=ts{pid-video=1,pid-audio=2,pid-spu=3},dst=127.0.0.1:4321}" --intf dummy Store it to iptv plugin configuration directory with name vlcstream.sh and give it execute permissions. Here's the corresponding channels.conf entry: VLC-channel;IPTV:1:IPTV|EXT|vlcstream.sh|1:P:0:1:2:0:0:1:0:0:0 Hope this helps. =) If you need further assistance, please contact me privately. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.0.2
Segers,Jan J.K.T. wrote: > so iptv opens vlc to transcode the stream as soon as i tune to the > stream channel and stops with transcoding as soon as i leave the > stream channel? > Yes that's the intended behavior. > to be honest, i did not make that many tests. i just tryed to prepare > my vdr for this new streaming possibility. maybe i should focus on > reading your new README ;) > > anyway, i dont need rtsp support if multiple windows media streams > will work on demand. i hope i got it right. > Please have a look at the example iptvstream.sh script provided with iptv plugin. This script can be used as a good starting point when adding vlc transcoded channels. We'll also try to clarify the README to avoid further misunderstandings. =) -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.0.3
Hello VDR community Iptv plugin developers are pleased to announce a release of vdr-iptv plugin version 0.0.3. This time the plugin includes a couple of bug fixes and tweaks (for example no more crashes at shutdown). This version also features back-ports of necessary iptv integration patches for vdr version 1.4.7. In other words using iptv plugin with stable vdr version should now be possible. Head to the plugin homepage for instructions and downloads: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.0.2
Udo Richter wrote: > I think that the decision to use liblivemedia as protocol layer is a > good way to go. Basically, you provide the URL, pick the wanted > sub-streams, and liblivemedia delivers video and audio as separate > data streams. If you're interested, I can share my work-in-progress > source code. (well, not much progress lately...) > Yes, we are interested in looking at how streamplayer would handle rtsp. Using external libraries could be a very clean way to go for iptv plugin as well. >> Testing is a bit hard since >> I'm not aware of suitable mpeg2 rtsp -stream providers. Are there any >> publicly available? > > The vlc player with its integrated vlm server (aka. telnet interface) is > a good starting point, as it provides RTSP VoD sources with the ability > of play/pause and seek. I'm not sure, but I think vlm can also stream > live streams. And even on-the-fly transcoding works. > Thanks for the advice. I'll see if I can get vlc to provide rtsp streams to help in plugin development and testing. -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.0.2
Segers,Jan J.K.T. wrote: > Hi, > > thanks for this great new plugin! i tryed VLC to transcode on the fly > some windows media streams which i want to use with your iptv plugin. > it seems to work with some issues: transcoding takes about 15% of my > cpu power per stream. i would like to watch 5 different streams, this > would take all my cpu power which is not very handy. i tryed using > the VoD feature of vlc, but there are two problems: > 1. vlc uses for VoD the rtsp protocol, where iptv has currently no support for. > 2. vlc does not allow transcoding a windows media stream with VoD (only with mpeg2 streams, but thats not very interesting). > Do you have any idea how to watch several streams with your plugin > without transcoding all the time? i only need the transcode when i > watch one of the stream channels, so VoD would be very usefull.. > Hi. Iptv plugin uses VLC to transcode only the stream being currently received so there really should not be any CPU power wasted on transcoding inactive streams. In other words a simple "video on demand" system should already be in place. At least I can add multiple streams to the channel list and only the active one is being transcoded. Have you experienced different behavior? Of course if recording then VDR will keep the stream opened and iptv plugin has to launch another instance of VLC to keep receiving two streams at the same time. BTW. we've actually been looking into adding support for receiving rtsp streams and while it is more laborous than other protocols I think implementing it would be entirely possible. Testing is a bit hard since I'm not aware of suitable mpeg2 rtsp -stream providers. Are there any publicly available? -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.0.2
Hello VDR community IPTV plugin developers are proud to present a new release of the plugin. This plugin is our attempt to transform VDR into a full-blown IPTV receiver. This version features numerous small bug fixes and enhancements and one major new feature: Support for external streaming applications. In short this means that reception capabilities are not limited only to MPEG1/2 TS. Instead you can do all sorts of wild and crazy things with IPTV limited only by external application support and transcoding performance. For example we have successfully used VLC media player to receive and feed mp3 internet radio stream to the IPTV plugin. VDR will then receive this data and handle it as any other radio channel. Also reception of various video formats such as Windows media mms streams is working with VLC and IPTV plugin. Head to the plugin homepage for instructions and downloads: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.0.1
Hello Rolf Ahrenberg and myself are pleased to announce the first release of joint effort plugin which turns VDR into a full-blown IPTV receiver. IPTV plugin implements an additional VDR device which provides all the functionalities of DVB cards such as live viewing, recording, epg etc. The plugin is capable of receiving MPEG transport streams via various network protocols, such as UDP/RTP multicast and HTTP. Also file input is supported. The plugin is tested with streamdev-server, VLC and IPTV stream provided by a local internet service provider. Minimum required VDR version is 1.5.10. The plugin also includes a patch to VDR core to allow plugin specific channels to be added to channels.conf. The patch is designed to be as generic as possible to be beneficial for other projects as well, for example analog and pvrinput plugins. We are also hoping to see the patch integrated into the core VDR later on. More details and the plugin package can be found from the plugin homepage: http://www.saunalahti.fi/~rahrenbe/vdr/iptv -- Antti Seppälä ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr