Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
Hi, Am 05.01.2014 12:42, schrieb Klaus Schmidinger: The changes since version 2.1.2: - Channels that are no longer contained in the current SDT of a transponder are now marked with the keyword OBSOLETE in their name and provider fields. That way you can identify obsolete channels when you switch to them, and you can get the complete overview of all obsolete channels by sorting the Channels list by provider (by pressing the 0 key twice). Automatic deletion of obsolete channels may follow later. What about channels on transponders which no longer get a lock while tuning, like S13.0E, 10930 H? Shouldn't those channels be declared OBSOLTE too, when a SDT hasn't been received? Maybe this should only be done if the device doesn't have a lock either, to avoid false positives. But this still seems error prone -- looks like a more complex solution is needed which keeps track of how often a transponder has been seen dead over a certain period of time before declaring these channels OBSOLETE (and later delete them automatically). I don't know if it is worth to extend the file format of channels.conf for that tracking, but at least in memory VDR could keep track of that, starting from scratch whenever VDR is restarted. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] porting vdr-plugin-sc from FFdecsa to dvbcsa: undefined symbol
Hi,
Am 27.12.2013 11:30, schrieb cedric.dew...@telfort.nl:
This compiles and installs fine, but I see the following
error in /var/log/syslog when I start VDR
vdr: [8061] ERROR: /usr/lib/vdr/plugins/libvdr-sc.so.1.7.28:
undefined symbol: _Z18dvbcsa_bs_key_freeP15dvbcsa_bs_key_s
vdr: [8118] VDR version 1.7.28 started
I find this odd, because /usr/include/dvbcsa/dvbcsa.h contains
the function prototypes for both dvbcsa_bs_key_free and
dvbcsa_bs_key_s :
void dvbcsa_bs_key_free(struct dvbcsa_bs_key_s *key);
struct dvbcsa_bs_key_s * dvbcsa_bs_key_alloc(void);
But why are they concatenated into one symbol?
Looks like you are using a plain C library with C++. The
undefined symbol is a C++ decorated one:
corei7:~ # c++filt _Z18dvbcsa_bs_key_freeP15dvbcsa_bs_key_s
dvbcsa_bs_key_free(dvbcsa_bs_key_s*)
corei7:~ #
It seems like the header files for libdvbcsa are not prepared for
C++. So the compiler puts a reference for a C++ decorated symbol
into the object file which the linker cannot resolve as the
library seems to contain only plain C symbols.
Try to put the #include statements for those header files into an
extern C block, like this:
extern C {
#include headerfile.h
}
This makes the compiler interpret the header file as plain C and
-- as a result -- generate plain C symbol references.
Hope this helps.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.35
Hi, Am 30.12.2012 12:52, schrieb Klaus Schmidinger: - Using relative paths again when building plugins locally (by request of Udo Richter). In compatibility mode, relative paths seem to be not a good idea. The reason is that for example LIBDIR gets passed as an argument to make (e. g. ../../lib) which cannot be changed anymore within the plugin's Makefile without specifying the override keyword. For example a single plugin used to build sublibraries in subdirectories. The Makefile to build those sublibraries contained LIBDIR=../../../../lib, but in 1.7.35 it used ../../lib and failed until I added override as mentioned above. - Re-enabled building plugins that still use pre-version-1.7.34 Makefiles. The file Make.global is present again to satisfy the include these Makefiles do, but the file itself contains no settings. The VDR Makefile's plugins target determines whether a particular plugin uses an old style Makefile and calls it accordingly. Note that this only works when building plugins from within the VDR source tree, using make plugins in the VDR source directory. In compatibility mode, Make.config gets included by the old plugin Makefiles if it exists. Make.config relies on $(CWD) being defined, but that is only true in VDR's Makefile. Hence, some variable definitions degrade to absolute paths in the root file systems and plugins fail to build. As a workaround I've added CWD=$(VDRDIR) to Make.global as Make.global is usually included by old plugin Makefiles too in front of Make.config. Finally, as a make in VDR's source directory always installs the plugins with new Makefile I wonder if it wouldn't be a good idea to add -p to the install command to preserve the build file times of the plugins. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Hi, Am 26.12.2012 15:54, schrieb Manuel Reimer: I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33. What is your plan? Do you want to build plugins the old way inside the VDR source dir? If so, then just add your options to your Make.config as you did in the past, but prefix them with an export . Something like: export PLUGIN_OPTION = any_value This way the options reach the plugin Makefiles if you do your make plugins as the global VDR Makefile exports the value. Thanks for this hint. This is what I was looking for. If it works as you write, then at least I have no need for plugins.conf at the moment. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Hi, Am 26.12.2012 09:53, schrieb Christopher Reimer: 2012/12/25 Klaus Schmidinger klaus.schmidin...@tvdr.de: 3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration. Agreed. No. Not agreed. Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched. I understand that this seems to be a quite simple solution, because in the end, almost any other configuration option will be converted to either compiler or linker settings. But it's quite lowlevel and one has to dig through the Makefile in depth to extract the necessary compiler or linker options. And as you already mention, plugin Makefiles need to be patched to get it working. For example, there can nolonger be any default values in the Makefile that get always passed to the compiler as a define, as one cannot override it with a different value in Make.config. The default value has to go into the source file in case a certain define (and hence, a specific value) has not been passed to the compiler. I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33. There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config.template) Well, that's not what I was looking for, but kls suggested that already on vdr-portal too. I dislike on that solution that there is not a single central configuration file, but a symbolic link could do the trick to share a common file. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
Hi, Am 24.12.2012 10:39, schrieb Klaus Schmidinger: - Removed some redundancy in the Makefile/Make.global/Make.config mechanism (suggested by Christopher Reimer). The file Make.global is no longer used, and plugin Makefiles don't include the file Make.config any more. Instead they now retrieve all necessary information through calls to pkg-config. I think it is not a good idea to have no longer a central config file which all parties (plugins and VDR itself) include in their Makefiles. I'd like to invite you for a discussion about reintroducing a common make configuration file for VDR-1.7.35 in a separate thread named [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35 Just hold your breath for a few seconds, until that thread appears in the mailing list ;-) Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Hi, as mentioned in the VDR-1.7.34 announcement, Make.config is now gone for plugins. Make.config gave me the opportunity to control features or behavior of plugins and VDR at a central location without having the need to adjust each plugin's Makefile. For example, while developing vdr-xine, I could keep vdr-xine's Makefile in a distributable state and still control to enable some features I'd like to use in my local configuration. And when upgrading some other plugins at bugfix level (i. e. there are usually no new features and hence the config variables can stay the same), there was no need to adjust the Makefile due to the config entries in Make.config. Here is an excerpt of my Make.config for an example of the above mentioned configuration settings: #xine #VDR_XINE_VDR_HAS_TRUECOLOR_OSD = 1 VDR_XINE_SET_VIDEO_WINDOW = 1 VDR_XINE_VERIFY_BITMAP_DIRTY = 0 #burn DVDDEV=/dev/hdd ISODIR=/video #vdr BIDI=1 VFAT=1 REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1 #muggle HAVE_ONLY_SERVER=1 As you can see, there is nothing like changing compiler or linker settings -- for that stuff, I really appreciate the way it is done now. In a private discussion with kls, he asked me to talk to other plugin developers too (so here we are) about that issue, so that any solution in that regard will be of broad agreement by all developers. To conclude: 1.) there is a need for a common make configuration file for both VDR and plugins. 2.) the file should be included in VDR's Makefile after including Make.config (maybe that idea should be dropped in favor of 5.a) as any VDR related option can be put into Make.config anyway). 3.) the file should be included into plugin Makefiles after having set PLUGIN and VERSION to be able to have some plugin-/version-dependent configuration. 4.) the file is optional -- maybe a template file like Make.config.template could indicate that there is something available for tuning. 5.) how do we name the file? 5.a) plugins.conf (doesn't fit perfectly for 2., to be a common file for VDR too) 5.b) Make.common 5.c) local.conf 5.d) Make.config.local 6.) where do we put the file? 6.a) kls suggested /etc/vdr at a random shot 6.b) I would like to put it next to Make.config 6.c) use pkg-config to determine path (defaults to VDRDIR) Please start sharing your ideas now ;-) Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-xine-0.9.4 vdr-1.7.33 video scaling API (YAEPG-Hack now obsolete)
Hi, Am 23.12.2012 23:01, schrieb Lucian Muresan: attached you'll find a patch against vdr-xine-0.9.4 that makes use of the new video scaling API introduced in vdr-1.7.33, yielding correct aspect ratio when scaling. How can it be used? Well, have a look at yaepg-hd patched with [1], but even more exciting when the video output plugin supports true color OSD (unfortunately vdr-xine can do this only in non-X11-overlay mode) is the new true color skin nOpacity [2]. BTW, Reinhard, do you still plan on maintaining vdr-xine? I was wondering because the homepage of the plugin is no longer accessible... I appreciate your patches and will have a look at it during the next days. Regarding vdr-xine's homepage, I was quite busy throughout the year so I haven't managed to look for a new provider in time. I hope the homepage can go online again early next year. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.29 + h264 MBAFF
Hi, Am 13.09.2012 12:25, schrieb Klaus Schmidinger: On 12.09.2012 17:19, Придворов Андрей (Pridvorov Andrey) wrote: Progress display show correct time, but at the end play freeze. Other player (on MS windows) play correct. Try http://rghost.ru/40326577 It looks like the frame type is 0xF0 for *all* frames of this stream. But when I play it on my TT S2-6400 card, even though I can move an editing mark to every single frame, only every 10th or so frame is actually displayed on the tv. So my guess is, the frame types are not set correctly in this stream. 0xF0 seems bogus to me. So far I have seen only 0x10, 0x30 and 0x50 (IIRC). Well, testing for the whole byte is not according to the specs, as only the upper 3 bits denote primary_pic_type. So the typical primary_pic_types are 0, 2 and 4 while 0xF0 yields 7. primary_pic_type tells you, which slice_types (among I, SI, P, SP, B) may be used to describe the picture, so one can derive the MPEG1/2 I, B and P picture type meaning from it for the typical cases. primary_pic_type 7 indicates that all slice types may be used to describe the picture, so the best match for a MPEG1/2 picture type would be a B picture. Hence, the byte value 0xF0 is valid and correct, but doesn't help anyfurther to find independent pictures. Bye. Klaus -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Thursday, September 13, 2012 1:33 AM To: vdr@linuxtv.org Subject: Re: [vdr] vdr-1.7.29 + h264 MBAFF On 12.09.2012 16:06, Придворов Андрей (Pridvorov Andrey) wrote: Hi. I have trouble with some h264 HD channels. It have MBAFF scan type, live tv on vdr works, but no recordings. Recorded file have 0 size. But, if in remux.c, in int cFrameDetector::Analyze(const uchar *Data, int Length) change independentFrame = FrameType == 0x10 to independentFrame = (FrameType == 0x10 || FrameType == 0xf0) Than all recordings fine. Is this correct? I tend to doubt that. What about the progress display when you replay such a recording? Does it show the correct times? Can you make a short recording available for further investigation? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-plugin; 16x9 no-signal image
Hi, Am 26.06.2012 06:02, schrieb Torgeir Veimo: I'm unable to change the no-signal image to always be shown in 16x9. Is there an easy way? All my sources are 16x9, and when using OSD blending, getting a 4x3 image on each channel change looks really bad. From INSTALL: BTW: the ...4x3... or ...16x9... indicate which aspect ratio should be assumed for the files. vdr-xine tries to load both specific files and falls back to the file name noSignal.mpg when a specific file does not exist. vdr-xine will then choose the file to display depending on VDR's DVB setup option video format. So just select 16:9 as video format in VDR's DVB setup. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbdevice.c
Hi,
Am 09.06.2012 08:40, schrieb Wolfgang Rohdewald:
in vdr-1.7.28 without patches
while browsing the log I found
Jun 9 05:28:08 server vdr: [13569] frontend 1/0 timed out while tuning to
channel 1877, tp 212713
Jun 9 05:28:40 server vdr: [13569] frontend 1/0 regained lock on channel 14,
tp 110743
so frontend 1 regained a lock it never had. That seems like a consequence
of the fact that LostLock is only a local variable in cDvbTuner::Action, so it
cannot be reset when the channel changes
Looks like LostLock should also be reset in case tsSet.
also, I wonder about this code sequence in dvbdevice.c:
switch (tunerStatus) {
...
case tsLocked:
if (Status FE_REINIT) {
...
else if (tunerStatus == tsLocked) {
at the else if, how could tunerStatus not be tsLocked?
In the case when the switch falls through from case tsTuned.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] probs with new ZDF HDchannels
Hi, Am 01.05.2012 20:08, schrieb Harald Milz: I just added the new ZDF HD channels (ZDF, KIKA, ZDF neo, kultur and info) and I get strange effects like the ones described in http://www.heise.de/newsticker/meldung/Neue-HDTV-Sender-Ruckler-auf-bestimmten-Receivern-1564225.html. It looks as if the color pallette switched every 0.7 s. This didn't happen with the old ZDF HD channel. My setup is unchanged. Other HD channels are not affected. Did anyone else observe this, and what can we do to fix this? You didn't mention your setup in detail, but I assume you're using a xine-lib VDPAU based solution. In my vdr-xine setup I had to switch from vdpau_h264 to vdpau_h264_alter decoder. The following lines from ~/.xine/config give vdpau_h264_alter a higher priority: # priority for vdpau_h264 decoder # numeric, default: 0 #engine.decoder_priorities.vdpau_h264:0 # priority for vdpau_h264_alter decoder # numeric, default: 0 engine.decoder_priorities.vdpau_h264_alter:1 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Undetected channels on transponders switching from DVB-S to DVB-S2
Hi, Am 11.09.2011 11:37, schrieb Henning Pingel: My questions are based on the experience when two transponders switched from DVB-S to DVB-S2 in 2011: 1) On S28.2E the transponder containing the BBC HD channels did this. 2) On S19.2E the transponder now containing the Sonnenklar.HD TV did this. In both cases VDR wasn't able to add the new DVB-S2 channels to the channels.conf automatically as long as not all predecessor channels had been manually removed from the channels.conf. From VDR 1.7.20 announcement: - Now scanning new transponders before old ones, to make sure transponder changes are recognized (thanks to Reinhard Nissl). Regarding Sonnenklar.HD TV: it appeared automatically in my channels.conf without further modifications. I have developed this patch for 1.7.17 so I haven't modified my channels.conf by hand since then. In case this transponder change has happened since 1.7.17, it seems that VDR 1.7.20 should be able to add the new channel automatically. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
Hi, Am 16.04.2011 16:28, schrieb syrius...@no-log.org: I'm now running one vdr instance with 4 dvb devices. One device is crashing quite often and I haven't find a way to automatically detect when it's crashed. (vdr used to issues unknown picture type message in the past) I'd like to prevent vdr from using it for recordings. Do you know of any plugin or patch that help achieving this ? Ideally I'd love to be able to set priorities and properties to devices. Something like: device #1: can_record, can_do_epg_scan, can_do_liveview, devprio=100 device #2: can_record, can_do_epg_scan, can_do_liveview, devprio=90 device #3: can_do_liveview, devprio=10 Is there a way for plugins to alter *cDevice::GetDevice behavior ? Are there any plans on that matter ? Please modify the attached plugin, telling that device 3 doesn't provide any transponder. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de vdr-transponderconstraints-0.0.1.tgz Description: GNU Unix tar archive ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine trickspeed bug report
Hi, Am 08.04.2011 19:45, schrieb Joerg Riechardt: In the replay of a h264 720p recording I am paused at a mark. 1. Now I press right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode ... In the rythm of the SequenceEndCode messages I see distortions and hold-ups in the video flow. The start is immediate. 2. This time starting at the mark I press play, pause, right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 P ... The start is delayed, but there are no distortions and the video flow is steady. So I guess there is something wrong with the SequenceEndCode detection in 1. and in 2. with the delayed start. You describe slow backward and slow forward behavior of VDR (and vdr-xine behavior in case of H.264 recordings). For the latter, VDR sends all pictures and xine replays them at reduced speed for slow motion. In case of slow backward, VDR sends only I-frames like it does for fast forward or fast backward, but at a much slower replay speed. As for all trickspeed modes which only transfer I-frames, vdr-xine inserts a H.264 SequenceEndCode between each frame to flush the frame immediately to screen, because the current H.264 decoder first fills its DPB with 16 frames before it outputs them on screen. For all other trickspeed modes (i. e. slow forward) you see the delay of filling the DPB. Regarding your distortions, disable deinterlacing in xine and verify, that your distortions go away besides that every second line of the image appears in background color. To fix this issue please apply a patch to VDR-1.7.17 (which was issued on this mailing list) regarding frame detection and rebuild your index file. Besides that you should also check the following settings in .xine/config: # disable decoder flush at discontinuity # bool, default: 0 engine.decoder.disable_flush_at_discontinuity:1 # disable decoder flush from video out # bool, default: 0 engine.decoder.disable_flush_from_video_out:1 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
Hi, I'm pleased to announce maintenance release 0.9.4. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2011-03-16: Version 0.9.4 - The contained xine-lib-1.1 patch is outdated but might still work. The patch will get updated in 0.9.5. - A couple of xine-lib-1.2 patches is still waiting to get commited. vdr-xine-0.9.4 should be able to work without them. - Fixed a couple of things in xine-lib-1.2 and VDPAU. - Fixed compilation for VDR-1.2.x and VDR-1.6.x. - Updated Makefile to VDR-1.7.17. - Added support for VDR-1.7.17s TrueColor OSD. - Added support for VDR-1.7.12s changed PCR handling. - Added support for VDR-1.7.11s semantic of MakePrimaryDevice. - Resolved a segfault regarding VDR-1.7.x and cutting marks in radio recordings (thanks to Joachim Wilke for providing a fix). - Included Lithuanian translation (thanks to Valdemaras Pipiras). - Included Slovak translation (thanks to Milan Hrala). - Included Chinese and Taiwanese translations (thanks to NanFeng). - Fixed MANUAL about centre_cut_out_mode (thanks to Vorg on #xine-vdpau). Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
Hi, Am 16.03.2011 20:29, schrieb Reinhard Nissl: - Added support for VDR-1.7.17s TrueColor OSD. I forgot to mention, that TrueColor OSD is currently only possible with VDPAU. Furthermore you have to select an OSD display mode different from X11 overlay in vdr-xines setup menu. Despite the name of this mode, it is currently not ARGB capable. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
Hi,
Am 14.03.2011 09:54, schrieb Simon Baxter:
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter
linu...@nzbaxters.com wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting
these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching
to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating
in MPEG1/2
mode
Those aren't error messages, they're just information messages
from vdr-xine.
Sorry, forgot to mention - I'm getting severe video slipping. The
audio sounds OK, but the video skips every few seconds as per the
timestamps:
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to
MPEG1/2 mode
Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in
MPEG1/2 mode
Looks like you're missing a patch for vdr-xine-0.9.3 to make it
compatible with vdr-1.7.12. Because since that version, channels
with PPID != VPID are handled differently by VDR, hence causing
this issue in vdr-xine.
vdr-xine-0.9.4 will include that patch, but it will still take a
few days to get it ready.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.3/xineDevice.c 2009-06-17 20:06:35.0 +0200
+++ xineDevice.c 2010-02-08 22:54:00.0 +0100
@@ -1539,7 +1546,13 @@ fclose(ff);
{
#if APIVERSNUM = 10701
if (Length = TS_SIZE)
- m_tsVideoPid = TsPid(Data);
+{
+#if APIVERSNUM = 10712
+ m_tsVideoPid = PatPmtParser()-Vpid();
+#else
+ m_tsVideoPid = TsPid(Data);
+#endif
+}
#endif
return Length;
}
@@ -4119,6 +4132,8 @@ store_frame(jumboPESdata, todo, __LINE__
void cXineDevice::MakePrimaryDevice(bool On)
{
+cDevice::MakePrimaryDevice(On);
+
xfprintf(stderr, -\n);
xfprintf(stderr, MakePrimaryDevice: %d\n, On);
xfprintf(stderr, =\n);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
Hi, Am 19.01.2011 13:42, schrieb Stuart Morris: One would need to be able to access the decoded frame containing 2 fields and perhaps use an OpenGL shader to perform field based colour space conversion and then draw the first field to the frame buffer. At the next vertical sync the shader would convert the second field and draw that to the frame buffer. With VDPAU is there a new OpenGL interop function that allows access to the decoded frame? If you enable bob deinterlacing you'll get that. Just set an interlaced video mode of appropriate resolution. Cannot tell whether VDPAU honors TOP/BOTTOM field flag and displays the frame when the field is due. This was always a problem with xxmc and VIA EPIA CLE 266. Incorrect field order is most noticeable on fast movements. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Collecting patches for vdr-xine-0.9.4
Hi, it looks like I can find more time this week to work on vdr-xine. I've seen some patches for vdr-xine-0.9.3 (and xine-lib) in the mailing list which address so far unsupported audio formats if I recall correctly, as vdr-xine still uses PES and my c*Repackers. I'd like to invite you to send them again to me (privately). A sample recording would be appreciated too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Hi, Am 05.10.2010 19:36, schrieb Luca Olivetti: Al 04/10/10 21:07, En/na Luca Olivetti ha escrit: Al 04/10/10 20:55, En/na Luca Olivetti ha escrit: Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this? Do you use this patch with vdr-xine? http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Hi, Am 05.10.2010 21:00, schrieb Luca Olivetti: Al 05/10/10 20:49, En/na Reinhard Nissl ha escrit: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this? Do you use this patch with vdr-xine? http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html Yes. Does this happen with 1.7.15 too? I'm still at 1.7.15 -- didn't find time to update yet. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Hi, Am 04.10.2010 21:07, schrieb Luca Olivetti: Al 04/10/10 20:55, En/na Luca Olivetti ha escrit: Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). Please have a look at http://sourceforge.net/mailarchive/forum.php?thread_name=4C93BD03.80702%40gmx.deforum_name=xine-devel and try changing buffer sizes. Just a guess. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Hi, Am 03.10.2010 21:23, schrieb Luca Olivetti: this has been bugging me for a while, but since it happens on channels I don't usually watch, I didn't ask before. There are some channels that are completely unwatchable: even with a perfect signal (at least according to femon) I can only see blocking artefacts and chirping sound. I tried vdr-xine, the dxr3 or vlc/mplayer through streamdev, the result is always the same. Here are some of the channels where this is happening right now: Mirabelle TV;EUTELSAT:10972:VC78M2O0S0:S5.0W:29950:1061=2:10...@3:0:0:4134:1375:20600:0 Normandie TV;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:851=2:852=...@3:0:0:405:1375:20400:0 TV8 MONT BLANC;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:881=2:882=...@3,883=...@3:0:0:408:1375:20400:0 TVN Warszawa;TVN:11508:VC56M2O0S0:S13.0E:27500:512=2:650=...@4:572:0:15801:318:1600:0 TVP Kultura;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:172=2:128=...@4:513:0:5113:318:1500:0 PULS;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:171=2:124=...@4:0:0:5112:318:1500:0 TRACE TV;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:164=2:96=...@4,97=...@4:0:0:5105:318:1500:0 (in fact all polish channels on this transponder do the same) RTV;Harmonic:11471:VM2O0S0:S13.0E:27500:611=2:6...@3:0:0:10622:318:1400:0 and many more. Any idea? I've just tried the mentioned S13.0E channels. They work flawlessly here. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
Hi, Am 29.08.2010 15:06, schrieb Klaus Schmidinger: DiscontinuityDetected: triggering soft start You may want to find out where this message comes from (it certainly doesn't come from the core VDR). This is just an implementation detail of vdr-xine. Why am I getting a SetPlayMode: 0 and receiver on device 2 thread ended (pid=16557, tid=16633) for no reason?? When a receiver is detached from a device, the play mode is set to pmNone (which is 0). My guess would be that the DiscontinuityDetected: triggering soft start is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream? I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] frequent xine crashes with vdr
Hi, Am 15.08.2010 11:21, schrieb marti...@embl.de: I start vdr and xine and all looks nicely and I zap channels a couple of times without problems and the 3rd time or so xine freezes and I need to restart it Which video output driver do you use? vdpau? Would you be so kind a supply a backtrace of xine when the freeze occurs? Run gdb xine `pidof xine` and then at the gdb prompt: thread apply all bt Please make sure to have debug symbols installed so that the backtrace shows reasonable function names and source locations. Could someone point out what is the likely culprit? Does vdr+xine run stable on 64 bits? I think so. uname -r 2.6.34-ARCH rni...@corei7:~ uname -a Linux corei7 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux I'm running openSUSE 11.3. BTW: I've noticed a similar behaviour on my system since a few days but I haven't managed to collect a backtrace though, because xine-lib resolved the freeze on it's own. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.15 / fix HD subtitles on arte HD
Hi, Am 06.06.2010 14:49, schrieb Klaus Schmidinger: - Implemented handling of HD resolution subtitles according to v1.3.1 of ETSI EN 300 743, chapter 7.2.1 (thanks to Rolf Ahrenberg). The attached patch fixes DDS detection on arte HD. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de --- ../vdr-1.7.15-orig/dvbsubtitle.c 2010-06-05 16:03:55.0 +0200 +++ dvbsubtitle.c 2010-07-18 21:29:50.0 +0200 @@ -660,7 +660,7 @@ cDvbSubtitleConverter::cDvbSubtitleConve dvbSubtitleAssembler = new cDvbSubtitleAssembler; osd = NULL; frozen = false; - ddsVersionNumber = 0; + ddsVersionNumber = -1; displayWidth = 720; displayHeight = 576; displayHorizontalOffset = 0; @@ -693,7 +693,7 @@ void cDvbSubtitleConverter::Reset(void) bitmaps-Clear(); DELETENULL(osd); frozen = false; - ddsVersionNumber = 0; + ddsVersionNumber = -1; displayWidth = 720; displayHeight = 576; displayHorizontalOffset = 0; ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re : vdr 1.7.10 no record channel
Hi, Am 30.06.2010 16:47, schrieb Senufo: I read the ISO / IEC 13818-2: 1995 for trying to better understand how is the detection of I-frames. In Chapter 6.2 the header image will begin by picture_start_code in remux.c if (scan == 0x0100) (/ / Picture Start Code If I understand the detection of the i-frame is in the picture_coding_type according to Table 6-12 picture_coding_type / coding method 000 / forbidden 001 / intra-coded (I) 010 / predictive-coded (P) 011 / bidirectionally-predictive-coded (B) 100 / Shall Not Be Used (dc intra-coded (D) in ISO/IEC11172- 2) 101 / reserved 110 / reserved 111 / reserved I do not understand this line of code: independentFrame = ((Data [i +2] 3) 0x07) == 1 / / I-Frame thank you for your answers Chapter 6.2.3 explains the picture header: picture_header() No. of bits Mnemonic picture_start_code32bslbf temporal_reference10uimsbf picture_coding_type3uimsbf vbv_delay 16uimsbf Data[i + 2] contains 2 LSB of temporal_reference (t), picture_coding_type (P) and 3 MSB of vbv_delay (v). So the bits of byte Data[i + 2] look like that: ttPPPvvv And the above code does: 3000ttPPP 0x07 0PPP == 10001 If you put 001 for an I frame from the above table for PPP you see the equation matches. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib patch
Hi, Am 29.03.2010 13:35, schrieb elimodel: reinhard, why don't you incude this new patch in the xine plugin source code? , why don't you release a new version with the new patch in the plugin? I'm just a little bit short on spare time, but I'm trying to release soon ... Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.14 + xine fails with h.264
Hi, Am 27.03.2010 12:42, schrieb Jouni Karvo: since I updated from vdr-1.7.11, there is some change in the way H.264 is treated: With 1.7.11 + xine with vdpau support, I can watch H.264 HDTV shows without problems. Occasionally, there is a small glitch. But with 1.7.14 + the same version of xine, H.264 (both SDTV and HDTV) fail. Syslog reports: The picture has big distortions, and typically xine hangs at some point. With traditional Mpeg-streams, there is no problem watching with 1.7.14. Since 1.7.12, VDR records PCR. Please apply the patch found in the below link to vdr-xine-0.9.3: http://www.linuxtv.org/pipermail/vdr/2010-February/022368.html Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 18.03.2010 13:43, schrieb peter: Does this happen too when not using vdpau? I'm not using vdpau (haven't got the hardware for it). vdr-1.7.10 xine-lib-1.2 The problem occurs when running xine with dxr3 output (xine --verbose=1 -V dxr3 -A alsa vdr:/tmp/vdr-xi/stream) Mar 18 13:26:43 vdr-desktop kernel: [ 6250.760298] em8300-0: adjusting scr: 30791 Mar 18 13:26:45 vdr-desktop kernel: [ 6252.872307] em8300-0: adjusting scr: 125823 Mar 18 13:27:05 vdr-desktop vdr: [4159] buffer usage: 70% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 80% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 90% (tid=4158) Mar 18 13:27:07 vdr-desktop vdr: [4159] buffer usage: 100% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4159] ERROR: driver buffer overflow on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4159] buffer usage: 30% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4158] ERROR: skipped 11 bytes to sync on TS packet on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (3) Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (11) Mar 18 13:27:18 vdr-desktop vdr: [4158] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame However: When running without dxr3 (xine --verbose=1 -V xshm -A alsa vdr:/tmp/vdr-xine/stream) everything is fine. Here's gdb output from a bad run: Well, vdr-xine is writing to xine and blocks as xine doesn't read any input data. Would you be so kind and create a backtrace of xine when this happens again. And provide an unwrapped backtrace, e. g. by attaching the backtrace as a text file, which makes it easier to read, especially as xine has much more threads. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 21.03.2010 16:36, schrieb Peter Odéus: Would you be so kind and create a backtrace of xine when this happens again. And provide an unwrapped backtrace, e. g. by attaching the backtrace as a text file, which makes it easier to read, especially as xine has much more threads. I would happily do that if you can guide on how to backtrace xine. When xine is unresponsive, type something like that: gdb /path/to/xine `pidof xine` At the gdb prompt, issue the following command: thread apply all bt and provide the output. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Am 17.03.2010 07:23, schrieb Torgeir Veimo: On 14 March 2010 21:47, Reinhard Nissl rni...@gmx.de wrote: Hi, Am 14.03.2010 12:46, schrieb Goga777: I have experienced this problem several times today while on HD h264 channels. Like previously posted: Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674) VDR was unresponsive and had to be restarted to fix. Best regards, Derek Sorry, forgot to mention this is with VDR-1.7.13... I confirm - with vdr 1.7.13 still have the same issue I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue. yes, I'm using the vdr-xine 093 please advice how should I use backtrace I see similar problems with xineliboutput, but I'm not sure it's exactly the same problem. I don't have to restart VDR, restarting the vdr-sxfe client is sufficient. Hmm, looks like xine / vdr-sxfe would be to blame. There are some cases where vdpau leaks images while decoding h264 video and when no more images are left, xine / vdr-sxfe freezes and vdr runs into an buffer overflow. Does this happen too when not using vdpau? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 13.03.2010 11:30, schrieb Goga777: I have experienced this problem several times today while on HD h264 channels. Like previously posted: Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674) VDR was unresponsive and had to be restarted to fix. Best regards, Derek Sorry, forgot to mention this is with VDR-1.7.13... I confirm - with vdr 1.7.13 still have the same issue I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 14.03.2010 12:46, schrieb Goga777: I have experienced this problem several times today while on HD h264 channels. Like previously posted: Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674) VDR was unresponsive and had to be restarted to fix. Best regards, Derek Sorry, forgot to mention this is with VDR-1.7.13... I confirm - with vdr 1.7.13 still have the same issue I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue. yes, I'm using the vdr-xine 093 please advice how should I use backtrace When VDR is unresponsive, type something like that: gdb /path/to/vdr `pidof vdr` At the gdb prompt, issue the following command: thread apply all bt and provide the output. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] enna + vdr
Hi, Am 26.02.2010 14:20, schrieb Lucian Muresan: Btw, I'm using vdr-1.7.12, xine-lib-1.2 and vdr-xine-0.9.3 on Gentoo, and the only way I can connect the traditional xine-ui to the running VDR instance is usig as the MRL netvdr:/localhost#demux:mpeg_pes, as for using the other way of connecting through a pipe (vdr:/tmp/vdr-xine/stream#demux:mpeg_pes), on my system there is no such pipe. I just wanted to try it that way in enna, but don't find a way to activate it in vdr-xine, is that no longer supported? Please check if you run vdr-xine with option -p. Just remove it then. MANUAL reports: -p[N] use socket connections on port N (18701) Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Strange behavior when replaying audio-only recordings with xine / vdpau
Hi, Am 14.02.2010 18:52, schrieb Joachim Wilke: I am using VDR 1.7.11 with xine / vdpau as output device. Replaying an audio only recording (e.g. from a radio channel) or an MP3 file (with mp3 plugin) leads to two strange things: 1.) The progress bar is always several seconds ahead - at the beginning of the recording it jumps instantly to ~20sec 2.) When pressing exit during playback the sound itself stops immediately but VDR hangs up to one minute before leaving the replay. I have no idea what the reason for this could be - does anybody of you have the same issue? I do. I have configured 2300 audio input buffers in .xine/config. In case of vdr-xine, each input buffer gets just a single audio frame which in case of usual mpeg1 layer2 audio means 24 ms audio. I haven't check yet, at which rate VDR generates index entries in case of radio recordings, but some other debug output shows that playFrame number (i. e. the frame which is currently transfered to xine) is about 800 ahead of Current (i. e. the frame which is currently played by xine), which is derived from STC, and Current is used to draw the progress bar. If you have a look into dvbplayer.c, you'll find this line: #define PTSINDEX_ENTRIES 500 It looks like VDR stores only 500 historic frame to pts associations relative to playFrame. So when you start replaying a recording, playFrame will quickly run up to something like 800. As VDR cannot find the STC value provided by vdr-xine in it's buffer, it will stay at the beginning of it's buffer and return something like 300 for Current. I assume that 300 is related to 20 seconds. I've increased the above constant for simplicity just to 5 for testing and the issue is gone at least for audio recordings, but I haven't tested the change with mp3 plugin yet. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.12 - issue with some mpeg2 channels (cVideoRepacker: switching to MPEG1/2 mode)
Hi, Am 08.02.2010 22:06, schrieb Goga777: In vdr/xine/vdr-xine logs I can see following Feb 8 21:16:31 arvdr vdr: [2544] cVideoRepacker: switching to MPEG1/2 mode Feb 8 21:16:31 arvdr vdr: [2544] cVideoRepacker: operating in MPEG1/2 mode Feb 8 21:16:33 arvdr vdr: [2544] cVideoRepacker: switching to MPEG1/2 mode Feb 8 21:16:33 arvdr vdr: [2544] cVideoRepacker: operating in MPEG1/2 mode Feb 8 21:16:33 arvdr logger: video I can only reproduce this issue on channels with separate PCR pid. I'll have to investigate further to find a solution. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.12 - issue with some mpeg2 channels (cVideoRepacker: switching to MPEG1/2 mode)
Hi,
Am 08.02.2010 22:29, schrieb Klaus Schmidinger:
I can only reproduce this issue on channels with separate PCR
pid. I'll have to investigate further to find a solution.
As of version 1.7.12 VDR records the PCR pid if it is different
than the video PID. For lack of better knowledge I made cDevice::PlayTs()
send the PCR packets to PlayTsVideo(). The FF cards don't have a problem
with that, but maybe xine or the cVideoRepacker does.
Maybe VDR shouldn't even replay the PCR data - please advise.
As it is possible to access cPatPmtParser since a few releases,
I've changed vdr-xine to pull VPID from there instead of picking
it from packets passed to PlayTsVideo.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.3/xineDevice.c 2009-06-17 20:06:35.0 +0200
+++ xineDevice.c 2010-02-08 22:54:00.0 +0100
@@ -1539,7 +1546,13 @@ fclose(ff);
{
#if APIVERSNUM = 10701
if (Length = TS_SIZE)
- m_tsVideoPid = TsPid(Data);
+{
+#if APIVERSNUM = 10712
+ m_tsVideoPid = PatPmtParser()-Vpid();
+#else
+ m_tsVideoPid = TsPid(Data);
+#endif
+}
#endif
return Length;
}
@@ -4119,6 +4132,8 @@ store_frame(jumboPESdata, todo, __LINE__
void cXineDevice::MakePrimaryDevice(bool On)
{
+cDevice::MakePrimaryDevice(On);
+
xfprintf(stderr, -\n);
xfprintf(stderr, MakePrimaryDevice: %d\n, On);
xfprintf(stderr, =\n);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
Hi, Am 26.01.2010 19:18, schrieb Jouni Karvo: I included logs, please let me know what to try next. Both of your so far posted logs show this scenario: Jan 26 19:54:55 vdr vdr: [-1] buffer usage: 70% (tid=-1) Jan 26 19:54:55 vdr vdr: [-1] buffer usage: 80% (tid=-1) Jan 26 19:54:55 vdr vdr: [-1] buffer usage: 90% (tid=-1) Jan 26 19:54:56 vdr vdr: [-1] buffer usage: 100% (tid=-1) Jan 26 19:55:24 vdr vdr: [-1] ERROR: video data stream broken Jan 26 19:55:24 vdr vdr: [-1] initiating emergency exit Jan 26 19:55:29 vdr vdr: [-1] PANIC: watchdog timer expired - exiting! This doesn't look like a vdr-xine issue. But before investigating this further, you first need to fix your system so that VDR can retrieve thread IDs. As the above log reports -1 as thread ID it is almost impossible to tell, which thread got stuck -- either the thread which does the recording or the other which talks to xine. Please tell a little bit about your system. I wonder how moving to x86_64 could result in such mess. Some infos about my system: Linux 2.6.31.8-0.1-desktop x86_64 [ openSUSE 11.2 ] rpm -q gcc gcc44 glibc gcc-4.4-4.2.x86_64 gcc44-4.4.1_20090817-2.3.4.x86_64 glibc-2.10.1-10.4.x86_64 A sample from my logs: Jan 26 20:54:01 corei7 vdr: [7376] switching to channel 7 Jan 26 20:54:03 corei7 vdr: [7430] cVideoRepacker: switching to MPEG1/2 mode Jan 26 20:54:03 corei7 vdr: [7430] cVideoRepacker: operating in MPEG1/2 mode And a request for further debug information: please provide it in a way that it doesn't get wrapped around. Wrapping makes it hard to read. Simply attach it as plain text file if you cannot find another way to achieve this. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] genindex.c for vdr-1.7.x
Hi,
Am 07.01.2010 22:09, schrieb Theunis Potgieter:
I guess I will have to wait for the output device plugins to update
before I can start using vdr-1.7.11. Thanks for pointing to the change
log :)
Regarding vdr-xine-0.9.3, please have a look at the attached patch.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.3/xineDevice.c 2009-06-17 20:06:35.0 +0200
+++ xineDevice.c 2010-01-06 15:46:15.0 +0100
@@ -4119,6 +4126,8 @@ store_frame(jumboPESdata, todo, __LINE__
void cXineDevice::MakePrimaryDevice(bool On)
{
+cDevice::MakePrimaryDevice(On);
+
xfprintf(stderr, -\n);
xfprintf(stderr, MakePrimaryDevice: %d\n, On);
xfprintf(stderr, =\n);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Moving to a stream mpeg or h264 with vdr-1.7.9
Hi, Am 12.11.2009 22:05, schrieb Senufo: I just found an error when I use the keys 4 or 7 for me to move in the mpeg2 stream (vdr-17.9 with vdr-xine 0.9.3). Clear(1785)! StillPicture: 0x191da2a0, 0 FIXME: xineDevice.c:1321 FIXME: xineDevice.c:2075 Clear(1786)! StillPicture: 0x19179110, 0 FIXME: xineDevice.c:1321 FIXME: xineDevice.c:2075 There is still a bug in VDR-1.7.9's I-frame detector which is used to generate the index file. The index position is off by one TS packet so that the first TS packet of the I-frame is missing when VDR sends the still picture data to vdr-xine. Hence, the image cannot be decoded, so you won't see a change on screen. The bug is going to be fixed -- see [vdr] FF/RW problems with xine. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.9.3 audio problems
Hi, Simon Baxter schrieb: #engine.buffers.video_num_buffers is left at the default of 500. If I set this any higher, fast forwarding or rewinding causes the video to jump about 90 seconds. VDR-1.7.x should address this. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.9.3 audio problems
Hi, Simon Baxter schrieb: Had no response on this - guess Reinhard has been away? Any suggestions on this?? Please tell vdr-xine settings regarding buffering and try to change the buffer settings in .xine/config to huge values as mentioned in MANUAL. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine - 4:3 zoom problem with h264 SD channels
Hi,
Goga777 schrieb:
on Astra 19,2E ther's several h264 SD 576i channels with aspect ratio above
4:3 (or 15:11).
[snip]
TV
Polonia;TVP:10861:hC56M5O35S1:S19.2E:22000:516=27:0;690=pol,691=pol:695:0:7104:1:1059:0
[snip]
on vdr-xine 093 the 4:3 image zoom doesn't work at all with such channels
only 16:9 image zoom works with them, but it's not correctly
could someone to test it please
I had a look at the above channel. xine reports a ratio of 13636.
But the current zoom code in input_vdr.c doesn't consider this to
be 4:3. Please replace the function adjust_zoom() by the
following code:
static void adjust_zoom(vdr_input_plugin_t *this)
{
pthread_mutex_lock(this-adjust_zoom_lock);
if (this-image4_3_zoom_x this-image4_3_zoom_y
this-image16_9_zoom_x this-image16_9_zoom_y)
{
int ratio = (int)(1 * this-frame_size.r + 0.5);
int matches4_3 = abs(ratio - 1);
int matches16_9 = abs(ratio - 17778);
/* fprintf(stderr, ratio: %d\n, ratio); */
if (matches4_3 matches16_9)
{
xine_set_param(this-stream, XINE_PARAM_VO_ZOOM_X,
this-image4_3_zoom_x);
xine_set_param(this-stream, XINE_PARAM_VO_ZOOM_Y,
this-image4_3_zoom_y);
}
else
{
xine_set_param(this-stream, XINE_PARAM_VO_ZOOM_X,
this-image16_9_zoom_x);
xine_set_param(this-stream, XINE_PARAM_VO_ZOOM_Y,
this-image16_9_zoom_y);
}
}
pthread_mutex_unlock(this-adjust_zoom_lock);
}
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How do I listen to a channel's soundtrack and it's audio description at the same time?
Hi, John Robinson schrieb: One member of this list very helpfully suggested that, to switch between the programme's main sound track and the audio description track, I can hit the 'Audio' key, then the right cursor key and then the 'Audio' key again. This does, indeed switch from the main programme sound track to the audio description track, but it only lets me hear one or the other, not both. Maybe I told you too much details of the audio menu so you got a bit confused. Your key sequence 'Audio', 'right cursor', 'Audio' may indeed do, what you experience. Let me explain: 1.) 'Audio' opens the audio menu. 2.) 'right cursor' selects the right channel of the current stereo track. 3.) 'Audio' switches to the next track (audio description) but stays at right channel of the audio description track. At the moment, there is no programme running where I could verify my conclusions, but for me it looks like that (referencing the explanations of my previous email): the audio description track provides two mono channels which appear as left and right channel of the stereo audio description track. The left channel seems to provide a mono audio signal of the main programmes sound track, while the right channel provides audio description only. So simply omitting step two 'right cursor' from your key sequence should do the trick and present both mono channels at the same time. The only drawback of the current solution is, that you hear the main programme sound track only on the left side of your audio equipment and the audio description only on the right side. Mixing both mono channels together and presenting the result as a stereo signal is feasible by output plugins but would require some way to tell the output plugin to activate this mode. The best would be if VDR's user interface would allow to select such a mode and provide that selection to the output plugin. Suggestion for extending the user and output plugin interface: In the audio menu, the left and right keys select between left, stereo and right channel. A further mode 'combined' should be added which can be reached by pressing 'right' when the right channel is selected. The current audio channel selection is provided in the output plugin interface via the method SetAudioChannelDevice. The parameter values 0, 1 or 2 represent stereo, left or right channel. A further parameter value 3 would represent 'combined' mode. For compatibility and the most common use case, 'combined' mode should need to be activated in VDR's setup menu, i. e. it is not available by default. Maybe Klaus can drop a few words about this extension. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine: Script mkNoSignal.sh for convert png2mpg
Hi, Александр schrieb: It requires: mpeg2enc ppmtoy4m pngtopnm The first two are in the mjpegtools package for Ubuntu. Not enough pngtopnm. As written in INSTALL: BTW: mkNoSignal.sh requires the following tools on your path: pngtopnmpart of netpbm-10.26.44-98.16 ppmtoy4mpart of mjpegtools-1.8.0 mpeg2encpart of mjpegtools-1.8.0 so please look for a netpbm package for ubuntu. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How do I get audio description with VDR
Hi, John Robinson schrieb: Hi everyone. I've just joined this list and am totally blind. I can listen to Freeview TV and radio channels through my Nebula Electronics USB receiver and VDR, but would like to receive audio description as well. I've heard that VDR can do this, but I haven't been able to find any information on how to set it up. If anyone could advise me, I'd very much appreciate it. I can only speak of the German TV channel Bayerisches Fernsehen. They provide an additional audio track called Audio description. For certain events e. g. most movies, this track provides audio description while it provides standard audio the other time, just like the other audio tracks do. To choose a different audio track, just open VDR's audio track menu and select a different track. I cannot tell how you can do that in your setup, but there exists a certain key to open it. Pressing the key again while the menu is open cycles to the next track. The menu disappears automatically after some seconds of inactivity. Some other stations chose a different method to broadcast a pair of mono audio tracks as a single stereo audio track. I cannot tell if your setup supports this, but if you open VDR's audio menu and press the button to navigate left or right, you select either the left or the right track of the stereo channel and hence one of the two mono tracks. In case you selected for example the left mono track, navigating to the right brings you back to stereo and a further move chooses the right track. Besides mono and stereo audio tracks, there exist surround sound tracks. I cannot tell whether your setup supports replaying surround sound or is at least able to transform it into stereo, but for such tracks, selecting among the individual mono tracks is not supported. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Audio problems with vdr-sxfe
Hi, gimli schrieb: on the weekend i tryed switching from vdr-1.7.0 to vdr-1.7.8. With vdr 1.7.8 there is a strange problem with vdr-xine. On ORF 1 HD and Arte HD i have no audio. On Anixe HD and the Astra demo channel audio is fine. On vdr 1.7.0 audio worked for ORF 1 HD and Arte HD, My aktual setup is : vdr 1.7.8 xine-vdpau rev 275 vdr-xine 0.9.3 Cannot reproduce with vdr-1.7.8, vdr-xine-0.9.3, xine-lib-1.2 + xine-lib-1.2-vdpau-r275.patch and this channel: arte HD;ZDFvision:11361:hC23M5O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra;6220=deu:6230:0:11120:1:1011:0 BTW: I have reverted this changeset in xine-lib-1.2 which is part of xine-lib-1.1 too, but not part of xine-vdpau: http://hg.debian.org/hg/xine-lib/xine-lib-1.2/raw-rev/fd48f5a5841d Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.3 plugin
Hi, I'm pleased to announce maintenance release 0.9.3. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-06-17: Version 0.9.3 - Updated MANUAL accordingly (e. g. some information about xine engine buffer sizes). - Implemented VDR-1.7.8s cDevice::GetOsdSize() and changed cDevice::GetVideoSize() accordingly. - Implemented video window support while showing an OSD for VDPAU to support plugins like yaepghd. - Clipped settings in setup page to reasonable values while editing to prevent rendering an unreadable OSD. - Introduced separate live TV buffer values for SD and HD video as well as audio to allow faster zapping on SD channels while still having large buffers for HD video. - Fixed setup page display while changing OSD extent. - Fixed a memory leak in processing TS still images. - Fixed a bug in processing TS still images which caused the tail of the image to get lost and hence the image not to get shown. - Updated it_IT.po (thanks to Diego Pierotto for providing the translations). NOTE: * vdr-xine xine-lib interface hasn't changed * BTW: - it seems to be necessary to restart VDR in order to make changes to the OSD extent take effect. - replaying fast reverse stops at start of recording. Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine-0.9.2 - ERROR: cOsd::SetAreas returned 5
Hi, Goga777 schrieb: how can I fix my problem with ERROR: cOsd::SetAreas returned 5 This number matches the enum value oeWrongAlignment. In VDR's code excerpt you can see the condition for this error: if (Areas[i].x1 Areas[i].x2 || Areas[i].y1 Areas[i].y2 || Areas[i].x1 0 || Areas[i].y1 0) return oeWrongAlignment; Jun 9 21:25:39 arvdr vdr: [12294] vdr-xine: new OSD(0, -108) requested with coordinates out of range Jun 9 21:25:39 arvdr vdr: [12294] ERROR: cOsd::SetAreas returned 5 I've no idea why a vanilla VDR-1.7.7 should produce such an incorrect OSD setup. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine buffer values
Hi, marti...@embl.de schrieb: Now, zapping time better. What is in your opinion the optimum buffer settings for vdr-xine and for .xine/config ? (I have a Hauppage S2-HD) These are my current settings: vdr/setup.conf xine.modeLiveTV.prebufferFrames = 11 some HD channels require more as xine-vdpau holds back for example 16 frames. Therefore the next vdr-xine release allows to configure the numbers for HD and SD video as well as audio separately. xine.modeLiveTV.prebufferHysteresis = 4 .xine/config # number of audio buffers engine.buffers.audio_num_buffers:460 the default value should do # number of video buffers engine.buffers.video_num_buffers:250 some HD channels require 1500 to 2000 # number of video frames engine.buffers.video_num_frames:22 increasing this to 30 allows more latency Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine and ffwd/rew/skip
Hi, Magnus Hörlin schrieb: Thanks, but that unfortunately didn't help me. For me, ffwd/rew hasn't worked with vdr-xine since back in the days when you had to patch if for networked use. Then xineliboutput came along and I have never managed to get vdr-xine to work well enough to replace it. I guess I have tried about 100 different versions of hardware/vdr/graphics drivers/xinelib and vdr-xine over the years. The HD playback is better than in xineliboutput but what I do a lot is to jump 60s forward through recordings and that doesn't work very well with vdr-xine. The progress bar jumps 60s almost immediately, but it only jumps about five seconds. And a few seconds later, it jumps to where it should. With xineliboutput a can hold the button down and it jumps very fast and precise. And ffwd/rew is instantaneous. With vdr-xine, xine-ui crashes almost every time. And since I don't even have a GPU on my vdr server, I'm not very fond of having to compile xine on it. But like I said, vdr-xine works better with HD channels and plays Swedish national television's 720p50 SVT HD which xineliboutput doesn't do very well so it would be nice to get it working. Actually, I tend to use XBMC to watch HD recordings since their vdpau implementation seems to be the best. Thanks for taking your time. Regarding jumping +/- 60s: with vdr-1.7.x accuracy has improved a lot since VDR reads back real replay position from xine. Can you provide backtraces of the xine-ui crashes? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Hi,
Magnus Hörlin schrieb:
I have to agree that the vdpau deinterlacers are better than the tvtime
ones, including the temporal only deinterlacer that is used for 1080i.
But it is as you say a little annoying that paused images are not
deinterlaced. I use the ION platform with 9400M.
Well, the attached patch is better than nothing but a better
approach would be to render both fields into a single surface
before displaying them. At the moment, both fields are rendered
separately.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
diff --git a/src/video_out/video_out_vdpau.c b/src/video_out/video_out_vdpau.c
--- a/src/video_out/video_out_vdpau.c
+++ b/src/video_out/video_out_vdpau.c
@@ -1386,7 +1394,7 @@ static void vdpau_display_frame (vo_driv
XLockDisplay( this-display );
- if ( frame-format==XINE_IMGFMT_VDPAU this-deinterlace non_progressive stream_speed frame_duration2500 ) {
+ if ( frame-format==XINE_IMGFMT_VDPAU this-deinterlace non_progressive /* stream_speed */ frame_duration2500 ) {
VdpTime current_time = 0;
VdpVideoSurface past[2];
VdpVideoSurface future[1];
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Hi, Niels Wagenaar schrieb: 2. Using plugins like vdr-xine and/or xineliboutput you have buffering time which is annoying for zap speeds on encrypted channels. Here you can find the changeset which is responsible for the buffering issue. http://sourceforge.net/mailarchive/forum.php?thread_name=4A15672E.5090908%40gmx.deforum_name=xine-devel If you revert the changeset, zapping should behave as usual. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
Hi,
Magnus Hörlin schrieb:
Well, it's A LOT better than nothing. Reinhard, you are a true hero. Now
if only ffwd/rew/skip would be as smooth with vdr-xine as it is with
xineliboutput... Anyway, your xinelib-1.2 vdpau patches are brilliant.
I've used every one of them since day one.
Well, have a look into xineDevice.c and locate
cXineDevice::HasIBPTrickSpeed(). Then remove the comment and
apply the attached patch to VDR.
The problem is, that I don't know which speed calculation to use
in SetTrickSpeed(). So I asked kls to supply this info as in the
attached patch but he thinks of changing the semantic of
SetTrickSpeed() at all. That's why I haven't released this
functionality yet.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.5-pre/./player.h 2009-03-08 13:29:10.0 +0100
+++ ./player.h 2009-04-02 20:53:04.0 +0200
@@ -27,7 +27,7 @@ protected:
bool DeviceFlush(int TimeoutMs = 0) { return device ? device-Flush(TimeoutMs) : true; }
bool DeviceHasIBPTrickSpeed(void) { return device ? device-HasIBPTrickSpeed() : false; }
bool DeviceIsPlayingVideo(void) { return device ? device-IsPlayingVideo() : false; }
- void DeviceTrickSpeed(int Speed) { if (device) device-TrickSpeed(Speed); }
+ void DeviceTrickSpeed(int Speed, bool IBP) { if (device) device-TrickSpeed(Speed, IBP); }
void DeviceClear(void) { if (device) device-Clear(); }
void DevicePlay(void) { if (device) device-Play(); }
void DeviceFreeze(void) { if (device) device-Freeze(); }
--- ../vdr-1.7.5-pre/./dvbdevice.c 2009-01-10 11:07:33.0 +0100
+++ ./dvbdevice.c 2009-04-02 20:52:05.0 +0200
@@ -1150,7 +1150,7 @@ int64_t cDvbDevice::GetSTC(void)
return -1;
}
-void cDvbDevice::TrickSpeed(int Speed)
+void cDvbDevice::TrickSpeed(int Speed, bool IBP)
{
if (fd_video = 0)
CHECK(ioctl(fd_video, VIDEO_SLOWMOTION, Speed));
--- ../vdr-1.7.5-pre/./dvbdevice.h 2008-12-06 14:31:12.0 +0100
+++ ./dvbdevice.h 2009-04-02 20:51:49.0 +0200
@@ -143,7 +143,7 @@ protected:
virtual int PlayTsAudio(const uchar *Data, int Length);
public:
virtual int64_t GetSTC(void);
- virtual void TrickSpeed(int Speed);
+ virtual void TrickSpeed(int Speed, bool IBP);
virtual void Clear(void);
virtual void Play(void);
virtual void Freeze(void);
--- ../vdr-1.7.5-pre/./dvbplayer.c 2009-03-29 18:39:43.0 +0200
+++ ./dvbplayer.c 2009-04-02 20:58:58.0 +0200
@@ -308,7 +308,7 @@ void cDvbPlayer::TrickSpeed(int Incremen
int sp = (Speeds[nts] 0) ? Mult / Speeds[nts] : -Speeds[nts] * Mult;
if (sp MAX_VIDEO_SLOWMOTION)
sp = MAX_VIDEO_SLOWMOTION;
- DeviceTrickSpeed(sp);
+ DeviceTrickSpeed(sp, playMode == pmFast playDir == pdForward DeviceHasIBPTrickSpeed());
}
}
--- ../vdr-1.7.5-pre/./device.h 2009-03-28 22:53:26.0 +0100
+++ ./device.h 2009-04-02 20:49:30.0 +0200
@@ -556,7 +556,7 @@ public:
virtual bool HasIBPTrickSpeed(void) { return false; }
/// Returns true if this device can handle all frames in 'fast forward'
/// trick speeds.
- virtual void TrickSpeed(int Speed);
+ virtual void TrickSpeed(int Speed, bool IBP);
/// Sets the device into a mode where replay is done slower.
/// Every single frame shall then be displayed the given number of
/// times.
--- ../vdr-1.7.5-pre/./device.c 2009-01-30 17:01:53.0 +0100
+++ ./device.c 2009-04-02 20:49:49.0 +0200
@@ -987,7 +987,7 @@ int64_t cDevice::GetSTC(void)
return -1;
}
-void cDevice::TrickSpeed(int Speed)
+void cDevice::TrickSpeed(int Speed, bool IBP)
{
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Digital encoding in first(top) video row
Hi, Alex Betis schrieb: I have few DVB-S channels with first (top) row of the video shown on the screen as a set of black and while pixels that definitely represent a digital information. I clearly see some counters running there. The same channel broadcasting by local cable provider don't have that line shown. Do you think they intentionally hide that row? Or there is a problem with MPEG decoding for those channels in VDR? The broadcaster chose to encode this line which was part of the original video. So after correct decoding the line appears in the images. Is there any way to auto detect and hide that row? Typically, this line is in the overscan area of the image. Simply zoom the video a bit and it will fall outside of the visible area. In case you can receive this channel: HD-Test ARD ZDF;IRT:11361:hC23M5O35S1:S19.2E:22000:6410=27:6420=deu;6421=deu,6422=Ori:6430:0:11140:1:1011:0 you'll see marks indicating overscan areas at 1 %, 2 %, 3 %, 4 % and 5 % of the image. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineplayer uncontrolable...
Hi, marti...@embl.de schrieb: VDR 1.7.7 I have installed the mplayer plugin and read the MANUAL in the xine plugin, consequently modified mplayer.sh to call xineplayer instead of mplayer So far so good but when I open the mplayer plugin and play any file (for example a .avi ) the movie displays correctly but there is no way to pause it, or otherwise control it. I press pause and I see the pause symbol on the screeen but whereas playing normal vdr recordings it works fine, with the mplayer plugin and xineplayer the movie does not pause. Anybody has experienced this and more important found a way to get this working? This is by design: this functionality requires SLAVE mode, but xineplayer currently only supports TRADITIONAL. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.7 playback - getting PPPP ??
Hi, Simon Baxter schrieb: I'm using vdr-xine as my soft device. The PP messages are in the console: snip SetPlayMode: 1 SetDigitalAudioDevice: 0 frame: (0, 0)-(720,576), zoom: (1.00, 1.00) Any ideas what this means? It means that VDR's call to cXineDevice::Poll() timed out. In other words, xine didn't get into a state where it could accept futher data for that period of time. You can ignore this piece of information when replaying recordings, but you shouldn't get this reported for live TV, where xine's input buffers aren't expected to fill up completely. MANUAL mentions to set engine.buffers.audio_num_buffers to 4 but VDR-1.7.x doesn't need this anymore. Just leave the setting untouched -- the default value of 230 should be ok. For some HD channels people reported that it is required to increase engine.buffers.video_num_buffers to 2500 or something like that. Otherwise the huge A/V offset between audio and video input packets cannot be compensated and leads to noticeable delays in decoding and presentation. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.2 plugin
Hi, I'm pleased to announce maintenance release 0.9.2. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-05-03: Version 0.9.2 - Updated MANUAL accordingly. - Added setup options to define OSD extent. - Implemented VDR-1.7.7s cDevice::GetVideoSize() to return an OSDs maximum extent. NOTE: * no xine-lib changes since 0.9.1 * BTW: it seems to be necessary to restart VDR in order to make changes to the OSD extent take effect. Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BBC HD and vdpau
Hi, Morfsta schrieb: Sounds like VDPAU (or xine's interface with VDPAU) doesn't support MBAFF properly then. BBCHD is one of the few HD channels that uses MBAFF, most use PAFF. Is there a chance to provide a TS sample for investigation? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi,
Klaus Schmidinger schrieb:
This indicates that cFrameDetector::Analyze() doesn't find any frames.
Take a look at the code beginning at
case 0x1B: // MPEG 4 video
if (scanner == 0x0109) { // Access Unit Delimiter
Apparently the scanner never gets to be 0x0109.
We'll need to know what condition to use to detect the frames.
According to spec, AUD is optional. Chapter 7.4.1.2.3 is not too
complicated to implement and most often sufficient.
For complete support, 7.4.1.2.4 is required too, but more
compliated and cannot be implemented without in depth parsing of
several H.264 data structures.
As vdr-xine doesn't implement the later and seems to work for
this kind of stream (see this thread), implementing the former
should fix this issue.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.1 plugin
Hi, I'm pleased to announce a the maintenance release 0.9.1. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-04-12: Version 0.9.1 - Adapted PlayTs() to semantic of VDR-1.7.5. - Fixed compilation for VDR 1.2.x, 1.4.x, 1.6.x and 1.7.x. - Added support for tIndex being uint16_t (not tested yet). - Changed trick speed modes to match GetSTC(). - Fixed buffer calculation after discontinuity which caused endless slow motion. - Changed GetSTC() to match VDR 1.7.5's requirements. - Implemented TS support to StillPicture(). - Fixed crash due to calling PlayTs() from different threads. - Fixed crashes due to negative OSD coordinates caused by some skins. - Fixed INSTALL regarding xine-ui cvs repository and how to apply the patches as they have been created differently since release 0.9.0. Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] Speedup patch for VDR-1.7.5
Hi,
the patch was previously part of my H.264 support patch. I
release it again now for 1.7.5 to not loose track of my work ;-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
diff -Nurp vdr-1.7.5-orig/Makefile vdr-1.7.5-speedup/Makefile
--- vdr-1.7.5-orig/Makefile 2008-12-24 16:21:09.0 +0100
+++ vdr-1.7.5-speedup/Makefile 2009-04-12 22:19:09.0 +0200
@@ -58,6 +58,25 @@ RCU_DEVICE ?= /dev/ttyS1
DEFINES += -DLIRC_DEVICE=\$(LIRC_DEVICE)\ -DRCU_DEVICE=\$(RCU_DEVICE)\
+ifdef LIRC_PUSHFREQ
+DEFINES += -DLIRC_PUSHFREQ=$(LIRC_PUSHFREQ)
+endif
+ifdef LIRC_REPEATDELAY
+DEFINES += -DLIRCD_REPEATDELAY=$(LIRC_REPEATDELAY)
+endif
+ifdef LIRC_REPEATFREQ
+DEFINES += -DLIRC_REPEATFREQ=$(LIRC_REPEATFREQ)
+endif
+ifdef LIRC_REPEATTIMEOUT
+DEFINES += -DLIRC_REPEATTIMEOUT=$(LIRC_REPEATTIMEOUT)
+endif
+ifdef LIRC_RECONNECTDELAY
+DEFINES += -DLIRC_RECONNECTDELAY=$(LIRC_RECONNECTDELAY)
+endif
+ifdef LIRC_PRIORITYBOOST
+DEFINES += -DLIRC_PRIORITYBOOST=$(LIRC_PRIORITYBOOST)
+endif
+
DEFINES += -D_GNU_SOURCE
DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
diff -Nurp vdr-1.7.5-orig/channels.c vdr-1.7.5-speedup/channels.c
--- vdr-1.7.5-orig/channels.c 2009-04-10 13:29:55.0 +0200
+++ vdr-1.7.5-speedup/channels.c 2009-04-12 22:19:09.0 +0200
@@ -202,7 +202,7 @@ cChannel::cChannel(void)
modification = CHANNELMOD_NONE;
schedule = NULL;
linkChannels = NULL;
- refChannel = NULL;
+ refChannels = NULL;
}
cChannel::cChannel(const cChannel Channel)
@@ -213,28 +213,26 @@ cChannel::cChannel(const cChannel Chann
portalName = NULL;
schedule = NULL;
linkChannels = NULL;
- refChannel = NULL;
+ refChannels = NULL;
*this = Channel;
}
cChannel::~cChannel()
{
- delete linkChannels;
- linkChannels = NULL; // more than one channel can link to this one, so we need the following loop
- for (cChannel *Channel = Channels.First(); Channel; Channel = Channels.Next(Channel)) {
- if (Channel-linkChannels) {
- for (cLinkChannel *lc = Channel-linkChannels-First(); lc; lc = Channel-linkChannels-Next(lc)) {
- if (lc-Channel() == this) {
-Channel-linkChannels-Del(lc);
-break;
-}
- }
- if (Channel-linkChannels-Count() == 0) {
-delete Channel-linkChannels;
-Channel-linkChannels = NULL;
-}
- }
- }
+ if (linkChannels) {
+ // in all channels which we link to remove the reference to us
+ for (cLinkChannel *lc = linkChannels-First(); lc; lc = linkChannels-Next(lc))
+ lc-Channel()-DelRefChannel(this);
+ delete linkChannels;
+ linkChannels = NULL;
+ }
+ if (refChannels) {
+ // in all channels which reference us remove their link to us
+ for (cLinkChannel *lc = refChannels-First(); lc; lc = refChannels-Next(lc))
+ lc-Channel()-DelLinkChannel(this);
+ delete refChannels;
+ refChannels = NULL;
+ }
free(name);
free(shortName);
free(provider);
@@ -588,7 +586,7 @@ void cChannel::SetLinkChannels(cLinkChan
q += sprintf(q, linking channel %d from, Number());
if (linkChannels) {
for (cLinkChannel *lc = linkChannels-First(); lc; lc = linkChannels-Next(lc)) {
- lc-Channel()-SetRefChannel(NULL);
+ lc-Channel()-DelRefChannel(this);
q += sprintf(q, %d, lc-Channel()-Number());
}
delete linkChannels;
@@ -599,7 +597,7 @@ void cChannel::SetLinkChannels(cLinkChan
linkChannels = LinkChannels;
if (linkChannels) {
for (cLinkChannel *lc = linkChannels-First(); lc; lc = linkChannels-Next(lc)) {
- lc-Channel()-SetRefChannel(this);
+ lc-Channel()-AddRefChannel(this);
q += sprintf(q, %d, lc-Channel()-Number());
//dsyslog(link %4d - %4d: %s, Number(), lc-Channel()-Number(), lc-Channel()-Name());
}
@@ -609,9 +607,39 @@ void cChannel::SetLinkChannels(cLinkChan
dsyslog(buffer);
}
-void cChannel::SetRefChannel(cChannel *RefChannel)
+void cChannel::AddRefChannel(cChannel *RefChannel)
+{
+ if (!refChannels)
+ refChannels = new cLinkChannels;
+ refChannels-Add(new cLinkChannel(RefChannel));
+}
+
+void cChannel::DelRefChannel(cChannel *RefChannel)
+{
+ for (cLinkChannel *lc = refChannels-First(); lc; lc = refChannels-Next(lc)) {
+ if (lc-Channel() == RefChannel) {
+ refChannels-Del(lc);
+ if (refChannels-Count() = 0) {
+delete refChannels;
+refChannels = NULL;
+}
+ return;
+ }
+ }
+}
+
+void cChannel::DelLinkChannel(cChannel *LinkChannel)
{
- refChannel = RefChannel;
+ for (cLinkChannel *lc = linkChannels-First(); lc; lc = linkChannels-Next(lc)) {
+ if (lc-Channel() == LinkChannel) {
+ linkChannels-Del(lc);
+ if (linkChannels-Count() = 0) {
+delete linkChannels;
+linkChannels = NULL;
+}
+ return
Re: [vdr] xine for vdr-0.7.4 doesn't patch
Hi, Simon Baxter schrieb: My point exactly - from INSTALL: snip keybindings to xine-ui for supporting my plugin's remote functionality. I use the following commands for patching: patch -d. -p0 /soft/src/VDR/PLUGINS/src/xine/patches/xine-lib.patch snip I'm sorry Simon, this one slipped through. I had created the patch differently (and much easier) this time and it therefore contains a different toplevel directory. I've changed INSTALL meanwhile to: patch -dxine-lib -p1 /soft/src/VDR/PLUGINS/src/xine/patches/xine-lib.patch Hope this works, too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Lauri Tischler schrieb: Darren Salt wrote: I demand that Lauri Tischler may or may not have written... Reinhard Nissl wrote: after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: Wonder where can I find keybindings of vdr-xine. It seems that keypadkeys in general work (keypad arrows, keypad enter) but where the hell are colorkeys (red, green, yellow, green) ? Started VDR with -P 'xine -r' They're wherever the rest of the key bindings are for whichever xine-lib front end you happen to be using. Sort of assumed that they would be defined in VDR's remote.conf file, where the Lord intended them to be :) The problem was that xine-ui didn't provide enough keys to cover all VDR functionality. That's why we introduced further VDR specific events. But they are not bound to any key by default. See MANUAL for additional information about the keys. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Reinhard Nissl schrieb: Lauri Tischler schrieb: Darren Salt wrote: I demand that Lauri Tischler may or may not have written... Reinhard Nissl wrote: after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: Wonder where can I find keybindings of vdr-xine. It seems that keypadkeys in general work (keypad arrows, keypad enter) but where the hell are colorkeys (red, green, yellow, green) ? Started VDR with -P 'xine -r' They're wherever the rest of the key bindings are for whichever xine-lib front end you happen to be using. Sort of assumed that they would be defined in VDR's remote.conf file, where the Lord intended them to be :) The problem was that xine-ui didn't provide enough keys to cover all VDR functionality. That's why we introduced further VDR specific events. But they are not bound to any key by default. So it made no sense to go through the remote learning mode if these additional keys had to be bound in xine-ui anyway. See MANUAL for additional information about the keys. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Joerg Riechardt schrieb: I tried with vdr-1.6.0.2 and got messages trying to connect or so, but never a connect. I used the added xine-lib (+ patch) and -ui under Suse 11.1. vdr-xine-0.8.2 works well. As I have no X I use fbxine. Couldn't reproduce this issue. fbxine worked with vdr-1.7.3 and xine-ui with 1.6.0. Thought of an issue (deadlock) with 1.6.0 but discovered later that 1.7.3 was running at the same time, using the same fifos. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-01-12: Version 0.9.0 - Updated INSTALL and MANUAL accordingly. - Fixed several multithreading issues which got triggered on SMP systems (thanks to Edgar (gimli) Hucek for reporting issues and testing fixes). - Added support for VDR-1.7.3 besides TS still pictures. - Pulled patched VDR-1.7.2's remux.[ch] for a quick adaption to to VDR-1.7.3 (thanks to Klaus Schmidinger for his approval). - Fixed PTS handling in xine-lib's FFmpeg decoder for recent FFmpeg versions which should provide better A/V sync now. - Added patch sets to input_vdr.c which allow to omit parts of the MRL, e. g. vdr:// should be sufficient now (thanks to Ludwig Nussel for providing them). - Make use of new OSD functionality in xine-lib-1.2. For now an OSD implementation must provide both new features to have vdr-xine make use of it. - Extended OSD support in xine-lib-1.2 to allow truecolor OSDs as well as hardware scaled OSDs. The new functionality is currently only provided by VDPAU enabled installations. - Added frame grabbing support for accelerated frame formats to xine-lib. Previously, xine-lib exitted the app when frame grabbing was requested for accelerated frame formats like xxmc. You'll now get a green image in that case. Reading back the content of an accelerated frame is currently only provided by VDPAU enabled installations. - Hacked support for VDR-1.7.1's new cDevice::PlayTs() method. - Grab image nolonger needs pnmcut to select the relevant area of the TV image. Besides that, grab image respects the aspect ratio you select in VDR's setup menu, i. e. a 16:9 setup and a 16:9 broadcast will grab you a image without black borders. A mismatch of aspect ratios will add black borders to the image to match the visual impression you get on your TV set. Additionally, the grabbing of field pictures was corrected with regard to color upsampling. - A script mkNoSignal.sh is provided to create custom logos. Just provide PNG files named noSignal16x9*.png (and ...4x3... respectively) and have the tools mentioned in INSTALL in your path. You'll have to move your custom logos then over the default files. - The vdr-xine logo is now available in two aspect ratios (4:3 and 16:9) as more channels provide 16:9 content. Then vdr-xine selects the logo which matches VDR's DVB setup option video format. - Added the ability to detect discontinuities in live TV and to start a new buffering period in such a case. This will help to resume to fluent playback from bad weather conditions or when disconnecting and reattaching the antenna cable. - Updated it_IT.po (thanks to Diego Pierotto for providing the translations). Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
Hi,
according to documentation, cTsToPes::GetPes() shall return a
complete PES packet. The attached diff fixes this.
cDevice::PlayTsAudio() and cDevice::PlayTsSubtitle() have to
return the Length passed as parameter. But cTsToPes::GetPes()
modified this parameter. The attached diff fixes this like for
cDevice::PlayTsVideo().
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.3-orig/device.c 2009-01-06 10:55:13.0 +0100
+++ device.c 2009-01-07 23:25:51.0 +0100
@@ -1288,8 +1288,9 @@ int cDevice::PlayTsAudio(const uchar *Da
for (int Pass = 0; Pass 2; Pass++) {
if (Pass == 0 !PayloadStart) // if no new payload is started, we can always put the packet into the converter
tsToPesAudio.PutTs(Data, Length);
- if (const uchar *p = tsToPesAudio.GetPes(Length)) {
- int w = PlayAudio(p, Length, 0);
+ int l;
+ if (const uchar *p = tsToPesAudio.GetPes(l)) {
+ int w = PlayAudio(p, l, 0);
if (w 0)
tsToPesAudio.Reset();
else if (PayloadStart)
@@ -1306,8 +1307,9 @@ int cDevice::PlayTsSubtitle(const uchar
if (!dvbSubtitleConverter)
dvbSubtitleConverter = new cDvbSubtitleConverter;
tsToPesSubtitle.PutTs(Data, Length);
- if (const uchar *p = tsToPesSubtitle.GetPes(Length)) {
- dvbSubtitleConverter-Convert(p, Length);
+ int l;
+ if (const uchar *p = tsToPesSubtitle.GetPes(l)) {
+ dvbSubtitleConverter-Convert(p, l);
tsToPesSubtitle.Reset();
}
return Length;
--- ../vdr-1.7.3-orig/remux.c 2009-01-06 15:46:21.0 +0100
+++ remux.c 2009-01-07 23:16:54.0 +0100
@@ -559,8 +559,10 @@ const uchar *cTsToPes::GetPes(int Lengt
}
else {
Length = PesLength(data);
-offset = Length; // to make sure we break out in case of garbage data
-return data;
+if (Length = length) {
+ offset = Length; // to make sure we break out in case of garbage data
+ return data;
+ }
}
}
return NULL;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HVR-4000, vdr-1.7.2 and v4l-dvb'hg ?
Hi, Mika Laitio schrieb: BUT there is somewhere bug in the vdr channel tuning because it seems that if I want to watch dvb-s or dvb-s2 channels, I must first tune to correct channel with vdr-1.6.0 or with szap-s2... I do not see such a behavior with stb0899 based TT-3200 here. Arte and ArteHD work out of the box with VDR-1.7.2 using this repository: http://mercurial.intuxication.org/hg/s2-liplianin Sure, had to add 2g flag in stb0899 source though. Before using this repository it was hardly possible to tune to ArteHD. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HVR-4000, vdr-1.7.2 and v4l-dvb'hg ?
Hi, Mika Laitio schrieb: Could you send for verification how you have defined arteHD data in vdr channels.conf? (Just to verify that I do not have there any mistakes) I have it in following way: arte HD;ZDFvision:11361:hC23M16O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra:6230:0:11120:1:1011:0 arte HD;ZDFvision:11361:hC23M16O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra:6230:0:11120:1:1011:0 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HVR-4000, vdr-1.7.2 and v4l-dvb'hg ?
Hi, Gregoire Favre schrieb: it took me some time to find out that my HVR-4000 don't work for DVB-S(2) with vdr-1.7.2. [snip] The card tune well for example with kaffeine to BBC HD. Any idea on how to use it with VDR (dvb-t is of second interest to me) ? Looks like you have to add the 2nd generation flag to your driver. Otherwise, vdr-1.7.2 doesn't assume that your card can do DVB-S2. For stb0899 it looks like this: diff -r 6241895c64f2 linux/drivers/media/dvb/frontends/stb0899_drv.c --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Thu Dec 18 13:07:18 2008 -0200 +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Tue Dec 30 10:06:51 2008 +0100 @@ -1914,6 +1914,7 @@ .caps = FE_CAN_INVERSION_AUTO | FE_CAN_FEC_AUTO | FE_CAN_QPSK +|0x1000 }, .release= stb0899_release, Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] H.264 support for VDR-1.7.2
Hi, attached you'll find an updated patch for VDR-1.7.2. The patch includes the formerly released remux fix. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de vdr-1.7.2-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cTS2PES::write_ipack infinite recursion
Hi,
Andreas Pickart schrieb:
Is there a regular chance for you to reproduce this issue?
I could send you a code fragment then which would store a
reasonably sized fragment of the TS stream which would help me
very much in solving this issue.
It hasn't happened again yet, and I don't think the chance is high that
it will occur again, even during bad reception...
I have extracted the TS data that was passed to cRemux::Put from the
coredump though (24440 bytes, I'll send it to you in a separate, private
mail).
Thanks for your efforts so far.
When I just feed this data to a pristine cRemux instance ('cRemux *remux
= new cRemux(1023, 0, 0, 0, true); remux-Put(data, sizeof data);'), it
doesn't trigger the bug however, so it depends on some state generated
by earlier packets I probably can't access anymore.
When I hack cTS2PES::ts_to_pes to always set done=true; at the start
of the function, write_ipack recurses in a similar fashion, though...
Maybe that helps... if you need earlier TS packets, maybe I could try to
dump them from the ringbuffer...
I would be glad if you could extract that data too ;-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-xine + ffmpeg? (h.264 problems)
Hi, Jelle De Loecker schrieb: I had to remove *-V xvideo --post vdr_video --post vdr_audio --post upmix_mono *or I would not have any sound. (Well, sound would play for a nanosecond and then drop out.) Hhm, I don't think that xine --help lists 'xvideo' near -V. I'm not sure which driver xine uses if it cannot find the specified one -- most likely xv. But removing the -V option would choose xv too, so why is there a difference? Regarding video: Morfsta sent me some samples of BBC HD which are interlaced but have incorrectly set the progressive_frame_flag. Forcing deinterlacing of such scenes with use_progressive_frame_flag=0 improves image quality but the default field order is incorrect which leads to a jumpy replay like that (assuming the correct order would be 1 2 3 4 5 6): 2 1 4 3 6 5 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-xine + ffmpeg? (h.264 problems)
Hi, Jelle De Loecker schrieb: I followed a german tutorial on how to install VDR with xine. It had some patches for better h.264 playback, but when I tune to BBC HD, it's still painfully slow, and the image is quite bad, too! Try to cheat decoding in ~/.xine/config: video.processing.ffmpeg_choose_speed_over_accuracy:1 video.processing.ffmpeg_pp_quality:0 video.processing.ffmpeg_skip_loop_filter:all video.processing.ffmpeg_thread_count:2 Regarding image quality: you'll have to use a deinterlacer xine ... -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=0 Using use_progressive_frame_flag=1 will disable the deinterlacer for progressive images automatically and save some CPU cycles but broadcasters often do not set this flag correctly in the images especially when there is only a little area with heavy movement (e. g. a football). Hence, those images do not get deinterlaced and look awfully. I compiled xine with the ffmpeg option (external ffmpeg or something) but I never installed ffmpeg nor are there any instructions on how to do so. configure ; make ; make install I mean, I could compile ffmpeg eventually, I just need to know if I need to apply any more patches or so ... I installed ffmpeg from the repository, but it doesn't seem to have any effect. Optimize your FFmpeg for your hardware, e. g. ../ffmpeg/configure --prefix=/soft/ffmpeg-video --arch=i686 --cpu=pentium4 --enable-pthreads --enable-shared --enable-gpl --enable-postproc --disable-stripping Similar optimization for xine-lib / xine-ui: CFLAGS='-g3 -O3 -pipe -march=pentium4' ../xine-lib-1.2/configure --prefix=/soft/xine-lib-1.2-video --with-external-ffmpeg --disable-dxr3 CFLAGS='-g3 -O3 -pipe -march=pentium4' ../xine-ui/configure --prefix=/soft/xine-ui-1.2-video --enable-vdr-keys Last but not least: make sure that you use a graphics board which supports hardware color space conversion and image scaling. Use an appropriate output driver, e. g. xine ... -V xv Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] open dvb-s2 channel on Hotbird - Eurosport HD Promo
Hi, Gregoire Favre schrieb: Oh, I alsa can't tune to : EDUSAT;CYFRA +:11278:vC34M2O0S0:S13.0E:27500:164:96=pol:0:0:13005:318:400:0 This channel is on the same transponder as the new HD channels, so it is no longer DVB-S. My VDR has updated this channel and tuning works (as I'm able to watch the HD channels) but it looks like the channel is no longer broadcast on this transponder. Here are the channels which I found in channels.conf on this transponder, but as written above, some of them may no longer be broadcast on this transponder: HBO;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:160:80=pol,81=ORY:507:100:13001:318:400:0 HALLMARK;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:161:84=pol,85=eng:0:100:13002:318:400:0 ANIMAL PLANET;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:162:88=pol,89=eng:0:100:13003:318:400:0 EDUSAT;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:164:96=pol:0:0:13005:318:400:0 EXTREME SPORTS;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:165:100=pol:0:100:13006:318:400:0 NATIONAL GEO;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:166:104=pol,106=hun,105=eng:509:100:13007:318:400:0 ZONE REALITY;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:167:108=pol,109=eng:0:100:13008:318:400:0 HBO2;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:168:112=pol,113=ORY:507:100:13009:318:400:0 CNBC;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:171:120=eng:0:500,100:13012:318:400:0 DISCOVERY;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:172:124=pol,125=eng:0:100:13013:318:400:0 tech 3;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:121=ita:0:0:13031:318:400:0 Music Choice Dance;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:613=A_1,614=A_2,615=A_3,616=A_4,617=A_5,618=A_6:0:100:13041:318:400:0 Music Choice Rock;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:619=A_1,620=A_2,621=A_3,622=A_4,623=A_5,624=A_6:0:100:13042:318:400:0 Music Choice Urban;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:625=A_1,626=A_2,627=A_3,628=A_4,629=A_5,630=A_6:0:100:13043:318:400:0 Music Choice 6;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:620,621,622,623,624:0:500:13082:318:400:0 Music Choice 7;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:625,626,627,628,629,630:0:500:13083:318:400:0 ESPN Classic Sport;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:169:116=pol,117=eng:0:100:13010:318:400:0 MTV TWO;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:170:118=eng:0:100:13011:318:400:0 Music Choice 5;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:613,614,615,616,617,618:0:500:13081:318:400:0 CANAL+ FILM HD;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:360:380=pol;381=ORY:551:100:13021:318:400:0 CANAL+ SPORT HD;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:361:384=pol;385=ORY:551:100:13022:318:400:0 NATIONAL GEO HD;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:362:0;388=pol:0:100:13023:318:400:0 ESP HD Intl;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3202=en2,3201=eng:0:0:13061:318:400:0 HBO HD;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:363:392=pol;393=eng:0:100:13024:318:400:0 ESP HD Turk;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3203=tur:0:500,B00,1803,100:13063:318:400:0 ESP HD Russian;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3204=rus:0:0:13064:318:400:0 ESP HD Dutch;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3205=ndl:0:0:13065:318:400:0 ESP HD Czech;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3206=CZK:0:0:13066:318:400:0 ESP HD German;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3207=deu;3208=deu:0:0:13067:318:400:0 ESP HD Portuguese;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3209=por:0:0:13069:318:400:0 ESP HD Polish;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3210=pol:0:0:13070:318:400:0 ESP HD Hungarian;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3211=hun:0:0:13071:318:400:0 ESP HD Spanish;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:3000:3212=esl:0:500,B00,1803,100:13072:318:400:0 EUSP PL AUDIO;CYFRA +:11278:vC23M5O20S1:S13.0E:27500:0:407=pol:0:0:13035:318:400:0 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.8.0 to 0.8.2 audio sync problems
Hi, Simon Baxter schrieb: I also have consistent audio sync problems on playback. The audio is about 1/4 of a second behind the video. Can this be adjusted out? Try to adjust the A/V offset in xine-ui by pressing the keys M, N or HOME. I'm not sure whether the set offset is persistent. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error decompressing frame for Astra HD+
Hi, Igor schrieb: during watching of Astra HD+ from Astra 19,2E I always have this errors We'll need to clarify what during watching means. See below for details. [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]no frame! ffmpeg_video_dec: error decompressing frame [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]no frame! ffmpeg_video_dec: error decompressing frame 200 frames delivered, 31 frames skipped, 52 frames discarded video_out: throwing away image with pts 120676128 because it's too old (diff : 25806). video_out: throwing away image with pts 120690172 because it's too old (diff : 43300). video_out: throwing away image with pts 120711478 because it's too old (diff : 73586). vdr: osdflush: n: 4, 76.7, timeout: 0, result: 0 video_out: throwing away image with pts 120732839 because it's too old (diff : 104127). I think it's ffmpeg's problem, but I don't know how can I solve it. It seems to me, nobody from ffmpeg-devel list doesn't want to fix it. Has somebody experience with this problem ? The above messages are OK when you switch to this channel because we jump right into the middle of the video stream. So we will see B pictures, which cannot be decoded without it's reference pictures (I or P pictures respectively). Moreover some pictures reference Picture Parameter Sets (PPS) which have been broadcast just before you switched to the channel, so these pictures cannot be decoded too. All those errors should go away from the time on, where an IDR picture is seen in the video stream, as all data up to the next IDR picture will not reference any data structures broadcast before the IDR picture. Let's now come back to the term during watching: As written above, those messages are OK when switching to a channel. When they appear during watching the channel, I could think of VDR having issued a CLEAR as it's buffers ran full for any reason, but your excerpt doesn't show such messages. Last but not least, the broadcast stream could have been buggy. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error decompressing frame for Astra HD+
Hi, Igor schrieb: I'm glad to see you :) Well, I was quite busy at work this week. what about your VDR system ? Have you the same errors ? Well, my P4 2.8 GHz HT system is not powerful enough to play this stream in real time. Hence, I regularly see VDR issue CLEARs after which such messages are normal. btw , I have uploaded one sample from AstraHD with the size 10 MB Astra.pes http://www.zshare.net/download/1179707004348a83/ you can try it As written above, I had to slow down replaying: xine -S slow2 astra.pes#demux:mpeg_pes This only gives me messages for two B pictures, i. e. you're cut VDR recording shows a picture structure like that: IBBP In MPEG2, one (VDR) would have set the broken link flag for such a group of pictures as the B pictures cannot be decoded without a reference picture from the previous GOP. But H.264 doesn't have a broken link flag, so that's why FFmpeg gives messages like the following: [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]no frame! [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]no frame! Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error decompressing frame for Astra HD+
Hi, Igor schrieb: Hence, I regularly see VDR issue CLEARs after which such messages are normal. sorry, what do you mean VDR issue CLEARs ? vdr-xine's console output: video: synced early [vVMA]buffered 8,8 frames (v:25,2, a:8,8) frame: (0, 0)-(1920, 1088), zoom: (1,00, 1,00) buffered 9,3 frames (v:20,4, a:9,3) buffered 10,5 frames (v:25,9, a:10,5) buffered 10,2 frames (v:30,8, a:10,2) Clear(0)DiscontinuityDetected: triggering soft start ! video: synced early [vAV]buffered 8,7 frames (v:28,7, a:8,7) buffered 9,3 frames (v:30,1, a:9,3) buffered 10,5 frames (v:30,5, a:10,5) buffered 7,2 frames (v:28,5, a:7,2) Clear(1)DiscontinuityDetected: triggering soft start ! video: synced early [VA]buffered 8,5 frames (v:21,5, a:8,5) VDR's syslog: May 10 17:31:49 video vdr: [5227] cVideoRepacker: operating in H.264 mode May 10 17:32:01 video vdr: [5228] buffer usage: 70% (tid=5227) May 10 17:32:01 video vdr: [5228] buffer usage: 80% (tid=5227) May 10 17:32:01 video vdr: [5228] buffer usage: 90% (tid=5227) May 10 17:32:01 video vdr: [5228] buffer usage: 100% (tid=5227) May 10 17:32:01 video vdr: [5228] ERROR: 3607 ring buffer overflows (678105 bytes dropped) May 10 17:32:01 video vdr: [5227] clearing transfer buffer to avoid overflows May 10 17:32:02 video vdr: [5228] buffer usage: 0% (tid=5227) xine's output: +++ CLEAR(17a): sync point: 1d ao_flush (loop running: 1) === CLEAR(17.1) === CLEAR(17.2) === CLEAR(17.3) === CLEAR(17.4) === CLEAR(17.5) --- CLEAR(17a) ao_close audio_out: no streams left, closing driver audio discontinuity #80, type is 0, disc_off 0 waiting for in_discontinuity update #80 video discontinuity #80, type is 0, disc_off 0 vpts adjusted with prebuffer to 58459551 +++ CLEAR(17b): sync point: 1d ao_flush (loop running: 1) === CLEAR(17.1) === CLEAR(17.2) === CLEAR(17.3) === CLEAR(17.4) === CLEAR(17.5) --- CLEAR(17b) But H.264 doesn't have a broken link flag, so that's why FFmpeg gives messages like the following: [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error [h264 @ 0xac236490]B picture before any references, skipping [h264 @ 0xac236490]decode_slice_header error so, could you give some resume about this errors ? is it ffmpeg/provider/vdr/driver problem ? or no any problem ? Well, one might consider this an error, but it has no influence on the output. VDR was written for MPEG1/2 and it properly calls cRemux::SetBrokenLink() when necessary, to indicate that the first few B frames shall not be decoded until two reference frames are available. As there is no such flag in H.264, the function doesn't do anything than logging, that it didn't find a MPEG1/2 GOP header where this flag is located. May 10 17:38:16 video vdr: [5430] SetBrokenLink: no GOP header found in video packet Supporting this issue properly in H.264 would mean to not send the first B frames to the output device which is more complex than just setting a single bit. And with the upcoming recording format changes I don't want to address this issue at the moment. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can not view DVB-S2 channels
Hi, can you try this FTA channel, which broadcasts MPEG2 via DVB-S2 at Hotbird 13.0 E: Initial;ITI:11449:hC23M5O35S1:S13.0E:27500:519:0:0:0:15100:318:1300:0 BTW: your syslog excerpt didn't show messages like May 10 18:04:03 video vdr: [6165] cVideoRepacker: switching to MPEG1/2 mode just May 10 18:04:03 video vdr: [6165] cVideoRepacker: operating in MPEG1/2 mode so I assume you didn't specify -l 3 on VDR's command line, or debug messages are logged into a different file by syslog. Please try to provide those log lines too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can not view DVB-S2 channels
Hi, Vangelis Nonas schrieb: When I switch to Initial channel I dont get the channel not available message, however I dont get a picture as well. I believe that this channel is not receivable, at least not at my location. Following is my log when starting vdr with BBC World, then switching to Initial, then back to BBC World (using -l 3): Well, I forgot to mention that the SkyStar HD (TT3200) driver still has an issue regarding tuning this channel. It may take up to several minutes until it successfully tunes to this channel (you'll see several messages like 'frontend 0 timed out while tuning to channel 1860, tp 111449'). BTW: Where do these PMT-SWITCH messages come from? OT: check your LANG and LC_... environment variables. Set LANG to one entry among the list which locale -a outputs and check the values of the other variables by typing locale In case an LC_... variable is not set explicitly, the locale command will print it's default value derived from other variables like LANG, so there is no need to set them unless you want some of them to be different from their default values. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 + xine plugin 0.8.2 - several iisues
Hi, Igor Nikanov schrieb: But if I disconnect from the card the antenna I will have this problem [snip] Apr 27 13:37:32 localhost vdr: [5732] timer 1 (88 1318-1618 '@Das gemütliche Schlafzimmer') set to event Sun 27.04.2008 14:0 Apr 27 13:37:32 localhost vdr: [5732] switching device 1 to channel 88 Apr 27 13:37:32 localhost vdr: [5732] timer 1 (88 1318-1618 '@Das gemütliche Schlafzimmer') start Apr 27 13:37:32 localhost vdr: [5732] Title: 'Das gemütliche Schlafzimmer' Subtitle: '(null)' Apr 27 13:37:32 localhost vdr: [5732] record /video/@Das_gemütliche_Schlafzimmer/2008-04-27.13.18.50.99.rec Apr 27 13:37:32 localhost vdr: [5732] recording to'/video/@Das_gemütliche_Schlafzimmer/2008-04-27.13.18.50.99.rec/003.vdr' [snip] Apr 27 13:38:03 localhost vdr: [5746] ERROR: video data stream broken Apr 27 13:38:03 localhost vdr:[5746] initiating emergency exit Apr 27 13:38:03 localhost vdr: [5732] emergency exit requested - shuttingdown [snip] Apr 27 13:38:06 localhost vdr: [5732] exiting, exit code 1 Apr 27 13:38:06 localhost vdr: [5732] emergency exit! When there is a recording going on and no more data comes in (due to the disconnected antenna cable), then VDR assumes a buggy driver/card, requests an emergency exit which will then reload the driver. In the case where this doesn't fix the problem (i. e. it won't help if you disconnected the antenna cable), VDR will continue to record but still sees no data. The result is, it will again request an emergency exit. This scenario will go on until either the timer(s) get(s) outdated or the signal comes back (by having someone connect the antenna cable again). There has been a discussion regarding pro and cons of emergency exit and the result is that at least from VDR-1.5.18 on you can disable this feature in VDR's setup/miscellaneous menu. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 + xine plugin 0.8.2 - several iisues
Hi, Igor Nikanov schrieb: But if I disconnect from the card the antenna I will have this problem [snip] let's see in the xine output [snip] video_out: throwing away image with pts 96108366 because it's too old (diff : 434402). video_out: throwing away image with pts 96111366 because it's too old (diff : 431402). video_out: throwing away image with pts 96114366 because it's too old (diff : 428402). video_out: throwing away image with pts 96117366 because it's too old (diff : 425402). video_out: throwing away image with pts 96120366 because it's too old (diff : 422402). video_out: throwing away image with pts 96123366 because it's too old (diff : 419402). video_out: throwing away image with pts 96126366 because it's too old (diff : 416402). video_out: throwing away image with pts 96129366 because it's too old (diff : 413402). video_out: throwing away image with pts 96132366 because it's too old (diff : 410402). video_out: throwing away image with pts 96135366 because it's too old (diff : 407402). video_out: throwing away image with pts 96138366 because it's too old (diff : 404402). video_out: throwing away image with pts 96141366 because it's too old (diff : 401531). video_out: throwing away image with pts 96144366 because it's too old (diff : 398630). video_out: throwing away image with pts 96147366 because it's too old (diff : 395630). When you disconnect the antenna cable for a certain amount of time, there will be a gap in presentation time stamps (PTS). This will cause xine to jump over the gap with the result that the previously established buffer will run empty immediately. Any further received images will therefore arrive to late at xine and cause the above messages. Maybe I can find a solution for vdr-xine to detect this issue and reestablish a suitable buffer in this case. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 channell's scan
Hi, Igor Nikanov schrieb: how is it possible to scan dvb-s/s2 channels with vdr 1.7.0 ? Well, there is no explicit scan functionality. When VDR receives a channel (for example when it does an EPG scan for all already known transponders (generated from channels.conf)) and sees a network information table (NIT), it will analyze it and add new channels to channels.conf, when it is allowed to do so. See VDR's setup / dvb menu, update channels = add new transponders. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new parameters for channels.conf in VDR 1.7.0
Hi, Igor Nikanov schrieb: from readme vdr 1.7.0 = Note that the channels.conf file now supports additional parameters, so you may want to make sure you have a backup of this file in case you need to go back to the previous version of VDR! = which difference between this describing ? http://linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf The new parameters are documented in man 5 vdr but the parameter S is missing: S0 = DVB-S S1 = DVB-S2 For DVB-S/S2 the following parameters are new: S, M, O = system, modulation, rolloff For DVB-T the following parameters are new: A, P = alpha, priority By comparing the 1.6.0 man page against the 1.7.0 one, you'll see that a couple of parameters (for example M and C) can have much more values now. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
Hi,
Stefan Lucke schrieb:
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62
(counter is at 8)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA
(counter is at 9)
Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital
compatibility mode - substream id = DA
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA
(counter is at 0)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41
(counter is at 0)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B
(counter is at 1)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6
(counter is at 2)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6
(counter is at 2)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A
(counter is at 3)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B
(counter is at 4)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C
(counter is at 4)
Wondering why the are different substream ids are reported with the same
counter value ;-).
This additional check was suggested by Marco Schlüßler, so maybe he can comment
on this and maybe find out why this is interfering with the pre 1.3.19 Dolby
Digital
detection?
Maybe I should have posted this patch to the list earlier too.
Without the patch, the counter will restart from 0 and prevent
VDR to run in compatibility mode just after VDR was going to
activate compatibility mode.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.18-dvbs2-other/device.c 2008-03-19 22:33:06.0 +0100
+++ device.c 2008-04-06 18:53:53.0 +0200
@@ -1335,6 +1346,7 @@ pre_1_3_19_PrivateStreamDeteced:
if (pre_1_3_19_PrivateStream MIN_PRE_1_3_19_PRIVATESTREAM) {
dsyslog(switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = %02X, SubStreamId);
ClrAvailableTracks();
+pre_1_3_19_PrivateStream = MIN_PRE_1_3_19_PRIVATESTREAM + 1;
goto pre_1_3_19_PrivateStreamDeteced;
}
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 does not compile
Hi,
Helmut Auer schrieb:
dvbdevice.c
dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()':
dvbdevice.c:271: error: 'struct dvbfe_info' has no member named 'delivery'
dvbdevice.c:286: error: 'struct dvbfe_info' has no member named 'delivery'
dvbdevice.c:307: error: 'struct dvbfe_info' has no member named 'delivery'
make: *** [dvbdevice.o] Error 1
The driver I am using ist http://jusst.de/hg/multiproto svn from today,
and the included frontend.h really has no delivery member in this structure.
delivery was removed 5 weeks ago:
http://jusst.de/hg/multiproto/log/46df93f7bcee/linux/include/linux/dvb/frontend.h
The attached patch should make it build.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.7.0-orig/dvbdevice.c ./dvbdevice.c
--- ../vdr-1.7.0-orig/dvbdevice.c 2008-04-13 16:15:35.0 +0200
+++ ./dvbdevice.c 2008-04-13 21:16:45.0 +0200
@@ -266,10 +266,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBS_TUNE_TIMEOUT;
lockTimeout = DVBS_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else if (frontendType DVBFE_DELSYS_DVBC) {
Frontend.delivery = DVBFE_DELSYS_DVBC;
@@ -281,10 +277,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBC_TUNE_TIMEOUT;
lockTimeout = DVBC_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else if (frontendType DVBFE_DELSYS_DVBT) {
Frontend.delivery = DVBFE_DELSYS_DVBT;
@@ -302,15 +294,12 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBT_TUNE_TIMEOUT;
lockTimeout = DVBT_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else {
esyslog(ERROR: attempt to set channel with unknown DVB frontend type);
return false;
}
+ CHECK(ioctl(fd_frontend, DVBFE_SET_DELSYS, Frontend.delivery)); //switch system
if (ioctl(fd_frontend, DVBFE_SET_PARAMS, Frontend) 0) {
esyslog(ERROR: frontend %d: %m, cardIndex);
return false;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Scan found no PIDs (NIT and TID)
Hi, Bikalexander schrieb: When I'm using the scan with option -o vdr I have the problem with some channels into channels.conf. In channels.conf for some of them channels the TID NID pids are missing This shouldn't matter much. I've modified channel 1 in my channels.conf and set NID and TID to 0. When VDR comes across this channel e. g. by an EPG scan or when switching to that channel, VDR will add NID and TID as necessary, as you can see from the following log line: Apr 13 21:25:13 video vdr: [30455] changing id of channel 1 from 0-0-28106-0 to 1-1101-28106-0 BTW: VDR must be allowed to modify channels.conf. You can do that in VDR's DVB setup menu. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.0
Hi,
Klaus Schmidinger schrieb:
This version switches to the multiproto driver and no longer works
with non-multiproto drivers. Hopefully there will soon be *one* driver
source that combines the latest multiproto version with Oliver Endriss'
full ts mod changes ;-).
Thanks to Manu Abraham, the merged repository (for ease of use)
is online now:
http://jusst.de/hg/multiproto_plus
It combines the following repositories:
http://jusst.de/hg/multiproto
http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
Note that this version just implements basic DVB-S2 handling. There is
no support for H.264 etc. yet. This will come in later 1.7.x versions.
To use the above up to date multiproto repositories, you'll
have to apply the attached patch to VDR-1.7.0. Alternatively, you
may want to apply my H.264 patch (see separate email), which
contains the changes for current multiproto too.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.7.0-orig/dvbdevice.c ./dvbdevice.c
--- ../vdr-1.7.0-orig/dvbdevice.c 2008-04-13 16:15:35.0 +0200
+++ ./dvbdevice.c 2008-04-13 21:16:45.0 +0200
@@ -266,10 +266,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBS_TUNE_TIMEOUT;
lockTimeout = DVBS_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else if (frontendType DVBFE_DELSYS_DVBC) {
Frontend.delivery = DVBFE_DELSYS_DVBC;
@@ -281,10 +277,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBC_TUNE_TIMEOUT;
lockTimeout = DVBC_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else if (frontendType DVBFE_DELSYS_DVBT) {
Frontend.delivery = DVBFE_DELSYS_DVBT;
@@ -302,15 +294,12 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBT_TUNE_TIMEOUT;
lockTimeout = DVBT_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, feinfo)); //switch system
}
else {
esyslog(ERROR: attempt to set channel with unknown DVB frontend type);
return false;
}
+ CHECK(ioctl(fd_frontend, DVBFE_SET_DELSYS, Frontend.delivery)); //switch system
if (ioctl(fd_frontend, DVBFE_SET_PARAMS, Frontend) 0) {
esyslog(ERROR: frontend %d: %m, cardIndex);
return false;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] H.264 support for VDR-1.7.0
Hi, attached you'll find an updated patch for VDR-1.7.0. The patch includes now the formerly released addon patches and fixes. Have a look at this page for more instructions on this concern: http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_xine Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] vdr-1.7.0-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Hi, Ian Bates schrieb: Thanks to everyone for their help and suggestions. More welcome too. In vdr-xine's setup menu, you can specify scaling factors for 16:9 and 4:3 images. Scaling 16:9 images by 133 % will fit it into a 4:3 window (e. g. full screen), dropping information on the left and on the right side. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Dominique Simon schrieb: I'd say it's suggested. At least it is part of my H.264 patches. What does the sync early patch do? Vanilla VDR waits for an I frame before it passes video (and audio) data on to output devices. Further more, audio data is still not passed on from that time, because VDR takes some time to decide which audio track shall get selected. The sync early patch addresses these issues. Audio and video packets are passed on a soon as they make up a valid frame. The result is that you can already hear the audio track before the video appears on screen. This is because video decoding can only start with an I frame. Any frames before the I frame won't appear on screen. But passing these frames to the output device has the benefit that PTS' (presentation time stamp) for these frames are passed on to the output device which needs this information to synchronize audio and video. As a result, audio and video will be in sync already when the first image appears on screen. That's why the patch got called sync early. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.18
Hi,
Reinhard Nissl schrieb:
attached you'll find updated patches for VDR-1.5.18.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR
(based on VDR-1.5.14) and requires to use the DVB drivers
from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most
suitable for DVB-C users.
VDR-1.5.14 reported changes to transponder data incorrectly. The
attached dvbs2 patch contains a fix for this issue by introducing
TransponderDataToString().
The patch includes now the formerly addon patch which fixed building
after recent multiproto changes.
The attached addon patch fixes a logic error in
cIteratorImplSourceNidTid. The error caused VDR to skip updating
transponder information for almost all channels.
The error is not related to DVB-S2 nor H.264 but slipped into
these patches at the time when I extended the patches to contain
formerly released speedup patches.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_xine
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.18-dvbs2-other/channels.c 2008-03-19 22:34:14.0 +0100
+++ channels.c 2008-04-01 19:28:45.0 +0200
@@ -1075,8 +1075,8 @@ cIteratorcChannel cChannels::GetChanne
}
virtual void *First(void) { return FindMatchingChannel(false, true); }
virtual void *Last(void) { return FindMatchingChannel(true, true); }
-virtual void *Prev(void) { return FindMatchingChannel(false); }
-virtual void *Next(void) { return FindMatchingChannel(true); }
+virtual void *Prev(void) { return FindMatchingChannel(true); }
+virtual void *Next(void) { return FindMatchingChannel(false); }
virtual void *Current(void) const { return current ? (cChannel *)current-Object() : NULL; }
};
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Did you create H.264 patches for VDR-1.6.0? No. The patches for 1.5.8 should still work. What I recall, 1.6.0 did only complete translation. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-dvd-cvs: deadlock when switching audio channel
Hi, please have a look at the backtraces of the following threads: VDR's main thread: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7f20c1e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7f1ca58 in _L_mutex_lock_86 () from /lib/libpthread.so.0 #3 0xb7f1c47d in __pthread_mutex_lock (mutex=0xa44ceec) at pthread_mutex_lock.c:81 #4 0x0814e111 in cMutex::Lock (this=0xa44ceec) at thread.c:191 #5 0x080c0656 in cThread::Lock (this=0xa44cedc) at thread.h:91 #6 0x0814e14a in cThreadLock::Lock (this=0xbfbeea90, Thread=0xa44cedc) at thread.c:392 #7 0x0814e18e in cThreadLock (this=0xbfbeea90, Thread=0xa44cedc) at thread.c:379 #8 0xb7a9e6d4 in cDvdPlayer::SetAudioTrack (this=0xa44ced0, Type=ttDolby, TrackId=0xa3d1a62) at player-dvd.c:2536 #9 0x080bb367 in cDevice::SetCurrentAudioTrack (this=0xa3d11a0, Type=ttDolby) at device.c:1058 #10 0x080e88d9 in cDisplayTracks::ProcessKey (this=0x88021d8, Key=kAudio) at menu.c:3595 #11 0x080e3773 in cDisplayTracks::Process (Key=kAudio) at menu.c:3545 #12 0x0815dec5 in main (argc=16, argv=0xbfbeef34) at vdr.c:1035 vdr-dvd's DvdPlayer thread: (gdb) bt #0 0x08159ef8 in Watchdog (signum=14) at vdr.c:164 #1 signal handler called #2 0xe40e in __kernel_vsyscall () #3 0xb7f20c1e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #4 0xb7f1ca58 in _L_mutex_lock_86 () from /lib/libpthread.so.0 #5 0xb7f1c47d in __pthread_mutex_lock (mutex=0xa3d224c) at pthread_mutex_lock.c:81 #6 0x0814e111 in cMutex::Lock (this=0xa3d224c) at thread.c:191 #7 0x0814e1e2 in cMutexLock::Lock (this=0xb18f61a0, Mutex=0xa3d224c) at thread.c:366 #8 0x0814e226 in cMutexLock (this=0xb18f61a0, Mutex=0xa3d224c) at thread.c:353 #9 0x080bf264 in cDevice::PlayPesPacket (this=0xa3d11a0, Data=0xafd00690 , Length=2034, VideoOnly=false) at device.c:1274 #10 0x080be564 in cDevice::PlayPes (this=0xa3d11a0, Data=0xafd00690 , Length=2034, VideoOnly=false) at device.c:1410 #11 0x081141f3 in cPlayer::PlayPes (this=0xa44ced0, Data=0xafd00690 , Length=2034, VideoOnly=false) at player.c:29 #12 0xb7a9fdf1 in cDvdPlayer::Action (this=0xa44ced0) at player-dvd.c:730 #13 0x0814de6e in cThread::StartThread (Thread=0xa44cedc) at thread.c:255 #14 0xb7f1a192 in start_thread (arg=0xb18f6b90) at pthread_create.c:296 #15 0xb7cd902e in clone () from /lib/libc.so.6 In frame #9 of VDR's main thread, mutexCurrentAudioTrack get's locked, then in frame #8, cDvbPlayer's thread mutex is to be aquired (LOCK_THREAD). In frame #12 vdr-dvd's DvdPlayer thread locked it's mutex (LOCK_THREAD), then in frame #9, mutexCurrentAudioTrack is to be aquired. As both threads lock the same mutexes in opposite order a deadlock occurs. As I'm not used to vdr-dvd development, I would be glad if someone could provide a fix for this issue. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine - screen size and resolution
Hi, serge pecher schrieb: I am making some test with vdr-xine 0.8.2, libxine en xine-ui from Reinhard’s site (kubuntu 7.10) It is on a laptop without dvb device. For the moment I just try to replay recordings from an other vdr box, and dvd with dvdswitch. I use a Sony bravia 32” TV screen connected at the vga output of the laptop. The resolution configured in xorg.conf is 1280x720. I achieve to have the “no-signal” in full screen. When I replay recordings, most of them are with wide black bands left right and for some of them also small bands updown. Some recordings (most movies) have wide bands on the four sides. The most dvd’s also have wide bands LR. One of them plays in full screen but the image is stretched. I was playing around with some settings of the plugin, but don’t see how to get a good result. In the past I made some test, I believed, with vdr-xine (or maybe xineliboutput ?), and I can remember something in the settings that achieved auto-scaling. I had at that time almost everything in full screen, but sometimes also with wrong stretching. I tried to start xine, just by typing xine in a terminal box and choosinf “vdr” and I also tried xine -V xv --post vdr_video --post vdr_audio --post upmix_mono vdr:/tmp/vdr-xine/stream#demux:mpeg_pes, but can’t really see a difference. As I understand, I have different sources, with different resolutions. Is there a manner to tell vdr-xine or xine to adapt the output as good as possible to my tv screen ? Please give the test-*.mpg files a try: http://home.vrweb.de/~rnissl/radio/ Add the option -l to xine's commandline to have it play the file endlessly. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
