Re: [vdr] [ANNOUNCE] VDR developer version 1.7.28
On 03.06.2012 14:41, Klaus Schmidinger wrote: On 03.06.2012 14:26, Wolfgang Rohdewald wrote: Am Sonntag, 3. Juni 2012, 12:44:24 schrieb Klaus Schmidinger: VDR developer version 1.7.28 is now available so I untarred the full archive into a new place and copied my old working Make.config timers.c: In constructor ‘cSortedTimers::cSortedTimers()’: timers.c:832: error: class ‘cSortedTimers’ does not have any field named ‘cVector’ I don't get such an error message here. g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\/var/run/lirc/lircd\ -D_GNU_SOURCE -DVIDEODIR=\/video\ -DCONFDIR=\/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 transfer.c timers.c: In constructor »cSortedTimers::cSortedTimers()«: timers.c:832: Fehler: Klasse »cSortedTimers« hat keinen Feldnamen »cVector« make: *** [timers.o] Fehler 1 make: *** Warte auf noch nicht beendete Prozesse... Same error here :-( . stefan@jarada /home/nfs/extra/src/video/DVB/vdr-1.7.28.jarada $ g++ --version g++ (Gentoo 4.4.5 p1.3, pie-0.4.5) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.28
On 03.06.2012 14:54, Udo Richter wrote: timers.c: In constructor ‘cSortedTimers::cSortedTimers()’: timers.c:832: error: class ‘cSortedTimers’ does not have any field named ‘cVector’ I don't get such an error message here. May be a compiler dependent problem. The attached patch makes it work for me. Patch works for me too, thanks. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 dvb-t channel mismatch
On Saturday 21 August 2010, L. Hanisch wrote: Hi, Am 21.08.2010 22:06, schrieb Stefan Lucke: reststarting my vdr activities I went into trouble with dvb-t channels.conf for Berlin. Just took the channels from: http://www.vdr-wiki.de/wiki/index.php/Channels.conf_DVBT-De-Berlin-Brandenburg There is the following entry for ARTE: arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:0:0 I was able to tune and watch tv on this channel, but there was no EPG available. VDR created the following new entry in channels.conf: arte;ARD:19150:B7C23D12G8M16T8Y0:T:0:0:0:0:0:2:8468:257:0 Tuning to this VDR generated channel shows now the EPG information, but no video and no sound :-(. What happens with this entry (adding the TID of the vdr-generated entry): arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:257:0 Thanks that brings EPG data to already present channels entry. Neither NID nor TID are shown while editing those entries, so I could not see a difference. Looking at NID I guess it plays it's role too. From epg.data: C T-8468-257-2 arte -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 dvb-t channel mismatch
On Sunday 22 August 2010, L. Hanisch wrote: Hi, Am 22.08.2010 10:35, schrieb Stefan Lucke: What happens with this entry (adding the TID of the vdr-generated entry): arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:257:0 Thanks that brings EPG data to already present channels entry. Neither NID nor TID are shown while editing those entries, so I could not see a difference. Looking at NID I guess it plays it's role too. From epg.data: C T-8468-257-2 arte The elements of the channel identifier are Source-NID-TID-SID. If you can't edit them in the OSD, stop your vdr and edit the channels.conf with an editor. The last four digits of the entry are SID:NID:TID:RID. - http://www.vdr-wiki.de/wiki/index.php/Channels.conf Thanks, but VDR is semi prepared for the fix. In file menu.c (line ~248) NID, TID and RID menuitems are commented out ;-) . So now I can delete the new entry first and set the TID of existing entry :-) to the correct value. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.15 dvb-t channel mismatch
Hi, reststarting my vdr activities I went into trouble with dvb-t channels.conf for Berlin. Just took the channels from: http://www.vdr-wiki.de/wiki/index.php/Channels.conf_DVBT-De-Berlin-Brandenburg There is the following entry for ARTE: arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:0:0 I was able to tune and watch tv on this channel, but there was no EPG available. VDR created the following new entry in channels.conf: arte;ARD:19150:B7C23D12G8M16T8Y0:T:0:0:0:0:0:2:8468:257:0 Tuning to this VDR generated channel shows now the EPG information, but no video and no sound :-(. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] softdevice+mplayer-plugin
On Sunday 22 March 2009, ua0lnj wrote: Hi This patch allows correct work of mplayer-plugin with softdevice from cvs. Otherwise softdevice lock output resources, and mplayer can't play (for example no audio for me). Thanks, if thats so simple... some action on: pmExtern_THIS_SHOULD_BE_AVOIDED. I'll apply this patch to cvs. If you like another name than ua0lnj being mentioned in README, please send me your real name. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: local variables limited in size to (8*1024*1024-32*1024) bytes ?
Hi,
the attached program segfaults when using a larger local variable.
Depending on used value I get segfaulst at different locations.
//#define BUFSIZE (9*1024*1024-16*1024) // only segfault
#define BUFSIZE (8*1024*1024-16*1024) // hello + segfault
//#define BUFSIZE (8*1024*1024-32*1024) // hello + 2nd line
When using last definition of BUFSIZE every thing is fine.
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ ./test
Speicherzugriffsfehler
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ vi test.cc
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ g++ -g test.cc -o
test
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ ./test
hello
./test: argc = 1
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ vi test.cc
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ g++ -g test.cc -o
test
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ ./test
hello
Speicherzugriffsfehler
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ ./test
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ ulimit
unlimited
[EMAIL PROTECTED] /home/nfs/extra/src/video/DVB/xlist $ gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1)
Copyright (C) 2006 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
--
Stefan Lucke
#include errno.h
#include fcntl.h
#include netinet/in.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
//XXX #define BUFSIZE 256*1024
//
//#define BUFSIZE 20*1024*1024
//#define BUFSIZE (9*1024*1024-16*1024) // only segfault
#define BUFSIZE (8*1024*1024-16*1024) // hello + segfault
//#define BUFSIZE (8*1024*1024-32*1024) // hello + 2nd line
#define DUMP 1
#ifdef DUMP
#define DBG(expr) expr;
#else
#define DBG(expr) {}
#endif
typedef unsigned long tPTS;
int main(int argc, char *argv[])
{
fprintf(stderr, hello\n);
fprintf(stderr, %s: argc = %d\n, argv[0], argc);
{
unsigned char a [BUFSIZE];
}
return 1;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Monday 24 November 2008, Stefan Lucke wrote: Hi, using vdr-1.7.1 patched for S2API with vdr-1.7.1-s2api-07102008-vanilla.patch and DVB drivers from yesterday (via: hg clone http://linuxtv.org/hg/v4l-dvb). I've the following issues (tuned to ZDF): - playing with softdevice there is no video, but audio and subtile work. - dumping the data I got via PlayVideo() to a file neither ffplay nor mplayer can identify stream info from dumped data. But Xine can play PES dumped via PlayVideo(). There are a few visible decoding errors. whereas Xine has no problems decoding the TS stream dumped at the same time. If some with TS/PES stream knowledge wants to look at: http://www.lucke.in-berlin.de/test_streams/ vdr-171.zz.PES vdr-171.zzz.TS -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Tuesday 25 November 2008, Frank Schmirler wrote: On Mon, 24 Nov 2008 17:42:28 +0100, Stefan Lucke wrote On Monday 24 November 2008, Frank Schmirler wrote: Unless I've overlooked some section repacker somewhere, there's a bug in cPatPmtGenerator. I've already sent the attached patch to Klaus, but he didn't have time to look at it yet. Thanks, but things went worse with that on my system: audio disappeared and nothing more to dump in PlayVideo() :-( . Problem seems to be that my patch fixes the generator, but the same mistake is made while parsing the TS packet. I attached an extended patch which fixes parsing, too. According to the dumps you sent me (thanks!), vdr-1.7.1 cPatPmtGenerator *is* broken. Sorry, but this version does not help much. Without patch ffplay mplayer can play dumped TS packets. With patch mplayer plays fine whereas ffplay only plays audio (no video), and softdevice only has some audible clicks. My main concern is that softdevice PlayTs*() never gets called and while writing these lines, I found the typo PlayTS vs PlayTs. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Monday 24 November 2008, Frank Schmirler wrote: On Mon, 24 Nov 2008 14:41:44 +0100, Stefan Lucke wrote - dumping the data I got via PlayVideo() to a file neither ffplay nor mplayer can identify stream info from dumped data. Unless I've overlooked some section repacker somewhere, there's a bug in cPatPmtGenerator. I've already sent the attached patch to Klaus, but he didn't have time to look at it yet. Thanks, but things went worse with that on my system: audio disappeared and nothing more to dump in PlayVideo() :-( . -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] black screen with softdevice 0.5.0 and vdr 1.6
Quoting Leo Márquez: Hi, I am trying to set up a vdr with softdevice 0.5.0 (dfb) and vdr 1.6. Vdr and softdevice compile fine but when I start vdr I get osd and audio and no video. The channels I want to see are dvb-t, no hd. I did not see any error in logs. I remember have this problem few time ago but any mailing list or google search helped me to remember what is the problem and the solution. Does your nvidia card works with X11 ? What's the exact model name ? I ask this because there were e few reports about a missing BES (back end scaler) in some newer cards. Thank you!. I put here the vdr output to help you know what is happening: vdr:/usr/src/vdr16# ./vdr -c /etc/vdr -v /videoteca/v0 -Psoftdevice -vo dfb: [snip] [setup-softdevice] setting alpha blend mode to software [softdevice] picture mirroring set to 0 (off) [setup-softdevice] pixel format set to (I420) Can you try to change the choosen pixel format via OSD ? [setup-softdevice] shouldSuspend to: 0 [setup-softdevice] syncTimerMode: sig [softdevice] UseSetSourceRectangle to off [softdevice] UseStretchBlitset to off Please try to change StrechBlit setting via OSD. [setup-softdevice] vidBrightness: -1 [setup-softdevice] vidContrast: -1 [setup-softdevice] vidHue: -1 [setup-softdevice] vidSaturation: -1 These are currently not changeable. Require some code modifications to softdevice. [snip] (*) DirectFB/Genefx: MMX detected and enabled (*) DirectFB/Graphics: nVidia NV02 (0x002d) 0.6 (directfb.org) (*) DirectFB/Core/WM: Default 0.2 (Convergence GmbH) [dfb] RAM: 32505600 bytes [dfb] Accellerated Functions: FillRectange DrawRectange DrawLine FillTriangle Blit StretchBlit All [dfb] Drawing Flags: Blend [dfb] Surface Blitting Flags: BlendAlpha BlendColorAlpha Colorize Deinterlace 23:33:23.0176 I [5033] [dfb] Supported video Modes are: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]@8 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]@8 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 23:33:23.0178 I [5033] [dfb] Enumerating display Layers 23:33:23.0179 I [5033] [dfb] Configuring CooperativeLevel for OSD Layer 0 FBDev Primary Layer Type: graphics Caps: brightness contrast saturation surface Layer 1 NVidia Overlay Type: picture video Caps: brightness contrast deinterlacing dst_colorkey hue saturation screen_location surface 23:33:23.0180 I [5033] [dfb] (osdLayer): flags, options, pixelformat: 000f, 00400c03 23:33:23.0181 I [5033] [dfb] (osdLayer): width, height: 768 576 23:33:23.0181 I [5033] [dfb] osdLayer without !! alpha channel 23:33:23.0188 D [5033] [dfb] surface capabilities for (scrSurface): videoonly, double-buffered, flipping, PixelFormat = 0x00418c04 23:33:23.0189 I [5033] [dfb] width = 768, height = 576 23:33:23.0189 I [5033] [dfb] got fmt = 0x00418c04 bpp = 32 23:33:23.0192 I [5033] [dfb] Using this layer for OSD: (FBDev Primary Layer - [768x576]) 23:33:23.0192 D [5033] [dfb] surface capabilities for (osdSurface): videoonly, double-buffered, flipping, PixelFormat = 0x00418c04 23:33:23.0192 I [5033] [dfb] Configuring CooperativeLevel for Overlay 23:33:23.0201 D [5033] [dfb] surface capabilities for (videoSurface): videoonly, PixelFormat = 0x00200806 23:33:23.0201 I [5033] [dfb] Using this layer for OSD:FBDev Primary Layer 23:33:23.0202 I [5033] [dfb] Using this layer for Video out: NVidia Overlay Don't know if some got NVIDIA + softdevice + DirectFB to work :-(. Stefan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice configure error
Zitat von ShorTie:
Trying to rebuild my gentoo system using the latest DirectFB, DFB++ and
ffmpeg.
Everytime I try to ./configure softdevice.cvs I get
BudgetVDR softdevice.cvs # ./configure --disable-vidix --disable-xv
--with-ffmpeg-path /usr/local/src/ffmpeg
ffmpeg path set to: /usr/local/src/ffmpeg
Testing system and cpu type... found Linux on i386 cpu.
Checking for pkg-config... Found.
Checking for ffmpeg... ./configure: line 213: ffmpeg_cflags: unbound
variable
Sortta seems like it's not finding ffmpeg to me, but have no clue what to
do.
Any help would be nice
- You could install your ffmpeg libs. By default ffmpeg's libs and
include files will be installed in /usr/local . With this install
target, we would usually find ffmpeg.
- The configure script has to be changed in case of --with-ffmpeg-path PATH
is specified. Test for test_ffmpeg_local line 236 should be protected by:
'if test ${ffmpeg_use_path} = no ; then' after line 235 and
closing 'fi' should be after line 239 of current cvs.
Stefan Lucke
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.18 subtitles issue
On Saturday 06 September 2008, matthieu castet wrote: Klaus Schmidinger wrote: On 09/05/08 16:36, sundararaj reel wrote: On Wed, Mar 26, 2008 at 9:55 PM, matthieu castet [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Next osd behaviour is weird : as soon as subtitle is started, when it will refresh it will mess up with other osd. For example if I start subtitle and then go to the menu, the menu will be clear by subtitle refresh, but I am still in menu mode. Hi all, Is there a fix for this problem ? I tested with vdr-1.6.0 + softdevice plugin. I have the same problem. I don't have such problems here on a FF DVB card. Could it be that the softdevice plugin doesn't handle the OSD levels correctly? These were introduced in VDR version 1.5.9. Yes it seems to be a softdevice problem : there a post on the softdevice ML, the developper try something, but it didn't solve the problem. See http://thread.gmane.org/gmane.comp.video.vdr.softdevice/689 The streams I got in this softdevice thread play fine with subtitles and vdr-1.5.12., but with no subtitles when using vdr-1.6.0 :-( . A fix should be in softdevice cvs now (3rd try). @Klaus: In vdr 1.5.12 maximum number of subtitles and audio languages could be set to 23. With vdr-1.6.0 I can select one more language (24 displayed as 2 boxes due to a font issue). After a vdr restart, number of languages is reset to 23 ;-) . -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.18 subtitles issue
Quoting Klaus Schmidinger [EMAIL PROTECTED]: On 09/10/08 22:21, Stefan Lucke wrote: @Klaus: In vdr 1.5.12 maximum number of subtitles and audio languages could be set to 23. With vdr-1.6.0 I can select one more language (24 displayed as 2 boxes due to a font issue). After a vdr restart, number of languages is reset to 23 ;-) . Does this mean that there is an actual problem in VDR = 1.6.0 that needs to be looked into, or was this solved with the fix in softdevice? The 23 vs. 24 number of language items is vdr (1.6.0) related only. But I don't think it's a real :-) problem. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-softdevice-0.5.0
Hello, the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) is pleased to announce a new release of vdr's softdevice plugin. General info: Softdevice plugin enables vdr to run on your desktop with so called budget cards. You'll get vdr output via framebuffer or X11-Xv or DirectFB or vidix to your screen. Decoding is done via ffmpeg. Supported vdr versions: 1.4.x, 1.5.x and 1.6.x Plugin's homepage is located at: http://softdevice.berlios.de/ 2008-04-18: softdevice-0.5.0 - Check configuration for ffmpeg r11816. - Removed timestamps, email addrs and src line # comments from *.po. 2008-04-16: - Silence some warnings. - softdevice.c: Fix spelling version check for trNOOP(). - Suspend output on user inactivity (see README): patch by Marko M�kel� 2008-04-15: - Fixed (changed) some italian chars. - Added local translations of yes/no. - Switched to vdr-1.5.x OSD translation. - Switched from av_read_packet() to av_read_frame(). 2008-04-14: - Italian translation by Diego. 2008-04-13: - audio: fix ac3 downmix request for ffmpeg = r10199. 2008-04-10: - SoftOsd: Adjust constructor definition to implementation. 2008-02-26: - fix for ffmpeg = r12194. - video-fb: via OSD selected screen aspect was not honored. 2008-02-20: - VideoFilter.c: fix some warnings and compile error with ffmpeg = r11816 2008-01-26: - OSD: missing call to ClearOSD() of output device. 2008-01-19: - OSD: fix drawing (missing method SetAreas()). 2007-12-25: - license: included gpl notice v2 or any later to README. - border detect: fix rounding issue. - audio: \n\r - \n substitution for ac3pt, some indentation cleanup (Xrun()) - shm-out: ensure nonNULL vout-ctl in Stop(); by Axel Naumann 2007-12-24: - mpegdecoder: compile fix for ffmpeg svn = r11071. revert AVFMT_NOFILE trick for actual ffmpeg = 11071. recommended ffmpeg versions: A) r11071 B) = r11307 2007-10-13: - shm-out: applied patch from Matthias Schwarzott to make ShmClient work at 1st start of softdevice with -vo shm:. allow xv startup aspect selection for shm out too. 2007-09-27: - audio: added open for number of channels device names CH1, CH2, CH3, .. . - mpeg2decoder: workaround for some ac3 decoding issues. 2007-09-23: - configure: fix framebuffer check. 2007-09-16: - border detect: whole black area was cut out. that's not correct when aspect ratio is greater than 16/9. limit cut out area to 16/9. - russian translation by neptunvasja 2007-08-29: - compile fix for vdr-1.5.9 based on Stone's patch. 2007-07-12: - video / dfb: moved some code from video.c to video-dfb.c as announced and changed some constants to those I use in productive VDR. 2007-07-11: - compile fix for: ./configure --disable-shm - applied patch from Matthias Schwarzott for compile issues with newer ffmpeg versions - applied patch from Artur Skawina for memory alignment error - video-xv: fix OSD parially not drawn or cleared in pseudo mode: - a small stripe remains on the right side, when video changed from 16:9 to 4:3 - only modified OSD was shown when deinterlacer was toggled on/off. 2007-05-10: - use libswscale if available. - remove left over code from the old video-fb. - remove pixel mask option from SoftOsd.[hc] and video*, which was only used by the old video-fb. - adapt MacVdrClient.c to the setupStore in shared memory. - remove softlog from setupStore. Pointers aren't valid in a shared memory block. - remove private variable setupStore from audio out methods. They can access the global variable. - move setupStore into a shared memory block. This allows ShmClient to have acces to the setupStore. - move CatchRemoteKey() into utils.c, else setup-softdevice.o would have to be linked into libsoftdevice-xv.so and -dfb.so 2007-04-12: - ShmClient: revertet previous change, as it breaks argument style of softdevice. - configure: fix typo (yaepg), rm .dependencies in case of changes, new opt: --disable-xinerama (by Matthias Schwarzott) - fix osdMode not initialized (by Matthias Schwarzott) - ShmClient: full screen start option (by Matthias Schwarzott) Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput audio lip sync problems
On Tuesday 15 April 2008, Theunis Potgieter wrote: Well it looks like I'm the only Gentoo user here that is experiencing this problem. I noticed a bit more on when it occurs. I've current changed my vdr process to run at -19 priority to see if it makes any difference. Livetv is some how now correct. But I still experience problems with recordings where cutting/editing occured. So I changed to vdr-softdevice, and I'm experience the same problem. LiveTV is acceptable but still experience audio/video sync problems after the replay has reached a edit/cut mark. (This is a recording that was processed) Any ideas? Not yet. Regarding you mentioned softdevice, can you tell us which ffmpeg svn release do you use (output of command ffplay [~ first 8 lines] gives a good hint)? At cut marks there are bigger pts jumps. Can you prepare a short recording which includes about 45 seconds before and after of your above mentioned recording for download? Link to download location should be send in private mail. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On Saturday 12 April 2008, Klaus Schmidinger wrote: On 04/09/08 08:54, Stefan Lucke wrote: On Wednesday 05 March 2008, Klaus Schmidinger wrote: On 03/04/08 10:58, Tero Siironen wrote: Hi, I upgraded from VDR 1.4.7 to 1.5.17 and noticed that some of my old recordings won't play decently with this new version. Here's a syslog entry and example clip can be found from http://kotisivu.suomi.net/izero/vdr-darwin/ddmode_example.zip (9MB) Those problematic recordings were done with some 1.3.x series VDR with ttxtsubs plugin in fall 2004. Plays fine with VDR 1.4.7, but playback stutters when playing with VDR 1.5.17. My system has DVB-C FF 2.1 and DVB-C budget cards. Running on Fedora 5. My guess would be that the offending data comes from the ttxtsubs plugin. Maybe you need to patch VDR to become aware of this. My guess is that this is introduced by vdr-1.5.11 Original vdr-1.6.0: Apr 9 08:29:38 jarada vdr: [7997] replay /net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec Apr 9 08:29:38 jarada vdr: [7997] playing '/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec/001.vdr' Apr 9 08:29:38 jarada vdr: [7997] loading /net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec//marks.vdr Apr 9 08:29:38 jarada vdr: [8019] dvbplayer thread started (pid=7997, tid=8019) Apr 9 08:29:38 jarada vdr: [8020] non blocking file reader thread started (pid=7997, tid=8020) Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = EB (counter is at 0) Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = 0B (counter is at 1) Attached pach fixes this problem for me. Your patch changed two things: the MIN_PRE_1_3_19_PRIVATESTREAM stuff, which merely made detection of pre 1.3.19 Dolby Digital data more reliable, and the (Data[7] 0x01) check in // Compatibility mode for old subtitles plugin:. I assume that the latter one is what's causing your problems. Can you please reinstate the MIN_PRE_1_3_19_PRIVATESTREAM stuff and check whether just leaving out the (Data[7] 0x01) check is enough to fix this? I guess you meant the following change only: --- device.c.orig 2008-03-09 11:03:34.0 +0100 +++ device.c2008-04-12 17:30:45.0 +0200 @@ -1265,7 +1265,7 @@ int PayloadOffset = Data[8] + 9; // Compatibility mode for old subtitles plugin: - if ((Data[7] 0x01) (Data[PayloadOffset - 3] 0x81) == 0x01 Data[PayloadOffset - 2] == 0x81) + if ((Data[PayloadOffset - 3] 0x81) == 1 Data[PayloadOffset - 2] == 0x81) PayloadOffset--; uchar SubStreamId = Data[PayloadOffset]; With this change it is still the same issue: no sound at all. Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62 (counter is at 8) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 9) Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = DA Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41 (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 1) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A (counter is at 3) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 4) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C (counter is at 4) Wondering why the are different substream ids are reported with the same counter value ;-). This additional check was suggested by Marco Schlüßler, so maybe he can comment on this and maybe find out why this is interfering with the pre 1.3.19 Dolby Digital detection? Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On Sunday 13 April 2008, Reinhard Nissl wrote: Hi, Stefan Lucke schrieb: Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62 (counter is at 8) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 9) Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = DA Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41 (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 1) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A (counter is at 3) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 4) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C (counter is at 4) Wondering why the are different substream ids are reported with the same counter value ;-). This additional check was suggested by Marco Schlüßler, so maybe he can comment on this and maybe find out why this is interfering with the pre 1.3.19 Dolby Digital detection? Maybe I should have posted this patch to the list earlier too. Ack. Maybe I should have tested my old recordings a bit earlier ;-) . Without the patch, the counter will restart from 0 and prevent Bingo. With patch, vdr-1.6.0 could replay these old recodings with sound, at least normal stereo. Thanks. VDR to run in compatibility mode just after VDR was going to activate compatibility mode. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On Wednesday 05 March 2008, Klaus Schmidinger wrote:
On 03/04/08 10:58, Tero Siironen wrote:
Hi,
I upgraded from VDR 1.4.7 to 1.5.17 and noticed that some of my old
recordings won't play decently with this new version. Here's a syslog
entry and example clip can be found from
http://kotisivu.suomi.net/izero/vdr-darwin/ddmode_example.zip
(9MB)
Those problematic recordings were done with some 1.3.x series VDR with
ttxtsubs plugin in fall 2004. Plays fine with VDR 1.4.7, but playback
stutters when playing with VDR 1.5.17. My system has DVB-C FF 2.1 and
DVB-C budget cards. Running on Fedora 5.
My guess would be that the offending data comes from the ttxtsubs plugin.
Maybe you need to patch VDR to become aware of this.
My guess is that this is introduced by vdr-1.5.11
Original vdr-1.6.0:
Apr 9 08:29:38 jarada vdr: [7997] replay
/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec
Apr 9 08:29:38 jarada vdr: [7997] playing
'/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec/001.vdr'
Apr 9 08:29:38 jarada vdr: [7997] loading
/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec//marks.vdr
Apr 9 08:29:38 jarada vdr: [8019] dvbplayer thread started (pid=7997, tid=8019)
Apr 9 08:29:38 jarada vdr: [8020] non blocking file reader thread started
(pid=7997, tid=8020)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = EB
(counter is at 0)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = 0B
(counter is at 1)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = D1
(counter is at 2)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = 5D
(counter is at 3)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = F0
(counter is at 4)
Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = 7E
(counter is at 5)
In this case there is no sound at all :-(.
Recording was done with vdr-1.2.1.
Plain vdr 1.6.0 with pre_1_3_19 change (from vdr-1.5.11) reverted:
Apr 9 08:25:50 jarada vdr: [7837] replay
/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec
Apr 9 08:25:50 jarada vdr: [7837] playing
'/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec/001.vdr'
Apr 9 08:25:50 jarada vdr: [7837] loading
/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec//marks.vdr
Apr 9 08:25:50 jarada vdr: [7859] dvbplayer thread started (pid=7837, tid=7859)
Apr 9 08:25:50 jarada vdr: [7859] resuming replay at index 69 (0:00:02.20)
Apr 9 08:25:50 jarada vdr: [7860] non blocking file reader thread started
(pid=7837, tid=7860)
Apr 9 08:25:50 jarada vdr: [7859] SetBrokenLink: no GOP header found in video
packet
Apr 9 08:25:50 jarada vdr: [7859] switching to pre 1.3.19 Dolby Digital
compatibility mode
Attached pach fixes this problem for me.
Just found Klaus message from 2007-10-21:
[vdr] VDR 1.5.10, Subtitles gets out of sync:
http://www.linuxtv.org/pipermail/vdr/2007-October/014316.html
--
Stefan Lucke
--- device.c.orig 2007-11-03 14:30:09.0 +0100
+++ device.c2008-04-08 15:06:51.0 +0200
@@ -209,9 +209,6 @@
// The default priority for non-primary devices:
#define DEFAULTPRIORITY -1
-// The minimum number of unknown PS1 packets to consider this a pre 1.3.19
private stream:
-#define MIN_PRE_1_3_19_PRIVATESTREAM 10
-
int cDevice::numDevices = 0;
int cDevice::useDevice = 0;
int cDevice::nextCardIndex = 0;
@@ -934,7 +931,7 @@
}
else
memset(availableTracks, 0, sizeof(availableTracks));
- pre_1_3_19_PrivateStream = 0;
+ pre_1_3_19_PrivateStream = false;
SetAudioChannel(0); // fall back to stereo
currentAudioTrackMissingCount = 0;
currentAudioTrack = ttNone;
@@ -1239,7 +1236,7 @@
int PayloadOffset = Data[8] + 9;
// Compatibility mode for old subtitles plugin:
- if ((Data[7] 0x01) (Data[PayloadOffset - 3] 0x81) ==
0x01 Data[PayloadOffset - 2] == 0x81)
+ if ((Data[PayloadOffset - 3] 0x81) == 1 Data[PayloadOffset
- 2] == 0x81)
PayloadOffset--;
uchar SubStreamId = Data[PayloadOffset];
@@ -1248,13 +1245,11 @@
// Compatibility mode for old VDR recordings, where 0xBD was
only AC3:
pre_1_3_19_PrivateStreamDeteced:
- if (pre_1_3_19_PrivateStream MIN_PRE_1_3_19_PRIVATESTREAM) {
+ if (pre_1_3_19_PrivateStream) {
SubStreamId = c;
SubStreamType = 0x80;
SubStreamIndex = 0;
}
- else if (pre_1_3_19_PrivateStream)
- pre_1_3_19_PrivateStream--; // every known PS1 packet
[vdr] dvbsubtitle issue
Hi, can someone with a full featured card test the short recording mentioned here: http://lists.berlios.de/pipermail/softdevice-devel/2008q1/003004.html When playing this with softdevice, consecutive subtitle areas are not erased. Between these trace messages there is no deletion of previous OSD area. So if the following area is of smaller size, parts of previous area remain on screen (in softdevice). END_OF_DISPLAY_SET_SEGMENT PAGE_COMPOSITION_SEGMENT The dvbsubtitle trace looks like: FramesPerSec: 25 Create SubtitlePage 1 (total pages = 1) PAGE_COMPOSITION_SEGMENT page refresh Update page id 1 version 15 pts 3614043382 timeout 2 state 1 PAGE_COMPOSITION_SEGMENT new Page Update page id 1 version 0 pts 3614216502 timeout 6 state 2 REGION_COMPOSITION_SEGMENT Region pageId 1 id 0 version 11 fill 1 width 510 height 44 level 4 depth 4 clutId 1 FillRegion 0 REGION_COMPOSITION_SEGMENT Region pageId 1 id 1 version 12 fill 1 width 224 height 44 level 4 depth 4 clutId 1 FillRegion 0 CLUT_DEFINITION_SEGMENT OBJECT_DATA_SEGMENT OBJECT_DATA_SEGMENT END_OF_DISPLAY_SET_SEGMENT PAGE_COMPOSITION_SEGMENT page refresh Update page id 1 version 1 pts 3614518658 timeout 2 state 1 PAGE_COMPOSITION_SEGMENT new Page Update page id 1 version 2 pts 3614576328 timeout 6 state 2 REGION_COMPOSITION_SEGMENT Region pageId 1 id 0 version 13 fill 1 width 330 height 44 level 4 depth 4 clutId 1 FillRegion 0 REGION_COMPOSITION_SEGMENT Region pageId 1 id 1 version 14 fill 1 width 264 height 42 level 4 depth 4 clutId 1 FillRegion 0 CLUT_DEFINITION_SEGMENT OBJECT_DATA_SEGMENT OBJECT_DATA_SEGMENT END_OF_DISPLAY_SET_SEGMENT PAGE_COMPOSITION_SEGMENT page refresh Update page id 1 version 3 pts 3614885762 timeout 2 state 1 PAGE_COMPOSITION_SEGMENT new Page Update page id 1 version 4 pts 3614926520 timeout 6 state 2 REGION_COMPOSITION_SEGMENT Region pageId 1 id 0 version 15 fill 1 width 362 height 44 level 4 depth 4 clutId 1 FillRegion 0 REGION_COMPOSITION_SEGMENT Region pageId 1 id 1 version 0 fill 1 width 322 height 44 level 4 depth 4 clutId 1 FillRegion 0 CLUT_DEFINITION_SEGMENT OBJECT_DATA_SEGMENT OBJECT_DATA_SEGMENT END_OF_DISPLAY_SET_SEGMENT PAGE_COMPOSITION_SEGMENT -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsubtitle issue
Quoting Klaus Schmidinger: On 01/19/08 14:28, Stefan Lucke wrote: Quoting Klaus Schmidinger: On 01/19/08 11:58, Stefan Lucke wrote: Hi, can someone with a full featured card test the short recording mentioned here: http://lists.berlios.de/pipermail/softdevice-devel/2008q1/003004.html Did it, and I can't see anything wrong with the display. There are three sets of subtitles, and each is displayed correctly. Thanks Klaus, but thats not the expected answer. I assume you meant that this was not the answer you were hoping for ;-) Excat :-( Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsubtitle issue
Quoting Klaus Schmidinger:
On 01/19/08 18:47, Luca Olivetti wrote:
En/na Stefan Lucke ha escrit:
Excat :-(
Stefan Lucke
In case it could help you: the dxr3-plugin had a similar issue, the
solution was to clear the osd each time SetAreas is called.
http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?r1=1.1.2.17r2=1.1.2.18
cDvbOsd also clears the OSD whenever SetAreas() is called:
eOsdError cDvbOsd::SetAreas(const tArea *Areas, int NumAreas)
{
if (shown) {
cBitmap *Bitmap;
for (int i = 0; (Bitmap = GetBitmap(i)) != NULL; i++) {
Cmd(OSD_SetWindow, 0, i + 1);
Cmd(OSD_Close);
}
shown = false;
}
return cOsd::SetAreas(Areas, NumAreas);
}
Thats exact the missing method in SoftOsd.c which will do the clear.
Should have had a look at the list a few minutes earlier.
Thanks.
Stefan Lucke
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + h264
On Tuesday 15 January 2008, Stefan Lucke wrote:
On Tuesday 15 January 2008, Reinhard Nissl wrote:
Hi,
Stefan Lucke schrieb:
is it correct that h264 is written as PES via PlayVideo() ?
For decoding with ffmpeg it would be useful to have a
PROGRAM_STREAM_MAP in front of a new video stream.
Basically not a bad idea, but where do you put it in live
streaming?
I think it should be transmitted first, after a stream reset.
A basic PSM that maps from PES 0x01e0 to h264 could
look like:
unsigned char psm_map_0xe0_to_h264 [] =
{ 0x00, 0x00, 0x01, 0xbc,
0x00, 0x10, // psm length
0x00, 0x00, // unknown
0x00, 0x00, // info length
// info data here
0x00, 0x04 // map length
// map data here
0x1b, 0xe0, 0x00, 0x00 // h264 map entry / NO map info
0x00, 0x00, 0x00, 0x00 // crc32
};
That is inspired by ffmpegs: libavformat/mpeg.c
mpegps_psm_parse() line ~220 .
And now I know that softdevice can switch between h264 and mpeg2
when using the following addition (file remux.c line ~2552):
#define TEST_cVideoRepacker
#ifdef TEST_cVideoRepacker
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0, 0x00,
new cVideoRepacker(h264));
#else
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0);
#endif
-- cut --
if (h264) {
resultBuffer-Put (psm_map_0xe0_to_h264, sizeof (psm_map_0xe0_to_h264));
fprintf(stderr, is h264\n);
} else {
fprintf(stderr, is NO h264\n);
}
-- cut --
The bad thing is, PSM info should be repeated more often, as the decoder
may reset itself due to bad reception (ahead of each video packet ??).
Or is there a simpler way to recognize h264 (or other codecs)
as Klaus demands?
Stefan Lucke
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr + h264
Hi, is it correct that h264 is written as PES via PlayVideo() ? For decoding with ffmpeg it would be useful to have a PROGRAM_STREAM_MAP in front of a new video stream. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + h264
On Tuesday 15 January 2008, Reinhard Nissl wrote:
Hi,
Stefan Lucke schrieb:
is it correct that h264 is written as PES via PlayVideo() ?
For decoding with ffmpeg it would be useful to have a
PROGRAM_STREAM_MAP in front of a new video stream.
Basically not a bad idea, but where do you put it in live
streaming?
I think it should be transmitted first, after a stream reset.
A basic PSM that maps from PES 0x01e0 to h264 could
look like:
unsigned char psm_map_0xe0_to_h264 [] =
{ 0x00, 0x00, 0x01, 0xbc,
0x00, 0x10, // psm length
0x00, 0x00, // unknown
0x00, 0x00, // info length
// info data here
0x00, 0x04 // map length
// map data here
0x1b, 0xe0, 0x00, 0x00 // h264 map entry / NO map info
0x00, 0x00, 0x00, 0x00 // crc32
};
That is inspired by ffmpegs: libavformat/mpeg.c
mpegps_psm_parse() line ~220 .
Or after a seek in VDR's recording player?
By above, it's just (pinned) at the beginning of the file.
Don't know if we should expect changes in between
(but all bad things happen).
Mplayer does some nice tests to determine PES vs. ES. It has just
not been extended to detect H.264 in the same way.
Aren't users beeing told to feed mplayer with PSM too ?
H.264 uses a
limited start code set compared to MPEG1/2 so it should be easy
to detect the content, due to the distribution of start codes.
--
Stefan Lucke
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
On Sunday 13 January 2008, Hagen Schöbel wrote: I have an problem with the original patch to vdr-1.5.12: [EMAIL PROTECTED]:/usr/local/src/vdr-1.5.12-dvbs2# make g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video\ -DCONFDIR=\/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 audio.c dvbdevice.h:38: Fehler: »dvbfe_delsys« bezeichnet keinen Typ make: *** [audio.o] Fehler 1 Any hints ? The include path to your modified DVB-S2 drivers is missing. I set this path in Make.config (see Make.config.template) to: DVBDIR = /usr/local/src/v4l-dvb/linux ..-DLOCDIR=\./locale\ -I/usr/include/freetype2 -I/usr/local/src/v4l-dvb/linux/include dvbdevice.c .. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR multiproto [Was: Two VDR's on one machine]
On Saturday 12 January 2008, Morfsta wrote:
On Jan 12, 2008 3:37 PM, Stefan Lucke [EMAIL PROTECTED] wrote:
Same here.
Which DVB-T device do you use ? I'm using a cinergyT2.
Ioctl's for this device are not passed
via the common frontend interface. The new API has to get
integrated into the cinergyT2 driver or client programs like vdr etc.
have to recognize the driver supported API ;-) .
I am using two Hauppauge Nova-T (tda1004x and cx2388x).
Manu said in an earlier thread that there should be compatibility with
the old API so he doesn't think that should be a problem. The driver
in the multiproto tree for my devices have not been changed so should
work through the compatibility layer.
The odd thing is that when I use an older pre-compiled VDR 1.4.x with
the new multiproto drivers everything works fine but when I compile
1.5.12 with multiproto includes it doesn't work.
So I guess in your case, there is still an issue with the compatibility
layer of http://jusst.de/hg/multiproto/ .
In my case I managed to get my cinergyT2 work with Reinhard's
modified vdr, with attached diff.
--
Stefan Lucke
diff -r 4df151d5b3fe linux/drivers/media/dvb/cinergyT2/cinergyT2.c
--- a/linux/drivers/media/dvb/cinergyT2/cinergyT2.c Sat Dec 01 01:50:24
2007 +0400
+++ b/linux/drivers/media/dvb/cinergyT2/cinergyT2.c Sat Jan 12 22:45:29
2008 +0100
@@ -1,5 +1,5 @@
/*
- * TerraTec Cinergy T²/qanu USB2 DVB-T adapter.
+ * TerraTec Cinergy T²/qanu USB2 DVB-T adapter.
*
* Copyright (C) 2004 Daniel Mack [EMAIL PROTECTED] and
* Holger Waechtler [EMAIL PROTECTED]
@@ -511,6 +511,106 @@ static uint16_t compute_tps (struct dvb_
return tps;
}
+static uint16_t compute_newtps (struct dvbfe_params *fep)
+{
+ uint16_t tps = 0;
+
+ switch (fep-delsys.dvbt.code_rate_HP) {
+ case DVBFE_FEC_2_3:
+ tps |= (1 7);
+ break;
+ case DVBFE_FEC_3_4:
+ tps |= (2 7);
+ break;
+ case DVBFE_FEC_5_6:
+ tps |= (3 7);
+ break;
+ case DVBFE_FEC_7_8:
+ tps |= (4 7);
+ break;
+ case DVBFE_FEC_1_2:
+ case DVBFE_FEC_AUTO:
+ default:
+ /* tps |= (0 7) */;
+ }
+
+ switch (fep-delsys.dvbt.code_rate_LP) {
+ case DVBFE_FEC_2_3:
+ tps |= (1 4);
+ break;
+ case DVBFE_FEC_3_4:
+ tps |= (2 4);
+ break;
+ case DVBFE_FEC_5_6:
+ tps |= (3 4);
+ break;
+ case DVBFE_FEC_7_8:
+ tps |= (4 4);
+ break;
+ case DVBFE_FEC_1_2:
+ case DVBFE_FEC_AUTO:
+ default:
+ /* tps |= (0 4) */;
+ }
+
+ switch (fep-delsys.dvbt.constellation) {
+ case DVBFE_MOD_QAM16:
+ tps |= (1 13);
+ break;
+ case DVBFE_MOD_QAM64:
+ tps |= (2 13);
+ break;
+ case DVBFE_MOD_QPSK:
+ default:
+ /* tps |= (0 13) */;
+ }
+
+ switch (fep-delsys.dvbt.transmission_mode) {
+ case DVBFE_TRANSMISSION_MODE_8K:
+ tps |= (1 0);
+ break;
+ case DVBFE_TRANSMISSION_MODE_2K:
+ default:
+ /* tps |= (0 0) */;
+ }
+
+ switch (fep-delsys.dvbt.guard_interval) {
+ case DVBFE_GUARD_INTERVAL_1_16:
+ tps |= (1 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_8:
+ tps |= (2 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_4:
+ tps |= (3 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_32:
+ default:
+ /* tps |= (0 2) */;
+ }
+
+ switch (fep-delsys.dvbt.hierarchy) {
+ case DVBFE_HIERARCHY_ON:
+ switch (fep-delsys.dvbt.alpha) {
+ case DVBFE_ALPHA_1:
+ tps |= (1 10);
+ break;
+ case DVBFE_ALPHA_2:
+ tps |= (2 10);
+ break;
+ case DVBFE_ALPHA_4:
+ tps |= (3 10);
+ break;
+ }
+ break;
+ case DVBFE_HIERARCHY_OFF
Re: [vdr] change make install to be really useful
Quoting VDR User: While we're on the topic of adjusting the Makefile.. I propose the following change to install-plugins: old: @cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(PLUGINLIBDIR) new: @cp --remove-destination $(PLUGINDIR)/lib/*.$(APIVERSION) $(PLUGINLIBDIR) The difference is copying *.$(APIVERSION) rather then lib*-*.so.$(APIVERSION). The reason is because not all plugins use the same naming (softdevice for example) and this minor adjustment would eliminate the need to edit the Makefile for this with every new version of vdr, or having to manually copy them to the install dir. Also I see no reason against it since we keep the APIVERSION. Which libs of softdevice are not matched by the old style ? Softdevice targets usually are: TARGETS = libvdr-$(PLUGIN).so and (with subplugins): TARGETS += lib$(PLUGIN)-xv.so TARGETS += lib$(PLUGIN)-dfb.so which are finally installed to: @cp $(CPOPTS) $@ $(LIBDIR)/[EMAIL PROTECTED](APIVERSION) And this should be match by : lib*-*.so.$(APIVERSION) And also the following change to clean-plugins: old: @-rm -f $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) new: @-rm -f $(PLUGINDIR)/lib/*.$(APIVERSION) @-rm -f $(PLUGINLIBDIR)/*.$(APIVERSION) Again using *.$(APIVERSION) instead of lib*-*.so.$(APIVERSION), and also if we're going to clean plugins from the source dir, it seems fitting to clean the installed ones as well since it's the expect behavior from most users I've observed. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] softdevice segfaulting on stream errors
On Tuesday 10 July 2007 16:20, Artur Skawina wrote: Some time ago the softdevice plugin started crashing when playing video streams containing errors, both while live viewing and watching recordings. Today I found a transponder where it reliably occurred within seconds and decided to investigate. The picture buffers used for video were 8-byte aligned, which happened to work for normal mpeg decoding, but wasn't enough. ffmpeg was executing SSE instructions when doing error concealment and those were segfaulting. Fix below. Thanks, applied. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Beta version of vdr with dvb-s2 support
On Sunday 08 July 2007 14:14, Reinhard Nissl wrote: Hi, Martin Werner wrote: I am stil uncertain of what DVB-S2 Hardware I should buy. But if you can give me a hint, I go - buy - and watch Pro7 tomorrow in HDTV. I don't want to make an advertisement here, but it's easy for me to grab a SAT PCI-KARTE TECHNISAT SKYSTAR HD (Bestnr.: 941604) http://www.conrad.de/scripts/wgate/zcop_b2c/!?perform_special_action=Produktdetailproduct_show_id=941604p_page_to_display=fromoutside Does it work? I use anways XINE as frontend .. so, I only would need to install the new card and apply your patch. Well, the next vdr-xine release will support it. It works here already, but the biggest drawback is that FFmpeg lacks interlaced H.264 decoding (PAFF, MBAFF), i. e. FFmpeg crashes after a few frames. Like the following mplayer messages: Movie-Aspect is 1.76:1 - prescaling to correct movie aspect. VO: [xv] 1920x1088 = 1920x1088 Planar YV12 [ASPECT] Warning: No suitable new res found! [ASPECT] Warning: No suitable new res found! [ASPECT] Warning: No suitable new res found! New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. [h264 @ 0x87fdf00]PAFF interlacing is not implemented??% ??,?% 0 0 [h264 @ 0x87fdf00]PAFF interlacing is not implemented [h264 @ 0x87fdf00]PAFF interlacing is not implemented -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
On Friday 29 June 2007 18:24, Georg Acher wrote: On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote: I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem. Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel Damm, that's the nvidia way. They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone. To my opinion that is a nogo way. I doubt if that's compatible with GPL. (otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas). -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice with menuaudio but no video
Quoting Darren Wilkinson: Stefan Lucke wrote: Quoting Darren Wilkinson: Torgeir Veimo wrote: On 27 Jun 2007, at 18:32, Darren Wilkinson wrote: The problem is that although I can hear the channel playing and I can see and use the vdr menus using softdevice I can't view the actual program wether or not it's live or recorded. Ae you using Xv output? It's prob the wrong colour key used for the overlay. Search the softdevice devel for a fix. --Torgeir Veimo [EMAIL PROTECTED] I forgot to mention that I'm using DirectFB only. And you forgot to mention which hardware you are using. With DirectFB we need hardware YUV - RGB conversion support. Plain fb output mode should run on any hw, but requires some more CPU power. Stefan Lucke I'm using nvidiafb with a GF 6600. 6600 ... I think that was the series, where they (nvidia) dropped the overlay unit. When I remind this correct, from this series on only the blitter can be used. So it _could_ be, that when selecting YUY2 as output pixel format _and_ setting Use StretchBlit to yes, video is shown. But this depends on DirectFB's driver capabilities too. However normal framebuffer is also showing menus but no video. Also shouldn't colourspace errors mean I get no menus either? Menus are drawn directly to framebuffer in RGB. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice crash
On Thursday 10 May 2007 20:19, [EMAIL PROTECTED] wrote: Hi there, My config: - Asus M2NPV-VM (Geforce6150), Hauppauge nexus-s. - suse 10.0, kde, vdr-1.4.4. I recently purchased a 32 LCD-TV, and I would like to set up vdr-softdevice, to connect vdrbox via D-SUB or DVI to the TV set. I compiled ffmpeg-0.4.9-cvs and vdr-softdevice-0.4.0 without any errors. Probing vdr with softdevice: tigervdr:/opt/tigervdr/vdr-1.4.4 # ./vdr -c /vdrconf -P 'softdevice -vo xv:' [softdevice] processing args [softdevice] argv [0] = softdevice [softdevice] argv [1] = -vo vo_argv: xv: [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3344640) [XvVideoOut]: Xinerama Screen 0: 0,0 1360x768 [XvVideoOut]: Xinerama Screen 1: 1360,0 720x480 [XvVideoOut]: osd_image shmid = 2949127 [XvVideoOut]: got osd_image: width 2080 height 768, bytes per line 4160 That's only 16bit per pixel. Please try 32bpp. [XvVideoOut]: max area size 2046 x 2046 [XvVideoOut]: using area size 736 x 576 [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder Segmentation fault I tried different ffmpeg and softdevice versions, with same result. Any hint? Can you try to change the OSD drawing mode in setup.conf ? softdevice.OSDalphablend = 1 If that doesn't help, we need the gdb backtrace of the segfault. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-softdevice-0.4.0
Hello, the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) is pleased to announce a new release of vdr's softdevice plugin. General info: Softdevice plugin enables vdr to run on your desktop with so called budget cards. You'll get vdr output via framebuffer or X11-Xv or DirectFB or vidix to your screen. Decoding is done via ffmpeg. Support of vdr versions earlier than vdr-1.3.7 has been removed. Supported vdr versions: 1.3.x, 1.4.x and 1.5.x Plugin's homepage is located at: http://softdevice.berlios.de/ Changelog since last release: 2007-04-11: softdevice-0.4.0 - xv-out: activate suspend/resume key (r/R) via configure (by Artur Skawina). - i18n: some german translations. - osd: moved aspect detection entry to Cropping sub menu. 2007-04-03: - add automatic border detection, based on a patch by Roland Praml. - altivec needs 16 byte alignment - compile fix for Darwin - make flag for shared linking a variable - add BGRA32 mode to SoftOsd - compile linux RTC syncing mode support only on Linux. - detect cpu endianness and define CPU_BIGENDIAN if necessary. - add video-quartz and audio-macos for Mac Os X support 2007-03-25: - fix types in GetTime(). - pts values are stored in uint64_t - almost complete rewrite of video-fb. Supported are now 15,16,24 and 32 bit depth framebuffers. The osd is rendered with software alpha blending, and it is even faster :-) 2007-03-12: - compile fix for recent ffmpeg SVN - include ffmpeg headers as 'extern C' - enable and use as default the software mixer. The old behaviour (use the system's mixer) can be selected via -vo oss:mixer. - increase the stepsize of the software mixer. - don't scale audio if the volume is at maximum. - set edge_width/_height always to zero. Fixes picture shiftes with the ShmClient. This is not the optimal(/final) solution... 2007-03-04: - video-dfb: Make use of SetSourceRectangle() runtime selectable, changed *SetSourceLocation* to SetSourceRectangle. 2007-02-26: - softlog: sanitycheck for zero length filenames and fix use filename member when changeing append mode. - video-dfb: shifted most prints via softlog. - video sync: preparation for new changeable sync parameters. 2007-02-24: - Makefile: add --remove-destination , so that make plugins does not disturb a running vdr. - softlog: added indicator for priority I(nfo), E(rror), D(ebug), T(race). - video-vidix: shifted prints via softlog. 2007-02-13: - fix gettid compile error on some systems. 2007-02-11: - Some more options selectable via log menu. 2007-02-10: - Pause the playback of recordings when suspended (by Marko Mäkelä) - add configurable logging - report Xrun audio duration 2007-01-28: - don't lock NULL pictures in cVideo::GetLockLastPic(). - implement avcodec_decode_audio2() interface to libavcodec. - set ic-bp.is_streamed to true, to avoid calls to unimlemented seek method. - add architecture x86_64 to configure and report unsupported architectures. - add StealToBitmap() for OSD in grabbed image. - add OSD with alpha blending to grabbed images. 2007-01-27: - video-dfb: - Limit VIA-unichrome name compare to 19 chars. - Detect a patched DirectFB version for VIA CN700 support, and set some parameters for video layer V3: pixelformat YUY2, NO hardware decoding support . 2007-01-20: - Fixed video-dfb for VIA-unichrome with current DirectFB cvs. In directfbrc pixelformat=AiRGB must be specified. 2007-01-15: - introduce yuv420_to_rgb15() (mmx acceleration still missing). - properly start cShmRemote thread in ShmClient. - avoid BadWindow errors by using an errror handler. Also fix BadWindow errors which occur after the xscreensaver has once been active. - fix vidWin for non zero VidX1 and VidY1. 2006-12-17: - Silence some warnings with gcc 4.1.1. - Adjust MMX and C version of fast_memcpy() to the same return type. - Fix wrong colors in yuv420_to_yuy2() when all MMX is disabled. 2006-12-13: - don't undefine X cursur on keypresses, to prevent the fake shift key press from producing flickering of the mouse cursor. - fix possible segfault. - fix possible division by zero. - comment out fake key sending syslog message - add cOSSAudioOut::GetDelay() (supplied by Lubos Novak). 2006-12-03: - applied patch from Matthias Schwarzott for vdr uint64 change. - unify yuv420_to_rgbXX() and yv12_to_yuy2_line() functions to allow usage in CopyScalePicBuf() - change CopyPicBuf_YUV420P_to_YUY() to a general YUV420P to planar conversion method - introduce the possibility to scale the video window (for yaepg). - detection of and support for the yaepg-patch. - add open sound system support (contributed by Lubos Novak). GetDelay() is commented out, this means the A/V
[vdr] softplay problem with ffmpeg [rev 8428] (Was: softdevice audio problem. audio repacker issue?)
On Sunday 18 March 2007 10:34, Martin Wache wrote: Stefan Lucke schrieb: But there is still one drawback. It is still not playable with softplay. Neither audio nor video. There are only some accustic fragments and no video frame. For me softplay works fine with vdr recordings. Did you make sure that you compiled softplay with the same ffmpeg version like the softdevice? Yes. just did a make clean-plugins, make plugins. This is with old (vdr-1.2.1) and new recordings. My current ffmpeg revision is 8428. Will test some older like 7852 too. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Saturday 17 March 2007 23:11, Martin Wache wrote: Hi, Reinhard Nissl schrieb: And old recordings will vanish as time passes by. I don't buy this argument. I know that there are VDR users with large archives of recordings, do you want to tell them that they can't use them any more? Second that. Lifetime 99. Won't tell my son, that his favorit recordings of Die Sendung mit der Maus won't be accessible after the next software upgrade :-) . -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Saturday 17 March 2007 22:05, Martin Wache wrote: I attached a patch with make the softdevice use av_read_frame(), it has still some issues, but it solves the problems Stefan reports. Martin, thats really great. Thank you. This solves the issue I had with playback of some old recordings. But there is still one drawback. It is still not playable with softplay. Neither audio nor video. There are only some accustic fragments and no video frame. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Is there a way to give inode entries a higher cache priority than data in the linux kernel?
Quoting Carsten Koch: Matthias Schniedermeyer wrote: ... 1) Is there a bug in the linux kernel that makes it spin up the disk needlessly even if the data are still in the cache? ... I haven't tried or read it myself, but this: Documentation/laptop-mode.txt might contain the information you need. Correct. Interesting information. I'll try it out. You may have a look at the following page too: http://gentoo-wiki.com/HOWTO_HDD_spindown_small_server Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-softdevice-0.3.1
Hello, the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) is pleased to announce a new release of vdr's softdevice plugin. General info: Softdevice plugin enables vdr to run on your desktop with so called budget cards. You'll get vdr output via framebuffer or X11-Xv or DirectFB or vidix to your screen. Decoding is done via ffmpeg. This is just a maintance release for previous 0.3.0 version, as code for support of vdr version earlier than vdr-1.3.7 will be removed soon. Supported vdr versions: (1.2.x,) 1.3.x and 1.4.x Plugin's homepage is located at: http://softdevice.berlios.de/ Changelog since last release: 2006-11-05: softdevice-0.3.1 - xv-out: limit used width height to screen dimensions. - audio: select alsa h/w-mixer for volume control via command line. 2006-10-11: - hopfull final color jump fix for odd cut columns from left values. - fix horizontal picture placement when YUY2 is selected for xv-out. 2006-10-10: - fix segfaults when YUY2 pixelformat is used for xv-out and cut lines from top is non zero. This fixes wrong colors and misplaced OSD drawing too, when cut colums from left is non zero. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice and epia tv-out problem with Xorg
On Donnerstag 02 November 2006 23:38, Stefan Lucke wrote:
Quoting Leo Márquez:
Hi again,
Stefan Lucke escribió:
/ But after started it without problems now I get:
//
// [softdevice] A/V devices initialized, now initializing MPEG2 Decoder
// X Error of failed request: BadValue (integer parameter out of range
for
// operation)
// Major opcode of failed request: 145 (MIT-SHM)
// Minor opcode of failed request: 3 (X_ShmPutImage)
// Value in failed request: 0x3ff
/
Which are the startup options now ?
0x3ff = 1023 = 1024 - 11
My startup options are only -vo xv:full
Did you changed your X resolution via ALT+CTRL+Keypad + ?
No but I press the 'f' key to toggle between fullscreen and windowed vdr
mode.
The second time I run vdr with -vo xv:full don't work
Ah, I should have mentioned that you _must_ not toggle full screen -
windowed mode, as windowed mode works with some default values
which even did not work previously (thats why I ask for full screen mode).
I'll send you a patch tomorrow that will restrict these values.
Ok, here comes the patch. I tested it with 640x480 resolution and now I do not
get these failed request any more. In contrast to your setup, mine worked fine
when setting softdevice.OSDalphablend = 1 in vdr's setup.conf even
without the patch.
--
Stefan Lucke
Index: video-xv.c
===
RCS file: /cvsroot/softdevice/softdevice/video-xv.c,v
retrieving revision 1.63
diff -U3 -r1.63 video-xv.c
--- video-xv.c 29 Sep 2006 19:17:18 - 1.63
+++ video-xv.c 3 Nov 2006 18:29:54 -
@@ -862,6 +862,23 @@
}
}
#endif
+
+ /* -
+ * limit widht and height to screen dimensions
+ */
+ {
+ int screen_width, screen_height;
+
+screen_width = DisplayWidth(dpy, scn_id);
+screen_height = DisplayHeight(dpy, scn_id);
+
+if (height screen_height)
+ old_dheight = lheight = dheight = height = screen_height;
+
+if (width screen_width)
+ old_dwidth = lwidth = dwidth = width = screen_width;
+ }
+
/* -
* default settings which allow arbitraray resizing of the window
*/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice and epia tv-out problem with Xorg
Quoting Leo Márquez [EMAIL PROTECTED]: Hi Stefan and thanks for your answer. I have solved the problem starting softdevice in full screen. So -vo xv:full worked. But after started it without problems now I get: [softdevice] A/V devices initialized, now initializing MPEG2 Decoder X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 145 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Value in failed request: 0x3ff Which are the startup options now ? 0x3ff = 1023 = 1024 - 11 Did you changed your X resolution via ALT+CTRL+Keypad + ? can you show us the output of command xdpyinfo ? Which osd_image size was reported in that case ? Serial number of failed request: 250 Current serial number in output stream: 251 I have seen that is another value in failed request: 0x33ff. I have tried with OSDAlphablend value to 1 without luck. What is the 0x33ff value related to? Thanks. Stefan Lucke escribió: Quoting Leo Márquez [EMAIL PROTECTED]: Hi!, Recently I have connected my vdr box to my CRT 16:9 TV. I use the s-video(I want to use the rca tv-out for digital audio) connector of my epia M.1. I have followed some instructions to configure xorg with s-video out from this page: http://www.kingcot.eclipse.co.uk/unichrome/unichromeTvOut.html I don't know if this url is up to date. I have got see my wmaker desktop in my tv but when I start vdr with softdevice I get: [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3345920) [XvVideoOut]: osd_image shmid = 2686978 [XvVideoOut]: got osd_image: width 720 height 576, bytes per line 2880 [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 145 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Value in failed request: 0x2ff 0x2ff = 767 = 768 - 1 768 is the default startup width. So you can try to: a. start in full screen mode -vo xv:full, which adjusts width and height to available max values (720 width in your case I guess). b. choose software OSD blending (via OSD :-( ) or via setup.conf: softdevice.OSDalphablend = 1 Serial number of failed request: 337 Current serial number in output stream: 338 Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice and epia tv-out problem with Xorg
Quoting Leo Márquez [EMAIL PROTECTED]: Hi!, Recently I have connected my vdr box to my CRT 16:9 TV. I use the s-video(I want to use the rca tv-out for digital audio) connector of my epia M.1. I have followed some instructions to configure xorg with s-video out from this page: http://www.kingcot.eclipse.co.uk/unichrome/unichromeTvOut.html I don't know if this url is up to date. I have got see my wmaker desktop in my tv but when I start vdr with softdevice I get: [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3345920) [XvVideoOut]: osd_image shmid = 2686978 [XvVideoOut]: got osd_image: width 720 height 576, bytes per line 2880 [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 145 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Value in failed request: 0x2ff 0x2ff = 767 = 768 - 1 768 is the default startup width. So you can try to: a. start in full screen mode -vo xv:full, which adjusts width and height to available max values (720 width in your case I guess). b. choose software OSD blending (via OSD :-( ) or via setup.conf: softdevice.OSDalphablend = 1 Serial number of failed request: 337 Current serial number in output stream: 338 Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVD plugin - sound jerky??
On Mittwoch 11 Oktober 2006 06:26, Simon Baxter wrote: It's been several months - and I never had a reply to this but it's still happening. I've rebuilt several times - but it's still the same. The dvd plugin works fine, except intermittently the sound disappears for about a second at the end of a scene. With debugging running I get these messages when the sound disappears: PPPClear(4)! Play I don't think these messages are dvd-plugin related, as I cannot find them via grep (vdr-xine ?). With which dvds did you get these messages? Clear(5)! SetAudioChannelDevice: 0 [snip] Each time the sound disappears, I get another 3-lines as per above. If it's relevant, I'm using vdr-1.4.1 with vdr-xine-0.7.9. Any clues?? - Original Message - From: Simon Baxter [EMAIL PROTECTED] To: VDR Mailing List vdr@linuxtv.org Sent: Wednesday, July 26, 2006 9:30 AM Subject: [vdr] DVD plugin - sound jerky?? I've had this problem for ages and never found any resolution to it as it's really only a problem with DVDs that have a lot of chapters. How is a lot of chapters defined (10, 50, 100, ..) ? When it get towards the end of a chapter, the sound disappears. The video is still fine, but the sound stops. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-softdevice-0.3.0
Hello, the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) is pleased to announce a new release of vdr's softdevice plugin. General info: Softdevice plugin enables vdr to run on your desktop with so called budget cards. You'll get vdr output via framebuffer or X11-Xv or DirectFB or vidix to your screen. Decoding is done via ffmpeg. Supported vdr versions: (1.2.x,) 1.3.x and 1.4.x Plugin's homepage is located at: http://softdevice.berlios.de/ Special hint: For cle266 hardware decoding support via DirectFB, you'll need a fresh version from todays DirectFB's cvs. Further you'll need libcle266mpegdec which is available from: http://sourceforge.net/projects/cle266mpegdec/ Changelog since last release: 2006-10-09: softdevice-0.3.0 2006-10-03: - fix hang after long pause. 2006-10-01: - enable cropping for video-shm. - Remove some unneeded code and fix ctl-width/height setting. 2006-09-29: - video-shm: silence warnings. - video-xv: removed osdMutex. - video-dfb: removed osdMutex. clear non video area when OSD is active to avoid fade effects. 2006-09-22: - protect locking for old picture by a separate mutex. - fix possible lost picture update and dropped areaMutex. 2006-09-21: - introduce a mutex to protect calls to videoOut from SoftOsd - initialize parameters for the vout-GetOSDMode() call 2006-09-19: - fix Error! Trying to unlock a nil picture... Ignoring error message. - use current_OsdMode instead of setupStore.OsdMode 2006-09-18: - fix RefreshAll for NoVScaleCopyToBitmap() - add a very simple cpu type and host system detection to configure - fix changing from pseudo to software osd blending for video-xv - remove no longer needed test for broken gcc compiler from configure - combine shared memory checks into CheckShmIDs() - improve error messages in video-shm.c 2006-09-17: - replace pshufw with MMX commands to make scaling optimazations available to processors without MMX2 - cleanup PicBuffer.c, release PicBuffers in destructor,... - add linux framebuffer detection to configure - disable libcle266mpegdec if no DirectFB is found - add altivec optimizations to some AlphaBlend() and yv12_to_yuy2_il_mmx2_line() - make utils.c compile on non MMX machines, cleanup some #ifdefs - fix compile issue with g++-4.1.1 - add NoVScaleCopyToBitmap() for RGB modes 2006-09-16: - added -vo shm: to help option - added support new fields from libcle266mpegdec-0.4 - video-dfb: removed check and support for DSBLIT_INTERLACED as DirectFB has buildin support for this now. - disable cle266 support if DirectFB is not patched for this - cle266: fix one aspect ratio info and configure (by Rolf Ahrenberg) 2006-09-12: - don't continue on argument errors 2006-09-11: - catch unrecognized options for dfb-out (reported by Rolf Ahrenberg) 2006-09-10: - fix NVidia software alpha blending OSD issue, which turned out to be a compiler problem with g++-4.1.1. (Many thanks to Prakash Punnoor, Matthias Schwarzott, Chris Elsworth and all the others who helped to fix this) 2006-09-09: - video-xv.c: silence some warnings - video-vidix: offer equalizer settings via OSD (brightness, hue, saturation and contrast) offer HW-deinetrlace via OSD when available (by Roland Praml) 2006-09-08: - limit destination video offsets to even values - fix typo in asignment - fix xv-out with subplugins disabled 2006-09-04: - fix wrong colors when using ShmClient (reported by Matthias Schwarzott and [EMAIL PROTECTED]) - disable debuging printouts - cleanup - set sPicBuffer completly to zero 2006-08-27: - adjust ffmpeg library order in configure - enable different pixel formats in video-xv - properly init ctl-key (reported by Matthias Schwarzott) 2006-08-05: - video-dfb: disable reported failed flags in SetParams() 2006-07-25: - no longer exit when a audio mode is not available, audio is only disabled. - clean up audio-alsa - init tmpOsdSurface and delete dirtyLines properly - try to use the XVideo default brightness, hue etc. values on first start - new option: -vo xv:use-defaults, can be used to reset the values of brightness, hue etc. to the default values. (Based on a patch by Matthias Schwarzott) 2006-07-16: - only link against libXi if necessary ( do we need libXi at all?) - check explicitly for pkg-config in configure - configure: --with-ffmpeg-path overrides pkg-config - unconditionally set _NET_WM_FULLSCREEN Atom when going fullscreen (recent Metacity WM need it) 2006-07-12: - fix segfault in OSD refresher. 2006-07-11: - remove no longer defined FFMPEG_VERSION string 2006-07-10: - move alsa related stuff into a separate file, enable build without alsa support - remove uneeded include of sys/mman.h and sys/ioctl.h from
Re: [vdr] 451 Grab image failed v4l problem?
On Mittwoch 13 September 2006 09:17, Leo Márquez wrote: Hi, Stone wrote: On 9/12/06, *Leo Márquez* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi again, I have installed the last mercurial v4l version and the grab command still not working. Anyone knows what could be the problem? If you are using softdevice, I'll have to mention that grab is not supported with softdevice. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: vdr suggestions osd colour oddity (Chris Elsworth)
On Montag 07 August 2006 05:20, Chris Elsworth wrote: On Sun, Aug 06, 2006 at 06:45:55PM -0700, CR wrote: Hi Chris, Chris Elsworth wrote: Yes, I read the old mails and found the hue of 0 or 100 suggestion, and tried it (see original mail I posted) and it didn't work. I just tried it again with softdevice from cvs to double check and it didn't have any effect, so maybe I'm running into a slightly different problem. Do you have any suggestions about how I might try to debug it? Can you take a look at: http://www.flickr.com/photos/[EMAIL PROTECTED] @CR, I've seen this but I don't know whats the problem with your setup or why our osd drawing is wrong in combination with nvidia cards. At which color depth is your X server running ? and let me know if your OSD looks like softdevice_wrongoverlay1_software or softdevice_wrongoverlay_software ? I think the problem lies in the code that alpha blends the OSD with the video image. Changing the HUE setting for me had no effect either. I notice the OSD becomes strange once any video is playing. Until then the OSD looks fine... Hello, Hmm, mine look different from all your examples. This is the pink, incorrect display: http://spork.qfe3.net/~chris/vdr/snapshot4.png When changing to this channel, vdr says: Aug 7 04:12:57 media vdr: [1191] [VideoOut]: 720x576 [90,0 540x576] - 1024x768 [128,0 768x768] This is a correct display: http://spork.qfe3.net/~chris/vdr/snapshot5.png And when changing to this channel, vdr says: Aug 7 04:13:29 media vdr: [1197] [VideoOut]: 720x576 [0,0 720x576] - 1024x768 [0,0 1024x768] Another incorrect: http://spork.qfe3.net/~chris/vdr/snapshot6.png And the log: Aug 7 04:14:35 media vdr: [1216] [VideoOut]: 704x576 [0,0 704x576] - 1024x768 [0,0 1024x768] Screenshots were made with ksnapshot. The only correlation I can make so far is that lower resolutions seem to present the problem? Can you try that without any skin / osd related plugin and with an unpatched (vanilla) vdr ? What are your osd postions and size specs (setup - osd) ? -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
