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 : 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] [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
[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] [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
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] [ANNOUNCE] VDR developer version 1.7.21
Hi, Am 09.09.2011 16:54, schrieb Klaus Schmidinger: Since you're saying that the problem is related to the dxr3 plugin I guess I won't see any error with my TT-S2 6400. I switch to 1.7.21 from 1.7.17 and see that teletext subtitles appear now for example on Das Erste HD. No matter which OSD size I setup in vdr-xine (e. g. 720x576, 1280x720 or 1920x1080), the subtitles are never positioned correctly and vdr-xine complains very often like that: vdr-xine: new OSD(-152, 0) requested with coordinates out of range Do these subtitles work correctly on your TT-S2 6400? Which OSD size do you use on your TT-S2 6400? 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] Fix for recording problem in VDR 1.7.20
Hi,
Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
Apparently in this file every TS packet that starts a new PES packet
has the "Payload Unit Start Indicator" flag set. Normally (AFAIK)
this
should only be set for TS packets that contain the beginning of an
actual payload unit (which may consist of several PES packets).
So I would assume that the TS data is in error.
I don't think that this assumption is correct. The playload start
is related to carried payload only, i. e. PES packets in case of
the video stream. And it would be sufficient to put there just a
single byte of the PES packet to set this bit, i. e. the first
0x00 of the start code sequence 0x00, 0x00, 0x01. Furthermore it
is specified that no second PES packet is allowed to start in the
same TS packet.
The PES layer itself has no access unit (= e. g. image) start
indicator. But when a PTS is part of the PES header, it has to be
applied to the first access unit (= e. g. image) which starts in
that PES packet (once again, it would be sufficient to put there
just the first byte of the start code sequence at the tail of the
PES packet). So you may use the PTS flag as Access Unit Start
Indicator ("AUSI"), which tells you that this PES packet will
start a new image but you cannot tell where, i. e. it is likely
that the PES packet will carry the tail of the previous image in
front of the new image. Using the "AUSI" is only of hint quality
as not every access unit (= e. g. image) will have a PTS
attached. Some stations label only I frames while others label
every frame or field.
In video streams, it is common use to have PES packets with a
zero length indicator which means the TS layer has to tell you
where the next PES packet starts. So such streams are likely to
have just a single PES packet per access unit (= e. g. image) and
as a result you see the TS PUSI at the same time as the PES "AUSI".
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
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
[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 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
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 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 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 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.de&forum_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] patch for crypted teletext pids
Hi, Am 09.09.2010 15:30, schrieb michael_kap...@inode.at: > I have had a problem watching the teletext on the crypted channels "ORF1 > HD" and "ORF2 HD" ... after doing some research on the web, i found out > that these two channels not only crypt their audio and video streams, but > also the teletext. (as far as I know, not even Sky/Premiere crypt their > teletext) Not that I have an usecase for this already, but what about scrambled DVB subtitles? Shouldn't those PIDs be sent to the CAM 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] 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 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
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
Am 17.03.2010 07:23, schrieb Torgeir Veimo: > On 14 March 2010 21:47, Reinhard Nissl 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] vdr-1.7.14 -> xineliboutput Rewind and Fast Forward problems in ts recordings
Hi, Am 14.03.2010 15:40, schrieb Halim Sahin: > The problem is the playback stopps after fwd/rev > the osd shows wrong position and sometimes the frontend vdr-sxfe hangs. > Tested with recordings from german pro Sieben. > The problem doesn't occour with old pes recordings. > > Q: can someone reproduce the problem? > Maybe it's related to my setup. > I am using unpatched versions of vdr and xineliboutput! > xineliboutput is the git version from vdr-developer (today's checkout). Do you use vdpau? I have got similar reports which only appear with vdpau and h264. There is no problem when using ffmpeg as decoder. It looks like vdpau h264 decoder leaks some images. 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] 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] 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] H264 syncearly patch
Hi, Am 14.02.2010 23:49, schrieb Rob Davis: > I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput > plug with a Hauppauge-PVR-HD. > With 1.6.0 and the h264-syncearly patch I got a nice picture but no > audio.. > > With 1.7.12 I can get audio but no picture. I thought h264 support was > built in already to 1.7.12, but I maybe wrong. If not, where can I find > an up to date patch for this? > > The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly.. In 1.6.x, cVideoRepacker was responsible to detect H.264 vs. MPEG2 (cannot tell why audio doesn't work in your case). In 1.7.x, cChannel provides this information (vtype). So it looks like pvrinput doesn't provide the information or channels in a way that vtype gets set to H.264. 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: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.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.11 (+ vdr-xine) segfaults
Hi,
Am 27.01.2010 06:26, schrieb Jouni Karvo:
> A quick google did not tell me how to enable thread numbers in the log.
> Is it a specific library package to be installed or is it some certain
> kernel option?
Edit VDR's thread.c and replace method cThread::ThreadId() with
the below version:
tThreadId cThread::ThreadId(void)
{
tThreadId tid = syscall(__NR_gettid);
if (tid == -1)
esyslog("ERROR: retrieving thread ID failed: [%d] %s", tid,
strerror(tid));
return tid;
}
Please report the logged error message.
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.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] FF/RW problems with xine
Hi, Timothy D. Lenz schrieb: > With some recordings FF/RW doesn't work correctly. The video/audio stops and > when you hit play again, it has moved to the new a new > location. Some recordings work, some don't. May have to do with some channels > use 720p and others use 1080i You had provided me a sample recording for a different issue. But that recording shows that the index entries for I frames are off by 1 TS packet most of the time. That's why FF/RW don't work properly as only I frames get transferred to the output device in that case. And with the first TS packet missing, the I frames cannot get decoded. I reported that issue to Klaus but -- to keep it simple -- he expects a patch to 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
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] Truecolor osd and speed.
Hi, Udo Richter schrieb: > On 13.06.2009 17:31, VDR User wrote: >> "VDR renders its OSD into an array (of 8 bit indexes into a palette right >> now, and of full 24(rgb)+8(alpha) bit color values for truecolor) >> and its up to the device implementation how it transfers that array (or >> parts of it) to the actual display hard- or software." > > To keep compatibility and to be less limited for a new OSD architecture, > I would strongly suggest to keep the current OSD as it is, and introduce > a secondary OSD2 interface for true color display. > > From the performance point of view, would it be possible to directly > render OSD into the graphics memory instead of copying an (possibly > 1920x1200x32 = 9Mb) memory OSD to the surface? > > However, this depends on how close this could be adapted by the > different platforms. How do eHD and VDPAU handle transparent overlays at > all? Are they merged with the video in software? Are they overlays that > get displayed in hardware? Would page flipping be possible? In VDPAU you have several layers (up to 4 at the moment) for video and OSD for example. All layers are independent of resolution, color space and color depth. For each layer you can define source and destination rectangles witch align the layers to the output rectangle. All scaling and blending operations are done by the hardware. Think of several OpenGL objects, so page flipping should be possible. vdr-xine transfers only the dirty rectangle of the OSD to xine (via pipe or socket), but the initial display of an OSD with the above mentioned dimensions would indeed need to transfer 9 Mb from VDR to xine. BTW: an issue regarding dirty rectangle and text rendering: wiping the background makes the area dirty even when continuously rendering the same text which actually doesn't change anything. 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] Truecolor osd and speed.
Hi, Klaus Schmidinger schrieb: > On 06/13/09 17:31, VDR User wrote: >> Some questions have come up about how to have a high resolution/color >> osd without having to sacrifice the speed of the osd. VDPAU users >> have noticed that when using a high resolution theme in yaepghd, it >> can take 5+ seconds for the osd itself to even be displayed. >> >> Per Klaus, VDR's position is this: >> "VDR renders its OSD into an array (of 8 bit indexes into a palette right >> now, and of full 24(rgb)+8(alpha) bit color values for truecolor) >> and its up to the device implementation how it transfers that array (or >> parts of it) to the actual display hard- or software." >> >> Some suggestions by Rnissl have been: >> -Similar way the eHD handles it > > Can you (or somebody else) summarize in a few words what special > handling the eHD does? I cannot tell, what these OSD function do internally, but it looks to me like they are meant to avoid copying large memory blocks to the eHD over and over: virtual void SetImagePath(u_int imageId, char const *path); virtual void DrawImage(u_int imageId, int x, int y, bool blend, int horRepeat = 1, int vertRepeat = 1); >> -Allow osd areas to overlap and put such images into separate areas > > I was aiming at having just one big area. The various areas that are > used now are just a makeshift solution for the low memory that was > available on the FF DVB cards. I would expect a "modern" hardware > to have enough memory to handle a full screen, 32 bit OSD. VDR 1.2.x could have overlapping windows and my vdr-xine supports it. For convenience, I've implemented VDR 1.3.x tAreas the same way. The idea is to put a background image into one window and the displayed text into another one (which appears is in front of the other), the window with the background image isn't changed while moving through the text. Think of layers. >> -Extend the osd api for scroll commands > > Ok, that sounds like a good thing to do. VDR would still draw into > its local OSD memory and do the scrolling there, but would not need > to actually send the entire scrolled area over to the hardware and > instead tell the hardware to perform exacly the same scrolling in its > copy of the OSD memory. In case a fancy OSD implementation puts a background image behind the OSD text, scrolling in the above sense doesn't is no benefit without separate layers for foreground and background. 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.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] 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] 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] 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.de&forum_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:
> 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_duration>2500 ) {
+ if ( frame->format==XINE_IMGFMT_VDPAU && this->deinterlace && non_progressive /* && stream_speed */ && frame_duration>2500 ) {
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] vdr-xine-0.9.2 plugin does not support cutting.
Hi,
Carsten Koch schrieb:
> I noticed, however, that it is extremely hard to use VDRs
> cutting function with it.
>
> For example, when I use the '7' and '9' keys to jump to the
> previous/next cut mark, or when I use the '4' and '6' keys to
> fine-position a cut mark, the video image is not updated, so I
> am basically forced to navigate in complete darkness.
>
> Is that a known bug?
Well, yes, but I didn't find time to look into a sample till
tonight. Please find attached the fix, at least for the sample I
was working with.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.2/xineDevice.c 2009-05-03 20:56:36.0 +0200
+++ xineDevice.c 2009-05-27 23:46:36.0 +0200
@@ -1258,6 +1258,8 @@ if (0)
FILE *ff = fopen("/tmp/still.ts", "wb");
fwrite(tsData, 1, tsLength, ff);
fwrite(tsTail, 1, TS_SIZE, ff);
+fclose(ff);
+}
vRemux->Put(tsTail, TS_SIZE);
@@ -1270,8 +1272,6 @@ fwrite(tsTail, 1, TS_SIZE, ff);
vRemux->Del(n);
}
-fclose(ff);
-}
if (0)
{
FILE *ff = fopen("/tmp/still.pes", "wb");
___
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: >> >> >> 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] 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
[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
Re: [vdr] xine for vdr-0.7.4 doesn't patch
Hi, Simon Baxter schrieb: > My point exactly - > from INSTALL: > > 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 > 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, 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, 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, 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
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Matthias Dahl schrieb: > I guess it's >= 1.7.3 only because I gave it a quick whirl with vdr 1.7.2 and > all I got were lot's of errors like: Well, vdr-xine-0.9.0 should be compatible till VDR-1.2.x. But VDR-1.7.1 and 1.7.2 miss an adapted APIVERSNUM so vdr-xine-0.9.0 assumes that there is no PlayTS(). Please change APIVERSNUM to 10701 in VDR's config.h 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] [ANNOUNCE] VDR developer version 1.7.2
Hi,
APIVERSION should have been changed to 1.7.1 at release 1.7.1
already as it introduced cDevice::PlayTs() and vdr-xine-0.9.0
relies on APIVERSION >= 10701 to support vdr-1.7.2.
When switching from a TV channel to a radio channel, vpid isn't
reset in cPatPmtParser and hence, vdr-xine-0.9.0 waits for video
frames to arrive which will not happen. As a result, one won't
hear anything from the radio channel until restarting VDR.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- vdr-1.7.2-orig/config.h 2008-09-14 15:46:13.0 +0200
+++ vdr-1.7.2-patched/config.h 2009-01-06 13:26:40.0 +0100
@@ -27,8 +27,8 @@
// The plugin API's version number:
-#define APIVERSION "1.7.0"
-#define APIVERSNUM 10700 // Version * 1 + Major * 100 + Minor
+#define APIVERSION "1.7.1"
+#define APIVERSNUM 10701 // Version * 1 + Major * 100 + Minor
// When loading plugins, VDR searches them by their APIVERSION, which
// may be smaller than VDRVERSION in case there have been no changes to
--- vdr-1.7.2-orig/remux.c 2008-12-13 15:30:15.0 +0100
+++ vdr-1.7.2-patched/remux.c 2009-01-06 13:20:40.0 +0100
@@ -2467,6 +3211,7 @@ void cPatPmtParser::ParsePmt(const uchar
int NumApids = 0;
int NumDpids = 0;
int NumSpids = 0;
+ vpid = vtype = 0;
SI::PMT::Stream stream;
for (SI::Loop::Iterator it; Pmt.streamLoop.getNext(stream, it); ) {
dbgpatpmt(" stream type = %02X, pid = %d", stream.getStreamType(), stream.getPid());
___
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, 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, 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,
Reinhard Nissl 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 ;-)
Please find attached the patch (should be compatible with 1.6.x
and 1.7.0) which fixes this issue.
The problem was, that "done" was set to true but not reset with
the next PES packet. Typically this is done when found reaches
plength + 6, or when found was at least 6. But in this case,
found was just 4 as the PES packet started near the end of an TS
packet. Then some TS packets were missing and the next one
started a new PES packet. But only found was reset to 0 while
done got stuck at true. Later on, this caused write_ipack() calls
with mpeg still being 0. In this case, send_ipack() didn't reset
count so that the recursive call to write_ipack() parsed ancient
data, leading to incorrect breakAt locations which made bite
negative. As a result, the recursive calls stepped forward and
backward on the same data forever.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.0-patched/remux.c 2008-02-24 19:14:45.0 +0100
+++ remux.c 2008-12-17 00:33:16.0 +0100
@@ -2430,9 +2451,8 @@ void cTS2PES::ts_to_pes(const uint8_t *B
dsyslog("PES packet shortened to %d bytes (expected: %d bytes)", found, plength + 6);
plength = found - 6;
send_ipack();
-reset_ipack();
}
- found = 0;
+ reset_ipack();
}
uint8_t off = 0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.2 + h264-patch + xineliboutput + vdr-xine + softdevice
Hi, Goga777 schrieb: > Dears developers of such nice these plugins/patch > > are you planing to adapt your plugins to vdr 172 ? Will someone release h264 > patch for vdr 172 ? Looks like I'm back to VDR development, but I cannot tell any schedules for patches 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] 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] Falsche PTS im PES-Stream beim Spulen in Videoaufnahmen
Hi, Matthias Bauer schrieb: > Das ist mein erstes Mail an diese Liste. Discussions on this list should be in English. Please keep this in mind when replying. > Ich habe meine Frage vor ein paar Tagen ins vdr-portal gestellt, aber > leider keine Antwort erhalten > > (http://www.vdr-portal.de/board/thread.php?threadid=82350) > > Wahrscheinlich wurde sie von den richtigen Leuten, die das auch > beantworten könnten, nicht gesehen. Darum probiere ich mein Glück > jetzt mal hier: > > > > Ich habe das Plugin für den VLC-Player als Streaming-Client vom > ffnetdef-Plugin geschrieben. > > Leider hat der VLC-Player ein Problem mit dem Stream von VDR- > Aufnahmen, sobald man anfängt zu spulen. Im Log steht dann, dass der > Stream falsche PTS (Presentation Time Stamps) hat. > > Ich habe in den Sourcecode von VDR und vom ffnetdev-Plugin > reingeschaut, und wenn ich alles richtig verstanden habe, werden die > PTS unverändert aus der Aufnahme an das ffnetdev-Plugin übergeben und > dort unverändert ins Netz gestreamt. > > Sobald man nun anfängt zu spulen, stimmen die PTS dann nicht mehr, > weil sie beim Vorwärtsspulen viel zu schnell ansteigen und beim > Rückwärtsspulen sogar rückwärts laufen. > > Beim Abspielen von Videoaufnahmen müssten die PTS eigentlich schön > fortlaufend kommen, egal, ob normal wiedergegeben oder gespult wird. > > Da das ffnetdev-Plugin dem Stream nicht ansieht, ob es Live-TV oder > eine Aufnahme ist, müsste das Patchen der PTS eigentlich der VDR machen. > > Was meint Ihr dazu? I came across the same issue when I coded vdr-xine. My understanding of FF-cards is that they use PTS only to synchronize audio and video streams, and not to determine the absolute replay time. As a result the frames are simply output one after another according to their coded display duration. When VDR uses fast forward for example, it simply drops all frames other than I frames and programs the FF-card to repeat the I frames for a certain number of times to emulate different speeds although the number of coded frames doesn't change. It furthermore deactivates PTS synchronisation as audio shall be suppressed at all during trick modes. As you wrote above, dropping all frames besides I frames will cause PTS to rise faster than a player would expect by adding a frame's duration to its last known PTS, as roughly 11 to 14 frame durations are missing between two I frames in this case. In vdr-xine I've solved the issue by removing the PTS/DTS flags in the PES headers and overwriting the PTS/DTS storage location by the padding byte 0xFF when VDR was replaying in trickspeed mode. In that way I didn't have to mangle the PES packet any further. I think that this manipulation could be done by VDR generally and shouldn't cause any problems on FF-cards. Another idea: if you have a look into the MPEG docs, you'll find a possibility to indicate trick modes in PES packets, and if I recall correctly, it should be possible by just setting a single bit. But I could be wrong and then it would be more complex than the approach in the previous paragraph. 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] cTS2PES::write_ipack infinite recursion
Hi, Andreas Pickart schrieb: > VDR (1.6.0-2) crashed after stuffing the syslog with: > vdr: [24126] ERROR: possible result buffer overflow, dropped 13 out of > 13 byte > vdr: [24126] ERROR: possible result buffer overflow, dropped 2048 out of > 2048 byte > > A backtrace shows that the function cTS2PES::write_ipack (initially > called from cTS2PES::instant_repack with Count=184) kept calling itself > (from then on with Count=180 and the same "Data" pointer all the time). > The variable "bite" was 4 on the first call and then 0 on all succeeding > ones. > It was a video pid being extracted, so the cVideoRepacker got called, > and I suspect its "breakAt" return value lead to the "// should never > happen" code that set "bite" to 0. > > Some state information from the cTS2PES instance: > pid=1023 size=2052 found=2200 count=2052 > cid=224 rewriteCid=224 subStreamId=0 > plength=4194234 plen[0]=98 plen[1]=124 flag1=flag2=0 hlength=0 mpeg=0 > check=0 mpeg1_required=mpeg1_stuffing=0 > done=true > tsErrors=2020124 ccErrors=697951 > ccCounter=8 > > The high error counts obviously show that the received data (from DVB-S) > was somehow defective (There were many "PES packet shortened" errors > earlier), but ideally VDR shouldn't crash even when the data is broken... > > Can anyone please fix this issue? 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. 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] 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] 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] 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] 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: > 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] 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
