[vdr] Feature suggestion: @include in channels.conf
Hi guys, I'm currently working on integrating my VDR setup with the commercial kartina.tv offering (found no workable reference so I'm doing it myself - will be documented at http://vdr-wiki.de/wiki/index.php/Kartina.tv_mit_IPTV). Because the channel list may be modified by the provider every now and then, and VDR cannot know anything about it, the channels.conf file needs to be rebuilt frequently outside of VDR (and reloaded on the next VDR restart). Since I'd like to see the kartina.tv channels at, say, @201, I have to parse the channels.conf file and insert the kartina.tv channels inbetween. This is cumbersome at best. It would be far easier if channels.conf could include other channels.conf files. Any ideas? I figure with more IPTV offerings on the horizon this is going to become more and more useful. -- Tomorrow will be cancelled due to lack of interest. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to convert a JPEG image to an HD video frame?
On 24.07.2011 21:07, André Weidemann wrote: Here are two simple lines to convert a jpg image to mpeg2: convert $Pict -background '#00' -resize 1920x1080 -gravity center -extent 1920x1080 /tmp/test.jpg ffmpeg -i /tmp/temp.jpg -an -vcodec mpeg2video -b 2500 -s 1920x1080 -qscale 2 -f mpeg2video $Mpeg Note: Depending on your distro, ffmpeg may not support mpeg2 video encoding. For mpeg4 the ffmpeg line looks like this: ffmpeg -i /tmp/temp.jpg -an -vcodec mpeg4 -b 2500 -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg For libx264 it looks like this: ffmpeg -i /tmp/temp.jpg -an -vcodec libx264 -vpre lossless_ultrafast -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg Note that -f mp4 means the output is not raw mpeg-4/H.264 but in the mp4 file format. For raw video (like mpeg2video in your first example), for MPEG-4 one can use -f m4v and for H.264 -f h264. The -vpre parameter requires a preset. They can usually be found under /usr/share/ffmpeg/libx264-*.ffpreset. If you want a 10 second video at 25 fps, you can do it like this: ffmpeg -loop_input -t 10 -r 25 -i /tmp/temp.jpg -an -vcodec mpeg4 -b 2500 -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg You may want to adjust the number of threads according to the number of cores in your machine. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
I've done some further investigation and as far as I can tell the problem appears to be with the value returned by cDiseqc::Codes in diseqc.c. The return value changed from 'uchar' to 'const uchar' between 1.7.18 and 1.7.19 and the returned value now always points to the last diseqc code in the string. The following trace from 1.7.19 shows the problem: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137345561 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137345580 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137345599 to : W15 T Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 The identical trace from 1.7.18 which works correctly looks like this: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137333177 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4 Sending Diseqc command: E0 10 38 F4 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137333196 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01 Sending Diseqc command: E0 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137333215 to : W15 T Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 I have tried to revert cDiseqc::Codes in 1.7.19 to the 1.7.18 version but the extent of the changes introduced to 1.7.19 in this area eventually defeated my limited C++ skills. In doing so I have learnt and read a lot and it appears that there are some pitfalls in returning 'const' values. I suspect that this is the problem here but can't be sure. If someone could have a look at this and suggest how to fix it, it would be much appreciated. Thanks, Mark. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature suggestion: @include in channels.conf
Am 25.07.2011 11:17, schrieb Harald Milz: Because the channel list may be modified by the provider every now and then, and VDR cannot know anything about it, the channels.conf file needs to be rebuilt frequently outside of VDR (and reloaded on the next VDR restart). You know that you can modify the current channel list by the SVDRP commands LSTC, MODC, MOVC, NEWC? You just need a way to distinguish between 'your' channels and other channels, so you know which to update. It would be far easier if channels.conf could include other channels.conf files. How should this be preserved if VDR saves the channels.conf? How should changes to the included files be handled? What happens if I move a channel / all channels out of the included file into the main file? An include structure is more easily handled on files that only get read. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
I’ve done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.
The following trace from 1.7.19 shows the problem:
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
The identical trace from 1.7.18 which works correctly looks like this:
Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s) const:
int n = strtol(t, p, 16);
if (!errno p != t 0 = n n = 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be if (!parsing) instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Thanks Udo, that seems to have done the trick.
I guess Klaus will pick this up as a matter of course ...
Regards,
Mark.
-Original Message-
From: Udo Richter [mailto:udo_rich...@gmx.de]
Sent: Tuesday, 26 July 2011 5:19 AM
To: VDR Mailing List
Subject: Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
I've done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.
The following trace from 1.7.19 shows the problem:
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
The identical trace from 1.7.18 which works correctly looks like this:
Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s)
const:
int n = strtol(t, p, 16);
if (!errno p != t 0 = n n = 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be if (!parsing) instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
