vdr

vdr@linuxtv.org

2 participants
6731 discussions

Start a nNew thread

cannot set volume with softdevice and vdr-1.3.23
by Halim Sahin 27 Mar '05

27 Mar '05

3 3

Basic shell problems / stdin / requant
by Gavin Hamill 27 Mar '05

27 Mar '05

Hi :) Following Sascha's announcement of an external script being used for remuxing, I've tried to implement not only 'normal' remuxing, but to include 'requantisation' in the pipeline so that the resulting MPEG2 stream sent to the client is much smaller than the input one.. and everything in realtime.... Unfortunately I've come up against a fairly fundamental problem... I've first grabbed some test data (by setting the /root/externremux.sh to "cat >/test.ts" for a few seconds). I'm trying to use this basic script that I found on a MythTV forum: mkfifo vid aud demux.mv2 demux0.mp2 replex --demux -k -o demux & cat demux.mv2 | buffer -s 50k -m30m | tcrequant -f 1.33 | buffer -m10m >vid & cat demux0.mp2 | buffer -s 50k -m30m | cat | buffer -m10m >aud & mplex -f 3 -V -o /dev/stdout aud vid And when I do a test run of just the 'replex' line from the shell, it works: telly:/tmp# cat test.ts | replex --demux -k -o demux using stdin as input Checking for TS: confirmed Trying to find PIDsmux.sh found vpid 610 (0x0262) apid 611 (0x0263) Video: aspect ratio: 16:9 size = 720x576 frame rate: 25.000 fps bit rate: 6.50 Mbit/s vbvbuffer 1835008 Sequence Extension: chroma 4:2:0 size = 720x576 bit rate: 6.50 Mbit/s vbvbuffer 1835008 frame rate: 25.000 starting with video PTS: 24:14:24.721 Audiostream: layer: 2 BRate: 256 kb/s Freq: 48.0 kHz frame size: 768 starting audio PTS: 24:14:24.410 But when I run it by piping the input to the script, replex doesn't get any input: telly:/tmp# cat test.ts | /root/externremux.sh telly:/tmp# using stdin as input Checking for TS: failed Checking for AVI: failed Checking for PS: confirmed(maybe) read 0.00 MB Can't find all required streams Please check if audio and video have standard IDs (0xc0 or 0xe0) And now if I remove the '&' from the replex line - it works again, but of course the script halts forever since the fifos replex is writing to will never be read! Am I missing something really simple here? Cheers, Gavin.

1 0

Channels with different language on L/R channels
by Rantanen Teemu 26 Mar '05

26 Mar '05

Is there a work in progress to support channels which have different languages on left and right audio channels in one audio PID? Cartoon Network Nordic seems to broadcast 4 languages in 2 audio PIDs. Teemu

3 8

RE: [vdr] vdr-xine: what's wrong with this pieceof code-- threadingissue?
by Rantanen Teemu 26 Mar '05

26 Mar '05

Reinhard Nissl wrote: > Please apply the attached patch to vdr-1.3.23 and tell me, whether > there is any improvement. At least there was one for me ;-) The patch does seem to make an improvement on rewinds. Keep up the good work, Teemu

1 0

mad: decode hdr error (with mp3-0.9.12)
by C.Y.M 26 Mar '05

26 Mar '05

When using mp3-0.9.12, I am noticing these messages in the log every time I play a mp3: mad: decode hdr error, frame=0 count=1: lost synchronization Is this a problem with libmad? Best Regards,

2 1

[BUG with PATCH] graphlcd-0.1.2-pre5 does not show channel info after startup
by Wolfgang Fritz 25 Mar '05

25 Mar '05

On my VDR (1.3.23), the graphlcd plugin does not show the channel name and logo after startup. When switching to another channel, name and logo are displayed correctly. Reason: graphlcd's display thread is not yet active when VDR calls the SetChannel() methods of all cStatus objects. Because graphlcd creates its cStatus object (cGraphLCDState) in the display thread, it misses the first SetChannel. Fix: 1. Move the plugin initialization from Start() to Initialize(). This makes it quite sure that the display thread is running at the first SetChannel. 2. In Start(), wait until the display thread is really active. On my system I have never seen a real wait here, but who knows... Patch is attached. Testers and feedback welcome. Wolfgang

1 0

Problem::Nexus-s 2.3::NTSC output
by Andrey Vlasov 25 Mar '05

25 Mar '05

