Re: [vdr] How to demux H.264 recording ?
Gregoire Favre schrieb: > Hello, > > i have just recorded one of the best movie from the Switzerland in H.264 > on Swiss HD channel :-) > > The quality is really good and I would like to keep de and fr AC3 (I > don't care about the en/it audio). > > Anyone know which tools are available to do it ? > > Thank, > Hi, I think there is no tool available for the PES recordings. ProjectX does not support H.264 at all, and the windows Tools xport and tsremuxer also don´t work. That´s why I also vote for TS as recording format :) Maybe there is any MPlayer option, but the question remains if Audio & Video are being synced - with xport (and DVBViewer TS recordings) it works. With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to demux H.264 recording ?
Gregoire Favre schrieb: > i have just recorded one of the best movie from the Switzerland in H.264 > on Swiss HD channel :-) > > The quality is really good and I would like to keep de and fr AC3 (I > don't care about the en/it audio). > > Anyone know which tools are available to do it ? The only tool I can name off the top of my head is the rather inappropriately named avidemux, but I'm not sure how good it is at audio/video sync. The learning curve seems pretty steep, at least. -- /* * * Otto J. Makela <[EMAIL PROTECTED]> * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ct 26/07: TT FullFeatured h264?
In ct 26/2007 p150 it is said that full featured cards allmost vanished after almost everybody had more than enought cpu power available. But they see a renaissance since even a lot of new pc are not strong enough for h264. They state that Techno Trend has announced such an aktive card (defined before as one with hardware decoder) for next spring! Does anyone know more? Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ct 26/07: TT FullFeatured h264?
[EMAIL PROTECTED] schrieb: > In ct 26/2007 p150 it is said that full featured cards allmost vanished after > almost everybody had more than enought cpu power available. But they see > a renaissance since even a lot of new pc are not strong enough for h264. > > They state that Techno Trend has announced such an aktive card (defined > before > as one with hardware decoder) for next spring! > > Does anyone know more? > Yes - see (german) vdrportal in HDTV section - discussion is allready ongoing for more then a year now i think. Means that it comes "soon to market" allready since a while. Reel extension is some steps further allready ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [patch] avoid inheritance of file descriptors
Hi,
I think there is a problem in calling external programs from plugins. If
such a program takes some while for execution (even in background) it
gets inherited all file descriptors of VDR. This prevents vdr from
zapping to another channel or even from restarting properly. You will
see messages like:
ERROR: /dev/dvb/adapter0/dvr0: Device or resource busy
or
ERROR (svdrp.c,84): Address already in use
Reason: By default unix inherits all file descriptors to child processes
when calling exec*(...) or system(...). You can avoid this by setting
FD_CLOEXEC on all file descriptors that should not be inherited.
Patch:
--- dvbdevice.c~2007-12-10 15:19:51.116943936 +0100
+++ dvbdevice.c 2007-12-10 15:19:51.120944682 +0100
@@ -63,6 +63,7 @@
int fd = open(FileName, Mode);
if (fd < 0 && ReportError)
LOG_ERROR_STR(FileName);
+ fcntl(fd, F_SETFD, FD_CLOEXEC);
return fd;
}
--- svdrp.c~2007-12-10 15:20:12.476929058 +0100
+++ svdrp.c 2007-12-10 15:20:12.480929804 +0100
@@ -91,7 +91,7 @@
LOG_ERROR;
return false;
}
- oldflags |= O_NONBLOCK;
+ oldflags |= O_NONBLOCK|FD_CLOEXEC;
if (fcntl(sock, F_SETFL, oldflags) < 0) {
LOG_ERROR;
return false;
Comments, ideas? I would be happy to see this little patch applied to
1.4 and 1.5 trunks of VDR.
Deti
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR and UPnP server
Hi, I am looking for a UPnP server that can stream VDR's recordings in my network. Has any work already started ? I read a couple of emails on this topic but those were sent two years ago. I am interested to hear what others have already done in this regard. Thanks, Sundararaj ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
On 12/10/07 15:28, Deti Fliegl wrote: > Hi, > > I think there is a problem in calling external programs from plugins. If > such a program takes some while for execution (even in background) it > gets inherited all file descriptors of VDR. This prevents vdr from > zapping to another channel or even from restarting properly. You will > see messages like: > > ERROR: /dev/dvb/adapter0/dvr0: Device or resource busy > or > ERROR (svdrp.c,84): Address already in use > > Reason: By default unix inherits all file descriptors to child processes > when calling exec*(...) or system(...). You can avoid this by setting > FD_CLOEXEC on all file descriptors that should not be inherited. > > Patch: > ... > Comments, ideas? Doesn't SystemExec() (see tools.c) take care of this? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Klaus Schmidinger wrote: > Doesn't SystemExec() (see tools.c) take care of this? Yes you are right - it takes care internally but not for plugins like dvdswitch etc. In order to fix this problem you could patch every single plugin or just set the right file descriptor flag once. I think the latter does not cause any interference and should solves some issues. Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Deti Fliegl wrote: > Klaus Schmidinger wrote: >> Doesn't SystemExec() (see tools.c) take care of this? > Yes you are right - it takes care internally but not for plugins like > dvdswitch etc. In order to fix this problem you could patch every single > plugin or just set the right file descriptor flag once. I think the > latter does not cause any interference and should solves some issues. For the record, the latter creates a small race condition: an external program could be launched before FD_CLOEXEC is set on an fd. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Anssi Hannula wrote: > Deti Fliegl wrote: >> Klaus Schmidinger wrote: >>> Doesn't SystemExec() (see tools.c) take care of this? >> Yes you are right - it takes care internally but not for plugins like >> dvdswitch etc. In order to fix this problem you could patch every single >> plugin or just set the right file descriptor flag once. I think the >> latter does not cause any interference and should solves some issues. > > For the record, the latter creates a small race condition: an external > program could be launched before FD_CLOEXEC is set on an fd. In VDR all file descriptors seem to be allocated at startup. IMHO it is not very likely that a race condition could happen. Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Deti Fliegl wrote: > Anssi Hannula wrote: >> Deti Fliegl wrote: >>> Klaus Schmidinger wrote: Doesn't SystemExec() (see tools.c) take care of this? >>> Yes you are right - it takes care internally but not for plugins like >>> dvdswitch etc. In order to fix this problem you could patch every single >>> plugin or just set the right file descriptor flag once. I think the >>> latter does not cause any interference and should solves some issues. >> For the record, the latter creates a small race condition: an external >> program could be launched before FD_CLOEXEC is set on an fd. > In VDR all file descriptors seem to be allocated at startup. IMHO it is > not very likely that a race condition could happen. ... except on dvr devices, I know. Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
On 12/10/07 21:07, Deti Fliegl wrote: > Klaus Schmidinger wrote: >> Doesn't SystemExec() (see tools.c) take care of this? > Yes you are right - it takes care internally but not for plugins like > dvdswitch etc. In order to fix this problem you could patch every single > plugin or just set the right file descriptor flag once. I think the > latter does not cause any interference and should solves some issues. Plugins can call SystemExec() just as well when the want to execute an external program. IMHO it is no feasible solution to expect every file handle to be opened with FD_CLOEXEC. Even if VDR itself would do this, there could still be plugins that don't. I'd say if some plugin wants to run an external program, it needs to take care by itself that all unneeded file handles are closed. That's what SystemExec() is for. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
I demand that Deti Fliegl may or may not have written... > Anssi Hannula wrote: >> Deti Fliegl wrote: >>> Klaus Schmidinger wrote: Doesn't SystemExec() (see tools.c) take care of this? >>> Yes you are right - it takes care internally but not for plugins like >>> dvdswitch etc. In order to fix this problem you could patch every single >>> plugin or just set the right file descriptor flag once. I think the >>> latter does not cause any interference and should solves some issues. >> For the record, the latter creates a small race condition: an external >> program could be launched before FD_CLOEXEC is set on an fd. > In VDR all file descriptors seem to be allocated at startup. IMHO it is > not very likely that a race condition could happen. >From open(2): O_CLOEXEC (Since Linux 2.6.23) Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid an additional fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag. Addi- tionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race condi- tions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2). No use *now*, I know - too many people not yet using a new-enough kernel... -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Kill all extremists! Vote Anarchist. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Klaus Schmidinger wrote: > Plugins can call SystemExec() just as well when the want to execute > an external program. Yes, but would you point every single developer on this issue? > IMHO it is no feasible solution to expect every file handle to > be opened with FD_CLOEXEC. Even if VDR itself would do this, there > could still be plugins that don't. It is enough to let VDR set this flag on its own file handles - the main problem is that while an external script/program is running and because of inherited DVB handles - zapping is blocked - a restart of VDR is impossible. > I'd say if some plugin wants to run an external program, it needs > to take care by itself that all unneeded file handles are closed. > That's what SystemExec() is for. Whatever - if you don't see the point I cannot help. Deti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
