vdr

vdr@linuxtv.org

6731 discussions

RE: [vdr] 4:3 stretched to 16:9?
by Martin 10 May '07

10 May '07

Hey Simon,my answer sounds maybe stupid, but I always have all output to 720x576. I use vdr-xine, xine is set to "no scale". So for example: we have shows on RTL or arte in 16:9 amorph which means, that we have 16:9 but with 720x576 pixels. My Sony 16:9 TV takes then the PAL and shows it in "wide".Regards,Martin> Date: Mon, 7 May 2007 23:55:20 +0100> From: linuxtv(a)nzbaxters.com> To: vdr(a)linuxtv.org> Subject: [vdr] 4:3 stretched to 16:9?> > Is there a way in VDR to reformat recordings made in 4:3 to play back in> 16:9 ?> > -Simon> > > _______________________________________________> vdr mailing list> vdr(a)linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _________________________________________________________________ Windows Live Hotmail: Der kostenlose E-Mail-Dienst - schnell, einfach & sicher! http://mail.live.com

3 4

[PATCH] dynamically sized ringbuffers v1
by Artur Skawina 09 May '07

09 May '07

vdr uses quite a lot of memory, RSS here used to be ~70M, so i decided to see if it could be reduced a bit. First suspects became the ringbuffers, cause i was seeing a lot of log lines such as "buffer stats: 96068 (1%) used". Turns out many buffers are way over sized, only a few percent of the memory are typically used, yet because of how a ringbuffer works _all_ of it is constantly accessed. I first tried to make the ringbuffer users smarter about picking the size and eg after changing the transfer buffer to start out small and use bigger sizes only when the current one isn't large enough it seemed a more reasonable size for that vdr instance was 384k instead of 2M. Similarly the TS buffer could be just a few hundred K instead of 2M. But that approach was not ideal as there isn't anything one could do after realizing the buffer is too small, it could be grown next time, after channel switch etc, but that's it. Also some of the huge buffers came from plugins, and I wasn't all that excited about fixing all of them (one example w/ the one-digit % fill was streamdev-server). It is hard to estimate what the proper size would be under load, with many simultaneous recordings. So I did attack this issue differently -- by making the ringbuffers themselves smarter. Patch below changes the interpretation of the 'Size' parm given when creating a buffer from a fixed length to a max limit. The buffers start out much smaller (currently 128k, instead of many megabytes) and grow automatically when they become almost full. This way all callers benefit, and they don't have to be modified at all. The buffers are actually always allocated using the max size, but only the necessary buffer part is used, the rest of the memory is never accessed; this is done this way so that no extra locking is necessary. I've tested this on two vdrs for a few hours and it seems to work, but it needs a lot more testing. There is some extra logging in this patch so that you can see what's going on; every time a ring buffer gets deleted it logs a line which tells you exactly how much memory was requested and how much was really needed. vdr: [19729] Deleting ring buffer "TS" size: 196608 / 2097152 (used 9.375% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 442368 / 5242880 (used 8.4375% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 131072 / 5242880 (used 2.5% of requested size) vdr: [19733] Deleting ring buffer "TS" size: 131072 / 2097152 (used 6.25% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 442368 / 5242880 (used 8.4375% of requested size) So each of the several 'Recorder' buffers was an order of magnitude smaller than w/o this patch and several megabytes less ram was used. artur diff --git a/ringbuffer.c b/ringbuffer.c index 0633bd3..8dd1efe 100644 --- a/ringbuffer.c +++ b/ringbuffer.c @@ -151,13 +151,29 @@ void cRingBufferLinear::PrintDebugRBL(void) } #endif +// cRingBufferLinear are dynamically sized, or at least we can pretend they are ;) +// We treat 'Size' as the maximum size, but start with a small buffer, which can +// grow later as it fills up. Memory is always allocated for the full buffer, but +// the unused RAM portion remains untouched until (if at all) it is actually needed. +// Note that we can not start with a larger than requested buffer because there are +// ring buffer users that cause crashes then (eg softdevice mpegdecoder absolutely +// needs 32/64k). + +// Startup size. 64k still causes overflows before buffer starts to grow, 128k doesn't. +// The buffers grow to 200..500k anyway, so maybe increasing this a bit more would +// make sense, but let's first see if it's really needed. +#define DEFRBSIZE KILOBYTE(128) + cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description) -:cRingBuffer(Size, Statistics) +:cRingBuffer(min(Size,DEFRBSIZE), Statistics) { description = Description ? strdup(Description) : NULL; tail = head = margin = Margin; gotten = 0; buffer = NULL; + maxsize = Size; + growbuf = 0; + dsyslog("New ring buffer \"%s\" size: %d margin: %d", description, Size, Margin ); if (Size > 1) { // 'Size - 1' must not be 0! if (Margin <= Size / 2) { buffer = MALLOC(uchar, Size); @@ -183,6 +199,8 @@ cRingBufferLinear::~cRingBufferLinear() #ifdef DEBUGRINGBUFFERS DelDebugRBL(this); #endif + dsyslog("Deleting ring buffer \"%s\" size: %d / %d (used %g%% of requested size)", description, + size, maxsize, size/(double)maxsize*100.0 ); free(buffer); free(description); } @@ -207,6 +225,13 @@ void cRingBufferLinear::Clear(void) int cRingBufferLinear::Read(int FileHandle, int Max) { + if (Available() >= size*2/4) + growbuf = 1; + if (growbuf && head>=tail && size<maxsize) { + size = min(size+size/2, maxsize); + dsyslog("Enlarging ring buffer \"%s\": %d bytes (Read())", description, size); + growbuf = 0; + } int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -236,6 +261,8 @@ int cRingBufferLinear::Read(int FileHandle, int Max) lastHead = head; lastPut = Count; #endif + if (Available() >= size*3/4) + growbuf = 1; EnableGet(); if (free == 0) WaitForPut(); @@ -245,6 +272,13 @@ int cRingBufferLinear::Read(int FileHandle, int Max) int cRingBufferLinear::Put(const uchar *Data, int Count) { if (Count > 0) { + if (Available()+Count >= size*2/4) + growbuf = 1; + if (growbuf && head>=tail && size<maxsize) { + size = min(size+size/2, maxsize); + dsyslog("Enlarging ring buffer \"%s\": %d bytes", description, size); + growbuf = 0; + } int Tail = tail; int rest = Size() - head; int diff = Tail - head; diff --git a/ringbuffer.h b/ringbuffer.h index dba0e61..f417d57 100644 --- a/ringbuffer.h +++ b/ringbuffer.h @@ -18,11 +18,11 @@ private: cCondWait readyForPut, readyForGet; int putTimeout; int getTimeout; - int size; time_t lastOverflowReport; int overflowCount; int overflowBytes; protected: + int size; tThreadId getThreadTid; int maxFill;//XXX int lastPercent; @@ -59,6 +59,8 @@ private: int margin, head, tail; int gotten; uchar *buffer; + int growbuf; + int maxsize; char *description; public: cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL);