Hi, I can not make Nexus-s 2.3 to work in NTSC mode. I have applied suggested patch --- dvb-kernel/linux/drivers/media/dvb/ttpci/av7110_av.c.orig 2005-02-17 11:30:15.000000000 -0800 +++ dvb-kernel/linux/drivers/media/dvb/ttpci/av7110_av.c 2005-02-17 11:32:50.000000000 -0800 @@ -1429,7 +1429,7 @@ void (*play[])(u8 *, int, void *) = { play_audio_cb, play_video_cb }; int i, ret; - av7110->vidmode = VIDEO_MODE_PAL; + av7110->vidmode = VIDEO_MODE_NTSC; for (i = 0; i < 2; i++) { struct ipack *ipack = av7110->ipack + i; but still experience the problem. I can not explain but it did work once and now I got same problem. Can anybody suggest what I should try else? Info: OS: Fedora Core 2 DVB driver: CVS VDR: 1.3.22 Plugins: remote rotor Location: North America/Canada Symptoms: rolling image on TV in B/W

1 0

RE: [vdr] vdr-xine: what's wrong with this piece of code -- threadingissue?
by Rantanen Teemu 25 Mar '05

25 Mar '05

Reinhard Nissl wrote: > But for any reason, "r == 0" happens still without the FIFO beeing closed. > Can someone tell me, how to handle this situation properly? It shouldn't be possible to read zero bytes from a file descriptor unless it's been set to nonblocking mode. In my opinion FIFOs are evil relics from stone age... Have you looked at networking patch for xine plugin? What it basically does is it replaces FIFOs with sockets. When xine is run on the same machine as VDR, then there's really not much difference between the FIFO behaviour (except that sockets do behave little nicer in my opinion), but it also allow you to run xine on a different machine than VDR. Anyway, in the xine-network version it was possible to get into deadlock depending on which part of code was running as the connection to xine was broken. I fixed it with this patch: http://tvr.dy.fi/xine-0.7.2-network-DeadLockFix.diff I could assume the same deadlock happens with FIFOs also unless read()=0 is handled. What do you think about integrating network -patch into xine-plugin? Teemu

2 1

Can't find PIDs converting to PS (with libdvb-0.5.5.1)
by C.Y.M 25 Mar '05

25 Mar '05

With the latest libdvb-0.5.5.1, I am no longer able to convert native vdr files to ps streams with the follow command: cat 00*.vdr|pes2ts2 0 0|ts2ps 0 0 > ~/file.ps pes2ts2 ts2ps Can't find PIDs Note: libdvb-0.5.5 works fine. Best Regards,

1 0

vdr-xine: what's wrong with this piece of code -- threading issue?
by Reinhard Nissl 25 Mar '05

25 Mar '05

Hi, I'm facing a deadlock situation, when the below code is modified to ignore the "r == 0" cases (= original code in vdr-xine-0.7.2): int cXineLib::xread(int f, void *b, int n) { bool atEOF = false; int t = 0; while (t < n) { void (* const sigPipeHandler)(int) = ::signal(SIGPIPE, SIG_IGN); errno = 0; int r = ::read(f, ((char *)b) + t, n - t); int myErrno = errno; ::signal(SIGPIPE, sigPipeHandler); if (r < 0 || (r == 0 && atEOF)) { if (EAGAIN == myErrno) continue; fprintf(stderr, "lib::read(%d) failed (atEOF: %d) %d: ", n, atEOF, myErrno); errno = myErrno; perror(""); disconnect(); return r; } else if (r == 0) { cPoller Poller(f); atEOF = Poller.Poll(0); fprintf(stderr, "--- lib read 0, atEOF %d\n", atEOF); } else atEOF = false; t += r; } return t; } Some more information: - Filedescriptor "f" represents a FIFO, which is opend for reading and should be in blocking mode by design. - As this function is called by different threads (synchronized outside via mutex), I save and restore the handler for signal SIGPIPE, as I don't want any of VDR's signal handlers to be triggered. The read() should block until data is available and typically return the number of bytes read, which should be greater than zero. But there are some cases, where read() returns zero: a) the writing side of the FIFO was closed. b) a signal caused the block to break. The original code simply ignores the result of zero, as for case a) a different function (xwrite), which should be called by a different thread, should see a SIGPIPE and initiate the disconnect(). Case b) should simply go on with reading the remaining data. But this leads to a deadlock situation where the read() never returns anything != 0 and therefore the original loop spins forever. This is most likely to trigger if you move cutting marks (on my machine it only triggers when xine uses -V xshm and when moving cutting marks in HDTV recordings). The new code above tries to detect case a) by asking a cPoller, whether data is available on file descriptor f, after the read returned 0. Let's assume, the Poll() returns true, because data is available: atEOF is set pessimistically but the next read() should return anything > 0, which resets atEOF. The loop continues. When the Poll() returns false as there is no further data available, the next read() should block. The loop continues. But the Poll() might return true in an error condition (e. g. the writing side of the FIFO was closed). Then the next read() is expected to return anything <= 0. The loop terminates and a disconnect() happens. The strange thing is now, that a disconnect() happens occationally when moving cutting marks. Any help appreciated! Thanks! Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr