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] [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] 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
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
[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
Re: [vdr] vdr-1.7.1 video stream format
On Friday 28 November 2008, Stefan Lucke wrote: > 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. Next test with vdr extensions patch64 (+ ext_h264 + s2api_v2): Enabling and activating livebuffer via OSD brings video stream back ;-) . > 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
[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
#include
#include
#include
#include
#include
#include
//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
[vdr] vdr-1.7.1 video stream format
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.
- additional implemented methods PlayTs*() won't get called.
class cSoftDevice : public cDevice {
private:
cMpeg2Decoder *decoder;
cVideoOut *videoOut;
cAudioOut *audioOut;
[snip]
public:
cSoftDevice(int method, int audioMethod, char *pluginPath);
~cSoftDevice();
[snip]
virtual int PlayVideo(const uchar *Data, int Length);
#if VDRVERSNUM >= 10701
virtual int PlayTSVideo(const uchar *Data, int Length);
virtual int PlayTSAudio(const uchar *Data, int Length);
virtual int PlayTS(const uchar *Data, int Length, bool VideoOnly = false);
#endif
--
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" -P"softdevice -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
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
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
[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 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 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 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) {
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.17&r2=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] 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 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. So I've to go to search for the missing Clear() in softdevice. > > Klaus > > > 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: > > ... > Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[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] 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
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
[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] [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;
+ ca
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: > Hi, > > Thanks for speaking with Marco, Reinhard - its appreciated. > > Unfortunately, the patch does not fix the problem. Still no picture on > DVB-T transmissions. 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 ;-) . > > Regards > > On Jan 11, 2008 7:21 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Reinhard Nissl schrieb: > > > > > So it seems to me that either the emulation layer has a bug for > > > DVB-T or the patched VDR passes incorrect data to the new API. > > > > Looks like the latter is true: Marco Schlüßler informed me that > > the mapping of TransmissionModes in nit.c for DVB-T is wrong. > > > > I've created the attached patch according to his' instructions. > > > > Please give the patch a try and report success or failure. > > > > > > Bye. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 plugin patches
On Montag 27 August 2007, Stone wrote: > On 8/27/07, Stone <[EMAIL PROTECTED]> wrote: > > > > It seems the new "Level" parameter in cOsd has caused xine and softdevice > > to fail in compile with vdr-1.5.9. Does anyone know how to fix these? > > > > This seems to build now with these changes. I didnt add backwards > compatibility for < 1.5.9 though. Please let me know if this is the correct > way. > > Best Regards. > Thanks, guarded by "#if VDRVERSNUM .." it's in softdevice cvs now. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
[vdr] New VDR logging method (Was: Re: [ANNOUNCE] VDR developer version 1.5.7)
On Sunday 12 August 2007 19:47, Patrick Cernko wrote: > Hi list, hi Klaus, > > Klaus Schmidinger wrote: > > > > The changes since version 1.5.6: > > > > - All logging now goes to LOG_ERR, because some systems split error, info > > and > > debug messages into separate files, which repeatedly caused extra efforts > > to > > find out when incomplete log excerpts were attached to problem reports in > > the past. > > should this change be permanent, configurable or will it only apply for > the developer releases? I vote for a configurable solution. Softdevice has such a mode (not realized for all messages but ..) which allows some kind of messages to be turned off (info, debug and trace). Messages can be written to stdout/stderr or to a configureable file with optionally current PID appended. > > In my opinion, it is a benefit to redirect different log levels to > different files for normal operation. In case of a bug, a > commandline/setup option could select this behaviour to produce full logs. -- 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] HELP! vdr-1.4.1 and softdevice-0.4.0 aren't working any more
Quoting Harald Milz: > Hi, > > after having reinstalled my VDR with OpenSUSE 10.1 a couple of weeks ago > (after which VDR was working happily for some time) some very strange > things happened. At first, after a reboot, sound was gone, without any > change in the configuration, only after rebooting. My setup is still as > described in > http://www.vdr-wiki.de/wiki/index.php/Softdevice-plugin#Matrox_G550_mit_DVI-Ausgang_und_DirectFB > (in German, though). In particular, softdevice is invoked as > > softdevice -ao alsa:pcm=plug:spdif#ac3=plug:spdif# -vo dfb: > > No sound from VDR. Video was displayed fine. I could play testsounds with > aplay just fine. To get the mixer unmuted and or let softdevice use mixer for volume control you'll have to add "mixer:" to your audio parameter. http://www.vdr-portal.de/board/thread.php?postid=619500#post619500 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=Produktdetail&product_show_id=941604&p_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] Beta version of vdr with dvb-s2 support
On Saturday 30 June 2007 19:25, jlac vdr wrote:
> Hi,
>
> This is a beta version of vdr which support dvb-s2.
> So this version is able to watch TVHD through a streaming plugin
> (streamdev plugin is include in archive).
>
> http://www.freewebs.com/jlacvdr/vdr-s2hd/vdr-1.4.6-s2hd-070630.tar.bz2
ONE week and no other feedback on this list :-( .
At least at vdr-portal there are a few people busy on that:
http://www.vdr-portal.de/board/thread.php?threadid=66165
I tried the diff file with vdr-1.4.0. Applies with a few offsets.
On tuning to:
Sat.1 HD:12722:hM8:S19.2E:22000:511:515:0:0:10201:0:1119:0
I can see with a slightly modified version of the patch for pat.c:
for (SI::Loop::Iterator it; pmt.streamLoop.getNext(stream, it); ) {
switch (stream.getStreamType()) {
case 0x19: // advanced codec HD digital television service
case 0x1b: //ISO/IEC 14496-10 Video (MPEG-4 part 10/AVC, aka
H.264)
printf("stream pid:%d (0x%04x) type
0x%04x\n",stream.getPid(), stream.getPid(), stream.getStreamType());
stream pid:255 (0x00ff) type 0x001b
stream pid:511 (0x01ff) type 0x001b
stream pid:255 (0x00ff) type 0x001b
stream pid:511 (0x01ff) type 0x001b
ERROR: no useful data seen within 10494724 byte of video stream
>From syslog:
Jul 7 13:47:46 jarada vdr: [18639] TS buffer on device 1 thread started
(pid=18612, tid=18639)
Jul 7 13:47:46 jarada vdr: [18640] ERROR: invalid Count in
cRingBufferLinear::Del: 0 (limited to -1742158149)
Jul 7 13:47:47 jarada vdr: [18637] PES packet shortened to 702 bytes
(expected: 1806 bytes)
Jul 7 13:47:47 jarada vdr: [18637] cAudioRepacker(0xC0): skipped 992 bytes
while syncing on next audio frame
Jul 7 13:47:47 jarada vdr: [18618] changing pids of channel 901 from
255+255:259:0 to 255+255:0;259=deu:0
Jul 7 13:47:48 jarada vdr: [18618] changing pids of channel 902 from
511+511:515:0 to 511+511:0;515=deu:0
Jul 7 13:47:48 jarada vdr: [18612] retuning due to modification of channel 902
Jul 7 13:47:48 jarada vdr: [18612] switching to channel 902
Jul 7 13:47:48 jarada vdr: [18637] transfer thread ended (pid=18612, tid=18637)
Looks like data gets not passed via remuxer to softdevice :-( .
>
> The DVB-S2 channels must have 'M8' in modulation field of channels.conf,
> for example:
> ASTRAPROMO_HD:12721:hC23M8:S19.2E:22000:767:768:0:0:10202:1:1119:0
>
>
> tested with:
> - linux 2.6.19
> - TT3200 card (manu drivers and laasa patch)
Tested with:
- linux 2.6.21-5
- Technisat SkyStar HD
02:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Unknown device 1019
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at feaffc00 (32-bit, non-prefetchable) [size=512]
jarada stefan # lspci -v -n -s 02:06.0
02:06.0 0480: 1131:7146 (rev 01)
Subsystem: 13c2:1019
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at feaffc00 (32-bit, non-prefetchable) [size=512]
--
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 menu&audio 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 with menu&audio but no video
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Q: dvd-plugin and softdevice
On Friday 11 May 2007 19:03, Harald Milz wrote:
> Hi,
>
> I would like to use the dvd plugin (CVS as of today) together with
> softdevice-0.4.0. Plays DVDs fine but no sound. In the plugin's source code
> there's in player-dvd.c:
>
> BitStreamOutActive = false;
> HasBitStreamOut = (cPluginManager::GetPlugin("bitstreamout") != NULL);
>
> SoftDeviceOutActive = false;
> HasSoftDeviceOut= (cPluginManager::GetPlugin("xine") != NULL);
>
> Shouldn't the plugin also check for softdevice? player-dvd.h says
>
> static bool SoftDeviceOutActive; // currently used to switch for xine
> static bool HasSoftDeviceOut;// currently used to switch for xine
Usually I do not modify dvd plugin to get sound :-) (AC3 optical link
to external decoder) . So it's only up to the "normal" audio selector
of vdr to choose the audio track.
>
> Hmmm -
[snip]
> libdvdnav: Menu Languages available: en
> libdvdnav: Language 'de' not found, using 'en' instead
> libdvdnav: Menu Languages available: en
> [mpegdecoder] Error! Codec 86020 not supported by libavcodec
> [mpegdecoder] Error! Codec 86020 not supported by libavcodec
86020 = 0x15004 = CODEC_ID_AC3
Can you try to select a non AC3 audio track or rebuild ffmpeg
with AC3 decoding support, as that's to my opinion missing.
--
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. - ad
Re: [vdr] VDR 1.4.5 problem replay old recordings
Quoting Per Mellander <[EMAIL PROTECTED]>: > I have recently upgraded my VDR from 1.3.31 to 1.4.5 ( 1.3 starting from > 1.3.20 something ). I have problem with replaying some ( not all ) of > the old recordings. When starting replaying, the live TV is freezed and > some kind of audio ( at high speed and chopped ) from the recorded > material is heard. > > During my update I've also gone from FF-card output to softdevice. I've > tried replaying the recordings with softplay and in that case the video > is shown distorted and at a very low speed and with no audio. Can you try the patch Martin posted here: http://www.linuxtv.org/pipermail/vdr/2007-March/012476.html A shorts test shows that it solves the problem with softdevice. Softplay is still an issue for me. > > My setup: > > VDR 1.4.5 > softdevice CVS 20070312 > softplay CVS 20070312 > FFmpeg version SVN-r7991, Copyright (c) 2000-2007 Fabrice Bellard, et al. >configuration: --enable-shared --enable-pp --enable-gpl >libavutil version: 49.3.0 >libavcodec version: 51.33.0 >libavformat version: 51.10.0 >built on Feb 17 2007 21:53:00, gcc: 4.1.1 20070105 (Red Hat 4.1.1-51) > > I haven't yet tested to replay with 1.4.5 and my Nexus-S FF because the > card is still in the old VDR machine. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[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 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] 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 20:57, Reinhard Nissl wrote: > Hi, > > Stefan Lucke wrote: > > > Dumping the first 16 bytes of audio packets we get, shows the following: > > ff fc a4 0d b6 64 88 55 33 65 56 54 44 21 33 33 > > ff fc a4 0d 54 6a 88 65 33 44 56 54 33 33 33 33 > > ff fc a4 0d 02 a4 88 55 33 54 66 44 43 33 33 33 > > 99 77 1b e6 34 b2 5f 41 e8 5b 90 a9 d2 04 24 5e > > ff fc c4 04 7c c4 dd 44 44 66 57 55 55 55 33 33 > > ff fc c4 04 1d 61 dd 46 44 66 55 55 55 55 33 33 > > 68 6a 60 18 d8 52 92 4f 54 98 0b 93 27 22 4e 74 > > ff fc c4 04 94 01 dd 44 56 66 55 55 55 55 33 33 > > > > Is audio repacker active even for old recording ? > > When I deactivate audio repacker, sound is garbled allways. > > cAudioRepacker was introduced after VDR-1.3.26 and it is only active in > transfer mode or while recording. It is not active while replaying a > recording, so it has no influence on recordings taken with VDR-1.2.1. Thanks for pointing that out. So we should look for solving that issue in softdevice. Hopefully FF-cards are not involved in such an issue (sound, sync issues). > > But when cAudioRepacker was not active, an audio PES packet may contain, > multiple audio frames and/or just a fragment of an audio frame at the > beginning or at the end of the PES packet. > > So if ffmpeg can only work on single and/or complete audio frames, > you'll have to break the PES packet apart and assemble the fragments at > the end and the beginning of the next PES packet. cAudioRepacker can do > this for you. Just feed it PES packets via it's Repack() method and the > given ResultBuffer will contain a PES packet per audio frame. Some time ago I've been told from ffmpeg people, that we sould read packets from AVParser. I guess that's the point which kicks us now. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] softdevice audio problem. audio repacker issue?
Hi, need some help in locating a decoding issue with old vdr recordings and softdevice. Recordings were done with vdr-1.2.1. They play fine when using ffplay . They play fine when using ffmpeg svn revision 6040 via vdr + softdevice. With vdr + softdevice there is no sound in ffmpeg svn rev 6147. With rev 6398 and newer sound is garbled and a lot of error messages are printed out. Dumping the first 16 bytes of audio packets we get, shows the following: ff fc a4 0d b6 64 88 55 33 65 56 54 44 21 33 33 ff fc a4 0d 54 6a 88 65 33 44 56 54 33 33 33 33 ff fc a4 0d 02 a4 88 55 33 54 66 44 43 33 33 33 99 77 1b e6 34 b2 5f 41 e8 5b 90 a9 d2 04 24 5e ff fc c4 04 7c c4 dd 44 44 66 57 55 55 55 33 33 ff fc c4 04 1d 61 dd 46 44 66 55 55 55 55 33 33 68 6a 60 18 d8 52 92 4f 54 98 0b 93 27 22 4e 74 ff fc c4 04 94 01 dd 44 56 66 55 55 55 55 33 33 Is audio repacker active even for old recording ? When I deactivate audio repacker, sound is garbled allways. -- 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
Quoting Leo Márquez <[EMAIL PROTECTED]>: > Hi Stefan, thanks for your patch!!. > Now I can start and toggle between fullscreen and windowed modes without > problems. > This patch will be included in cvs version or I have to apply to every > new release? This will be included in cvs soon. > But I still with black screen. Now the syslog says: > > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: XV_SWOV: available ports > 68 - 68 > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: XV_SWOV: format > 0x30323449 is NOT in format list: Ah, thats I420. So please select YV12 or YUY2 pixelformat via OSD, and you should get video too . > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x32595559[YUY2] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x32315659[YV12] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x434d5658[VIA] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x35315652[RV15] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x36315652[RV16] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: 0x32335652[RV32] > Nov 5 20:35:16 dori vdr: [4461] [XvVideoOut]: (ERROR) could not grab > any port! No video possible! > 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 Stefan Lucke: > > Another issue that I don't know if is related with the main topic is > > that when I start vdr correctly (only the first time) I don't get video. > > I'm using streamdev-client. In syslog I see: > > > > [XvVideoOut]: (ERROR) could not grab any port! No video possible! > > Oh, then I misunderstood you. Thought the it works the first time > you called it. > So did you ever or never get video ? > > I like to ask for output of: xdpyinfo . Sorry, that should be: xvinfo . 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: > 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. > > >can you show us the output of command xdpyinfo ? > > > > > My xdpyinfo output command Is here: > > name of display::0.0 > version number:11.0 > vendor string:The X.Org Foundation > vendor release number:70101000 > X.Org version: 7.1.1 > number of screens:1 > > screen #0: > dimensions:720x576 pixels (183x146 millimeters) > resolution:100x100 dots per inch > depths (7):24, 1, 4, 8, 15, 16, 32 The resolution and #of screens I wanted to see (no further hint). > >Which osd_image size was reported in that case ? > > > > > [setup-softdevice] startup aspect set to (16:9 wide) > [softdevice] initializing Plugin > [softdevice] Initializing Video Out > [softdevice] ffmpeg build(3345920) > [XvVideoOut]: osd_image shmid = 2129920 > [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: 0x3ff > Serial number of failed request: 250 > Current serial number in output stream: 251 > > Another issue that I don't know if is related with the main topic is > that when I start vdr correctly (only the first time) I don't get video. > I'm using streamdev-client. In syslog I see: > > [XvVideoOut]: (ERROR) could not grab any port! No video possible! Oh, then I misunderstood you. Thought the it works the first time you called it. So did you ever or never get video ? I like to ask for output of: xdpyinfo . > > Thank you for you attention. 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 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" > 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 fil
Re: [vdr] Best video card for 1080i/p with softdevice?
On Freitag 15 September 2006 20:16, Niko Mikkila wrote: > On Sat, 16 Sep 2006 01:23:58 +0900 (EIT) > "Anthony Hornby" <[EMAIL PROTECTED]> wrote: > > > Hi everyone, > > just discovered that my trusty old G550 can only do 1280x1024 via the DVI > > output damn it !! > > > > Anyone have any recommendations for a card which will work with softdevice > > and directfb or vidix to do digital 1080p and 1080i resolution output via > > DVI? > > I will be connecting it via a DVI-HDMI converter cable to a Toshiba > > 62CM9UA rear projection TV. > > > > I am after the most stable card with the best playback quality I can get > > and don't mind spending a few hundred dollars to get the right one. > > > > Thanks for your help. > > > > Regards Anthony. > > Hi, > > cheap ATI and NVIDIA cards are good for HD video output (esp. NVIDIA > because you can get MPEG-2 acceleration working with the binary > drivers). The cheapest passively cooled cards work as well for video > playback on Linux as the high-end models, so don't pay over 40 euros > for one. The cheapest way is to go into a shop and buy a simple set top box. So get you both: closed hardware and closed source. Most advantage is: As you've paid, you'll get paid professional service in case you have a problem. > However, these cards work best through the X.org drivers, so > you're better off with vdr-xineliboutput than with softdevice. Anyway, > Xine offers better deinterlacers, which are very important for playback > quality with such displays as yours. > > Niko -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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: Re: vdr suggestions & osd colour oddity (Chris Elsworth) (Stefan Lucke)
On Dienstag 08 August 2006 03:56, CR wrote: > Hi, > > > > > 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 ? > > Stefan, I am running at "24 bpp", 800x600. Is this 24 bpp with 3 bytes or 24 bpp with 4 bytes ? Output of xdpyinfo will clear this. > Can you shed some light on how > softdevice does it's alpha blending? I assume the decoded video frame is > in non-RGB color space and from what I read about VDR's OSD that is in > RGB, right? Yes. Video is in fourcc YV12 and vdr OSD is RGB via lookup table. > > So, does softdevice do the RGB-->YUV for the OSD and then alpha-blend that > into the video frame? Yes. And that way, mixing an OSD converted to YV12 color space with YV12 video (OSD drawing set to software) works with Matrox, Radeon and VIA-Unichrome with "-vo xv:". In case of Radeon (mentioned as my current setup) our OSD mixing method works with "-vo vidix:" too. So its either a choice of software or hardware :-( . software: use vdr-xine or xinelibout, hardware: use cards that work: matrox, radeon, Unichrome or savage (with a small change which is a work-around of a driver bug: http://www.mail-archive.com/devel@xfree86.org/msg06044.html ) > > Supposedly using Cairo/XRender, alpha-blending can be done by the video > card hardware, I wonder how hard it would be to modify softdevice for > this. > -- 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
