[vdr] Re: VDR-1.7.7 Video aspect ratios (was: [ANNOUNCE] VDR developer version 1.7.7)
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
Anyway, I'm not very fond of this new interface addition. After a little
playing with xineliboutput plugin in the past, the OSD scaling to video
size is a total mess and hence the HUD mode was developed, where the
OSD resolution is the same as the output resolution and the video is
scaled to that resolution. I'd strongly suggest to implement
cDevice::GetOSDSize(), so the output plugins can correctly set their
OSD resolution with minimal scaling artefacts.
Of course, you could misuse the current GetVideoSize always to result an
output (OSD) resolution, but that would break i.e. all skin plugins that
will certaily make use of this new method.
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 little bugs report
On 05/03/09 10:06, marti...@embl.de wrote: Using VDR 1.7.6 1) On 7 East, there are hannels with two audio shown as TUR, and ORJ (Tur for Turkish and Orj for original language) Default audio is Tur and in the OSD settings it is not possible to give Orj a higher priority as it is no t in the list of languages. Well, orj is not an actual language ;-) What you could try is to add orj to const char *LanguageCodeList[] in i18n.c and see if that helps. -- Thanks Klaus, That works perfect! Any chance it can be added to the core as orj is a kind of virtual language and in most cases it does equal to English... Also one little thing that is driving me crazy. My 3 years old daughter presses accidentally the Pause button and starts al l sort of instant recordings silenty, my wife then complains vdr is broken because she can´t change channels. What I am asking for is for some possibility to make the instant recording ask for confirmation before starting the instant recording. The problem is even worse as we could actually be watching a DVD or an .avi file outside vdr (but with vdr running in the background to allow for recordings and so on) and pause the movie and lirc always helpful will send the pause comm and to vdr as well so I end up with even more undesired recordings. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 little bugs report
Quoting marti...@embl.de: Also one little thing that is driving me crazy. My 3 years old daughter presses accidentally the Pause button and starts al l sort of instant recordings silenty, my wife then complains vdr is broken because she can´t change channels. What I am asking for is for some possibility to make the instant recording ask for confirmation before starting the instant recording. My 1.5 years old son and my 3 years old daughter would do the same, but I have found an easy workaround. I put the remote control out of their reach. Gerald This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
Rolf Ahrenberg a écrit :
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
16:10 is also a common device aspect ratio these days ;-)
Anyway, I'm not very fond of this new interface addition. After a little
playing with xineliboutput plugin in the past, the OSD scaling to video
size is a total mess and hence the HUD mode was developed, where the
OSD resolution is the same as the output resolution and the video is
scaled to that resolution. I'd strongly suggest to implement
cDevice::GetOSDSize(), so the output plugins can correctly set their
OSD resolution with minimal scaling artefacts.
I strongly second that. Add the fact that some (most ?) of the channels
here mess / cheat with aspect ratio / resolution, and I currently (VDR
1.6, SDTV, xineliboutput) have a unextricable aspect/resolution/OSD
problem. I'm not even trying to solve it...
I'd also suggest the maximum OSD size is 1920x1200 instead of 1920x1080,
as this 16:10 resolution is very common in computer land. That's also
the maximum a DVI single link can output.
--
NH
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
On Mon, 4 May 2009, Nicolas Huillard wrote:
Rolf Ahrenberg a écrit :
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
16:10 is also a common device aspect ratio these days ;-)
Well, those values (taken from H.264 specs) were for the video aspect
ratio and not the output aspect ratio. IIRC, the H.264 contains also so
called extended aspect ratio, that could contain almost anything.
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
On Mon, 4 May 2009, Falk Spitzberg wrote: The OSD should adopt to the size of the video material. If that is scaled to some non TV screen size, the OSD is scaled by the same factor. I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
and what about anamorphic material? A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to 16:9 to look ok (no egg-heads). Wouldn't it be correct also to draw the OSD anamorphic so that is not screached by the TV? Did you get the point? It's somehow difficult to describe this topic for me. Regards, Matthias 2009/5/4 Rolf Ahrenberg rahre...@cc.hut.fi: On Mon, 4 May 2009, Falk Spitzberg wrote: The OSD should adopt to the size of the video material. If that is scaled to some non TV screen size, the OSD is scaled by the same factor. I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
Off-topic question: Are there any (free) EDID binary data editors available that are able to edit the CEA block http://en.wikipedia.org/wiki/EDID#Extension_Block_Details ? I'd like to disable 1080i modes from my EDID via CustomEDID option to avoid Nvidia drivers to use them as back-end resolution for scaling all modes on my HD-Ready LCD TV. 720p modes give best visual result but latest Nvidia driver's artificial intelligence decides that 1080i is best for me :^( I'm too lazy to decode, encode and compute checksum for the block by hand :^) BR, Seppo Artem Makhutov wrote: Adding the CustomEDID DFP-0:/etc/X11/LG-edid.bin option solved everything for me. Now the X-Server starts with the native LCD-TV resolution, even when the TV is turned off. Regards, Artem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
Am Montag, den 04.05.2009, 14:13 +0200 schrieb Nicolas Huillard:
Rolf Ahrenberg a écrit :
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
16:10 is also a common device aspect ratio these days ;-)
It may be a common aspect ratio for display devices, but not for video
material. Movies and TV shows are mostly produced in 4:3, 16:9 or
2.21:1.
The OSD should adopt to the size of the video material. If that is
scaled to some non TV screen size, the OSD is scaled by the same factor.
Anyway, I'm not very fond of this new interface addition. After a little
playing with xineliboutput plugin in the past, the OSD scaling to video
size is a total mess and hence the HUD mode was developed, where the
OSD resolution is the same as the output resolution and the video is
scaled to that resolution. I'd strongly suggest to implement
cDevice::GetOSDSize(), so the output plugins can correctly set their
OSD resolution with minimal scaling artefacts.
I strongly second that. Add the fact that some (most ?) of the channels
here mess / cheat with aspect ratio / resolution, and I currently (VDR
1.6, SDTV, xineliboutput) have a unextricable aspect/resolution/OSD
problem. I'm not even trying to solve it...
I'd also suggest the maximum OSD size is 1920x1200 instead of 1920x1080,
as this 16:10 resolution is very common in computer land. That's also
the maximum a DVI single link can output.
--
Falk
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.7
On 03.05.2009 23:09, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Yes, sorry, was a typo.
Reinhard Nissl already notified my about it ;-)
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
On 04.05.2009 08:00, Rolf Ahrenberg wrote:
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
Anyway, I'm not very fond of this new interface addition. After a little
playing with xineliboutput plugin in the past, the OSD scaling to video
size is a total mess and hence the HUD mode was developed, where the
OSD resolution is the same as the output resolution and the video is
scaled to that resolution. I'd strongly suggest to implement
cDevice::GetOSDSize(), so the output plugins can correctly set their
OSD resolution with minimal scaling artefacts.
Of course, you could misuse the current GetVideoSize always to result an
output (OSD) resolution, but that would break i.e. all skin plugins that
will certaily make use of this new method.
Looks like the name of this function wasn't very well chosen, sorry.
It's probably best to go for a
cDevice:GetOsdSize(int Width, int Height, double Aspect);
through which the output device can tell VDR which size the OSD
shall have, and Aspect being a double value allows the device to
give VDR a hint whether the OSD shall be stretched (default
is 1.0, and it's not mandatory that the OSD actually uses this hint).
The existing GetVideoSize() could still be left in there, returning
the actual video size of the displayed matierial, which might be
displayed by some plugin.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] logo for vdr-xinelibout
hi
the logo from xinelibout is distorted in the upper left corner.
so i make a patch witch is transparent and in korrect aspect
ratio.
see attached patch.
stefandiff -urNad vdr-plugin-xineliboutput-1.0.0~rc2~/vdrlogo_32x32.c vdr-plugin-xineliboutput-1.0.0~rc2/vdrlogo_32x32.c
--- vdr-plugin-xineliboutput-1.0.0~rc2~/vdrlogo_32x32.c 2007-06-16 19:39:19.0 +0200
+++ vdr-plugin-xineliboutput-1.0.0~rc2/vdrlogo_32x32.c 2007-06-16 19:40:31.0 +0200
@@ -17,204 +17,124 @@
unsigned char pixel_data[32 * 32 * 4 + 1];
} vdrlogo_32x32 = {
32, 32, /*4,*/
- \375\375\374\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\374\377\375\375\375\377\375\375\374\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\366\363\370\377\365\362\367\377\374\374\373\377\375\375
- \374\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\373\377\374\374\375\377\366\362
- \371\377\365\361\367\377\365\361\370\377\365\361\367\377\367\363\372\377
- \374\372\375\377\370\367\370\377\364\361\370\377\364\361\367\377\365\361
- \367\377\365\361\367\377\365\361\367\377\365\361\367\377\365\361\367\377
- \366\362\370\377\373\371\374\377\374\375\375\377\375\375\375\377\375\375
- \375\377\375\375\375\377\210s\245\377Q0\177\377\336\326\346\377\376\374\374
- \377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375
- \375\375\377\375\375\374\377\370\365\371\377\233\207\265\377T3\204\377O.
- \201\377O.\201\377O.\201\377T4\205\377nQ\224\377\245\221\276\377eN\207\377
- O.\202\377O-\201\377O-\201\377O.\201\377O.\201\377O-\201\377Q1\203\377iK
- \221\377\270\247\311\377\372\371\374\377\375\375\375\377\375\375\375\377
- \241\216\271\377:\17x\377\256\235\303\377\375\375\374\377\375\375\375\377
- \375\375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\374
- \373\377\236\214\270\377;\21x\377:\17w\377:\17w\377;\16w\377:\17y\377:\17
- z\377:\17z\377\23w\377kQ\221\377C\37x\377:\17x\377:\17x\377:\17x\377:\17
- x\377:\17x\377:\17w\377:\17w\377;\24v\377\264\245\311\377\374\374\375\377
- \375\375\374\377\316\303\332\377:\20x\377\205k\246\377\375\375\375\377\375
- \375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\375\375\375
- \377\352\345\360\377C\35{\377:\20u\377\33j\377\c\377\c\377\e\377:
- \40e\3779\26n\377;\17x\377\27w\377v_\230\377A*c\377B,d\377C-e\377D.e\377
- E/f\377D-g\377;\31k\377:\17z\377R2\204\377\367\364\371\377\375\375\375\377
- \363\356\367\377A\32z\377\\;\213\377\373\372\374\377\375\375\375\377\375
- \375\375\377\375\375\375\377\375\375\375\377\375\375\375\377\264\244\310
- \377:\20w\...@\i\377K1o\377\306\303\312\377\313\311\315\377\312\311\315
- \377\304\302\306\377\237\230\252\377K-u\377;\17x\377pT\231\377\332\327\333
- \377\334\333\334\377\336\336\335\377\340\337\337\377\342\340\340\377\336
- \336\337\377\256\246\270\377B\40u\3779\20x\377\313\302\331\377\375\375\375
- \377\375\373\375\377dD\221\377?\31w\377\355\351\362\377\375\375\375\377\375
- \375\375\377\375\375\375\377\375\375\375\377\375\375\373\377\211o\252\377
- ;\24q\377Cn\377\31s\377\354\351\356\377\375\375\374\377\375\375\375\377
- \375\375\375\377\375\375\375\377\310\301\323\377\27v\377?\32y\377\352\344
- \357\377\375\376\374\377\375\375\374\377\375\375\374\377\375\375\374\377
- \375\375\374\377\374\374\374\377\223}\261\377:\16y\377\236\214\265\377\375
- \375\374\377\375\375\375\377\220y\257\377:\20v\377\312\300\327\377\375\375
- \375\377\375\375\375\377\375\375\375\377\375\375\374\377\374\374\375\377
- \\:\214\377G)p\377P/\204\377=\30t\377\353\351\355\377\375\375\375\377\375
- \375\374\377\374\374\374\377\374\374\373\377\374\373\374\377w^\234\3778\20
- z\377\266\251\312\377\375\375\374\377\375\375\375\377\375\375\375\377\375
- \375\375\377\375\375\375\377\375\375\374\377\304\267\323\377;\17x\377\201
- m\236\377\375\375\374\377\375\375\375\377\274\257\316\377:\17y\377\240\217
- \271\377\375\375\372\377\375\375\375\377\375\375\375\377\375\375\375\377
-
Re: [vdr] VDR-1.7.7 Video aspect ratios
Matthias Becker a écrit : and what about anamorphic material? A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to 16:9 to look ok (no egg-heads). Wouldn't it be correct also to draw the OSD anamorphic so that is not screached by the TV? Did you get the point? It's somehow difficult to describe this topic for me. With today's pixel-displays, we'd like to avoid all scaling, stretching, etc. done by the panel itself. ie. like Rolf said, always output from the computer at panel resolution, with 1:1 pixel mapping. Video would be scaled, but not the OSD. Regards, Matthias 2009/5/4 Rolf Ahrenberg rahre...@cc.hut.fi: On Mon, 4 May 2009, Falk Spitzberg wrote: The OSD should adopt to the size of the video material. If that is scaled to some non TV screen size, the OSD is scaled by the same factor. I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
I keep seeing mention of people using computer monitors and that VDR should be designed to accommodate their aspect ratios. I'd like to point out that plenty of users don't use VDR with a computer monitor at all. Like many others, I have an hdtv (60 in my case) and would love to have an osd that 1920x1080 always, regardless of the content I'm watching. Why? Because my tv can handle it so why not? My main VDR box is in my living room, tucked away behind my tv with no keyboard, no mouse, no monitor, no anything. I do have a test box connected to a 19 monitor but certainly our primary VDR use is on a real tv so that's where our main concern/interests are. I'm not sure what the best way to deal with this situation is but I strongly urge patience and proper design so nothing is force while looking ok for some people but like crap for others. Not everyone uses computer monitors for their output device, and not everyone uses a tv (of whatever size/aspect ratio). Surely there's a sane reasonable solution that works for *. Maybe some user settings are required so people can tweak the osd to look good with their specific display type? Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] xxv-1.3 - Feature release (1.4 rc)
Hello Joerg, Am Sonntag, den 03.05.2009, 21:13 +0200 schrieb Joerg Bornkessel: My 2 channels on TeleColumbus in Berlin are encrypted on my system. Maybe this channels are filtered. See inside xxv - Setting Channels FilterCA Also, plz can you check the wml part for xxv mobile, Please try SVN-Release 1413, i have ported to some changes from modul HTTPD to modul WAP. But WML himself is a little bit of outdated. ;-) A native optimized XML-(HTTP)-Skin should better usable on smartphone. Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Black screen on some channels with vdr 1.7.6
It's a pity, no answer. I would like to note, that with vdr 1.7.7 is result same-NO video but audio is OK. Receiving these channels with sat boxes like dreambox or triple dragon is without problem. Thanks for any suggestions. BR Marky -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Marek Hajduk Sent: Friday, May 01, 2009 11:30 AM To: vdr@linuxtv.org Subject: Re: [vdr] Black screen on some channels with vdr 1.7.6 Marek Hajduk píše v Út 28. 04. 2009 v 23:07 +0200: Hi, On some channels I get only audio. Screen is still black without Picture. There are two encrypted channels from 19.2E, in UPC packet: AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=1:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 Spektrum,Spektrum;UPC Direct:11671:hC56M2O0S0:S19.2E:22000:401=1:410=hun,411=cze:420:D02,1815:20360:1:1031:0 I am using eHD, but with VDPAU and xine is result same = black screen. When I try to record thease channels, recording has 0 kB. However, I can watch thease channels through streamdev plugin and popcornhour or vlc, but Picture has lot of errors. Here is recording through streamdev plugin. Download link: http://rapidshare.com/files/226876888/1220.ts If somebody will want to fix it, I can provide some more debug info. Regards Marky Hi again, I checked this recording with TS Doctor and I get this continuing errors: TS ERROR: Invalid paket xxx! Error: sync_byte_error Resync found for next paket yy with offset: -zzz. Maybe it helps. BR Marky ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Black screen on some channels with vdr 1.7.6
On 04.05.2009 23:05, Marek Hajduk wrote: It's a pity, no answer. I would like to note, that with vdr 1.7.7 is result same-NO video but audio is OK. Receiving these channels with sat boxes like dreambox or triple dragon is without problem. '1' is not a known video stream type in VDR. Try '2' or '27', as in AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=2:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 or AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=27:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 Klaus -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Marek Hajduk Sent: Friday, May 01, 2009 11:30 AM To: vdr@linuxtv.org Subject: Re: [vdr] Black screen on some channels with vdr 1.7.6 Marek Hajduk píše v Út 28. 04. 2009 v 23:07 +0200: Hi, On some channels I get only audio. Screen is still black without Picture. There are two encrypted channels from 19.2E, in UPC packet: AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=1:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 Spektrum,Spektrum;UPC Direct:11671:hC56M2O0S0:S19.2E:22000:401=1:410=hun,411=cze:420:D02,1815:20360:1:1031:0 I am using eHD, but with VDPAU and xine is result same = black screen. When I try to record thease channels, recording has 0 kB. However, I can watch thease channels through streamdev plugin and popcornhour or vlc, but Picture has lot of errors. Here is recording through streamdev plugin. Download link: http://rapidshare.com/files/226876888/1220.ts If somebody will want to fix it, I can provide some more debug info. Regards Marky Hi again, I checked this recording with TS Doctor and I get this continuing errors: TS ERROR: Invalid paket xxx! Error: sync_byte_error Resync found for next paket yy with offset: -zzz. Maybe it helps. BR Marky ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Black screen on some channels with vdr 1.7.6
On Monday 04 of May 2009, Klaus Schmidinger wrote: On 04.05.2009 23:05, Marek Hajduk wrote: It's a pity, no answer. I would like to note, that with vdr 1.7.7 is result same-NO video but audio is OK. Receiving these channels with sat boxes like dreambox or triple dragon is without problem. '1' is not a known video stream type in VDR. Try '2' or '27', as in AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=2:660=hun,661=cze,662=eng:0:D02,18 15:20352:1:1063:0 or AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=27:660=hun,661=cze,662=eng:0:D02,1 815:20352:1:1063:0 Klaus Many thanks, it seems to works (with type of 2), but it is necessary to set Update channels to no. BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Black screen on some channels with vdr 1.7.6
Many Thanks, Klaus. It works. I will try to record several seconds, because picture has errors. once again, thanks for help. BR Marky Klaus Schmidinger píše v Po 04. 05. 2009 v 23:34 +0200: On 04.05.2009 23:05, Marek Hajduk wrote: It's a pity, no answer. I would like to note, that with vdr 1.7.7 is result same-NO video but audio is OK. Receiving these channels with sat boxes like dreambox or triple dragon is without problem. '1' is not a known video stream type in VDR. Try '2' or '27', as in AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=2:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 or AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=27:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 Klaus -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Marek Hajduk Sent: Friday, May 01, 2009 11:30 AM To: vdr@linuxtv.org Subject: Re: [vdr] Black screen on some channels with vdr 1.7.6 Marek Hajduk píše v Út 28. 04. 2009 v 23:07 +0200: Hi, On some channels I get only audio. Screen is still black without Picture. There are two encrypted channels from 19.2E, in UPC packet: AXN,AXN;UPC Direct:10921:hC56M2O0S0:S19.2E:22000:651=1:660=hun,661=cze,662=eng:0:D02,1815:20352:1:1063:0 Spektrum,Spektrum;UPC Direct:11671:hC56M2O0S0:S19.2E:22000:401=1:410=hun,411=cze:420:D02,1815:20360:1:1031:0 I am using eHD, but with VDPAU and xine is result same = black screen. When I try to record thease channels, recording has 0 kB. However, I can watch thease channels through streamdev plugin and popcornhour or vlc, but Picture has lot of errors. Here is recording through streamdev plugin. Download link: http://rapidshare.com/files/226876888/1220.ts If somebody will want to fix it, I can provide some more debug info. Regards Marky Hi again, I checked this recording with TS Doctor and I get this continuing errors: TS ERROR: Invalid paket xxx! Error: sync_byte_error Resync found for next paket yy with offset: -zzz. Maybe it helps. BR Marky ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
