[vdr] [iptv] [input_vdr] No data in 8 seconds, queuing no signal image
a.seppala+vdr at gmail.com
Sun May 3 11:16:54 CEST 2009
Paul Menzel wrote:
> Am Samstag, den 02.05.2009, 21:24 +0300 schrieb Antti Seppälä:
>> Do you know what encoding format your provider uses for the streams?
>> Play it with mplayer -v rtp://126.96.36.199:1234 to see the information.
> TRIED UP TO POSITION 321104, FOUND 47, packet_size= 188, SEEMS A TS? 1
Mplayer detects that your stream is transport stream, which is what vdr
> PARSE_PMT(28106 INDEX 0), STREAM: 0, FOUND pid=0x30 (48), type=0x10000005, ES_DESCR_LENGTH: 0, bytes left: 28
> ...descr id: 0xa, len=4
> Language Descriptor: deu
> PARSE_PMT(28106 INDEX 1), STREAM: 1, FOUND pid=0x31 (49), type=0x50, ES_DESCR_LENGTH: 6, bytes left: 17
> ...descr id: 0x56, len=10
> PARSE_PMT(28106 INDEX 2), STREAM: 2, FOUND pid=0x34 (52), type=0xffffffff, ES_DESCR_LENGTH: 12, bytes left: 0
This is the pid information vdr also requires in the channels.conf entry.
> Searching for picture parameter set... H264: 0x128
This means that the stream is using h264 encoding.
> I tried it with S0P0 and there was only a black screen shown and I could
> see the VDR menu on top of it. I also noticed the the following line was
> added to channels.conf. I do not know how it got there.
> Das Erste;ARD:10:IPTV|S0P0|UDP|188.8.131.52|1234:P:0:0:49=deu:52:0:28106:1:1019:0
The line was added by vdr when it detected that the stream is in the format it
supports. (Though I wonder if it shouldn't happen when disabling sid scanning
It also means that iptv plugin is working and the stream in rtp format
is really supported.
The entry contains 0 as the video pid which means that the channel is treated
like a radio channel.
> Changing to this channel with the up key, I could hear the audio, but
> instead of the video some kind of animation was shown. Those you can set
> up in your media players and which move to the audio.
This is what xineliboutput does when viewing a radio channel. It's called the
I think you are only missing h264 support from vdr core which could be the
reason why the video pid of the channel is set to zero.
A patch for adding h264 support to vdr 1.6 -series is included in this mailing
list post: http://www.linuxtv.org/pipermail/vdr/2008-March/016227.html
It's the vdr-1.5.18-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2
and it works for 1.6 even though the name suggests 1.5 version.
Vdr 1.7.x includes h264 support by default.
More information about the vdr