2 4

OT: noad
by Wolfgang Goeller 09 May '07

09 May '07

Hello I just found out: I can't find noad. The old homepage is no longer valid. Does anyone know more Thanks Wolfgang

2 1

4:3 stretched to 16:9?
by Simon Baxter 09 May '07

09 May '07

Is there a way in VDR to reformat recordings made in 4:3 to play back in 16:9 ? -Simon

2 1

CAM/CI Problems
by Simon Baxter 07 May '07

07 May '07

I've been posting a lot of messages lately about problems I'm having getting my TechnoTrend Budget 1500/CI (dvb-c) and Irdeto CAM working, on both this and the linux-dvb lists. As I've not had very many responses, I can only assume there's few people using this combination, and I probably need to look at addressing the problem myself. To summarise my problem: The DVB card registers properly, and I can scan channels etc fine. All the channels available to me are scrambled. The CAM seems to register properly also, but I can't access the CAM menu or decrypt anything. -VDR flip-flops the CAM between ready/present -kernel messages "dvb_ca adapter 0: DVB CAM detected and initialised successfully" repeat over and over -'gnutv -cammenu' reports "en50221_tl_poll: CAWrite failed" and "en50221_stdcam_llci_poll: Error reported by stack:-2" -the card and CAM work fine in a Dreambox and under (Windows) GBPVR My question is, can anyone suggest any other tools which test CAMs? Also, I don't really understand how the CAM is accessed - can anyone point me in the right direction? Thanks! Simon

