Re: [vdr] A/V out of sync for a lot of channels
Am 10.03.2010 17:22, Niels Wagenaar wrote: 2010/3/10 Jörg Knitterjoerg.knit...@gmx.de: I watch Channel4 a lot and I don't have any issues with it using xineliboutput or my Reel HDe (read: it's not noticable). But if you could tell mee the German channels, I could check with those as well. Don´t know if it also happens with xineliboutput. In the tests before, I had major problems with xineliboutput, even with sound output, that´s why I am glad that the yavdr team choose xine over xineliboutput which worked better so far with my configuration. I have had major problems with ProSieben, but I also could reproduce it with ZDF, ARD and RTL, simply every channel that has a DD 2.0 audio track. Switch the audio to MP2, and the sound will be instantly in sync in all of the mentioned channels. With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A/V out of sync for a lot of channels
Am 10.03.2010 11:53, Günter Merz wrote: Meanwhile, I've played back a vdr recording in xine (xine-ui) (the file itself, not through vdr) and can confirm the a/v sync problem is still there. I played back the same recording with mplayer and the a/v sync problem seems to be gone---maybe with the small note that mplayer takes a few moments to adjust. This pretty much rules out vdr and vdr-xine as the source of the problem as well. As far as I know, mplayer and ffmpeg use the same codebase (mostly). From the above, I deduce that xine-lib or my configuration thereof produces the a/v sync problem. Can anyone confirm or contradict my thesis? I have seen the same problem on german channels - but not on all, and I found a common sense: - channels with MP2 audio: sync ok - channels with AC3-5.1: sync ok - channels with AC3-2.0: not always in sync, playing back and forth helps, there also seems to be a drift over time I am using yavdr 0.1.1 (http://www.yavdr.de) which also includes XBMC which is not based on xine. I haven´t seen any sync problems here so far. With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] More features for Livebuffer
VDR User wrote: On Mon, Mar 2, 2009 at 2:28 AM, Rene linu...@hertell.com wrote: Also a nice thing to have is a way of watching the saved livebuffer-files. Now it get´s saved into /video/LiveBuffer, and vdr does not see this. Maybe it could be saved into a subdirectory like /video/LiveBuffer/2100-01-01.00.01.50.99.rec, then vdr would always have it as the last recording available in the recordings-list... You really want to record non-stop 24/7 to your harddrive like MythTV does? What about using RAM oder some kind of flash media? I would really appreciate such a function - as long I can choose where I want the buffer to be written... I also would prefer not to have a HD recording 24/7... With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Goga777 schrieb: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? AFAIK there is no XBMC mailing list, and I did not find the time to take a closer look in the forums... I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. And why does the VDR state press any key to cancel shutdown? I thought that VDR should be running all the time in the background... Currently, I use the tv-out of the gfx card for XBMC and the tv-out of my FF for VDR, switching simply by selecting a different video input on my amplifier, but with HD, the FF might replaced within the next 12 months. With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Niko Ringelstein wrote: Jörg Knitter wrote: Goga777 wrote: http://www.youtube.com/watch?v=_Cl70fq7sn8 here's you can have a look on xbmc and integrated in it vdr Maybe this is a trivial question, but how does he switch between XBMC and VDR? I have read (and thought) about some little script that switches between XBMC and VDR, and there was one solution mentioned here using LIRC. But the way it is shown on the video it look like a real integration. That's what I have done. I've written a little script which is called from the XBMC scripts section. It basicly starts vdr-sxfe and kills xbmc. After exiting vdr-sxfe xbmc is started again. VDR is running in the background connected with my server in the basement through streamdev. This solution works very good for me. In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC + VDR 1.7.0
Niko Ringelstein wrote: Jörg Knitter wrote: In the video, it looks like the the user is using a main menu entry, that why I wondered, because the XBMC VDR plugin does not seem to support OSD transmission. Joerg As far as I know it connects via streamdev-client. Then, IMHO the OSD would be missing and the switch time would be longer - that´s why I ask. So I assume that he is using sxfe-vdr... Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
Klaus Schmidinger wrote: Well, tell that to people writing plugins for such output devices. I don't see where *I* would be involved there?! Are there enough interfaces to be able to read the and control the OSD for including them seamlessly it into a different front-end? I don´t think that SVDRP and interpreting the returned data is the best way to go. And what about the limitation on one OSD per VDR? I think, these are the real limitations - currently users of media center UIs are exiting them and start xinelib for using VDR and visa verse. A better separation of back-end and front-end could IMHO solve the problem and end the discussion about hardware related support. Because with a clean and some kind of more standardized interface (which also transmits OSD related information), you could write every output device connector/plug-in that you can think and be compatible to more front-ends or devices then before. Even an evil Windows front-end with VDR running on Windows (with the help of something like colinux or a VM) would be possible. Currently, xinelib (with original OSD) uses a different protocol than the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in (with OSD tranfered with some kind of VNC IIRC) which also works different from the streamdev approach (without OSD) that is used for hardware streaming clients that use oxyl etc. Unfortunately, I am just a user, not a developer though I am at least able to read and modify simple C and script code ;) - it has been a long time since I was student and was able/had the time to code little projects... With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
Petri Helin wrote: [...] start up a fluxbox session. The fluxbox session runs a start up script which starts vdr-sxfe, which connect to the xineliboutput plugin. [...] One general question: Is vdr-sxfe reliable enough on bad-weather-conditions? I have played around last week with VDR-1.5.18 and xineliboutputs internal display window, and it was rock-solid while in the past other solutions like xine or vdr-sxfe crashed if there was a bigger problem with the signal strength. Or do you have implemented some kind of keep vdr-sxfe alive-functionality? Because having to start vdr-sxfe manually again is IMHO not really set-top-box-like... :) On the other hand, I would prefer using vdr-sxfe instead of the internal x11 display because then I can release LIRC by shutting down vdr-sxfe e.g. if I want to use Elisa as second Media Center for playing back MP3s and videos in a more comfortable way than VDR can offer... With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger wrote: Yes or No? Yes. Although there have not been too many improvements, a lot of plugins had to be updated due to UTF-8 support etc. If you continue with huge things like H.264 and TS recording (yes, yes, yes :)), it might even take longer getting a new stable base for distributions etc. (although I am using 1.4.7 and still satisfied with it). I fear that waiting for multiproto to get into the kernel might become a neverendings story like the unbearable discussion before (including all those indignities) about future DVB driver development. Maybe we can start a bet when this finally going to happen... ;) Furthermore, I think, making it stable will just delay the H.264 development for several weeks (the last steps to the last stable releases might have taken a maximum of 6 weeks) while waiting for H.264 and TS recording will take a lot of months including waiting and evaluating supporting hardware (decoder cards, graphic card drivers) and software (xine/ffmpeg etc.). With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Reinhard Nissl wrote: The attached patch allows now to define timeouts and frequencies for example in Make.config, so there is no need to patch every VDR version. Furthermore, frequencies are now defined in unit 1/s instead of the unit ms (which defined the period), making values more intuitive. I would prefer some OSD settings for LIRC (if possible) because on every VDR setup you are able to do first controls with the keyboard. So you could access the settings menu and tune the LIRC settings the way you want. A makefile settings also will not work if you use some prebuild packages. I also remember the time using LIRC when I always had to patch the lirc code - currently, I am glad being able to use DVB-IR. :) With kind regards Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to demux H.264 recording ?
Gregoire Favre schrieb: Hello, i have just recorded one of the best movie from the Switzerland in H.264 on Swiss HD channel :-) The quality is really good and I would like to keep de and fr AC3 (I don't care about the en/it audio). Anyone know which tools are available to do it ? Thank, Hi, I think there is no tool available for the PES recordings. ProjectX does not support H.264 at all, and the windows Tools xport and tsremuxer also don´t work. That´s why I also vote for TS as recording format :) Maybe there is any MPlayer option, but the question remains if Audio Video are being synced - with xport (and DVBViewer TS recordings) it works. With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
Klaus Schmidinger schrieb: I don't want to lose the ability to record 3 DVB-S transponders in parallel, and I also need the DVB-T card. Have you ever thought about a USB solution? I also would prefer PCI, but I also could not believe that a lot of boards have just 3 PCI slots - no way using a separate sound card instead of on-board-sound or a PCI-WLAN device (which is also supported better than the USB ones) if you want 3 tuners without using a dual-tuner card. And speaking of those HIFI-like cases: Most solutions I have seen just support one PCI card using a riser card, so here USB is also the only way to get more than two tuners into such a PC. I know that USB devices use a little bit more CPU power, but in my tests one or two years ago, it has not been too much (on Windows e.g. just around 5-10% more CPU usage with a DVB-T-Stick compared to a DVB-T-PCI card; on todays systems, it might be even less). I cant say if there are more disadvantages using a USB solution instead of a PCI card (apart from missing drivers etc.). There is e.g. a USB-DVB-S-Box by Terratec, and if I remember right, the Pinnacle USB-DVB-S2 box (which is a Technotrend production) is already supported on linux. With kind regards Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
VDR User wrote: Also, I talk with many dvb users on pretty much a daily basis and I've never once heard someone say they've left VDR for that other software because of eye-candy/UI. Most people seem to be concerned with capability functionality, not pretty graphics. My personal opinion is that, because I'm biased in favor of VDR, it's disappointing to see so many users abandon it simply because of the lack of support for things that are becoming more common in-demand every day. [...] A lot of these guys aren't coders, aren't used to compiling things, and aren't even used to using a console for that matter. They often use ready packages, and if those packages don´t contain the necessary patches, they will never get it to work. The more the interest shifts, the more people will leave VDR in its current state behind for something more suitable. Klaus very honestly said he's perfectly ok with that and sees no incentive to support this stuff so the story pretty much ends there. I fully agree with you (with [nearly?] all points) . I think you can see the interest in HD in the high number of hits e.g. in the DVB-S2 section at vdrportal.de. The people here and at vdrportal are very technically interested, so I think that there are a lot of early adopters that do not want to wait until 2010. And speaking for other PVR hard- and software solutions too, scrambling is no real problem for people who want to get certain content - and this is no secret as you can see in the vdr-wiki entry. HDCP output is no problem as the Dreambox 8000 is also said not to support this flag. Or do you think that Dream Multimedia will get sued as soon as the Dreambox 8000 is out because of this missing feature? With kind regards Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
Hi, Reinhard Nissl wrote: And I don't think that we will see a FF card which can handle H.264. Gfx cards take over that business and once the VA API is released and supported, those functionality will even be available on Linux. Let´s hope that the VA API will soon be released and get working drivers because the current situation is not satisfying. I am a satisfied FF-SD user for years, but it´s biggest pro, the 1:1 interlace output, becomes unimportant in times of progressive LCD screens. And the gfx cards are already good enough in decoding H.264 (at least on Windows) that I currently don´t see any sense in waiting for a FF-HD card - apart from the mentioned missing H.264 acceleration on linux. In fact, I fear more limitations in the ongoing VDR development if people again have to take care e.g. for OSD sizes of certain hardware boards and have to fight with (closed source) firmware bugs. A hardware independent approach would allow e.g. more flexibility in UI control. You might say: The UI is sufficient, but if I think of using VDR as media center I think of all the complicated things that need to be done e.g. to simply get an image displayed on FF cards (see the discussion on interlaced display of images some days ago). Also features like a web browser plug-in (e.g. for easier access to web-tv) will never be possible as people still have to take care of certain hardware limitations. Another approach would be calling external web browsers, media players etc. from VDR, but then I doubt that I can still use the remote control for also controlling the external applications. Just my thoughts about the future of VDR in a future flat-screen-enhanced living room (still enjoying superb tube tv quality...). With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
Luca Olivetti schrieb: En/na Graziano Pavone ha escrit: I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..) A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine. I experienced the same with xineliboutput. A very interesing feature of xinelibout is the ability to control deinterlacing, color settings etc. from within the VDR OSD in the plug-in´s settings. Furthermore, xineliboutput has a function that cuts and scales letterboxed 16:3 to anamorph 16:9, there is an audio equalizer and much more... With kind regards Jörg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