1 0

Galaxis LinuxTV terminal : IDE connection
by Trick 07 May '07

07 May '07

Hello, Sorry for repeating this message in this mailing list. I realized it was better here than DVB mailing list. I'm using a DVB-C LinuxTv terminal called Galaxis. I bought it on Ebay and apparently it is made for the Austrian market. Everything works great on the French Cable! >From what I understood this terminal has a IDE connection for a hard drive. I opened the terminal and indeed I found the IDE plug. Though I didn't find the electrical plug for the hard drive. Does anybody own this terminal and tried to connect a hard drive? What would be the next step? Hard drive recognition by the BIOS? Software to install to be able to record TV shows? Thank you in advance. Patrick

1 0

[ANNOUNCE] VDR sync early patch
by Reinhard Nissl 06 May '07

06 May '07

Hi, the motivation for this patch was to speed up zapping channels when using vdr-xine, i. e. to shorten the time from pressing the remote button till audio and video appear. FF card users may only see the effect of this patch when the FF card is running in transfer mode. The idea is to not wait for the first I frame in transfer mode. Although output devices "can't" decode any frames before the first I frame, the contained PTS in the PES packets allows the device to synchronize audio and video even before the first video frame appears on screen. Another issue which is addressed by this patch is that audio packets were not delivered to the device immediately after switching the channel, so the above change didn't have any effect. Calling EnsureAudioTrack() fixes this. How much speed up can be expected? Well, it varies from zap to zap as it depends on a couple of parameters like the offset of audio and video PTS, whether a PTS is available per frame, the number of frames till the next I frame arrives, etc. But a speed up should be noticeable. BTW: Testers of plugin ** should comment out the following line in cTSBuffer::Get() in file device.c, like that: // if(!device->***) device->***=new c***; This change is highly recommended if you experience buffer overflows while switching channels, though they are not related to the sync early patch. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

1 0

Cut marks editing problem
by Olaf Titz 06 May '07

06 May '07

I'm editing a recording with some errors in it (errors of the kind "broken MPEG kills vdr-sxfe"). Looks like the index.vdr is broken, so I run genindex. After that, some existing cut marks are not on a GOP boundary any more (looks like genindex really has fixed something). I can't edit these cut marks any more. When I put the cursor on the broken mark, neither of 4 6 7 9 keys do anything. With 0 the mark is not deleted, rather a new one generated at the right position but I can't get rid of the broken mark. Proposed fix: on the 7 and 9 keys, look if the mark is really on a GOP boundary, and if not, scan for the next one, adjusting the mark. This would also help with manual editing of the marks.vdr file. Olaf

2 1

epgsearch compile error vdr-1.5.2
by Simon Baxter 06 May '07

06 May '07

I'm getting the following error when I try and compile epgsearch-0.9.19 Plugin epgsearch: make[1]: Entering directory `/usr/src/development/vdr-1.5.2/PLUGINS/src/epgsearch-0.9.19' g++ -g -O2 -Wall -Woverloaded-virtual -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I 18N='"epgsearch"' -I../../../../DVB/include -I../../../include -I../../../.. /DVB/include conflictcheck.c conflictcheck.h: In member function 'int cConflictCheckDevice::ProvidesCa(const cChannel*) const': conflictcheck.h:106: error: 'class cDevice' has no member named 'ProvidesCa' make[1]: *** [conflictcheck.o] Error 1 make[1]: Leaving directory `/usr/src/development/vdr-1.5.2/PLUGINS/src/epgsearch-0.9.19' Any ideas?

1 1

remoteosd / multi-box question
by Simon Baxter 05 May '07

05 May '07

Hi. I use remoteosd to schedule and record programs on a remote device, which I access from the primary device via an NFS share. Problem is, new programs only appear in the primary device once VDR restarts. Is there a way to refresh recording directories without restarting VDR?

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr